Thanks for the detailed reply! On Sat, Sep 24, 2016 at 11:32 PM, David Kalnischkies <da...@kalnischkies.de> wrote:
> > 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. > Thanks! Let me know if there’s anything you’d like me to test. > > > > 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. > Done: https://github.com/stapelberg/i3-autobuild-keyring/commit/d42e1af4406b23820751dd66fa2129637ac9630e > > 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. > I don’t control the repository building part — that’s outsourced to bintray.com. Are there any tangible benefits (aside from working around this specific bug) they’d get from switching to InRelease? > > > > 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 > Neat! I didn’t know this was possible. Updated the instructions accordingly: https://github.com/i3/i3.github.io/commit/d82c5335de3e52f06a0dc6d364284d315def4d71 and https://github.com/i3/i3.github.io/commit/28387385984f9fa52061c4cdc59e20ba1d03965f > > 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 > -- Best regards, Michael
