Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

> Yeah, sorry, there should be --export.
>

Great!

gpg --no-default-keyring --export --keyring /etc/apt/trusted.gpg >
/etc/apt/trusted.gpg.new

fixed the problem. I now need to decide whether I should nuke and pave.

The only question that remains is: how did this happen? There must be an
issue lurking there somewhere.

Thanks for the assistance.

Pete

Bug#863179: apt: GPG errors on update and other operations

[Julian Andres Klode]

On Thu, Jun 01, 2017 at 07:52:04PM +1000, Peter Miller wrote:
> > That's your problem. Run
> 
> >
> >   gpg --no-default-keyring --keyring /etc/apt/trusted.gpg >
> > /etc/apt/trusted.gpg.new
> >   mv /etc/apt/trusted.gpg.new /etc/apt/trusted.gpg
> >
> > To convert the keybox file back to a key ring.
> >
> >
> The gpg command hangs. If I issue it without the pipe I get:
> 
> gpg: Go ahead and type your message ...
> 
> trusted.gpg appears to be empty, apart from producing the above output.
> It's 32 bytes long.
> 
> I've poked around the gpg command, but I'm not actually sure what this is
> supposed to achieve. Should there be a "command" as a gpg argument?

Yeah, sorry, there should be --export.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

> That's your problem. Run

>
>   gpg --no-default-keyring --keyring /etc/apt/trusted.gpg >
> /etc/apt/trusted.gpg.new
>   mv /etc/apt/trusted.gpg.new /etc/apt/trusted.gpg
>
> To convert the keybox file back to a key ring.
>
>
The gpg command hangs. If I issue it without the pipe I get:

gpg: Go ahead and type your message ...

trusted.gpg appears to be empty, apart from producing the above output.
It's 32 bytes long.

I've poked around the gpg command, but I'm not actually sure what this is
supposed to achieve. Should there be a "command" as a gpg argument?

Thanks, Pete

Bug#863179: apt: GPG errors on update and other operations

[Julian Andres Klode]

On Wed, May 31, 2017 at 07:45:51PM +1000, Peter Miller wrote:
> > What about /etc/apt/trusted.gpg
> >
> trusted.gpg: GPG keybox database version 1, created-at Fri Apr 28 07:45:49
> 2017, last-maintained Fri Apr 28 07:45:49 2017

That's your problem. Run

  gpg --no-default-keyring --keyring /etc/apt/trusted.gpg > 
/etc/apt/trusted.gpg.new
  mv /etc/apt/trusted.gpg.new /etc/apt/trusted.gpg

To convert the keybox file back to a key ring.

> 
> >
> > What you can do is manually run apt-key verify for an InRelease file, e.g.:
> >
> > /usr/bin/apt-key verify
> > /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_InRelease
> >
> 
> No can do. Closest is:
> 
> root@pete:/var/lib/apt/lists# /usr/bin/apt-key verify
> /var/lib/apt/lists/debian.mirror.digitalpacific.com.au_debian_dists_stretch_Release
> gpgv: Signature made Tue 23 May 2017 06:42:01 AEST
> gpgv:using RSA key 8B48AD6246925553
> gpgv: Can't check signature: No public key
> gpgv: Signature made Tue 23 May 2017 06:42:01 AEST
> gpgv:using RSA key 7638D0442B90D010
> gpgv: Can't check signature: No public key
> root@pete:/var/lib/apt/lists#
> 
[...] 
> So, I don't understand what to compare, or what to download, or where from.

The idea was to download an InRelease file from a Debian mirror, and run
apt-key verify on it to see error messages.
-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

>   ... In the gmail web UI,
> you click on the three dots and then move your cursor to the position
> where you want to start writing (I actually forgot to add this to the
> previous email...).
>

OK. I'm not a fan of a UI where the same element does very different
things. In the past there was a separate option for reply inline.

>
>
> These look correct. Just to clarify: Running file shows you "GPG key
> public ring" for each file?


yes


> What about /etc/apt/trusted.gpg
>
trusted.gpg: GPG keybox database version 1, created-at Fri Apr 28 07:45:49
2017, last-maintained Fri Apr 28 07:45:49 2017

>
> What you can do is manually run apt-key verify for an InRelease file, e.g.:
>
> /usr/bin/apt-key verify
> /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_InRelease
>

No can do. Closest is:

root@pete:/var/lib/apt/lists# /usr/bin/apt-key verify
/var/lib/apt/lists/debian.mirror.digitalpacific.com.au_debian_dists_stretch_Release
gpgv: Signature made Tue 23 May 2017 06:42:01 AEST
gpgv:using RSA key 8B48AD6246925553
gpgv: Can't check signature: No public key
gpgv: Signature made Tue 23 May 2017 06:42:01 AEST
gpgv:using RSA key 7638D0442B90D010
gpgv: Can't check signature: No public key
root@pete:/var/lib/apt/lists#



> /usr/bin/apt-key verify
> /var/lib/apt/lists/dl.google.com_linux_chrome_deb_dists_
> stable_Release{.gpg,}
>
> (showing the two different invocations). If you don't have InRelease
> (or Release.gpg and Release) files, you could download one manually.
> This should error messages from gpgv.
>

Now, I don't understand the intention. Here is a listing from that
directory:

debian.mirror.digitalpacific.com.au_debian_dists_stretch_contrib_binary-amd64_Packages
debian.mirror.digitalpacific.com.au_debian_dists_stretch_contrib_dep11_Components-amd64.yml.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_contrib_dep11_icons-64x64.tar.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_contrib_i18n_Translation-en
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_binary-amd64_Packages
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_binary-amd64_Packages.diff_Index
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_dep11_Components-amd64.yml.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_dep11_icons-64x64.tar.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_i18n_Translation-en
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_i18n_Translation-en.diff_Index
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_binary-amd64_Packages
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_binary-amd64_Packages.diff_Index
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_dep11_Components-amd64.yml.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_dep11_icons-64x64.tar.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_i18n_Translation-en
debian.mirror.digitalpacific.com.au_debian_dists_stretch_Release
debian.mirror.digitalpacific.com.au_debian_dists_stretch-updates_Release
lock
partial
security.debian.org_dists_stretch_updates_main_binary-amd64_Packages
security.debian.org_dists_stretch_updates_main_i18n_Translation-en
security.debian.org_dists_stretch_updates_Release

So, I don't understand what to compare, or what to download, or where from.

Thanks, Pete

Bug#863179: apt: GPG errors on update and other operations

[Julian Andres Klode]

On 29 May 2017 at 09:53, Peter Miller  wrote:
> Hi,
>
>
> If you'd like to show me how I can use the gmail web interface to respond
> inline and select what to quote, do go ahead. I really don't like to be
> called names, especially when there is no basis for it.

Oh, I wasn't name calling, I just stated facts. In the gmail web UI,
you click on the three dots and then move your cursor to the position
where you want to start writing (I actually forgot to add this to the
previous email...).

>
> Sorry, but I did miss the  stuff from David. But, all files in that
> directory are -rw-r--r-- 1 root root and all files are GPG key files.

These look correct. Just to clarify: Running file shows you "GPG key
public ring" for each file? What about /etc/apt/trusted.gpg

>
> And:
>
> stat /tmp
>   File: /tmp
>   Size: 4096Blocks: 8  IO Block: 4096   directory
> Device: 10302h/66306d   Inode: 5373953 Links: 14
> Access: (1777/drwxrwxrwt)  Uid: (0/root)   Gid: (0/root)

That looks correct.

What you can do is manually run apt-key verify for an InRelease file, e.g.:

/usr/bin/apt-key verify
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_InRelease
/usr/bin/apt-key verify
/var/lib/apt/lists/dl.google.com_linux_chrome_deb_dists_stable_Release{.gpg,}

(showing the two different invocations). If you don't have InRelease
(or Release.gpg and Release) files, you could download one manually.
This should error messages from gpgv.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

Hi,


If you'd like to show me how I can use the gmail web interface to respond
inline and select what to quote, do go ahead. I really don't like to be
called names, especially when there is no basis for it.

Sorry, but I did miss the  stuff from David. But, all files in that
directory are -rw-r--r-- 1 root root and all files are GPG key files.

And:

stat /tmp
  File: /tmp
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: 10302h/66306d   Inode: 5373953 Links: 14
Access: (1777/drwxrwxrwt)  Uid: (0/root)   Gid: (0/root)
Access: 2017-05-24 20:21:01.468603835 +1000
Modify: 2017-05-29 17:45:53.533125958 +1000
Change: 2017-05-29 17:45:53.533125958 +1000
 Birth: -

So, it doesn't look like the issue?


Thanks, Pete

On 26 May 2017 at 19:51, Julian Andres Klode  wrote:

> On Fri, May 26, 2017 at 06:21:23PM +1000, Peter Miller wrote:
> > Julian,
> >
> > Sorry, but gmail does not allow me to reply inline, or to select what I
> > quote. I am using the only option I have.
>
> Yeah, right. No. That's a lie.
>
> >
> > I am not and did not ignore Frank's advice, which included a *count* of
> the
> > files in /etc/apt/trusted.gpg.d. That advice was followed and was a dead
> > end. Frank's advice was that the keys seem to be correct. There is a bug
> > somewhere in here, I just don't know where. I did not try to fix anything
> > from a clean install before this issue showed up.
>
> There is no Frank here, and nobody here gave you an advice to count
> files.
>
> >
> > I do appreciate you responding to me, but it's really not helping that we
> > seem to be talking at cross purposes. I am not a Debian dev, but do have
> a
> > technical background. So, I have tried my best to listen to advice, and
> to
> > do what research I can.  I am happy to follow any clear instruction, and
> > would really like not to have to reinstall the operating system to fix
> what
> > appears to be a simple problem. I understand I am using Testing, but
> there
> > must be a way out of here.
>
> David gave you very clear instructions (and I quoted them twice for you)
>
> 1. run ls -lh on all files in trusted.gpg.d to figure out permissions
> 2. run file on all files to check that they are all valid GPG public
>key files
> 3. And run a stat on /tmp to check if your system is not messed up there.
>
> You have followed *none* of the instructions, so I get the feeling
> you are just here to troll. So this is your last chance, after that
> I'll ignore you and ask for you to be banned or something.
>
> And one last time, the original quote from David:
>
> > > > > > On 23 May 2017 at 21:35, David Kalnischkies <
> da...@kalnischkies.de>
> > > > > wrote:
> > > > > > > Julian was asking basically for running both:
> > > > > > > ls -l /etc/apt/trusted.gpg{,.d}
> > > > > > > file /etc/apt/trusted.gpg{,.d/*}
> > > > > > >
> > > > > > > As he thinks it might be a permission/wrong-file-in-there
> problem,
> > > > > which
> > > > > > > is the most likely cause… I would add a "stat /tmp" as I have
> seen
> > > it
> > > > > > > a few times by now that people had very strange permissions on
> /tmp
> > > > > > > – all of which usually caused by "fixing" some problem earlier…
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#863179: apt: GPG errors on update and other operations

[Julian Andres Klode]

On Fri, May 26, 2017 at 06:21:23PM +1000, Peter Miller wrote:
> Julian,
> 
> Sorry, but gmail does not allow me to reply inline, or to select what I
> quote. I am using the only option I have.

Yeah, right. No. That's a lie.

> 
> I am not and did not ignore Frank's advice, which included a *count* of the
> files in /etc/apt/trusted.gpg.d. That advice was followed and was a dead
> end. Frank's advice was that the keys seem to be correct. There is a bug
> somewhere in here, I just don't know where. I did not try to fix anything
> from a clean install before this issue showed up.

There is no Frank here, and nobody here gave you an advice to count
files.

> 
> I do appreciate you responding to me, but it's really not helping that we
> seem to be talking at cross purposes. I am not a Debian dev, but do have a
> technical background. So, I have tried my best to listen to advice, and to
> do what research I can.  I am happy to follow any clear instruction, and
> would really like not to have to reinstall the operating system to fix what
> appears to be a simple problem. I understand I am using Testing, but there
> must be a way out of here.

David gave you very clear instructions (and I quoted them twice for you)

1. run ls -lh on all files in trusted.gpg.d to figure out permissions
2. run file on all files to check that they are all valid GPG public
   key files
3. And run a stat on /tmp to check if your system is not messed up there.

You have followed *none* of the instructions, so I get the feeling
you are just here to troll. So this is your last chance, after that
I'll ignore you and ask for you to be banned or something.

And one last time, the original quote from David:

> > > > > On 23 May 2017 at 21:35, David Kalnischkies 
> > > > wrote:
> > > > > > Julian was asking basically for running both:
> > > > > > ls -l /etc/apt/trusted.gpg{,.d}
> > > > > > file /etc/apt/trusted.gpg{,.d/*}
> > > > > >
> > > > > > As he thinks it might be a permission/wrong-file-in-there problem,
> > > > which
> > > > > > is the most likely cause… I would add a "stat /tmp" as I have seen
> > it
> > > > > > a few times by now that people had very strange permissions on /tmp
> > > > > > – all of which usually caused by "fixing" some problem earlier…

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

Julian,

Sorry, but gmail does not allow me to reply inline, or to select what I
quote. I am using the only option I have.

I am not and did not ignore Frank's advice, which included a *count* of the
files in /etc/apt/trusted.gpg.d. That advice was followed and was a dead
end. Frank's advice was that the keys seem to be correct. There is a bug
somewhere in here, I just don't know where. I did not try to fix anything
from a clean install before this issue showed up.

I do appreciate you responding to me, but it's really not helping that we
seem to be talking at cross purposes. I am not a Debian dev, but do have a
technical background. So, I have tried my best to listen to advice, and to
do what research I can.  I am happy to follow any clear instruction, and
would really like not to have to reinstall the operating system to fix what
appears to be a simple problem. I understand I am using Testing, but there
must be a way out of here.

Regards, Pete Miller

On 25 May 2017 at 21:33, Julian Andres Klode  wrote:

> On Thu, May 25, 2017 at 08:23:34PM +1000, Peter Miller wrote:
> > Julian,
> >
> > There is no such thing as perfect security. I was and am using a trusted
> > mirror, so I'm much more worried about the Windows machines I have to use
> > at work, and are necessarily linked to my linux boxes. So, please,
> > understand that I understand the (small) risk I have taken. I wouldn't
> even
> > take the time to verify my packages later, as it's not worth the
> > investment. I have good backups of all my important stuff, and I would
> > notice a bot eventually. So, could we please get back to my question?
> >
> > Is there any way to fix my keys?
>
> This is getting ridiculous. David told you precisely what to do and I
> quoted it for you in the previous email again, if you keep ignoring that,
> that's your problem. This is likely the last time I'll quote that for you:
>
> > On 25 May 2017 at 19:00, Julian Andres Klode  wrote:
> > > You know, that bit:
> > >
> > > > On 23 May 2017 at 21:35, David Kalnischkies 
> > > wrote:
> > > > > Julian was asking basically for running both:
> > > > > ls -l /etc/apt/trusted.gpg{,.d}
> > > > > file /etc/apt/trusted.gpg{,.d/*}
> > > > >
> > > > > As he thinks it might be a permission/wrong-file-in-there problem,
> > > which
> > > > > is the most likely cause… I would add a "stat /tmp" as I have seen
> it
> > > > > a few times by now that people had very strange permissions on /tmp
> > > > > – all of which usually caused by "fixing" some problem earlier…
>
> Also please reply properly, as explained below.
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#863179: apt: GPG errors on update and other operations

[Julian Andres Klode]

On Thu, May 25, 2017 at 08:23:34PM +1000, Peter Miller wrote:
> Julian,
> 
> There is no such thing as perfect security. I was and am using a trusted
> mirror, so I'm much more worried about the Windows machines I have to use
> at work, and are necessarily linked to my linux boxes. So, please,
> understand that I understand the (small) risk I have taken. I wouldn't even
> take the time to verify my packages later, as it's not worth the
> investment. I have good backups of all my important stuff, and I would
> notice a bot eventually. So, could we please get back to my question?
> 
> Is there any way to fix my keys?

This is getting ridiculous. David told you precisely what to do and I
quoted it for you in the previous email again, if you keep ignoring that,
that's your problem. This is likely the last time I'll quote that for you:

> On 25 May 2017 at 19:00, Julian Andres Klode  wrote:
> > You know, that bit:
> >
> > > On 23 May 2017 at 21:35, David Kalnischkies 
> > wrote:
> > > > Julian was asking basically for running both:
> > > > ls -l /etc/apt/trusted.gpg{,.d}
> > > > file /etc/apt/trusted.gpg{,.d/*}
> > > >
> > > > As he thinks it might be a permission/wrong-file-in-there problem,
> > which
> > > > is the most likely cause… I would add a "stat /tmp" as I have seen it
> > > > a few times by now that people had very strange permissions on /tmp
> > > > – all of which usually caused by "fixing" some problem earlier…

Also please reply properly, as explained below.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

Julian,

There is no such thing as perfect security. I was and am using a trusted
mirror, so I'm much more worried about the Windows machines I have to use
at work, and are necessarily linked to my linux boxes. So, please,
understand that I understand the (small) risk I have taken. I wouldn't even
take the time to verify my packages later, as it's not worth the
investment. I have good backups of all my important stuff, and I would
notice a bot eventually. So, could we please get back to my question?

Is there any way to fix my keys?

BTW, I have worked on systems that deal with legal property ownership, so I
appreciate matching effort to risk.

Thanks, Pete

On 25 May 2017 at 19:00, Julian Andres Klode  wrote:

> On Thu, May 25, 2017 at 06:49:31PM +1000, Peter Miller wrote:
> > David,
> >
> > Thanks for your time on this. I am surprised that the answer to this
> issue
> > is a re-install: it's only the keys that are corrupt somehow, and I am
> > surprised there is not a simple way to fix this. I have an unusual setup
> > with a mirrored ZFS pool as my home directory, so I'm a little
> > apprehensive. I know a re-install is usually not a big issue, but I'd
> > rather not take that risk in this situation.
>
> You are completely missing the point (any package you installed unchecked
> could be MITMed was what he said), and the second half of David's email
> (to look at the files in trusted.gpg.d and fix/remove the wrong ones).
>
> You know, that bit:
>
> > On 23 May 2017 at 21:35, David Kalnischkies 
> wrote:
> > > Julian was asking basically for running both:
> > > ls -l /etc/apt/trusted.gpg{,.d}
> > > file /etc/apt/trusted.gpg{,.d/*}
> > >
> > > As he thinks it might be a permission/wrong-file-in-there problem,
> which
> > > is the most likely cause… I would add a "stat /tmp" as I have seen it
> > > a few times by now that people had very strange permissions on /tmp
> > > – all of which usually caused by "fixing" some problem earlier…
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#863179: apt: GPG errors on update and other operations

[Julian Andres Klode]

On Thu, May 25, 2017 at 06:49:31PM +1000, Peter Miller wrote:
> David,
> 
> Thanks for your time on this. I am surprised that the answer to this issue
> is a re-install: it's only the keys that are corrupt somehow, and I am
> surprised there is not a simple way to fix this. I have an unusual setup
> with a mirrored ZFS pool as my home directory, so I'm a little
> apprehensive. I know a re-install is usually not a big issue, but I'd
> rather not take that risk in this situation.

You are completely missing the point (any package you installed unchecked
could be MITMed was what he said), and the second half of David's email
(to look at the files in trusted.gpg.d and fix/remove the wrong ones).

You know, that bit:

> On 23 May 2017 at 21:35, David Kalnischkies  wrote:
> > Julian was asking basically for running both:
> > ls -l /etc/apt/trusted.gpg{,.d}
> > file /etc/apt/trusted.gpg{,.d/*}
> >
> > As he thinks it might be a permission/wrong-file-in-there problem, which
> > is the most likely cause… I would add a "stat /tmp" as I have seen it
> > a few times by now that people had very strange permissions on /tmp
> > – all of which usually caused by "fixing" some problem earlier…

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

David,

Thanks for your time on this. I am surprised that the answer to this issue
is a re-install: it's only the keys that are corrupt somehow, and I am
surprised there is not a simple way to fix this. I have an unusual setup
with a mirrored ZFS pool as my home directory, so I'm a little
apprehensive. I know a re-install is usually not a big issue, but I'd
rather not take that risk in this situation.

Is there no way to reset the keys?

By the way, I got into this situation without doing anything unusual, just
installing from the CD image and updating.

Regards, Pete

On 23 May 2017 at 21:35, David Kalnischkies  wrote:

> On Tue, May 23, 2017 at 10:59:32AM +1000, Pete Miller wrote:
> > Subsequently, I have run "apt update --allow-insecure-repositories",
> which
> > worked, but a subsequent "apt-get update --allow-unauthenticated" and
> similar
> > failed to update any packages due to key errors as detailed in the
> thread.
>
> Problems are only very sheldomly solved by blindly running random
> commands. Most of the time they just "solve" something by poking a hole
> somewhere else… and disabling security is the poster child for creating
> two new problems with every problem solved this way!
>
> ALL packages you have installed while using such options could be coming
> straight from NSA^WNorthkorea^Wsome evildoers using your computer now to
> collect intel on you and your neighbors, mine cryptocurrencies or upload
> childporn in your name. So the most sensible approach is in fact a clean
> reinstall and avoiding harming your system before you ask for help next
> time. You would bring a car which makes funky sounds directly to an
> engineer, wouldn't you? Instead of taking a hammer and randomly hitting
> the car denting metal and breaking glass in the hope that it might
> magically work out anyhow if only you hit hard enough…
>
>
> > Running aptitude with options allowed the outstanding packages to be
> updated,
> > but the key errors persist in apt, synaptic and aptitude, even though the
> > correct keys seem to be installed.
>
> Debian comes with all keys to deal with the archive by default and as
> Frank has walked you through on debian-user@ they seem to be there just
> fine.
>
> (Importing any Release.gpg is btw never going to work. It contains the
> signature created with a (private) key, not the (public) key itself. You
> just need the (public) key to verify the signature.)
>
> Julian was asking basically for running both:
> ls -l /etc/apt/trusted.gpg{,.d}
> file /etc/apt/trusted.gpg{,.d/*}
>
> As he thinks it might be a permission/wrong-file-in-there problem, which
> is the most likely cause… I would add a "stat /tmp" as I have seen it
> a few times by now that people had very strange permissions on /tmp
> – all of which usually caused by "fixing" some problem earlier…
>
>
> It is btw highly unlikely that aptitude allowed an update while the
> others didn't (but then you say it didn't anyhow, so who knows) as they
> are sharing all the same code and data then it comes to downloading so
> we can work on making it "perfect" once from a security standpoint
> rather than "so lala"¹ for each individual package manager.
>
> ¹ german for "okayish", but with a (stronger) hint of "would not hold
> its ground if someone would look closer".
>
>
> Best regards
>
> David Kalnischkies
>

Bug#863179: apt: GPG errors on update and other operations

[David Kalnischkies]

On Tue, May 23, 2017 at 10:59:32AM +1000, Pete Miller wrote:
> Subsequently, I have run "apt update --allow-insecure-repositories", which
> worked, but a subsequent "apt-get update --allow-unauthenticated" and similar
> failed to update any packages due to key errors as detailed in the thread.

Problems are only very sheldomly solved by blindly running random
commands. Most of the time they just "solve" something by poking a hole
somewhere else… and disabling security is the poster child for creating
two new problems with every problem solved this way!

ALL packages you have installed while using such options could be coming
straight from NSA^WNorthkorea^Wsome evildoers using your computer now to
collect intel on you and your neighbors, mine cryptocurrencies or upload
childporn in your name. So the most sensible approach is in fact a clean
reinstall and avoiding harming your system before you ask for help next
time. You would bring a car which makes funky sounds directly to an
engineer, wouldn't you? Instead of taking a hammer and randomly hitting
the car denting metal and breaking glass in the hope that it might
magically work out anyhow if only you hit hard enough…


> Running aptitude with options allowed the outstanding packages to be updated,
> but the key errors persist in apt, synaptic and aptitude, even though the
> correct keys seem to be installed.

Debian comes with all keys to deal with the archive by default and as
Frank has walked you through on debian-user@ they seem to be there just
fine.

(Importing any Release.gpg is btw never going to work. It contains the
signature created with a (private) key, not the (public) key itself. You
just need the (public) key to verify the signature.)

Julian was asking basically for running both:
ls -l /etc/apt/trusted.gpg{,.d}
file /etc/apt/trusted.gpg{,.d/*}

As he thinks it might be a permission/wrong-file-in-there problem, which
is the most likely cause… I would add a "stat /tmp" as I have seen it
a few times by now that people had very strange permissions on /tmp
– all of which usually caused by "fixing" some problem earlier…


It is btw highly unlikely that aptitude allowed an update while the
others didn't (but then you say it didn't anyhow, so who knows) as they
are sharing all the same code and data then it comes to downloading so
we can work on making it "perfect" once from a security standpoint
rather than "so lala"¹ for each individual package manager.

¹ german for "okayish", but with a (stronger) hint of "would not hold
its ground if someone would look closer".


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

Julian,

I thought doing one update might fix the issue, since nothing else was
working, hence --allow-unauthenticated.

I did not install or update anything in /etc/apt/trusted.gpg.d, or anywhere
else similar, so how did it get corrupted? Is there a source issue? Are
there automated checks after download?

Sorry, I don't understand what "output of file(1)" (or any of your other
advice) means. Could I have it in plain English, please? How do I replace
the GPG files? The Release.gpg files on mirrors don't import as keys.

Thanks, Pete Miller

On 23 May 2017 at 16:57, Julian Andres Klode  wrote:

> On Tue, May 23, 2017 at 10:59:32AM +1000, Pete Miller wrote:
> > Package: apt
> > Version: 1.4.1
> > Severity: important
> > Tags: d-i
> >
> > Dear Maintainer,
> >
> > I installed Stretch from the CD image to new physical hardware, and then
> > updated the system. I can't remember if errors started straight away, or
> took a
> > while to manifest.
> >
> > See this thread for some background: https://lists.debian.org/debian-
> > user/2017/05/msg00311.html
> >
> > Subsequently, I have run "apt update --allow-insecure-repositories",
> which
> > worked, but a subsequent "apt-get update --allow-unauthenticated" and
> similar
> > failed to update any packages due to key errors as detailed in the
> thread.
>
> --allow-unathenticated is for install/upgrade, I think, not for update.
> Anyway,
> your system is broken, fix it, instead of doing dangerous stuff like this:
> One
> of your files in /etc/apt/trusted.gpg.d/ is probably in a wrong format.
>
> That's what you want for .gpg files (output of file(1)):
>
> GPG key public ring, created Fri Nov 21 21:01:13 2014
>
> .asc files are valid too, containing armored public keys. Sometimes
> you get "GPG keybox database version 1" files (which gpg2 uses for
> keyrings) - these are not valid files.
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#863179: apt: GPG errors on update and other operations

[Julian Andres Klode]

On Tue, May 23, 2017 at 10:59:32AM +1000, Pete Miller wrote:
> Package: apt
> Version: 1.4.1
> Severity: important
> Tags: d-i
> 
> Dear Maintainer,
> 
> I installed Stretch from the CD image to new physical hardware, and then
> updated the system. I can't remember if errors started straight away, or took 
> a
> while to manifest.
> 
> See this thread for some background: https://lists.debian.org/debian-
> user/2017/05/msg00311.html
> 
> Subsequently, I have run "apt update --allow-insecure-repositories", which
> worked, but a subsequent "apt-get update --allow-unauthenticated" and similar
> failed to update any packages due to key errors as detailed in the thread.

--allow-unathenticated is for install/upgrade, I think, not for update. Anyway,
your system is broken, fix it, instead of doing dangerous stuff like this: One
of your files in /etc/apt/trusted.gpg.d/ is probably in a wrong format.

That's what you want for .gpg files (output of file(1)):

GPG key public ring, created Fri Nov 21 21:01:13 2014

.asc files are valid too, containing armored public keys. Sometimes
you get "GPG keybox database version 1" files (which gpg2 uses for
keyrings) - these are not valid files.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#863179: apt: GPG errors on update and other operations

[Pete Miller]

Package: apt
Version: 1.4.1
Severity: important
Tags: d-i

Dear Maintainer,

I installed Stretch from the CD image to new physical hardware, and then
updated the system. I can't remember if errors started straight away, or took a
while to manifest.

See this thread for some background: https://lists.debian.org/debian-
user/2017/05/msg00311.html

Subsequently, I have run "apt update --allow-insecure-repositories", which
worked, but a subsequent "apt-get update --allow-unauthenticated" and similar
failed to update any packages due to key errors as detailed in the thread.

Running aptitude with options allowed the outstanding packages to be updated,
but the key errors persist in apt, synaptic and aptitude, even though the
correct keys seem to be installed.

I cannot force version for apt to update to version 1.4.4, so I am stuck on
1.4.1, although no similar errors are reported there.

Thanks, Pete Miller



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-3-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-
services/org.freedesktop.PackageKit.service && /usr/bin/test -S
/var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest
org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout
4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null;
/bin/echo > /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";