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

[Sven Hartge]

Mark Fletcher  wrote:
> On Tue, Mar 28, 2017 at 09:51:18AM +0200, Sven Hartge wrote:
>> Mark Fletcher  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?

Looking at my notes: The key ID in questions refers to a subkey. apt
seems to not use them when present in files in /etc/apt/trusted.gpg.d/.
But Googles Release file is signed by multiple keys, so this message
should be benign.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

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

[Mark Fletcher]

On Tue, Mar 28, 2017 at 01:24:59PM +0200, Frank wrote:
> Op 28-03-17 om 07:48 schreef Frank:
> 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.
> 
Thanks very much for your reply. I took the file I had previously 
downloaded, and had been placing in /etc/apt/trusted.gpg.d/ , and ran 
apt-key add on that file. It responded "OK", and after that aptitude 
update runs with zero errors.

Putting the file in trusted.gpg.d didn't work, importing it using 
apt-key add did. Given Sven's experience to the contrary, I am at a loss 
to explain that.

But what is important to me for now is that, at last, both problems from 
this thread are resolved and I get no errors when I run aptitude update. 
Thanks very much to everyone who contributed.

Mark

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

[Mark Fletcher]

On Tue, Mar 28, 2017 at 09:51:18AM +0200, Sven Hartge wrote:
> Mark Fletcher  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

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

[Frank]

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

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

[Frank]

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.

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

[Sven Hartge]

Frank  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.

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

[Sven Hartge]

Mark Fletcher  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.

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

[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).



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

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

[Mark Fletcher]

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

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

[Frank]

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

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

[Mark Fletcher]

On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:
> Frank  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

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

[Sven Hartge]

Mark Fletcher  wrote:
> On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:
>> Frank  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.

S°

-- 
Sigmentation fault. Core dumped.

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

[Frank]

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

On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:

Frank  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

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

[Mark Fletcher]

On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:
> Frank  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

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

[Sven Hartge]

Nicholas Geovanis  wrote:
> On Sun, Mar 26, 2017 at 2:11 PM, Sven Hartge  wrote:
>> Nicholas Geovanis  wrote:
>> > On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge  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
>amd64commandline 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.

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

[Nicholas Geovanis]

On Sun, Mar 26, 2017 at 2:11 PM, Sven Hartge  wrote:

> Nicholas Geovanis  wrote:
> > On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge  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
   amd64commandline package manager



> Grüße,
> Sven.
>

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

[Sven Hartge]

Nicholas Geovanis  wrote:
> On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge  wrote:
>> Frank  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.

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

[Reco]

Hi.

On Sun, 26 Mar 2017 13:56:54 -0500
Nicholas Geovanis  wrote:

> On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge  wrote:
> 
> > Frank  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

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

[Nicholas Geovanis]

On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge  wrote:

> Frank  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.
>

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

[Sven Hartge]

Frank  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.

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

[Frank]

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

Anyone know what this means when running aptitude update?

[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.

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