Bug#772676: apt: accesses files not listed in Release file
David Kalnischkies dixit:
>What I meant is: The Release file is perceived as unsigned. Of course,
>we do download Release.gpg after that (in experimental we do it even the
>other way around) and before we try other files, BUT if we don't know the
>key used to sign the Release file, the signature is absolutely useless
>and not at all different to not having a signature at all.
Right. But for unsigned repositories, it should still follow the
normal path of downloading only things listed in the Release file.
Did APT not use a Release file at all before SecureAPT arrived?
>(The longtime goal of apt/experimental is to kill support for unsigned
>repositories completely, BUT this has a bootstrap problem in so far as
>you have to get the key from somewhere and most users do it via the
>(unverifiable) repository they want to be verified as in your log… which
>was talking about two independent "apt-get update"s with an intermediate
>"apt-get install wtf-debian-keyring"
Indeed. This is the main problem for such repositories.
I normally tell people to download the key from a public
keyserver, check its signature (from my main key), and
then apt-key add it… but still just install the keyring
package unsigned at work, over the LAN connection (where
the chance of something untoward happening is very low).
So I don’t do it either…
… maybe an HTTPS download of a shell script doing the
apt-key add magic (for those who trust X.509 PKI), plus
a detached PGP signature for that script… oh, whom am I
kidding… but I’ll still add those.
>even if your follow-up message
>suggests that it would just be one "apt-get update"…)
No, the follow-up was the a-g u after installing the
keyring package.
>Well, Translation-* files were introduced in Debian in ~2005, so
>I wouldn't call that "only recent versions". I think you are referring
>to Translation-en, which is much newer (~2010).
Oh okay. I did not notice the other Translation files having
been there earlier at all – I tend to run my computers in
en-GB and (my own, not those at work) UTC timezone, and in
my time as DD I haven’t come across package description
translations either, I guess there are close-knit teams doing
those, then.
>Their appearance in the
>Release file is a lot more recent by comparison: I think Michael wrote
>the patch to make them appear in Release files on Debian cds last month.
Ah okay. So I guess adding an empty Klingon translation file
would only prevent all accesses except to Translation-en?
>It is true that the repositories without them out-number those with them
>by far, but these few are the most important and also most resistent to
Right.
>> >using Translation-en anyhow if you are a good boy…
>>
>> Not for a 100-packages personal repository…
>
>Of course! It makes even more sense for these repositories as their
>content hardly changes as much as those of e.g. Debian unstable, so
>apt could get away with not downloading long descriptions for weeks.
Their content would change every time all the other files change
(I only generate new Packages, Sources, Release files if there’s
something new to do). Plus I’d have to split them off the freshly
generated Packages file (dpkg-scanpackages)…
… maybe something for mkdebidx.sh v2, which I intend to eventually
write, which would not use dpkg-scan{packag,sourc}es any more…
>This was done to get CVE-2013-1051 fixed very quickly and without much
>fuzz for everyone involved as "people" wanted to release wheezy (and as
Right. I remember that.
>a release either). No released Debian version was effected, so it might
>not have that much attention as e.g. on Ubuntu – but they didn't care
>too much either as they hadn't an InRelease file anywhere (and still
>haven't).
Ah okay.
>If you had/have problems attributed to flipping between these two you
>should be reporting a bugreport, which given it is a regression would
>have had the same very high severity as the CVE itself. It would have
>been ~2 years ago at least, now it would be a 'new' security bug.
Hm yes. I think I just did rm /var/lib/apt/archives/{,*/}* and another
apt-get update, and all was fine. Same for the changes in, I think,
1.0.9 by the way, but always on very few machines…
>Huh? I might be biased and all, but if you remember any details, feel
>free to share them as I am under the impression that all what is needed
>is a second invocation of gpg which is mentioned in apt-secure manpage.
Oh, there’s a manpage… well I tried to get around the second invocation
and even analysed the PGP format…
>Jessie will be the first apt release to use it at all.
Ah okay, so I can re-enable them for jessie/sid.
>What you see is what happens if we take this advice to an extreme:
>Completely ignore the Release file if it can't be verified; and yet,
>you are complaining about it. Be careful what you wish for. ;)
If you completely ignore it, you must not download _any_ of the
other files ;-)
What I meant is, if it's signed, check it first, if not don’t,
well you can’t… but either way, you can only download Packages
and Sources files based on the information in it.
Anyway, thanks for the detailed answers, explanations and
background information. Very much appreciated!
So, to summarise:
• I’ll put up a script calling apt-key add, on https and with
a detached PGP signature, to try to get people to not install
the keyring package from an unsigned repository.
• I’ll add an empty Translation-tlh_DE file to the repository,
to get rid of all but the Translation-en accesses, for whom
there is (probably?) no cure except actually providing them.
• I’ll re-enable InRelease for jessie and sid.
• I’ll think about Translation-en on the next version of my
repository creation script.
Hm, maybe there should be a sort of best practices for addon
APT repositories documentation somewhere… maybe I’ll write
that when I write up something more about my repo anyway.
bye,
//mirabilos
--
18:47⎜<mirabilos:#!/bin/mksh> well channels… you see, I see everything in the
same window anyway 18:48⎜<xpt:#!/bin/mksh> i know, you have some kind of
telnet with automatic pong 18:48⎜<mirabilos:#!/bin/mksh> haha, yes :D
18:49⎜<mirabilos:#!/bin/mksh> though that's more tinyirc – sirc is more comfy
Reply to: