Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #179373 > unrolled thread

Anyone know what this means when running aptitude update?

Back to article view | Back to linux.debian.user

Contents

  Anyone know what this means when running aptitude update? Mark Fletcher <mark27q1@gmail.com> - 2017-03-26 18:10 +0200
    Re: Anyone know what this means when running aptitude update? Frank <zuiderduin@gmx.com> - 2017-03-26 18:50 +0200
      Re: Anyone know what this means when running aptitude update? Sven Hartge <sven@svenhartge.de> - 2017-03-26 21:00 +0200
        Re: Anyone know what this means when running aptitude update? Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-03-26 21:00 +0200
          Re: Anyone know what this means when running aptitude update? Reco <recoverym4n@gmail.com> - 2017-03-26 21:10 +0200
          Re: Anyone know what this means when running aptitude update? Sven Hartge <sven@svenhartge.de> - 2017-03-26 21:20 +0200
            Re: Anyone know what this means when running aptitude update? Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-03-26 21:50 +0200
              Re: Anyone know what this means when running aptitude update? Sven Hartge <sven@svenhartge.de> - 2017-03-26 22:10 +0200
        Re: Anyone know what this means when running aptitude update? Mark Fletcher <mark27q1@gmail.com> - 2017-03-27 01:30 +0200
          Re: Anyone know what this means when running aptitude update? Frank <zuiderduin@gmx.com> - 2017-03-27 07:50 +0200
          Re: Anyone know what this means when running aptitude update? Sven Hartge <sven@svenhartge.de> - 2017-03-27 11:10 +0200
        Re: Anyone know what this means when running aptitude update? Mark Fletcher <mark27q1@gmail.com> - 2017-03-27 17:20 +0200
          Re: Anyone know what this means when running aptitude update? Frank <zuiderduin@gmx.com> - 2017-03-27 18:10 +0200
            Re: Anyone know what this means when running aptitude update? Mark Fletcher <mark27q1@gmail.com> - 2017-03-28 01:00 +0200
              Re: Anyone know what this means when running aptitude update? Frank <zuiderduin@gmx.com> - 2017-03-28 07:50 +0200
                Re: Anyone know what this means when running aptitude update? Sven Hartge <sven@svenhartge.de> - 2017-03-28 10:10 +0200
                  Re: Anyone know what this means when running aptitude update? Frank <zuiderduin@gmx.com> - 2017-03-28 12:10 +0200
                Re: Anyone know what this means when running aptitude update? Frank <zuiderduin@gmx.com> - 2017-03-28 13:30 +0200
                  Re: Anyone know what this means when running aptitude update? Mark Fletcher <mark27q1@gmail.com> - 2017-03-28 14:40 +0200
              Re: Anyone know what this means when running aptitude update? Sven Hartge <sven@svenhartge.de> - 2017-03-28 10:00 +0200
                Re: Anyone know what this means when running aptitude update? Mark Fletcher <mark27q1@gmail.com> - 2017-03-28 14:30 +0200
                  Re: Anyone know what this means when running aptitude update? Sven Hartge <sven@svenhartge.de> - 2017-03-28 16:20 +0200

Page 1 of 2  [1] 2  Next page →

#179373 — Anyone know what this means when running aptitude update?

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

[toc] | [next] | [standalone]

#179376

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

[toc] | [prev] | [next] | [standalone]

#179394

Frank <zuiderduin@gmx.com> 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.

[toc] | [prev] | [next] | [standalone]

#179395

[Multipart message — attachments visible in raw view] — view raw

On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <sven@svenhartge.de> wrote:

> Frank <zuiderduin@gmx.com> 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.
>

[toc] | [prev] | [next] | [standalone]

#179396

	Hi.

On Sun, 26 Mar 2017 13:56:54 -0500
Nicholas Geovanis <nickgeovanis@gmail.com> wrote:

> On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <sven@svenhartge.de> wrote:
> 
> > Frank <zuiderduin@gmx.com> 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

[toc] | [prev] | [next] | [standalone]

#179398

Nicholas Geovanis <nickgeovanis@gmail.com> wrote:
> On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <sven@svenhartge.de> wrote:
>> Frank <zuiderduin@gmx.com> 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.

[toc] | [prev] | [next] | [standalone]

#179400

[Multipart message — attachments visible in raw view] — view raw

On Sun, Mar 26, 2017 at 2:11 PM, Sven Hartge <sven@svenhartge.de> wrote:

> Nicholas Geovanis <nickgeovanis@gmail.com> wrote:
> > On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <sven@svenhartge.de> 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.
>

[toc] | [prev] | [next] | [standalone]

#179402

Nicholas Geovanis <nickgeovanis@gmail.com> wrote:
> On Sun, Mar 26, 2017 at 2:11 PM, Sven Hartge <sven@svenhartge.de> wrote:
>> Nicholas Geovanis <nickgeovanis@gmail.com> wrote:
>> > On Sun, Mar 26, 2017 at 1:51 PM, Sven Hartge <sven@svenhartge.de> 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.

[toc] | [prev] | [next] | [standalone]

#179414

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

[toc] | [prev] | [next] | [standalone]

#179423

Op 27-03-17 om 01:23 schreef Mark Fletcher:
> On Sun, Mar 26, 2017 at 08:51:55PM +0200, Sven Hartge wrote:
>> Frank <zuiderduin@gmx.com> 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

[toc] | [prev] | [next] | [standalone]

#179428

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

[toc] | [prev] | [next] | [standalone]

#179471

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

[toc] | [prev] | [next] | [standalone]

#179476

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

[toc] | [prev] | [next] | [standalone]

#179503

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

[toc] | [prev] | [next] | [standalone]

#179511

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

[toc] | [prev] | [next] | [standalone]

#179514

Frank <zuiderduin@gmx.com> 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.

[toc] | [prev] | [next] | [standalone]

#179516

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.

[toc] | [prev] | [next] | [standalone]

#179519

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

[toc] | [prev] | [next] | [standalone]

#179525

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

[toc] | [prev] | [next] | [standalone]

#179513

Mark Fletcher <mark27q1@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web