...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
HOWTO)
* 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
Packages.gz.
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''
starring:
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
indifferent
<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
Difference
<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
IMHO
<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,
redhat.
<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
compromised.
<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,
or...)
<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
autobuilders?
<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?
<is> MORNING
<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
no-signatures
<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
instance
* 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)
alone
<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
available
<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
(maybe)
<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
machine
<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
keyring.
<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
packages?
<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
thingy
<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
arragement
<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
dpkg?
<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)
Cheers,
aj
--
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