Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Programming Technology

Managing Code Signing Digital IDs for Open Source? 103

Posted by Cliff from the project-security dept.
Saqib Ali asks: "What are the best practices for managing Code Signing Digital IDs for Open Source projects, where the developers are dispersed throughout the globe? For our project there is NO central office, where we can secure the private key for the Code Signing Digital ID. Who should have the possession of the private key? Multiple people, or just the project manager? What Key Escrow (recovery) techniques can be used, in case the private key holder is not available? Who should be allowed to digitally sign the build? Currently one person handles the signing responsibility, but I think that is surely a single point of failure. Any thoughts/ideas?"
This discussion has been archived. No new comments can be posted.

Managing Code Signing Digital IDs for Open Source? More

Managing Code Signing Digital IDs for Open Source?

Comments Filter:

  • Why ask? (Score:5, Funny)

    by hyfe ( 641811 ) on Tuesday May 03, 2005 @04:35PM (#12424663)
    Post-it notes all the way baby!
    • Wasn't that supposed to be the end-all of trust & authentication systems?

      Somehow the Longhorn/Passport mechanism will handle all your secuirty needs by magic.

      • Somebody please gilt frame parent as classic example of karma whoring.
        • Too bad it's not an effective means of karma whoring; since the theme for this troll account (Microsoft's team99 astroturfing campaign) is so ludicrous I can really only get Funny mods that don't help this account's Karma.

          I might occasionally try to say something positive enough about Microsoft that it gets as many insigtfuls or informative's as it does Trolls, but I"m not holding my breath.

          I think the best I can hope for is that I retain my +1 as a logged-in-user with thie Team99 parody at least as long
  • not quite sure. .. never though about it.. but most groups i would think would have atleast one backup person for such a job

  • RM (Score:2, Informative)

    by Anonymous Coward
    It's called the Release Manager.

    • I'm not sure how the Release Manager in Debian works, but a lot can probably be learned from Debian here. They (of course) have developers all over the globe, and they use a debian keyring for signing packages, as I understand it.

      Since Debian is deliberately open and accountable in all aspects, you should be able to go back in their mailing lists and find the discussions that took place for different options etc.

  • Just checksum (Score:1, Insightful)

    by Anonymous Coward
    and be done.
    • And since some older or less secure hashing algorithms might be fooled (modified file, same checksum), use multiple checksum methods. For example, provide both an MD5 and SHA-1 hash for each release package.

      In theory, somebody could cook up a modified file that gives the same hash. But modifying a file and still have multiple hash algorithms produce the same checksums, is very, very, much harder to do -- if not impossible.

      Just post those hashes on trusted servers, and any file that matches both (or mor

      • And since some older or less secure hashing algorithms might be fooled (modified file, same checksum), use multiple checksum methods. For example, provide both an MD5 and SHA-1 hash for each release package.

        That's extremely unlikely, even with weak checksums. What you need to worry about is whether a server that will give you a fake binary will also give you a matching fake checksum.

        Just post those hashes on trusted servers, and any file that matches both (or more) hashes must be your package.

        By trust

  • Sharing the public key (Score:5, Insightful)

    by xmath ( 90486 ) on Tuesday May 03, 2005 @04:41PM (#12424721)
    There are so-called secret-sharing [wikipedia.org] systems, which allow you to distribute a secret (such as a private key) over some number of people such that a specified number of people (the threshold) must work together to recover the secret.

    This way, you can avoid a single person being able to sign, while at the same time making sure that no single person is critical for the signing.

    • Re:Sharing the public key (Score:5, Interesting)

      by cpeikert ( 9457 ) <<ude.tim.mula> <ta> <trekiepc>> on Tuesday May 03, 2005 @04:55PM (#12424884) Homepage
      Secret sharing is a good start, but it doesn't get you all the way there.

      Suppose it's time to sign a new build: then some parties reconstruct the secret key, and *poof* all of a sudden all the parties knows the secret key, and you're back to a single point (or even multiple points) of (security) failure.

      What is needed is a threshold signature scheme (in which the key is never explicitly reconstructed). But I don't know of any free or even cheap implementations (they tend to complicated protocols).

      • Found it! (Score:3, Informative)

        by jd ( 1658 )
        CODEX [umd.edu] is a package that seems to provide what you want. It took some digging, though. I'd add it to Freshmeat, but this looks too much like a one-off project, rather than something being sustained.
      • Share secret between m1 developers and m2 smart cards (like iButton/Java Ring). The signing key is shared between the smart cards, and one developer key. k1 of the m1 developers can reconstruct the developer key. The signing key is reconstructed with k = 2 from the developer key and any smart card key. It exists momentarily only inside the secure smart card memory, and signing takes place inside the smart card.

        So to sign, requires cooperation of k1 developers, and 1 smart card.

    • 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.
    • This is a good idea, but I think it would be even simpler to do this:

      When everyone agrees build abc1337 is the release master, a hash should be created by each developer and then signed. That way you can use your gpg web of trust to verify the authenticity of the binary. You might not trust the Release Coordinator, but since three of your good friends were coders and signed it, you can trust the build. Code signing certificates were created my corporate entities like Microsoft to make open source look i
      • "Code signing certificates were created my corporate entities like Microsoft to make open source look insecure."
        That's a rather unfair statement. It was created as a way for you to know exactly who a piece of code came from, that's all. You can then decide whether to trust it or not. The problem arises because people started to assume signed code is safe to run just because it's signed.
    • -Disclaimer- nCipher, my employer, offers these products so I am a bit biased ;)

      Secret sharing schemes are available for code signing using either MS AuthentiCode, signtool, etc. The private key used to sign the code is stored in a hardware security module ensuring that the key is not exportable and used only within the module.

      Some major software vendors use developer signatures as code source review and strip multiple user level signatures which contain certain attributes in the DN of the cert identify
    • I am aware of the m of n concept. What i was looking for was some examples of pratical solution (commercial or opensource) that would work for our needs. we can not afford the verisign's key escrow service.
  • Somtimes a single point of failure is the best option. Keep it simple (KISS). Just my 2 cents though.

  • I know who you can trust. (Score:4, Funny)

    by Anonymous Coward on Tuesday May 03, 2005 @04:43PM (#12424745)
    Micros~1.

    They invented code signing after all....

  • smart cards? (Score:3, Interesting)

    by John Harrison ( 223649 ) <johnharrison@[ ]il.com ['gma' in gap]> on Tuesday May 03, 2005 @04:43PM (#12424747) Homepage Journal
    put the signing certs on pin protected smart cards. Then ship the cards to the people you want to have be able to sign. Ship the pin to unlock the card by a different method.

  • Start a "trust tree" (Score:1, Interesting)

    by Anonymous Coward
    The signer of the build can be the "root" and just grow this tree to include all contributors.

  • Interesting (Score:4, Interesting)

    by Daath ( 225404 ) <(kd.redoc) (ta) (pl)> on Tuesday May 03, 2005 @04:45PM (#12424764) Homepage Journal
    An organisation such as the EFF or the like, should have such a key escrow service ;)

  • Share split with a minimum number (Score:4, Insightful)

    by m50d ( 797211 ) on Tuesday May 03, 2005 @04:45PM (#12424769) Homepage Journal
    Share split the key among a number of trusted project leaders, and require over half but not all of them to restore the key. Maybe give the project manager more than one share, but ensure that s/he doesn't have enough shares to make them essential - that way you don't need any escrow, if someone goes AWOL you can recombine the rest of your shares and then split it again without them. That's probably the best way to do things. However, I think having a single person sign the build is probably "good enough" unless it's an extremely sensitive application.

  • You'd prefer multiple? (Score:3, Interesting)

    by Arakonfap ( 454732 ) on Tuesday May 03, 2005 @04:48PM (#12424797)
    You'd prefer multiple points of failure? :-)

    In all seriousness, a single point of failure means you only have to worry about one person's key being comprimised. On the other hand, multiple developers available to sign something means multiple points that could have the key stolen.

    A backup is a good idea - escrow of some sort, but having multiple devs sign sounds like a bad idea IMHO.
    • for a OpenSource project relying on one person to be available everytime a new build needs to be rolled-out is not feasible. Even though the project member trust this person with the private key, we can not expect him to be around when we need the executable signed.

  • Split secrets (Score:5, Insightful)

    by lewis2 ( 212695 ) on Tuesday May 03, 2005 @04:48PM (#12424807) Homepage
    In high assurance scenarios like commercial CA operations private-keys are never controlled by an individual. Typically an N of M scheme is used to activate crypto-hardware.

    There as been some interesting work done demonstrating the generation of partial signatures using partial keys - this probably meeds one of your needs. Each of the trusted core of developers gets part of the private-key and uses that to sign part of the release, all the signature parts are assembled and voila you're done. Key recovery works well here as each key part can be encrypted and backed up elsewhere (USB token somewhere else). This may be way overkill for your needs.

    Why not just use an OTS code signing certificate and use the Mozilla or Java or OpenSSL tools to manage signing? If you lose the key you can just get a (free) replacement. This way your key chains up to a well known root that ships with FF, Java, Opera etc. Also if you find your key has been compromised for whatever reason, CRLs or OCSP will be available to prevent use of the compromised key by whomever it is you want to defend against.

    • Re:Split secrets (Score:3, Insightful)

      by Conare ( 442798 )
      Good post! One nit pick - it's usually called M of N (just in case someone wants to google it). Also hardware scheme won't work for them here, due to the distribted nature of the organization.

      I may be misunderstanding you, but generally in digital signing, you don't recover the signing private key, because there is no point to it. Just issue a new one. Key Recovery is only useful for encryption purposes when there is data that is encrypted and will be lost unless you can recover the key. With digital si
    • What is an OTS code signing certificate?? BTW we are signing executable and not active X / applets.
      • OTS: off the shelf, meaning a typical one you'd find in a 'store."

        Many of the commercial certificate authorities offer code-signing certificates for software management programs like Qualcomm's BREW, Microsoft Smartphone, Sun Java, Sun J2ME, SymbianMicrosoft ActiveX, etc. These are governed by the CA under either their policy or a policy specified by the platform vendor, or the carrier/operator.

        If you are looking for tamperproofing and easy verification by end users there is no need to go for an expensive

  • Good use for AI (Score:3, Funny)

    by null etc. ( 524767 ) on Tuesday May 03, 2005 @04:50PM (#12424826)
    Well, you should do what I'm doing. I'm in the same situation, and I've decided to program an Artificial Intelligence (AI) bot running on AIM (haha, get it?) to manage our keys.

    I've almost finished programming it with some neat defense technology, to deal with hackers that try to break into it, or child pedos that think it's a seven year old boy and want to play.

    Now, I'm going to give it some ability to review the source code for our missile-launching satellites and robotic defense schematics.

    BTW you'll find this funny: it's already smart enough to complain about the name I gave it. Although personally, I think SkyNet is a great name.

    • Ask it about plum pudding.

      If it knows what you're talkin about, that's okay, you've just accidently coded the second smartest computer of all time. Name it Deep Thought, and it'll be happy.

      If it does not know about plum pudding, and/or shows any kind of anti-human sentiment (e.g has your pr0n collection recently been replaced by a set of skeletons?), please send us your name and address and we will try to help. Do not plug the computer into the internet, and do not let it play with anything which looks li

  • Why is this presumed to be an Open Source issue? (Score:5, Insightful)

    by ScentCone ( 795499 ) on Tuesday May 03, 2005 @04:51PM (#12424839)
    Certainly the risks are higher, in open source development, of people bailing out of the effort. But pretty much any organization of any size engaged in such projects ("closed" or otherwise) has issues like this.

    I've run into problems with departing web admins and SSL cert renewals, domain management absent the original admin/tech contacts, or just simple stuff like having to crack ZIP files because the project manager has gone on to greener pastures. So far I have yet to beat the paper backup in the company management's private safe, with the In Case Of Death, Open Me label on it. For multi-developer projects, there's usually a central figure - sort of an Alpha Dog - no matter how peer-ish the project is supposed to be.
  • What are the best practices for managing Websites for Open Source projects, where the developers are dispersed throughout the globe? For our project there is NO central office, where we can secure the password for the downloads Website? Who should have the possession of the password? Multiple people, or just the project manager? What Password Escrow (recovery) techniques can be used, in case the password holder is not available? Who should be allowed to upload the build? Currently one person handles the upl
  • ...isn't it about time we shelved that idiotic phrase "best practices"? Can't you just ask for the best way, or the best method? People are using "best practices" for everything from EMail management to installing a new kitchen sink. It's hokey and pretentious, and I'll be really glad if I never see it again.

    Okay, I feel better now. Thank you.

    P.S. My karma is right on the edge, so if you mod me down I'll probably lose all my bonuses and everything.

  • You know what they say (Score:4, Funny)

    by pHatidic ( 163975 ) on Tuesday May 03, 2005 @04:53PM (#12424869)
    Three people can keep a secret, if two of them are dead.
  • Having a backup in case you loose the private key is a good idea.

    Having someone available to take over the duties of signing if the regular signer goes on vacation or leaves is a good idea.

    The idea behind signing is that the receiver knows that the signed item can be trusted. Giving everyone a key justs dilutes the trust, so less is better. Keep the number of people with the key to a minimum.

  • Shamir Secret Share (Score:3, Informative)

    by cheesedog ( 603990 ) on Tuesday May 03, 2005 @05:11PM (#12425031)
    Why not use Shamir secret sharing [harvard.edu] to hold onto the private key? You can choose N people to hold pieces of the private key and choose K = N such that [any] K individuals can reconstruct the secret (but not any less than K).
  • Your project manager, or build engineer, or whoever is responsible for ensuring that a new build is "legitimate," should have sole possession of the private key used to sign the finished project.

    In case of disaster (project manager disappears), you should escrow the private key using a secret-splitting scheme such that 51% or more of your developers can recover it.
  • Every developer should have his own key and release with it. Then he alone bears the responsibility and there is no trouble deciding who did what and all.

    For the major releases it would probably be sound to have a single key that the 10 must influential developers had acces to but only used in agrement with each other.

  • personal reputation (Score:3, Interesting)

    by MathFox ( 686808 ) on Tuesday May 03, 2005 @05:17PM (#12425114)
    Why doesn't the package builder sign the package with his personal key? This has the additional advantage that you can trace problems to individuals and/or broken keys. The core group of developers should cross-sign all of their public keys; they can then sign the keys of the people that are allowed to make "official" distributions. From then on it is just a matter of key management: distribute the "trusted" public keys and revoke keys when people leave the project.

  • Don't make work for yourself (Score:5, Insightful)

    by TrumpetPower! ( 190615 ) <ben@trumpetpower.com> on Tuesday May 03, 2005 @05:20PM (#12425150) Homepage

    What are the best practices for managing Code Signing Digital IDs for Open Source projects

    I'd have to say that you're over-thinking this. I doubt you need digital signatures at all.

    First, should there be any questions at all, well--Use The Source, Luke! You've got it, so examine it and compile it yourself. That's one of the big selling points of open source, no?

    For binary releases, just do it the OpenBSD way. Official releases are created and hosted on trusted servers, along with the hashes. A bunch of mirror sites copy the releases and the hashes. (And, there're these nifty CDs that come pre-packaged with the release and the hashes.)

    Anybody who has any questions can verify the hashes on their own copies in any number of ways. You could get the hash off the trusted site, several of the mirrors, etc. You could email somebody you trust, asking them to confirm them. You could even use a telephone or meet in person.

    Belive me, if there's any hanky-panky going on, it'll show up real quick. All sorts of people will raise a ruckus.

    So, the end result is that you get secure code that everybody trusts and you don't have to muck around with digital signatures, secret sharing, and all that.

    Don't get me worng--all those things have their places. Distributing free software just ain't one of them.

    Cheers,

    b&

    • Just one thought, although presented as [source] code signing, perhaps this may have applicability in a system like Windows where code signing is used to allow the "object code" to run--or run without extra hassle.

    • Official releases are created and hosted on trusted servers, along with the hashes.

      How do these trusted servers remain trusted?

    • Some opensource projects require that they be signed - one that comes to mind is the BouncyCastle Crypto API for Java [bouncycastle.org] - its got a BSD-style licence, but in order to use it in a JVM without hassle, then the .jar has to be signed with a key that has gone through some sort of process with Sun.

      There's nothing stopping you from going through this process yourself, but it's apparently painful and long-winded.

      BouncyCastle have done this, thus making it easy for the rest of us.

      Perhaps the poster could ask them w
    • If the project manager for each project were to digitally sign off on their part if the project, and each archivist signed-off on their archives, etc, then each user could filter by who they personally trusted, you wouldn't need a "master" cert, nothing would need regenerating when someone left/joined, and there's be enough of an electronic paper trail to identify exactly where any problems lay.

    • I'd have to say that you're over-thinking this. I doubt you need digital signatures at all.
      First, should there be any questions at all, well--Use The Source, Luke! You've got it, so examine it and compile it yourself.

      I'd have to say you're underthinking this. Nobody has the time to source review every app and update of that app. Many lack the skills, and almosy everyone lacks sufficient attention span to ready and perfectly comprehend all the source code.

      A great deal of stuff is done on trust, and

  • hm (Score:2)

    by savuporo ( 658486 )
    Why not have one authority certificate for issuing further signing certificates to each release manager ?
    The public needs only to know this one authority certificate, and validate the signature up to this one cert.

  • Secret Sharing and Verifiable Secret Sharing (Score:5, Informative)

    by HidingMyName ( 669183 ) on Tuesday May 03, 2005 @05:32PM (#12425309)
    Key escrow/recovery schemes where there is a sort of "backdoor" built in to allow for key recovery via trusted third parties fell out of favor in the late 1990's, as can be seen at: in this paper [cdt.org].

    My research is currently looking into approaches to related areas (as a user, not necessarily as a cryptographer), you may wish to look into "secret sharing", where given a secret (e.g. a private key), a set of participants, and what the literature calls an access structure which is a collection of subsets of participants that you wish to be able to easily recover the secret (called a qualified subset), establishes a two stage protocol:

    1. Share - a trusted entity called the dealer takes the secret and encodes it into a set of shares, securely awarding each participant a unique share.
    2. Reconstruct - some subset of the participants presents their shares, if the shares are valid and the subset is a qualified subset, the secret is recovered and securely distributed to that subset of participants, otherwise the secret should not be revealed.
    Now, there are (t,n) theshold schemes where any subset of t or more participants where t is between 2 and n are qualified to recover the key otherwise they are not.

    There are proactive variants that periodically recut the shares to prevent accumulated leaking of shares over time from forming a qualified subset.

    Also there are verified secret sharing schemes which support a verify operation, where a share can be checked for correctness without trying to reconstruct the secret (so that bad dealers can be caught and that at reconstruct time invalid shares can be found prior to reconstruction).

    Finally there are "cheating immune" schemes. A cheater is a participant who gives a bogus share at reconstruct time. If they know something about the reconstruction step and can assume the other participants are giving valid shares, some schemes may allow the cheaters to learn something about the secret. In cheating immune schemes, this is prevented.

    Finally there are schemes that use verifiable threshold schemes and verifiable secret sharing for digital signatures.

    If you are interested in some references, Doug Stinson's bibliography on Secret Sharing [uwaterloo.ca] (he has some recent work too). Tal Rabin has done some good work, as has Markus Stadler. Recent work by Stanislaw Jarecki [uci.edu] has caught my eye.

  • Are we talking about "Code signing" in the sense of "here is a binary that some third party can trust you to use" sense? The Fritz Hollings/MPAA/Microsoft sense where any other compile of the same source code is useless?

    If so, your problems go a lot deeper than key management.

  • by using a single remote server whose key is distributed through a basic ssl connection with which you determine a new key between the two computers which are communicating. Distribute an algorithm which updates the remote server's key at a constant time period. This is how ATMs communicate with central computer servers.
  • Why not let several people sign it, with different keys? Then announce that it's only valid if signed by some number of that set of keys.

    Tim

  • What security goal are you trying to achieve? What is an "official" package anyway? What happens is somebody wants to fork the code?

    Debian signs binary packages with the public key of the individual maintainer who made the upload. Those keys are then linked in a web of trust. There is also an archive key held by the release managers.

  • Keep a printout... (Score:2, Informative)

    by davidwr ( 791652 )
    In addition to everything else that's been suggestion, keep a digital and printed copy of important, long-lived items like keys someplace safe, like a safe deposit box, preferably one with multiple non-bank-controlled keys, two of which need to be used to open the box.

  • Just use personal keys (Score:3, Interesting)

    by Sloppy ( 14984 ) * on Tuesday May 03, 2005 @06:31PM (#12425961) Homepage Journal
    Why can't people just sign with their personal keys? And if another developer approves the same build, then it gets a second signature, and so on. The more signatures it has by people you trust, the more you trust it.

    No need for shared secrets, no need for a "master" key of any kind.

    Who should be allowed to digitally sign the build?
    Anyone in the world. Their reputation is what's on the line, not the project's reputation.
    • You got the mechanism right, it's all about trust. And the signing is nothing more than an advanced checksum. But the point is probably that they bought a key from thawte or verisign for $$$ so that users that download ther executable(with internet explorer) are assured they downloaded an unmodified executable.

      Now only one person got the "root certificate". I think that a second person who is thrusted better has thei key as well, in case this singe person gets hit by a bus. Sending the key in a closed enve
  • Does anyone remember the golden days of PGP? There were key signing events where a "trust" network was established. Could this not be applied to code signing? i.e. there is a single master key that is controlled by the lead developer that is used only to sign individual developer keys. The lead developer would have his own key as well -- like I said, the master key is *only* for signing. Then some sort of revision control system could verify the trust relationship of the developer's key versus the mast
  • Key escrow does not apply when it comes to signing, it only applies to encryption. You don't need a backup of signing keys, you just get new keys once the old keys are no longer available (check out the concepts behind digital signatures). You can have as many signing keys as you have developers, e.g.: - Code Signing 001 (for John) - Code Signing 002 (for Aziz) - Code Signing 003 (for Tsjang) - etc. If you are worried about theft and sabotage, like unauthorized people signing on your behalf, get dece
  • Code signing is a mechanism for proving "who" is endorsing that code as something you can trust. Your problem is defining "who" and that's not really a technical problem.

    If somebody forks you, you shouldn't sign their code. Not because it's bad, but because you can't vouch for it. THEY should sign their code.

    Letting somebody else have the key to sign code is endorsing that your good name should go on ANYTHING that they decide to put out. Certainly, a project above a certain size with a community of maintainers should distribute this responsibility.

    If I had a small project, I would make sure the key was left to somebody in my will (and I'd probably leave it with some close friends) - hopefully it'd get to somebody who'd be nominated to takeover the probject - because if I die presumeably I'm less worried about someone pretending to be me. This is a form of key escrow, but it's not a very arbitrary one.

    For a larger project, it must be almost the highest level of trust, and it doubtless has to be learned. Those levels of trust would go something like:
    bank accounts & corp documents
    CVS log modification (auditability erasing)
    code signing
    CVS commit (but at least you can track it after the fact)
    fast-track patch submission
    anyone (normal patch submission)

    These levels are a pyramid; fewer people should be trusted at each level - and fewer people are needed.

  • As noted, you can overthink this one to death. A simple recipe may address your needs:

    1. The PM generates the key pair and obtains the certificate. The PM is steward of the key pair.

    2. The PM performs all signing operations. They're the PM - trust them.

    3. For backup purposes, you need multiple people to have access to the key pair in an emergency, e.g., PM hit by bus. Rent a safety deposit box and give the PM and two or three other senior individuals access authority. Perhaps require two or more signers

  • 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:

    1. The key holder was in posession of the private key at the time the release was signed, and
    2. 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

  • They have advanced secret sharing algorithms for that sort of thing. Something like k out of n people have to agree to sign it. I kind of doubt it'll play nicely with PGP though. Something really should be done about making such schemes more available.

    Does anyone else think PGP only supports outdated techniques?
  • I think a new digital signing algorithm needs to be invented that has a public key and multiple private keys.

    However, these private keys would not be usable by themselves: You would need several, but not all, of the private key holders to put their keys together in order to sign something. The algorithm would somehow need to account for the number of private keys and how many of them are needed to enable a working signing operation.

    So, for example, your loosely-knit organization that is dispersed all arou

  • I don't think it's a good idea to use a key issued to an organization in this case. If your organization does not have an office you will probably not be able to get a code signing cert from Thawte (or other CAs) stating your organization's name, anyway. You will fall back to GPG/PGP probably.

    At Apache Software Foundation (ASF) we use personal GPG keys. Of course that makes it a little tricky for the user, because he must know that the signer belongs to the organization. You should therefore clearly state
  • I've long objected to the idea that my users (BlogBridge http://www.blogbridge.com/ [blogbridge.com]) are asked about certificates by Java.

    Not only is the question impossible to understand for normal people, it is also scary and confusing. And IMHO for those who THINK they understand the question, it creates a very false sense of security.

    After all, unless your name is Bill Gates or Microsoft, how is the user to know whether Acme Corp from Denver Colorado are good guys or secretly malware developers? By signing the code w
  • Maybe I'm missing something here, but who cares if your key is lost or you drop out of the project? The person that takes it up can just get their own key and sign it with that.

    For corporations (and maybe the very largest of OSS foundations) there are valid reasons to care about these issues, because they have a name, and generally only 1 name, to protect. I just don't see what the point is for smaller OSS developers.

    So what if the next version to come out is signed with a different key owned by a diff

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close