On Thu, Dec 11, 2014 at 03:29:07PM +0000, Thorsten Glaser wrote:
> David Kalnischkies dixit:
> >That would be nice… we can't really us an unsigned Release file though
>
> Uhm, it downloads Release.gpg right after Release and before all
> the Packages* files, so this is not an excuse.
In retrospective, I shouldn't have used the word "unsigned" here…
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.
First priority is hence to prevent this Release file to become signed in
the eyes of apt, which is why everything before experimental currently
doesn't really use it at all as a source for information.
(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" even if your follow-up message
suggests that it would just be one "apt-get update"…)
> >The Translation files are a different matter: They are requested because
> >they weren't in the Release file for years, so we have to guess that
> >they exist.
>
> Ah. But asides from the Debian repositories (and even then, only
> for recent versions), almost no other repos have these files.
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). 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.
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
change - and they tend to be generated by tools older than the release
they generate. In other words, if you want to introduce something new in
this millennium you either need a time machine or change the client to
work with servers many generations old, even if that means more work for
the client with "strange" requests to the server.
> >Split long descriptions out (Translation-en) or just create
> >an empty Translation-tlh_DE (for german-based Klingons) which you
> >mention in the Release file (In fact, any file matching Translation-*
> >will work) to hint apt that you mention all the Translation files you
> >got in the Release file, so that it doesn't have to guess. You should be
>
> Ugh. But ok, we have a workaround then…
>
> >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.
> >To remove the last remaining 404, add an InRelease file. Helps a lot in
>
> I used to have that. Then, APT decided to not use them any more.
> Then, APT decided that, when a repo had an InRelease file it does
> not use any more, it does not need to download the new Release and
> Release.gpg files, and threw errors and/or used old information.
> The switch to not use InRelease files was almost silent, only
> mentioned in changelog entries and all that.
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
it was end of March, Ubuntu was probably not that far away from
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).
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.
> Then I disabled InRelease file generation, which had cost me quite
> some effort to write in the first place.
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.
> Now you tell me I should be using it? Since when *does* APT use
> them again? I did not get that message.
>
> (Actually, since I occasionally have use cases for as far back
> as sarge and dapper, a list for which releases of both InRelease
> is safe to use would be welcome.)
Jessie will be the first apt release to use it at all.
Various unstable versions had support for it since 2011 I think,
which means some derivatives have picked it up at times, but well,
its not like you would have to choose between both schemes…
> >Having explained both behaviours as non-bug, I hope its clear why I also
> >mark this bugreport as done with this message.
>
> As I wrote above, the first behaviour is IMO still buggy as it
> occurs after APT has already received the Release.gpg file.
> (Would it behave the same with InRelease?)
>
> Generally, APT should not download *any* files from a mirror
> before it has not verified the {,In}Release file content and
> can then act upon that. I cannot see any valid reason for it
> to do otherwise; maybe there is, in which case please tell ;)
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. ;)
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: Digital signature