On Wed 05 Jul 2017 at 11:10:44 (+0200), Michael Lange wrote: > Hi, > > I'm glad you could finally fix the issue. > > On Wed, 5 Jul 2017 12:15:33 +0930 > "Wayne Hartell" <w.hart...@ozemail.com.au> wrote: > > > I know I just wrote a long e-mail on this, but I think I just figured > > out in my own mind exactly what is going on and wanted to document it. > > > > > > > > As others have said the /etc/apt/trusted.gpg file is the issue. > > > > > > > > It seems that what is happening is this: > > > > > > > > 1. For some reason the first use of software-properties-gtk > > creates this file, but (the bug I presume) is that it's not created > > correctly. It's empty and potentially has the wrong permissions on it. > > Maybe there is actually a bug in software-properties-gtk. I mentioned > earlier that on Jessie the permissions of the file are 0600, I now > checked on a laptop with Sparky linux (which basically *is* stretch) and > found that the file's permissons on that system are 0644, so maybe the > newer version of apt requires this and software-properties-gtk fails to > set this correctly? > > > > > a. I suspect it being empty is the consequence of the > > permissions, but I am just guessing. > > Maybe, but since this file appears to be the place where custom added keys > go (whereas keys from debian keyring packages apparently go > to /etc/apt/trusted.gpg.d/ ) it might also be ok if there are none. From > what you experienced it seems possible that maybe newer versions of apt > require a new format of this file and again software-properties-gtk fails > torespect this, but that is of course just another guess. > > > > > 2. Running 'apt-get update' will now produce errors about user > > "_apt" and not being able to read the /etc/apt/trusted.gpg file. > > > > 3. Making /etc/apt/trusted.gpg readable (i.e., 0600 --> 0644) only > > obfuscates the problem; now the empty file is accessible (so no errors > > about reading it), but the keys are not available > > and /etc/apt/trusted.gpg.d is now ignored and results in key errors. > > [Wild goose chase may now commence]. > > This might back up my above guess. > > > > > 4. The real fix is to delete /etc/apt/trusted.gpg and after that > > point it seems not to be created again (even if running > > software-properties-gtk). Everything works again since > > the /etc/apt/trusted.gpg.d folder can once again be interrogated. > > When I run apt-key list here, /etc/apt/trusted.gpg always seems to be > evaluated first, so I guess that if this file is corrupted the command > just stops with an error message. > If one wants to confirm that it is actually software-properties-gtk who > creates a corrupted trusted.gpg file it should be possible to add (for > testing purposes) a key from a third party repo manually with > software-properties-gtk and later again with apt-key add and compare the > result. If it works from the command line and fails from the gui it would > be proof enough to desreve a bug report, I think.
This is a very long thread, and I make no apologies if I have missed something, but I've seen no reference to ยง5.3.2 in the Release Notes for stretch. This touches on changes made to apt and troubleshooting its new user-privelege mode. (It's a long time since I'd read these but was revisiting them in connection with other threads.) Cheers, David.
