[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Packages and Signatures, a summary

...or "Why IRC sucks".

First the summary, then the (somewhat edited) logs. This summary is
naturally biassed depending on how I misunderstood stuff. Read the logs
for the real deal.

The summary:

	* As is usual, everyone thinks the best solution is just to
	  implement everything everyone ever suggested and be done
	  with it.

	* Nobody uses GPG securely. (It's true. Someone should write a

	* We still need to come up with some reasonable way of updating
	  the dinstall key used to sign Packages.gz files.

	* Verifying uploader-signed .debs is valuable as long as its
	  done by hand with the full knowledge of the admin. Automating
	  some aspects is plausible, certainly, but automating everything isn't.

The idea being discussed toward the end of these logs is basically how
to automate which aspects of verifying a signed .deb. Note that this
isn't for your casual user, it's for paranoics who also have some idea
how Debian actually works. It breaks down into a couple of parts:

	* First, you have to keep your local copy of the keyring very
	  secure. You don't want an NMU of tictactoe overwriting it, eg.

	* Second, you need to have some way of working out who, exactly,
	  *should* be signing which packages. The best mechanism is
	  just knowing everyone in the project, and what they should
	  be signing.  The suggested mechanism is something like an
	  authenticated Maintainers file, but also with information
	  about how should be NMUing what, as far as Debian knows.

	* Third, if you automate this (getting the Debian trust db, and
	  installing packages suggested by it), it's no more secure
	  than doing it with Packages.gz files, which is easier to
	  do. If you don't automate it, and use common sense as well,
	  you can be much *better* off.

Note that none of this is a prerequisite for implementing signed

And so, that leaves us with the logs.

FX: lights dim
    curtains close
    grainy black and white projector whirs up
    curtains open
    short animation
    fade to black...

The voice over begins: For tonight's episode of `Supa Secret Developer
IRC Discussion', we present...

	``The Signed Packages Dilemma''


	Jason Gunthorpe, as Culus, the Mad Hacker!
	Joey Hess, as joeyh, Mr False Modesty, himself!
	Manoj Srivistava, as Manoj, the paranoiac!

with guest appearances by:

	James LewisMoss, as dres_
	Brendan O'Dea, as bod
	Mark Brown, as broonie
	Edward Brocklesby, as is (ha!)
	Randolph Chung, as tau^2
	Chris Waters, as xtifr

And, as your narrator,

	Anthony Towns, as aj

We begin with the arrival of Manoj, who is cheerfully accosted by Culus:

<Culus> Manoj:  Lets say that someone were to actually implement
        signed package files..
<Manoj> Culus: Yes?
<Culus> Manoj:  Would you think people would yell and scream?
<aj> Culus: nah, all the yelling and screaming has finished for
        a couple of months now
<joeyh> Culus: I think people would stop talking abstract,
        and start adopting it, and actually find the problems people keep
        bringing up, if they exist.
<Culus> joeyh:  That doesn't work with crypto systems
<dres_> aj: joking? always can find more things to yell and
        scream about. :)
<Culus> by the time you find the problems it is too late
<Culus> it either is or is not good
<Manoj> Culus: No. I think that signed package files do two
        things: prevent man in the middle attacks, and perhaps prvide a way
        of ensuring the package is a Debian package, not just a package by
        a Debian developer
<joeyh> Culus: all the problems I saw with signed packages were
        at the level of "what do we do once we have them"
<aj> dres: yeah, but people'll have gotten bored with packages.gpg
        now, and they'll yell and scream about other things instead;
        you watch
<Culus> Manoj:  I've become rather fond of the thought of having
        the security  key on each release
<Culus> Manoj:  I like that alot for some reason
<Culus> aj: Global index :P
<Manoj> Culus: Beware the irrational temptation for mad grabs
        of power ;-)
<joeyh> Manoj: too little, too late ;-)
<Culus> Manoj:  haha :P
<aj> Culus: nah, no one cares about that
<Manoj> Culus: However, signed debs prvide security against a
        maddned dinstall/hacked master
<Culus> aj: Smite!
<aj> Culus: well, except you
<Culus> Manoj:  No more than keeping .changes though
* joeyh just wants to know that this make .deb is from Manoj. I don't care 
        if it doesn't help the end-user.
<Culus> aj: And I have a very valid reason why thank you
<aj> Culus: and it's arguably better too; it's at least
<Manoj> The problem with signed debs is, of course, that it has
        little meaning for vast majority of people, unless they can get
        the developers key into their web of trust
<joeyh> see above
<Culus> joeyh:  You want apt to stop after each deb and say
        'this package is from Manoj, would you like to accept it [Y/n]' ?
<aj> joeyh: having fun messing with lwn's mind, btw?
<Manoj> Culus: keeping .changes in the .deb is adequate as
        a signature
<joeyh> aj: weekly
<Manoj> Culus: thoguh that won't quite work ;-)
<joeyh> Culus: something along those lines. I'd probably just
        validate my mirror after each mirror run.
<Culus> joeyh:  How *exactly* do you validate it?
<Manoj> Culus: How are you planning on keeping .changes in a
        fashion that is secure?
<joeyh> Make sure all packages are signed by a developer in
        my keyring.
<Culus> Manoj:  I was thinking of keeping an indefinate archive
        of d-d-changes on murphy and another box
<Culus> joeyh:  That doesn't say that make is from manoj though
<joeyh> sorry, that was just an example.
<Manoj> Culus: I would like to see the data.tar znd control.tar
        be signed, and the signature be carried around in the .deb; so I can
        pick up a .deb off the street, veruify it comes from a developer,
        and install
<Culus> Manoj:  I really think that just gives a false sense of
        security, but people seem to want it and wichert is keen on giving
        it to them so I expect you'll see that
<Manoj> Culus: Umm. I need network connectivity for that, and
        I need a secure method of accesing murphy
* joeyh would certianly verify .deb's hw downloads from random websites, if 
        it were possible.
<Manoj> The problem I see with signed packages files is ensuring
        the integrity of the signing process.
<Culus> Manoj:  I see that as being akin to SSL
<Culus> and very good in the case of stable releases
<Culus> so I like it alot
<joeyh> I don't get it, how is it different than signing .changes?
<Manoj> joeyh: how does one do that? A signed .deb would
        accomplish that, yes, but looking at the md5sum in an insecure
        Packages files is, umm, to many unknowns
<joeyh> I'm all for both. I woul personally use signed .deb's
        more tho
<Manoj> Culus: A combination of signed .debs, and a signed
        packages file, would be optimal, IMHO
<joeyh> oh, I somehow read "packages files" as "debs". Must
        be tired.
<Culus> See, I worry people will trust signed debs far more than
        they should be trusted
<Culus> our signed deb != RH signed rpm, Bug Huge Freaking
<Manoj> joeyh: you have to sign the data.tar and control.tar
        files in the .deb ar archive
<joeyh> I disagree. I don't think the man on the street will
        have any conception of what ".deb Signed by Manoj" stands for. I
        do, and I trust it. He would tend to trust "collection signed by
        the debian project" more.
<Manoj> joeyh: you are correct, to a point
<Culus> joeyh:  But the question remains, how do you check that?
<Manoj> joeyh: however, we come into trust issues now
<aj> Culus: But as Apt's author, you get to decide what Joe
        Regular trusts; it'll just be whatever Apt defaults to giving
        errors about
<joeyh> right.
<Culus> You have to manually have a step where you specificaly
        check that the .deb is from manoj
<joeyh> yes.
<Manoj> 'joeyh: if Debian gains a reputation, and Debian
        provides a secure keyring (signed and all), then knowing a package
        is signed by a guy in the keyring may have value, even for the man
        in the street
<Culus> Without that step the whole signed deb thing is pointless
<joeyh> perhaps dpkg --force-checks-sigs --fail-if-maintainer-did-not-sign
<Culus> joeyh:  You mean keep a persistant record of who signed
        the currently installed package?
<joeyh> no, this would be on a package I am installing.
<Manoj> I am tired, andf there are too many threads to this
        discussion ;-(
<aj> Culus: BTW, if Debian signs Corel's key and/or vice-versa,
        we probably need a standard format, signed message like: "The
        Debian-unstable key is now: <public key>." signed by past valid
        keys, when a debian key gets updated. Rather than just (ab)using
        the web of trust for it.
<Culus> joeyh:  Then it is pointless
<Culus> you are checking that the internal maintainer field
        matches the signature?
<aj> Culus: I think I could implement that in shell, or so,
        if that's any help.
<joeyh> Manoj: true, but I don't see that happening for eg,
<Manoj> aj: diziet came up with a cryptographically secure method
        of interlocking signatures to create a signing key for debian
<aj> Manoj: nod
<joeyh> of course, they do it brain-dead anyway.
<aj> Manoj: do you know where that is?
<Culus> Manoj:  That was too complex I think
<Manoj> aj: I have a copy stashed somewhere, but I can't look
        till tomorrow
<Manoj> aj: I am not looking through my tapes at this point ;-)
<aj> Manoj: your /tapes/? errr, don't go to that much trouble :)
<Manoj> Culus: Do you have an objetion to having dpkg sign the
        data and control files, and add the signature to the .deb?
<Manoj> aj: it is niot a major deal -- I'll look when backing up,
        and I can backup slightly earlier
<xtifr> ooh, sounds like a good idea
<xtifr> unless I'm overlooking something....
* joeyh really feels we are having a tough time separating signing packages 
        and how to use them once signed.
<aj> xtifr: it's hard to verify, and hard to draw meaning from;
        but it is a good idea
<aj> verify? implement. in dpkg. as in.
<joeyh> and the fact that some people drag eccessive paranioa
        into it doesn't help. I want a _tool_. I have to trust myself to
        have the brains to use it wisely.
<Manoj> Culus: So a .deb can optionally hae the developers
        signature. Now, we put a signed gpg keyring out there, people can
        have an assurance that the guy signing the apckage is a developer
        (how much to trust him, they have to decide). Now, a signed packages
        file, ensures that someone has not substituted another .deb (with
        perhaps a valid signature) on the mirror du jour. This prevents
        mirror in the middle attacks.
<joeyh> and to weigh the benefits and risks.
<Manoj> joeyh: The weak points are: you have oto trust the
        deelopers machine is secure, and his key has not been stolen; and
        secondly, that the packages file is signed by an authorized user
        on master.
<Manoj> The former I don't have a solution for; the latter means
        that human intervention shall be required to sign the packages file,
        and then 2 reduces to 1.
<dres_> Manoj: always the end points. is it secure if any one
        key is compromised?
<Manoj> dres: if a maintainers key is compromised, another
        developer can put in a trojan
<aj> dres: compromising a single key lets you masquerade as that
        developer; making nmus, getting db.d.o to change your password and
        login, stuff like that, at least until someone notices and revokes
        the key
<dres_> Manoj: that seems to be the thing to protect against.
<Culus> Joey:  I think the question of tool and its utility
        is critical in deciding what kind of scheme to implement, if you
        scheme needs a tools that nobody will use properly then it sucks.
<Manoj> dres: however, a signed packages file means that
        you can't do a mirror in the middle attack, even if you know a
        develoerps key, unless the developer happens to be the one who runs
        and signs dinstall
<dres_> aj: sure, the question is more if the keyring can be
<aj> how often do we think the unstable/dinstall key would need
        to be changed?
<Manoj> joeyh: I'll come to usage in a moment
<joeyh> Culus: I think it's as if you were arguing the signed
        email is useless because a majority of people will blindly trust
        anything they read in signed mail.
<Culus> Joey:  No.. I would argue signed email is useless if
        mutt did not show the singing key when it showed you the message
<aj> (ie expire, or be compromised, or we'd get bored with it,
<xtifr> wait, are you guys saying that I *shouldn't* have put
        my private key up on my web page?  :)
<Manoj> aj: more frequent changes may not be more secure; since
        people have to get the changed key and trust it
* bod sees a minor problem with debs containing signatures
* Manoj kicks xtifr
<aj> Manoj: are we talking infrequent enough that doing it by
        hand is not a problem?
<joeyh> Culus: so you're down to an app implementation detail. Why
        should an app implementation detail defer someone implementing
        signed {email,debs} immediatly.
<Manoj> aj: yes
<bod> how does a developer sign packages built by the
<Manoj> aj: changing the dinstall key should be a major deal
<aj> bod: by hand, on their own machine
<joeyh> bod: the same way they sign .changes files, presumably.
<Culus> joeyh:  Point. If nobody intends to use them as they
        need to be used then why do you provide them?
<Manoj> aj: we have to propogate the changes; and perhaps have
        it signed by more than one developer, and have it widely published
<xtifr> yes, I'd like to meet mr. dinstall in person one of
        these days
<aj> Manoj: yes, that makes sense. too automated is definitely
        bad. good.
<joeyh> bod: which might be varying degrees of secure. Or not
        much at all, I have no clue how the autobuilders work.
* Manoj thinks very few people really use gpg securely
<bod> aj, joeyh: I thought that the proposal was to sign the
        binaries, not the source
<bod> the source is already signed
<joeyh> bod: source is already signed, around the same time the
        binaries would be signed.
<tau^2> Manoj: you mean with locked away floppies and such?
<joeyh> ie, binary signing would be part of the build process,
        along with source signing.
<dres_> Manoj: on no machine connected to a network?
<aj> bod: .changes files include the .deb's though, don't hey?
<bod> now?
<aj> bod: the idea is just to move the signatures into the .debs
        as well, to make life easier
<joeyh> yes, they do.
<bod> hrm
<tau^2> Manoj: i doubt anyone does actually :/
<Culus> Manoj:  I think .deb signing boils down to the only
        automated way to use .deb signatures is not much more secure than
<Manoj> dres: I boot from readonly known media while disconnected
        from the net, pop in floppy, mount floppy, sign, unmount floppy,
        reboot to reconnect to the net
<Culus> Manoj:  so I question their value
<bod> excuse me if this is naieve, but would it not be possible
        to have a single debian key?
<Manoj> Culus: I disagree.
<Culus> bod:  We have the security key
<bod> ie. developers upload with signed .changes
<is> bod: how to change the key?
<bod> then the binaries are signed by a `debian' key
<Manoj> Culus: When I sign my .deb; and that signatuire is a
        part of the .deb; why does it not have value? Not all my packages
        are distributed by Debian, BTW
<joeyh> Culus: "not much more secure". That is a value decision,
        IMHO. Please don't force your values on me
<joeyh> bod: I have no way of knowing then that manoj actually
        built a package.
<is> bod: removing developers etc
<is> bod: and what does it gain?
<aj> joeyh: were the an Uploader: field in Packages.gz, you'd
        have a way of knwoing to some extent. not that there is.
<Culus> joeyh:  if it is going to be project policy to accept a
        certain overall security protocol I think the project should make a
        very carefull choice that can be correctly understood by our users
        and developers!
<Manoj> aj: the problem with .changes file is that they are
        detached from the .deb;
<xtifr> bod: also greatly increases the chance that the key will
        be compromised
<aj> Manoj: exactly
<bod> is: a much smaller keyring
<joeyh> aj: I'd not know for _sure_, because master may be
        compromized, etc. It'd be nice to know, ever were master compromised,
        that manoj made this deb sitting on it.
<aj> joeyh: you'd have debian's word for it, just not manoj's
<Culus> Everyone keeps saying they want to check that the .deb
        comes from a developer, but nobody has explained how to do that!!
<aj> joeyh: obviously manoj's would be more reliable for that
* joeyh prefers to trust Manoj over Debian, thanks.
<joeyh> ;-)
<Manoj> aj: you can't put a changes file in the .deb; you need
        dpkgt to actually sign the tar files themselves which make up a .deb
<tau^2> Culus: first you pick up the phone....
<bod> the changes file doesn't relate to the binary at all
<Manoj> The signed paclkage file does soemthing different
<Manoj> The signed package file (modulo compromise) says this
        is a official debian package, and not just changed on this mirror
<aj> So does anyone have a problem with both being implemented,
        and Debian defaulting to using singed Packages to check validity
        of .debs, but leaving other signatures there if other people want
        to use them?
<joeyh> Culus: er, what do you mean? I can check if a signed
        .deb comes from manoj the same way I can check if a singed email
        comes from manoj.
<Manoj> The signed deb says the maintainer really created this
<Manoj> They are two different assurances
<Culus> joeyh:  Sure, but how are you going to integrate that
        into your daily upgrade routine?
<joeyh> Culus: again, I don't think integration and use is
        what matters.
<aj> Manoj: should i keep saying `yes' and `agreed' and `metoo',
        or just let you talk? :)
<Culus> joeyh:  Humor me, what would you do?
<xtifr> be nice to be able to mark certain packages as "always
        check sig", while leaving others (with minimal security implications)
<joeyh> how I use it depends on what tradeoffs I want to
        make. Maybe I only accpet .debs from Manoj, because I only trust
        him. Whatever..
<Manoj> Culus: I run a script off apt preinstall that looks at
        the signature, looks at the debian keyring sitting on my cdrom,
        and bails if it fails
<Manoj> (You do have the keyring burned into a cd, right?)
<joeyh> xtifr: all packages have identical security implications.
<aj> Manoj: and what do you do when new-maintainers reopens?
<Culus> Manoj:  So uh.. That has all kinds of horrible attacks
<aj> Manoj: half a dozen changes to the keyring every week...?
<bod> Manoj: the keyring and the deb are on the same CD?
<xtifr> Joeyh: not if I know that I use some packages as root
        and not others
<Culus> bod:  No he means his keyring is very trusted
<Manoj> Culus: I first run a script that checks the packages
        file, then checks the mirror against the apckages file (I do this
        late night)
<joeyh> xtifr: no, all are identical.
<joeyh> debhelper.deb can contain /lib/libc.so
<Manoj> aj: when NM reopens, I wait for a new keyring, and ensure
        it si signed by james key which is on the cdrom
<Manoj> aj: then I replace the cdrom
<Manoj> bod: heck, no. the cd only contains the current keyring
        that I trust
<bod> ah
<xtifr> joeyh: ok, yes, but that doesn't mean I want to check
        every package every time; I might be more concerned with the packages
        that I run as root -- certainly I'd be no worse off than I am now
<Manoj> Culus: what attacks?
<Culus> Manoj:  So all you have done is say that the package came
        from a person who's key you once trusted to belong to that person
<bod> CD because you don't trust mag media?
<joeyh> ok, that's your tradoff (but Imho, it's not a good idea;
        all package's maintainer scripts run as root)
<Culus> Manoj:  You haven't checked that it is the right person!
<dres_> Culus: that's always true.
<Culus> You all realize there are ~645 keys in our keyring
<dres_> Culus: there has to be some trust somewhere.
<Manoj> Culus: Packages file checks out (against my trusted
        keyring). I check mirro for all debs therein. .debs are fine. Now
        before I install, I check each deb against the keyring again --
        any failrure, I bail. Now I know the .deb comes from debian, and
        it was created by an official maintainer.
<Manoj> This is way better than I can do now
<xtifr> joeyh: well, it might depend on the overheads -- if
        checking all packages is almost transparent, that's one thing;
        if it's a major hassle for each package, that's quite another...I
        had the idea that it might be the latter
<joeyh> well, I think we've recapitulated the discussion nicely,
        now we seem to be back to "no security is absolute, so I want none
        at all"
<dres_> joeyh: :)
* aj repeats: So does anyone have a problem with both being
        implemented, and Debian defaulting to using singed Packages to
        check validity of .debs, but leaving other signatures there if
        other people want to use them?
<Manoj> joeyh: I think that we need both methods. What do
        you think?
<Culus> Manoj:  What is the point of the .deb checj?
<joeyh> Manoj: full agreement
<Manoj> aj: I have no issues at all with implemnting both methods
<aj> Manoj: and debian defaulting to just using the former?
<dres_> Culus: replacing files on a mirror.
<Culus> dres:  eh?
<Manoj> Culus: protects against master corruption: I know the
        deb comes from a maintainer
<aj> Manoj: (ie, the latter needs an admin to take special care,
        beyond just pointing and clicking)
<xtifr> I have no problem with both if it can be shown to work
        technically (I realize that's the next step)
<joeyh> aj: I don't think we have to worry about debian's
        defaults, I would assume that if we don't default to check the
        latter, people will write tools anyway to do so with varying intents.
<Culus> Manoj:  If master was corrupted in that way the attacker
        would have no trouble forging an arbitary pgp signature on a .deb
<Manoj> Culus: You need to compromise both individual keys *AND*
        master to put a fake package on my machine
* joeyh states at culus
<joeyh> <Culus> Manoj:  If master was corrupted in that way the
        attacker would have no trouble forging an arbitary pgp signature
        on a .deb
<joeyh> !!!!
<joeyh> wtf!
<Manoj> Culus: really? Please forge my pgp signature. I'll give
        you root on my machine.
<aj> joeyh: ssh hack, etc
<joeyh> ok, you've got root on master, go produce a .deb signed
        by me.
<Culus> joeyh:  I've shown it already! I, AS ROOT on master
        could have HACKED Julians box.
<Manoj> Culus: Pleawe hack mine
<joeyh> oh, the ssh agent thing?
<Culus> Manoj:  I don't need to hack yours.
<Culus> Manoj:  I need to hack the single weakest developer
<aj> Culus: that won't let you change manoj's keyring though
        in action)
<Culus> aj: I steal a key in his keyring
<Manoj> Culus: That is still a higher bar to pass.
<Culus> aj: Any hey, there are 645 to choose from
<Culus> Manoj:  I think the incremental jump from hacking master
        to hacking the weakest developer box is very, very, small.
<Manoj> Now not only do you have to hack master, you have to
        find a machine to ssh into, then you have to crack the passphrase
        on the gpg key (if it is on the machine you crack)
<Manoj> The point is not perfect security, but in raising the
        bar higher
<Culus> Manoj:  Core dump mutt and steal the passphrase it stores
        in ram.
<joeyh> Manoj: amen
<Manoj> (perfect security makes it impossible to actually do
        any work)
<joeyh> [consult your most recent perfect security thread,
        I'm sure you've read them..]
<aj> Culus: but, depending on what manoj does with his signed
        .deb's, he mightn't accept Julian's NMU of debian-keyring, or gpg,
        or login, or a bunch of other things. This may, eg, give him the
        ability to recover from a compromise much better than he could
        otherwise. It adds /something/.
<Manoj> Culus: sorry, there are fewer and fewer chances at
        each level
<Manoj> core dump mutt?
<Culus> Manoj:  Ever wonder how all those people who sign every
        email do it? Passphrase is stored in ram in the mutt process.
* Manoj is designing security policy on a DARPA project right now
<Culus> cat /proc/`pidof mutt`/mem
<aj> Culus: (well, some of us just type the fucking thing out
        repeatedly too)
<broonie> Culus: Or they type it every time...
<aj> Culus: (god it's painful)
<xtifr> sounds like another reason for me to continue not using
        mutt :)
<aj> Culus: now *trojaning* mutt, that would be more like it
<Culus> *shrug*
* Manoj mutters against silly users of gpg
<xtifr> aj: that introduces a bootstrap issue -- the point of
        this exercise is to be able to create trojans
<broonie> xtifr: The time it takes to forget is configurable.
<Culus> Manoj:  Thats why I think we are making a bad statement
        by signing .debs
<Culus> People will just assume it has the same meaning as a RH
        signature on a deb - but it doesn't!
<xtifr> broonie: well, that's something, still not my cup of tea,
        though :)
<Manoj> Culus: you have to hack master, crack a users box,
        sneak in when they are using mutt (and crack mutt;s encryption --
        I hope they encrypt the pass phrase in ram)
<aj> xtifr: ssh into the machine, make a mutt binary in ~/bin,
        add ~/bin to the user's default PATH, wait
<Manoj> Culus: I think you are over reacting
<xtifr> aj: ah, good point
<dres_> time for sleep...
<Manoj> Culus: any signature is ultimately not perfectly
        trustwothry since you don't know the protocols used while making it,
        or the protocols keeping the private key secure
<Culus> Manoj:  I see the act of cracking master a very high bar
        already - if someone was set upon injecting a trojan into debian
        they would have no qualms at going onwards.
<Manoj> Culus: But that by itself is not reason enough not to
        implement the signature scheme
<Manoj> Culus: But signed debs allow security for non-debian debs
<Culus> Manoj:  But then actually checking the signatures is
        little more than throwing salt over your shoulder
<Manoj> like stuff i make available for testing, etc
<Culus> Manoj:  I'll grant you that signed debs are very powerfull
        when each one is hand inspected
<Culus> *very powerfull*
<aj> Culus: which is a reason to implement them
<Manoj> It adds value. Just cause some idiots are going to think
        it is way more securte than it is, well, most epolpe using debian
        lilkely fall into that category
<aj> Culus: albeit not do anything with them automatically
<Culus> aj: Yes, I never really said we shouldn't implement them,
        I just worry about automated checking
<Manoj> Culus: I shall inspect the .debs against a trusted
<Culus> Manoj:  Not good enough :> If you download something
        from your site check that it is signed by you and not me :>
<Manoj> sheesh
<Manoj> getting Culus to this point was hard
<joeyh> Fact is, there are people out there who build as many
        .deb's as possible from source, because they want to be able
        to verify sigs first, and you cannot currently do that with
        binaries. We've heard from some of them on the lists, I think
        biffhero is another. So there's evidence there are people who this
        could directly benefit.
<Manoj> Culus: whats wrong with checking against a trusted
        keyring in apt preinstall?
* tau^2 thinks we are going in circles
<Culus> Manoj:  That is what I primarily object to right there.
<Manoj> Culus: I see.
<Manoj> Culus: well, yes, my automated check assumes that I
        trust all developers
<Culus> Manoj:  I think to advertise that feature is overstating
        our security to our users!
<Manoj> tau^2: hush. we have Culus rattled
<Culus> joeyh:  Yes.. those people who are so paranoid would
        not use automated checking
<Manoj> Culus: My machine, my policy, right?
<tau^2> Manoj: heh, well, i'll go sleep and leave you guys
        alone... 'night
<aj> ummm.
<Culus> Manoj:  Sure, but I don't think the *project* should
        advertise that this is marvelous new thing
<Manoj> Culus: I probably would try and make sure the maintainer
        and the sig match, in some way
<joeyh> yes, but they would probably enjoy the convenience of
        being able to install selected binary .deb's of say, X, without
        having to build the whole damn thing to verify it.
<Manoj> Culus: We shall mention your objection in every place
        where we do so advertize
<Culus> Manoj:  I would add a 'make.deb is signed by MANOJ,
        Accept [y/n]' feature to APT
<Culus> Manoj:  But I don't think I would want to see it done
        without that prompting
<Manoj> Culus: good enough. I would use that feature
<Culus> Manoj:  I also like the idea joey brought up of storing
        that 'make was accepted from MANOJ' so all future makes from manoj
        are accepted too
<joeyh> I did? Oh well, give me credit, I doin't mind..
<Culus> Manoj:  I think doing that really makes .deb signatures
        very strong, but only if you know make is supposed to be from manoj
<Culus> which is like 10 people in the whole world who could
        rattle that off for every .deb out there
<Manoj> Culus: Can you pop up the maintainer field from the
        Packages fiel or something?
<Culus> Manoj:  You mean the currently installed maintainer?
<Manoj> If the packages file was signed, and I checked the sig,
        that gives an additional measure
<Manoj> Culus: Yes, what the apckages fiel thiunkls should be
        the maintainer
<joeyh> oh, I just took aj's Packages file corruption idea
        one step further.. Package: debhelper\nProvides: libc6\nReplaces:
        libc6\nConflicts: libc6\n
<aj> joeyh: that wouldn't actually install though, i think
<Manoj> So the maintainer is Bar (from Packages fiel), but the
        signature is from foo, I can reject
<joeyh> aj: why not?
<Culus> Manoj:  I would like to see dpkg store the signer when
        it unpacks. I would prefer to show something concrete like the pgp
        key used rather than something changable like the maintainer field
<aj> joeyh: hmmm
<joeyh> libc6 isn't essential or anything.
<joeyh> may be versioned provides issues.
<aj> joeyh: you'd get dinstall to remove libc6, but not to
        install debhelper, maybe. yeah, okay, i'll pay that
<joeyh> Culus: I'm not sure if there is great utility is storing
        the signer. _That_ could be corrupted by rogue packages.
<joeyh> I agree I'd perfer to see the key id.
<Manoj> Culus: Sounds even better.
<Culus> joeyh:  Non, I mean the maintainer field in the .deb
        does not necessarly have to corrispond to the uploader
<Culus> joeyh:  NMUs for instance, right?
<joeyh> yes...
<Manoj> Culus: wait: I want to check the maintainer as in the
        Packages file against the gpg key in the .deb
<joeyh> I agree about the maintainer stuff, I just don't know
        if storing the data after installing the packages gains you much.
<Culus> Manoj:  Lets do both
<Culus> How about this.. We introduce the concept of a package <->
        Key trust database - which is effectively what we are discussing here
<Manoj> Culus: So the signed Packages file indicates that make is
        from me, but the .deb has your sig, the user can accept or reject --
        (perhaps NMU, perhasps a trojan)
<Manoj> Culus: Go on
<aj> Culus: how do you cope with nmu's then?
<Culus> We can provide a tool that can be run after apt has got
        the .debs on your local machine that displays the trust relationships
        and allows you to edit them
<Culus> it can remember that Manoj is allowed to upload Make on
        a permanent basis and it can permit a single shot NMU upload
<Culus> from aj, lets say
<Culus> It has menus and things to show you that the make package
        claims to be from manoj, and that the current .deb is an nmu from aj
* Manoj mutters he knew there was a reason he
        assigned culus Master status on advogado
<Culus> and, in future, it could connect VIA Ssl to a central
        server and view our information about NMUs and what not
<aj> Culus: is that better than signed Packages though?
<Culus> the whole thing allows you to assign your own trust
        preferences to each .deb and each signer and checks it as
        automatically as possible
<Culus> aj: Yes, much.
<aj> Culus: the trust db would be no more secure than signed
<Culus> aj: but it is not for novice users.
<Culus> aj: The trust DB would be stored in encrypted form using
        the users local key
* joeyh just notices Marcus's post "speaking in favour of signed 
        Packages files"
<Culus> or some other tripwire scheme to keep it safe
<Culus> aj: This is only for the most advanced users.
<Culus> aj: Normal users would use automatic package file
        signature checking.
<aj> Culus: hmmm. okay...
<Manoj> Culus: How do I know who created the current package/?
<joeyh> Manoj: whoever signed it.
<Culus> Manoj:  It would be shown to you in the trust editor
<joeyh> I like this, fwiw.
<Manoj> Culus: Or how does apt guess who created the current
        package, if the .deb is not siugned?
<aj> Culus: in any event, and hax0ring of the trustdb would
        probably be easily noticable, and hence ineffectual
<Culus> and it would say 'Warning! Not signed by manoj!'
<joeyh> if the deb's not signed, I suspect Culus's trust display
        will include lots of red.
<Manoj> Culus: But the package still needs to be signed, right?
<Culus> joeyh:  Yes, I think so too
<joeyh> hehe
<Culus> Manoj:  Yes, package signatures are key to the trustdb
<aj> joeyh: ``Hacking Colourblind Debian Users Made Simple'' ?
<Manoj> Oh. I am sleepy.
<joeyh> lol
<Manoj> cool
<joeyh> ok, we seem to have consensed..
<Manoj> But we need to get dpkg changed, then
<Culus> I like this
<joeyh> er, is that a word?
<Manoj> joeyh: no
<Culus> Manoj:  Naw, all this is external to dpkg
<aj> ``Consensed Milk -- Preferred beverage of Debian developers'' ?
<xtifr> no, not a word!  please, god, make it stay not a word! :)
<aj> Culus: huh? how to you have a signed .deb without changing
<Manoj> Culus: How do packages get signed, then?
<Culus> we wrap dpkg with trusted-dpkg using the APT
        reconfiguration routines which does a trust db check.
<joeyh> xtifr: well, it'd be used so rarely, it doesn't matter
<Culus> We use the apt preinstall checks to hook the trust edtitor
<xtifr> joeyh: :)
<Culus> and we use joeyhs new slang gui to write the editor
<joeyh> aj: dpkg-deb -b is all that needs changed.
<Manoj> Culus: not the check -- thre creation part
<Culus> aj: Oh, aside from that, you need the build tools updated
* joeyh runs screaming from culus
<xtifr> joeyh: not once the marketting droids spot it1 :)
<aj> Culus: right
<Culus> but 'dpkg' doesn't do that :>
<aj> Culus: pffft, it's in dpkgsomething.deb
<Culus> joeyh:  Who has more espies now! :>
<joeyh> Culus: there is probably value in adding a switch to
        dpkg that dumps out a package's sig.
<Manoj> Culus: So we need someone to change dpkg -b to start
        signing stuff
<joeyh> no verification, no value judgements.
<Culus> joeyh:  dpkg-deb I guess.
<xtifr> I *still* want a way to mark a package as "download
        the source, merge in my changes from cvs, build, and then install"
        in apt :)
<joeyh> so, what's this about Benc implementing signed .deb's?
<Culus> Manoj:  been done, in dpkg cvs
<Culus> aj: Can you write this up?

(more or less verbatim; some irrelevencies were deleted)


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

Attachment: pgpSWvR_2R4G4.pgp
Description: PGP signature

Reply to: