[background] on Linux, sensible people *never* install programs that haven't
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?