If you're in the Bay Area, you may be interested in TechShop (http://www.techshop.ws/). They're up in the industrial complex across highway 101 from Menlo Park off the Marsh Rd. exit. Like the Crucible in Berkeley, they're a place with a bunch of tools for prototyping: PCB etchers, 3d printers, electronically controlled lathes, CNC milling machine, etc. They're scheduled to open their doors in August, I think. $30 gets you a "day pass" to use all the equipment in the building. $100 gets you a monthly membership.
Before all your project members start spinning PGP keys, you might what to ask yourself, "what do I hope to achieve by signing releases?" Digital signatures are used to prove two things:
The key holder was in posession of the private key at the time the release was signed, and
The key holder was in posession of a hash of the thing that got signed.
Everything else is implied by policy and semantics. For reasons I'm unclear on, people frequently confuse signed code with trusted code. You can make signed code trusted by promising to do things like check the code for correctness, verify that all the submitters to the project were upstanding people, and swear on a stack of holy books that you implement good security practices to protect the integrity of your source base. Establishing trust is a tricky proposal.
Applying crypto alone to solve trust issues is, in general, a bad idea. As fun as it is to spin PGP keys, read off key fingerprints over the phone, and so forth, it a hollow exercise unless you publish the meaning of the signature. For instance, many OS vendors and languages have the concept of signed code. Code signing has been hailed by some as the panacea for all our trust issues. Well guess what. Bad guys can sign code just as easily as good guys; the only thing that keeps your copy of Internet Explorer from being hijacked by roving gangs of underaged hax3n is the default settings for whose signing keys are considered trusted. And guess what? Thats something that's established by policy. And sometimes even this is not enough. In order to be enrolled for a code signing key, you usually have to jump through some adminsitrative hurtle like showing up at a notary public and proving you're not Kevin Mitnick and then faxing a notarized statement to an underpaid Verisign employee. Some manner of voodoo then occurs that results in a certification authority making a public statement about how good a guy you are. If you're a bad guy and you can convince a certifying authority that you're really a good guy, bingo! you now have trusted code running amuck in your cozy WinXP install.
But we all knew this was a problem and use Linux or FreeBSD or OpenBSD.
Okay... before I fall too far down the rabbit hole, let me try to make some constructive statements.
There are a couple of places where crypto is important to your project. The first is to authenticate submitters when they check in files to the CVS tree. SourceForge uses SSH to encrypt username / password pairs when it's time to log into their CVS repository. This is useful for keeping prying eyes from sniffing your submitter's passwords. I believe, but am not certain (and I hope someone can tell me I'm wrong here... I haven't checked anything INTO a SF project in a couple of years.) I believe that SF doesn not REQUIRE you to verify your identity or your machine's identity via crypto. You MAY do it, but I don't know if it's possible to require it.
This can be a problem if someone tries a man-in-the middle attack on you. Assuming your project is of a high level of sensitivity, someone might subvert your connection with the internet and pretend to be your CVS repository (e.g. - sourceforge.) If you're not using crypto to authenticate your repository's identity, the man-in-the-middle can pretend to be them to you and pretend to be you to them. Assuming the stars are aligned, they can watch as you key in your password and voila! they can pretend to be you.
But all is not lost. SF publishes their host keys. Through arcane modifications to files in your ~/.ssh or ~/.ssh2 directories, you can tell your client to barf if it detects MITM shenanigans. Assuming you do this BEFORE your submitters ever log in, you should have a modicum of security. If you do this AFTER your submitters login and select their passphrase, well...
You also have to hope that your submitters are trustworthy. Yeah, sure they're smart coders, but maybe they've jus
Secret Sharing is appropriate for when you need to recover a secret or private key. It's not entirely clear that you need to always have recoverability of a key used to sign a release.
If you publish the semantics that as long as your release signing key is signed by a "trusted key" and then make sure that individual release managers are somehow authenticated before their keys are signed, you should be okay, assuming your release managers practice good crypto hygeine.
Slashdot Mirror
If you're in the Bay Area, you may be interested in TechShop (http://www.techshop.ws/). They're up in the industrial complex across highway 101 from Menlo Park off the Marsh Rd. exit. Like the Crucible in Berkeley, they're a place with a bunch of tools for prototyping: PCB etchers, 3d printers, electronically controlled lathes, CNC milling machine, etc. They're scheduled to open their doors in August, I think. $30 gets you a "day pass" to use all the equipment in the building. $100 gets you a monthly membership.
Before all your project members start spinning PGP keys, you might what to ask yourself, "what do I hope to achieve by signing releases?" Digital signatures are used to prove two things:
Everything else is implied by policy and semantics . For reasons I'm unclear on, people frequently confuse signed code with trusted code. You can make signed code trusted by promising to do things like check the code for correctness, verify that all the submitters to the project were upstanding people, and swear on a stack of holy books that you implement good security practices to protect the integrity of your source base. Establishing trust is a tricky proposal.
Applying crypto alone to solve trust issues is, in general, a bad idea. As fun as it is to spin PGP keys, read off key fingerprints over the phone, and so forth, it a hollow exercise unless you publish the meaning of the signature. For instance, many OS vendors and languages have the concept of signed code. Code signing has been hailed by some as the panacea for all our trust issues. Well guess what. Bad guys can sign code just as easily as good guys; the only thing that keeps your copy of Internet Explorer from being hijacked by roving gangs of underaged hax3n is the default settings for whose signing keys are considered trusted. And guess what? Thats something that's established by policy. And sometimes even this is not enough. In order to be enrolled for a code signing key, you usually have to jump through some adminsitrative hurtle like showing up at a notary public and proving you're not Kevin Mitnick and then faxing a notarized statement to an underpaid Verisign employee. Some manner of voodoo then occurs that results in a certification authority making a public statement about how good a guy you are. If you're a bad guy and you can convince a certifying authority that you're really a good guy, bingo! you now have trusted code running amuck in your cozy WinXP install.
But we all knew this was a problem and use Linux or FreeBSD or OpenBSD.
Okay... before I fall too far down the rabbit hole, let me try to make some constructive statements.
There are a couple of places where crypto is important to your project. The first is to authenticate submitters when they check in files to the CVS tree. SourceForge uses SSH to encrypt username / password pairs when it's time to log into their CVS repository. This is useful for keeping prying eyes from sniffing your submitter's passwords. I believe, but am not certain (and I hope someone can tell me I'm wrong here... I haven't checked anything INTO a SF project in a couple of years.) I believe that SF doesn not REQUIRE you to verify your identity or your machine's identity via crypto. You MAY do it, but I don't know if it's possible to require it.
This can be a problem if someone tries a man-in-the middle attack on you. Assuming your project is of a high level of sensitivity, someone might subvert your connection with the internet and pretend to be your CVS repository (e.g. - sourceforge.) If you're not using crypto to authenticate your repository's identity, the man-in-the-middle can pretend to be them to you and pretend to be you to them. Assuming the stars are aligned, they can watch as you key in your password and voila! they can pretend to be you.
But all is not lost. SF publishes their host keys. Through arcane modifications to files in your ~/.ssh or ~/.ssh2 directories, you can tell your client to barf if it detects MITM shenanigans. Assuming you do this BEFORE your submitters ever log in, you should have a modicum of security. If you do this AFTER your submitters login and select their passphrase, well...
You also have to hope that your submitters are trustworthy. Yeah, sure they're smart coders, but maybe they've jus
Secret Sharing is appropriate for when you need to recover a secret or private key. It's not entirely clear that you need to always have recoverability of a key used to sign a release.
If you publish the semantics that as long as your release signing key is signed by a "trusted key" and then make sure that individual release managers are somehow authenticated before their keys are signed, you should be okay, assuming your release managers practice good crypto hygeine.