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. Regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. War isn't a good life, but it's life. -- Kirk, "A Private Little War", stardate 4211.8