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 <da...@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
>
