On Sat, Sep 24, 2016 at 09:04:48PM +0200, Michael Stapelberg wrote:
> I tested this in Debian stable (with apt 1.0.9.8.3) and Debian
> testing/experimental (with apt 1.3~rc4 and 1.3, respectively). In Debian
> stable, this works as expected, but in Debian testing and experimental,
> I run into the bug. See the bottom of this report for a full command
> log.
That is a bug, althrough it's about not storing the Release.gpg file if
the Release file isn't stored at the same time – which it isn't if we
already got the latest version in storage – not about not downloading it…
Responsible seems to be apt-pkg/acquire-item.cc:1928 which checks if the
Release file was an IMSHit and only if not stores both files. We should
probably check here if the Release.gpg exists before skipping the
storage. If noone beats me to it I will have a look at patch+test for
next week… it gets a bit late to fiddle with security for today and I am
not really around tomorrow.
> When adding the http://dl.bintray.com/i3/i3-autobuild-ubuntu xenial
> repository, the Release and main_binary-amd64_Packages.lz4 files are
> downloaded and stored in /var/lib/apt/lists. Release.gpg is discarded
> because the necessary public key to verify the signature is not yet
> installed.
Just for the record: lz4 files aren't downloaded. The file downloaded is
likely xz or gz compressed and the current default is to uncompress, but
docker images tend to be configured to store them compressed, which apt
does by uncompressing the xz/gz and recompressing as lz4 on the fly.
Not important for this report, but just for completeness.
> After installing i3-autobuild-keyring, which adds the public key using
> apt-key add, the signature can successfully be verified (apt-get update
> no longer prints an error).
Pretty please with cherry on top don't use 'apt-key add'. Just ship your
keyring in /etc/apt/trusted.gpg.d/ avoiding the need for an installed
gpg. That works for ages now and since recently it even shows warnings.
And while I am suggesting changes: Try to provide an InRelease file,
solves a bunch of problems you likely don't have – but it also "works
around" this bug.
> This seems like a regression to me, and requires an extra step in the
> instructions for our users on how to enable our repository.
I haven't seen the instructions, but the outline you gave with the
commands doesn't look too bright. I don't have to tell you that
--allow-unauthenticated is bad and we are on an active crusade against
it… In fact, your commands just work because you used 'apt-get' and
even there it will stop working in buster. If you had used 'apt' it
would have completely failed the first update already.
I would suggest instructions like (= not tried):
$ /usr/lib/apt/apt-helper download-file http://example.org/keyring.deb keyring.deb SHA256:AAABBBBCCCC…
# apt install ./keyring.deb
# apt edit-sources yourcoolstuff.list
# apt update
Beside that something like this will work in stretch and beyond it is
also more secure (assuming your users read the instructions on a https
site) as that will automatically validate at least with a hash and
doesn't rely on a user doing a check which most don't… (and which is
very hard to perform in the --allow-unauthenticated pattern even if you
want to).
(keep the URI http:// through as a https:// one needs the optional
-https transport your users might or might not have installed)
If you think that process could be streamlined you are probably right,
but nobody designed and implemented it yet.
Best regards
David Kalnischkies