been digitally signed. This is how linux users avoid most malware bollocks:
Each time you sign a package, you give your word (generally trackable back to
the name on your passport) that it isn't malicious. Signing a malware
package, as a trusted developer, would get your name pasted all over
slashdot, and you would be flamed about it for years. (and possibly even sent
to prison, like a virus writer would) [/background]
Most of us on debian have (at some point) tried to install something, and it's
not been signed with a trusted key (one used by a trusted person). We then
have to go and get the key from a keyserver, in order to avoid error messages
each time we install a package signed by this person. This is ugly for a few
reasons:
a) How do you know that the key is trusted. You just got it off an arbitrary
webserver. None of your friends told you that it could be trusted.
b) Can anyone *ever* remember the command for importing keys, and telling apt
that they're trusted?
This is also a problem that alexreg and I identified as a requirement for our
windows apt-msi project, if it ever got off the ground. I think I have a
potentially elegant solution to this problem. Read on.
1) Create a package called trust-<name>-<fingerprint>-1.0.deb, which
automatically imports your key.
2) Make all of your packages depend on >=trust-<name>-<fingerprint>-1.0
That way, anyone who installs your package will only get warned once (if they
get warned a second time, then they can start to worry, in the same way that
ssh server keys work). This scheme *should* work without any special support
from apt.
Also, if you know a trusted developer, and they have you on their web of
trust, you can ask them to sign trust-<name>-<fingerprint>, and put it in
their repository. This way, users (or smart package managers) can install the
trust- package first, and proceed without having *any* "unsigned package"
warnings.
One thing that could be a little tricky is trust revocation. It might be
possible to create a package called trust-<name>-2.0 which revokes trust in
the key, but an attacker could create a package called trust-<name>-3.0 that
foils this scheme. On the other hand, getting onto someone's web of trust
generally means that they have seen your passport, so creating a situation
that required a key to be revoked would necessarily involve identity theft.
What do you all think? Could it work?
2 comments:
It's an interesting idea... my knowledge of webs of trust and package signing has gotten a bit hazy since we last discussed this in relation to apt-msi. I do *think* what you're saying is to treat trust keys like packages and version them. Before I comment further, I'm wondering if when you write:
2) Make all of your packages depend on >=trust-<name>-<fingerprint>-1.0
you imply that later versions of trust-<name>-<fingerprint> would be valid dependencies to a package released at the time that trust-<name>-<fingerprint>-1.0 was released?
Also, your worry about trust revocation seems unnecessary, for the reason you pointed out. What I'm more curious about is the mechanism by which a developer who you consider trusted would sign your key and how this new version would be distributed.
Anyway, I'm definitely intrigued, but perhaps a bit ignorant still. Time to log in to MoinMoin and formalise this? :D I'm thinking I might have even have time to do something about apt-msi later this term, if you're up for it too.
P.S. lol blogger - it seems to think the <name> and <fingerprint> HTML tags are dangerous.
Yeah. Depend on versions greater than 1.0. All versions should contain the same key, but if you let the repository maintainers create a 2.0 package (which will always get preference over 1.0), signed by someone already on the web of trust, you can avoid "unsigned package" warnings. Similarly, they can create version 3.0 which is the revocation certificate.
Post a Comment