Anyone know what this means when running aptitude update?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Anyone know what this means when running aptitude update?

Mark Fletcher-2
Hello

When I run aptitude update I get, amongst the successful update reports,
the following error messages:

W: There is no public key available for the following key IDs:
1397BC53640DB551
W: Failed to fetch http://http.debian.net/debian/dists/jessie-backports/main/i18n/Translation-enIndex: Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.
E: Couldn't rebuild package cache

I'm not sure if the warning about the key and the second warning are
related or not, I've got my doubts.

My sources.list looks like this:

#

# deb cdrom:[Debian GNU/Linux wheezy-DI-a1 _Wheezy_ - Official Snapshot amd64 NETINST Binary-1 20120512-00:39]/ wheezy main

# deb cdrom:[Debian GNU/Linux wheezy-DI-a1 _Wheezy_ - Official Snapshot amd64 NETINST Binary-1 20120512-00:39]/ wheezy main

deb http://ftp.jp.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.jp.debian.org/debian/ jessie main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

deb http://ftp.jp.debian.org/debian/ jessie-updates main contrib non-free

deb http://www.deb-multimedia.org jessie main non-free


and files in sources.list.d add the following:

deb http://dl.google.com/linux/talkplugin/deb/ stable main

deb http://http.debian.net/debian/ jessie-backports main


I'm located in Japan, hence my (long-standing) use of the Japan Debian
mirror ftp.jp.debian.org for the mainstream stuff, but I came late to
the party of automatic mirror selection, hence my more-recently-added
jessie-backports using http.debian.net. Which seems to be having some
sort of problem...

I imagine jessie-backports is available on ftp.jp.debian.org, but rather
than camouflage the problem I'd like to understand and solve it.

Googling around the missing key ID, most of the solutions are for Ubuntu
and mention PPAs which are not a Debian thing. I am not sure where to go
to find the public key with that key ID, for the first warning, and I
really don't know how to interpret the second, if it is not caused by
the first (instinctively, I suspect not).

Any idea what is causing the warnings I consistently get on aptitude
update, and can anyone confirm that the errors that follow those
warnings are caused by the warnings and not indicative of something ELSE
being wrong?

Thanks

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Frank-13
Op 26-03-17 om 18:01 schreef Mark Fletcher:

> Hello
>
> When I run aptitude update I get, amongst the successful update reports,
> the following error messages:
>
> W: There is no public key available for the following key IDs:
> 1397BC53640DB551
> W: Failed to fetch http://http.debian.net/debian/dists/jessie-backports/main/i18n/Translation-enIndex: Hash Sum mismatch
> E: Some index files failed to download. They have been ignored, or old ones used instead.
> E: Couldn't rebuild package cache
>
> I'm not sure if the warning about the key and the second warning are
> related or not, I've got my doubts.

They're not. The key ID is a very well known issue (at least on the
forums), to do with google's repository. They started using a new key
last April and didn't tell anyone.
The hash sum mismatch is usually a passing issue: updating while the
repository/mirror itself is in the process of updating. If it keeps
showing up, that mirror is probably borked. Try deb.debian.org instead
of http.debian.net.

The key ID can be fixed in several ways. I usually suggest:

wget -qO- https://dl.google.com/linux/linux_signing_key.pub | sudo
apt-key add -

Alternatively:

sudo apt-key adv --keyserver keys.gnupg.net --recv-keys 1397BC53640DB551

Regards,
Frank

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Sven Hartge-5
Frank <[hidden email]> wrote:

> The hash sum mismatch is usually a passing issue: updating while the
> repository/mirror itself is in the process of updating. If it keeps
> showing up, that mirror is probably borked. Try deb.debian.org instead
> of http.debian.net.

deb.debian.org, http.debian.net and httpredir.debian.org are the same.
The old service behind http.debian.net and httpredir.debian.org were
switched off in February and the hostnames now point to the same system
backing deb.debian.org

> wget -qO- https://dl.google.com/linux/linux_signing_key.pub | sudo
> apt-key add -

No, please do NOT use "apt-key add" but instead download the key and put
it as a file with the suffix ".gpg" into the directory
/etc/apt/trusted.gpg.d/

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Nicholas Geovanis-2
On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <[hidden email]> wrote:
Frank <[hidden email]> wrote:

> wget -qO- https://dl.google.com/linux/linux_signing_key.pub | sudo
> apt-key add -

No, please do NOT use "apt-key add" but instead download the key and put
it as a file with the suffix ".gpg" into the directory
/etc/apt/trusted.gpg.d/

Hi -
Just curious why you recommend this instead of "apt-key add"?
Thanks.....Nick
 
Grüße,
Sven.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

recoverym4n
        Hi.

On Sun, 26 Mar 2017 13:56:54 -0500
Nicholas Geovanis <[hidden email]> wrote:

> On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <[hidden email]> wrote:
>
> > Frank <[hidden email]> wrote:
> >
> > > wget -qO- https://dl.google.com/linux/linux_signing_key.pub | sudo
> > > apt-key add -
> >
> > No, please do NOT use "apt-key add" but instead download the key and put
> > it as a file with the suffix ".gpg" into the directory
> > /etc/apt/trusted.gpg.d/
> >
>
> Hi -
> Just curious why you recommend this instead of "apt-key add"?

Because 'apt-key add' can add multiple keys with such invocation.
Downloading a public key to a file *and* reading it can prevent this.

Reco

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Sven Hartge-5
In reply to this post by Nicholas Geovanis-2
Nicholas Geovanis <[hidden email]> wrote:
> On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <[hidden email]> wrote:
>> Frank <[hidden email]> wrote:

>> No, please do NOT use "apt-key add" but instead download the key and
>> put it as a file with the suffix ".gpg" into the directory
>> /etc/apt/trusted.gpg.d/

> Just curious why you recommend this instead of "apt-key add"?

Because the man-page for apt-key says so:

,----
|  add filename
|      [...]
|      Note: Instead of using this command a keyring should be
|      placed directly in the /etc/apt/trusted.gpg.d/
|      directory with a descriptive name and either "gpg" or
|      "asc" as file extension.
`----

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Nicholas Geovanis-2
On Sun, Mar 26, 2017 at 2:11 PM, Sven Hartge <[hidden email]> wrote:
Nicholas Geovanis <[hidden email]> wrote:
> On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <[hidden email]> wrote:
>> No, please do NOT use "apt-key add" but instead download the key and
>> put it as a file with the suffix ".gpg" into the directory
>> /etc/apt/trusted.gpg.d/

> Just curious why you recommend this instead of "apt-key add"?

Because the man-page for apt-key says so:

,----
|  add filename
|      [...]
|      Note: Instead of using this command a keyring should be
|      placed directly in the /etc/apt/trusted.gpg.d/
|      directory with a descriptive name and either "gpg" or
|      "asc" as file extension.
`----

Thanks. FYI my Debian 8.4 apt-key man page does not contain that text.
ii  apt                                   1.0.9.8.3                            amd64        commandline package manager

 
Grüße,
Sven.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Sven Hartge-5
Nicholas Geovanis <[hidden email]> wrote:
> On Sun, Mar 26, 2017 at 2:11 PM, Sven Hartge <[hidden email]> wrote:
>> Nicholas Geovanis <[hidden email]> wrote:
>> > On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <[hidden email]> wrote:

>>>> No, please do NOT use "apt-key add" but instead download the key and
>>>> put it as a file with the suffix ".gpg" into the directory
>>>> /etc/apt/trusted.gpg.d/

>> Just curious why you recommend this instead of "apt-key add"?
>>
>> Because the man-page for apt-key says so:
>>
>> ,----
>> |  add filename
>> |      [...]
>> |      Note: Instead of using this command a keyring should be
>> |      placed directly in the /etc/apt/trusted.gpg.d/
>> |      directory with a descriptive name and either "gpg" or
>> |      "asc" as file extension.
>> `----


> Thanks. FYI my Debian 8.4 apt-key man page does not contain that text.
> ii  apt                                   1.0.9.8.3
>    amd64        commandline package manager

But it works. I converted all my systems two weeks ago from putting
everything into /etc/apt/trusted.gpg via "apt-key add -" to single files
in /etc/apt/trusted.gpg.d/, which allows me to handle the keys, addition
*and* removal, very easily via puppet.

Doing this with the one file is much more complicated, with the new
approach I just need to add or remove the GPG pubkey files to the
directory and everything works.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Mark Fletcher-2
In reply to this post by Sven Hartge-5
On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:

> Frank <[hidden email]> wrote:
>
> > The hash sum mismatch is usually a passing issue: updating while the
> > repository/mirror itself is in the process of updating. If it keeps
> > showing up, that mirror is probably borked. Try deb.debian.org instead
> > of http.debian.net.
>
> deb.debian.org, http.debian.net and httpredir.debian.org are the same.
> The old service behind http.debian.net and httpredir.debian.org were
> switched off in February and the hostnames now point to the same system
> backing deb.debian.org
>

This has been going on for weeks now, I have been hoping in vain that
the issue would clear itself, as Frank suggested, before I posted here.
It doesn't look like it is going to. So, are we saying that
deb.debian.org, http.debian.net and httpredir.debian.org, being the
same, are all "borked"? Doesn't feel right, more people would be up on
their hind legs yelling for footnotes if so, no?

The fix for the key ID issue looks straightforward though, thanks Frank
and others for that. I'll try out this
download-and-put-in-the-right-place approach, that's new to me. Should I
make efforts to remove the old key Google were previously using?

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Frank-13
Op 27-03-17 om 01:23 schreef Mark Fletcher:

> On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:
>> Frank <[hidden email]> wrote:
>>
>>> The hash sum mismatch is usually a passing issue: updating while the
>>> repository/mirror itself is in the process of updating. If it keeps
>>> showing up, that mirror is probably borked. Try deb.debian.org instead
>>> of http.debian.net.
>>
>> deb.debian.org, http.debian.net and httpredir.debian.org are the same.
>> The old service behind http.debian.net and httpredir.debian.org were
>> switched off in February and the hostnames now point to the same system
>> backing deb.debian.org
>>
>
> This has been going on for weeks now, I have been hoping in vain that
> the issue would clear itself, as Frank suggested, before I posted here.
> It doesn't look like it is going to. So, are we saying that
> deb.debian.org, http.debian.net and httpredir.debian.org, being the
> same, are all "borked"? Doesn't feel right, more people would be up on
> their hind legs yelling for footnotes if so, no?

Apparently the mirror that comes up is bad. Kind of disappointing the
deb.debian.org mechanism doesn't seem to work much better than the
httpredir. I used to use that until I noticed it wasn't always up to the
task, so I switched to ftp.nl.debian.org, which just works. For you,
ftp.jp.debian.org probably will as well.

> The fix for the key ID issue looks straightforward though, thanks Frank
> and others for that. I'll try out this
> download-and-put-in-the-right-place approach, that's new to me. Should I
> make efforts to remove the old key Google were previously using?

No need. That one is still in the key file you are going to download. To
be honest, I suggested what I did because those are a simple one-liners
and they work. I use /etc/apt/trusted.gpg.d myself, but my system is on
stretch and I wasn't sure about jessie.

Regards,
Frank

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Sven Hartge-5
In reply to this post by Mark Fletcher-2
Mark Fletcher <[hidden email]> wrote:
> On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:
>> Frank <[hidden email]> wrote:
 

>>> The hash sum mismatch is usually a passing issue: updating while the
>>> repository/mirror itself is in the process of updating. If it keeps
>>> showing up, that mirror is probably borked. Try deb.debian.org
>>> instead of http.debian.net.
>>
>> deb.debian.org, http.debian.net and httpredir.debian.org are the
>> same.  The old service behind http.debian.net and
>> httpredir.debian.org were switched off in February and the hostnames
>> now point to the same system backing deb.debian.org
>>

> This has been going on for weeks now, I have been hoping in vain that
> the issue would clear itself, as Frank suggested, before I posted
> here.

You may want to head over to https://lists.debian.org/debian-mirrors/
and report the issue there. This will get the attention of the right
people to diagnose and possibly fix the problems you are having.



--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Mark Fletcher-2
In reply to this post by Sven Hartge-5
On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:

> Frank <[hidden email]> wrote:
>
> > The hash sum mismatch is usually a passing issue: updating while the
> > repository/mirror itself is in the process of updating. If it keeps
> > showing up, that mirror is probably borked. Try deb.debian.org instead
> > of http.debian.net.
>
> deb.debian.org, http.debian.net and httpredir.debian.org are the same.
> The old service behind http.debian.net and httpredir.debian.org were
> switched off in February and the hostnames now point to the same system
> backing deb.debian.org
>

Well, switching from http.debian.net to deb.debian.org seems to have
fixed that one. The error relating to that has gone away.


> > wget -qO- https://dl.google.com/linux/linux_signing_key.pub | sudo
> > apt-key add -
>
> No, please do NOT use "apt-key add" but instead download the key and put
> it as a file with the suffix ".gpg" into the directory
> /etc/apt/trusted.gpg.d/
>
I downloaded the file from the above URL, and copied it as root to
/etc/apt/trusted.gpg.d as instructed. Since all the other files in that
directory were owned by root I made sure this one was too. And I renamed
it to add .gpg on the end. It seems to have made the problem noticeably
worse. On doing an aptitude update I now get:

W: GPG error: http://dl.google.com stable Release: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY A040830F7FAC5991 NO_PUBKEY 1397BC53640DB551
W: There is no public key available for the following key IDs:
CBF8D6FD518E17E1

Which is worse than it was before, it is now complaining about more keys.

Help...

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Frank-13
Op 27-03-17 om 17:14 schreef Mark Fletcher:
> Well, switching from http.debian.net to deb.debian.org seems to have
> fixed that one. The error relating to that has gone away.

Don't be surprised if it comes back. I think it may just have selected a
different mirror now, but you can't be certain it will always pick that one.

>>> wget -qO- https://dl.google.com/linux/linux_signing_key.pub | sudo
>>> apt-key add -
>>
>> No, please do NOT use "apt-key add" but instead download the key and put
>> it as a file with the suffix ".gpg" into the directory
>> /etc/apt/trusted.gpg.d/
>>
> I downloaded the file from the above URL, and copied it as root to
> /etc/apt/trusted.gpg.d as instructed. Since all the other files in that
> directory were owned by root I made sure this one was too. And I renamed
> it to add .gpg on the end.

That's for binary key files. This one is ascii armoured, so it needs an
.asc 'extension'.

> Which is worse than it was before, it is now complaining about more keys.

Let's try the proper extension first and see what that fixes.

Regards,
Frank

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Mark Fletcher-2
On Mon, Mar 27, 2017 at 06:06:05PM +0200, Frank wrote:
> Op 27-03-17 om 17:14 schreef Mark Fletcher:
> >Well, switching from http.debian.net to deb.debian.org seems to have
> >fixed that one. The error relating to that has gone away.
>
> Don't be surprised if it comes back. I think it may just have selected a
> different mirror now, but you can't be certain it will always pick that one.

Right. So far it hasn't but I get what you are saying. I don't believe,
however, that I ran for weeks getting redirected to the same mirror and
getting the same error and then at the moment I switched my settings the
mirror changed and solved the problem by coincidence. Clearly the change
had an impact. So that's good.

>
> >>>wget -qO- https://dl.google.com/linux/linux_signing_key.pub | sudo
> >>>apt-key add -
> >>
> >>No, please do NOT use "apt-key add" but instead download the key and put
> >>it as a file with the suffix ".gpg" into the directory
> >>/etc/apt/trusted.gpg.d/
> >>
> >I downloaded the file from the above URL, and copied it as root to
> >/etc/apt/trusted.gpg.d as instructed. Since all the other files in that
> >directory were owned by root I made sure this one was too. And I renamed
> >it to add .gpg on the end.
>
> That's for binary key files. This one is ascii armoured, so it needs an .asc
> 'extension'.
>

Right, for the key issue, that has taken me right back to where I started:

W: There is no public key available for the following key IDs:
1397BC53640DB551

Now that is the only complaint, which is a significant improvement on
where I started thanks to the fixed mirror, but the key ID issue isn't
solved.

I tried naming the file linux_signing_key.pub.asc and
linux_signing_key.pub.gpg.asc .

Neither worked (in the sense that the warning above appeared). Since
this is the warning I was getting to start with, it almost feels like
this file is either not being read (although naming it ending .gpg
causes mayhem so I guess it is) or it doesn't contain what I need. I
downloaded it using the wget command above except without the -qO-
because I wanted to see what wget was doing and I didn't want the
downloaded result going to standard output.

Possibly stupid question -- this is Jessie, does this mechanism of
dropping the files in trusted.gpg.d work properly in Jessie or is it
new?

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Frank-13
Op 28-03-17 om 00:57 schreef Mark Fletcher:
> Right, for the key issue, that has taken me right back to where I started:
>
> W: There is no public key available for the following key IDs:
> 1397BC53640DB551

Odd. If you do a web search with that number, you'll find a lot of posts
mentioning this issue and all of them point to the same fix: get
google's new key (file).

> Possibly stupid question -- this is Jessie, does this mechanism of
> dropping the files in trusted.gpg.d work properly in Jessie or is it
> new?

Good question. Sven said it worked. I can't confirm that. It may be
worth to try to import that key directly from a keyserver, like I
suggested in my first reply:

sudo apt-key adv --keyserver keys.gnupg.net --recv-keys 1397BC53640DB551

Regards,
Frank

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Sven Hartge-5
In reply to this post by Mark Fletcher-2
Mark Fletcher <[hidden email]> wrote:

> Possibly stupid question -- this is Jessie, does this mechanism of
> dropping the files in trusted.gpg.d work properly in Jessie or is it
> new?

It works properly. I have several hundred servers as proof.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Sven Hartge-5
In reply to this post by Frank-13
Frank <[hidden email]> wrote:
> Op 28-03-17 om 00:57 schreef Mark Fletcher:

>> Right, for the key issue, that has taken me right back to where I started:
>>
>> W: There is no public key available for the following key IDs:
>> 1397BC53640DB551

> Odd. If you do a web search with that number, you'll find a lot of posts
> mentioning this issue and all of them point to the same fix: get
> google's new key (file).

>> Possibly stupid question -- this is Jessie, does this mechanism of
>> dropping the files in trusted.gpg.d work properly in Jessie or is it
>> new?

> Good question. Sven said it worked. I can't confirm that. It may be
> worth to try to import that key directly from a keyserver, like I
> suggested in my first reply:

> sudo apt-key adv --keyserver keys.gnupg.net --recv-keys 1397BC53640DB551

Do NOT *EVER* do this. Importing a key from the keyservers just because
apt says it does not know the ID is wrong.

You might get MitM'ed right now (in this case we know this is the ID of
Googles key, but my argument still holds in general) and installing the
attackers forged pubkey is exactly what he would want.

Only ever install keys from trusted sources into your apt's trusted
keyring.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Frank-13
Op 28-03-17 om 09:54 schreef Sven Hartge:
> in this case we know this is the ID of Googles key, but my argument
> still holds in general

In general, yes.

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Frank-13
In reply to this post by Frank-13
Op 28-03-17 om 07:48 schreef Frank:

> Op 28-03-17 om 00:57 schreef Mark Fletcher:
>> Right, for the key issue, that has taken me right back to where I
>> started:
>>
>> W: There is no public key available for the following key IDs:
>> 1397BC53640DB551
>
> Odd. If you do a web search with that number, you'll find a lot of posts
> mentioning this issue and all of them point to the same fix: get
> google's new key (file).

Mark,

As it turns out the ID 1397BC53640DB551 refers to a subkey of key
7721F63BD38B4796. Both seem to be present in google's key file, so I
can't explain why apt ignores one of them.
I'll leave it up to you if you want to try importing it (again) the
oldfashioned way. It shouldn't do any harm in this case.

Regards,
Frank

Reply | Threaded
Open this post in threaded view
|

Re: Anyone know what this means when running aptitude update?

Mark Fletcher-2
In reply to this post by Sven Hartge-5
On Tue, Mar 28, 2017 at 09:51:18AM +0200, Sven Hartge wrote:
> Mark Fletcher <[hidden email]> wrote:
>
> > Possibly stupid question -- this is Jessie, does this mechanism of
> > dropping the files in trusted.gpg.d work properly in Jessie or is it
> > new?
>
> It works properly. I have several hundred servers as proof.
>
Care to hazard any guesses why it *isn't* working in this case, then?
Any other logs or config I should be looking at? Anything else I might
have that might be overriding correct stuff with wrong stuff?

Mark

12