Re: dpkg-sig support wanted?
On Fri, 25 Nov 2005, Anthony Towns wrote:
> (I'm amazed the security "crisis" we're having is about deb sigs
> *again*, when we're still relying on md5sum which has a public exploit
> available now...)
Do you really want a thread about how we should switch everything to SHA-512
or something like that?
> Huh? Why do you want multiple signatures of a .changes file?
If I am to do with a .changes file everything I can do with the in-deb
signatures, it needs to support at least nested signatures.
> > and also that the .changes file will be stored in the
> > archives along with the .debs,
>
> As it turns out, that's probably not feasible per se -- it likely implies
> too much inode usage, and slack space.
That speaks for in-deb signatures in the usability department.
> > and that .debs with wrong/incomplete/missing
> > Source: fields will be rejected (such as all automated bin-NMUed .debs made
> > until about a week ago, or any made by a maintainer right now),
>
> Huh? I don't think #62529 is fixed yet. If you think you'll have better
> luck at doing so, be my guest. That's not a prerequisite for verifying
> packages from changes files though.
Well, the email about the new bin-NMU structure implied that it was fixed
for *NMUs done through that structure*. I very much doubt we can produce
bin NMUs in our systems with the proper Source header without taking very
special steps.
> > > My objection is that it's *useless* for *Debian*. Debian has too many
> > > sources for packages for key management to be plausible, and keeps
> > This applies to .changes files too, with the aggravating addition that those
> > are a bitch to find right now.
>
> Uh, no, .changes files are not remotely useless for Debian right now.
> Where would you get that idea?
I was refering to "Debian has too many sources for packages for key
management to be plausible". Duh, obviously .change files are useful for
Debian, DAK needs them.
> The tools are the least concern; what's a few dozen lines of code here
> and there matter? If you insist every package only be uploaded once, and
> do the maximum packages per day, and stop all other development just to
> get deb sigs done, it's roughly half a year before that's finished. New
> packages, bug fixes, new upstream versions will make it take longer.
Who said anything about adding in-deb sigs to the entire archive?
> > where dpkg would simply refuse
> > per user-set policy any non-signed deb or any deb without a specific
> > signature...
>
> I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting
I see I have to spell it out completely all the time, for you will always
assume you are talking to clueless people who either doesn't know anything
about the issue at hand, or who will be impressed by your over-use of
"snake-oil".
If I want dpkg to always check a signature, it is because it is a signature
I know must be there. Like an hypothetical signature added by
DAK/dinstall/whatever, or a signature I add to all debs in a specific
repository under my control (and in this case, with a timestamp under my own
control too, which means I can use it). Doing so with signed release files
is possible, but not always in the same way and under the same conditions,
and it requires a lot of fragile infrastructure which would be less fragile
using in-deb signatures.
> a signature by a random Debian developer to mean something is not
> reasonable.
YOU are the one who is bringing in signatures from j.random developer.
Which, I should add, is all we have in .changes files. Release files are
something else, though.
> I'm tempted to do something like that anyway to see if the md5sum
> exploit can be used to create fire and ice .debs. Without signed debs,
Make that an exploit that says "kaboom, you're it" but still runs dpkg, and
I will help you with it.
> you'll have no reason to trust it, which is exactly right; with signed
> debs, you'll have reason to know I built it, but you won't have reason
> to know I was never going to upload it to Debian because I was just
> experimenting with some possible security vectors. The question is, will
> you make the unwarranted assumption that because it's been built by me,
> that it's usable my you?
I won't, that's for sure. I might trust such a deb because it was in a
archive where you place debs for general use or something else like that,
but not because you signed it.
> The explanation you need is "...which is useful because _____". Again, I
> can't see any need for multiple signatures for Debian; for non-Debian,
> if deb sigs are convenient, use them.
deb sigs get a lot less convenient if Debian doesn't allow them in debs
uploaded to the archive. I don't really care if Debian will ever use the
in-deb signatures somehow or not, but I'd like to see them allowed into the
archive.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: