[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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 <david@kalnischkies.de> 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


Reply to: