Re: Module Signatures
I'm confused. We have a heirarchy, not a web: CPAN signs author keys, authors sign modules. Wouldn't x509 certificates (SSLish) be better suited for this? -- Ian Langworth
Re: Module Signatures
On Wed, 26 Jul 2006 12:10:07 +0800, Adam Kennedy [EMAIL PROTECTED] said: I do agree, but if you are going to do that we should know NOT to tell people on failing platforms to do something we know is going to fail. So if we know it doesn't work on Windows (for example) we shouldn't be telling them to install Module::Signature, because it just leads them down the wrong (painful) path. Right. CPAN 1.87_54 is uploaded and there you can turn on and off signature checking more conveniently than in 1.87. I'll make a 1.88 release RSN. -- andreas
Re: Module Signatures
* Andreas J. Koenig [EMAIL PROTECTED] [2006-07-26 05:50]: I'll assume you didn’t actually mean it the way it came out;) that you were actually complaining that M:S falls short because our security model needs *further* action not because M:S has deficiencies. If M:S has deficiencies, maybe we should address them now. Both. M::S as it stands is broken in some ways, but even when it works, the security model is only minimally useful. Reduction of utility due to breakage is not acceptable, but depending on the value of the security model, some breakage can be put up with for some time; reduction of utility due to actual security (say, CPAN.pm requires manual override to install something merely because its author’s key expired) is absolutely acceptable – it’s the *point* of the excercise. That’s what I meant to say. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Module Signatures
Hmm, in retrospect I realize that this phrasing was a bit ambiguous: * A. Pagaltzis [EMAIL PROTECTED] [2006-07-26 04:10]: I’ll assume you didn’t actually mean it the way it came out; that you were actually complaining about the tools. To clear up any confusion, here’s how it should read: I’ll assume you didn’t actually mean it the way it came out; I think that you were actually complaining about the tools. I agree that Module::Signature falls far short of doing an adequate job; no argument from me about that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Module Signatures
* Adam Kennedy [EMAIL PROTECTED] [2006-07-19 18:40]: My biggest criticism of every attempt I've seen at adding more security is that it reduces utility. And since we've NEVER (yet) had a security violation that I'm aware of, the net result is we just sacrifice utility for potential security gain. That line of reasoning really troubles me: it implies that it’s not worthwhile to protect against a plausible danger before real damage has happened. In fact, if the measures are implemented well, then the security gain from them will always remain “potential”. I’ll assume you didn’t actually mean it the way it came out; that you were actually complaining about the tools. I agree that Module::Signature falls far short of doing an adequate job; no argument from me about that. But I think so not because it decreases utility but because it doesn’t actually increase security. When it decreases utility, it’s just because it fails to work, not because in exchange for security. If I could trade some utility for an actual increase in security, I would. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Module Signatures
On Wed, 19 Jul 2006 18:09:08 +0200, A. Pagaltzis [EMAIL PROTECTED] said: Maybe we need a perlish kind of building it. It's not perlish to show each other a passport and make sure that the image there matches the face. hmm, I don’t know how else you’d do it; at least for high confidence, you really have to be absolutely sure that you’re signing the key of the person who is who they’re claiming to be, and there isn’t much opportunity to be completely certain in online interactions. 1. If you ask CPAN contributors to supply their PK *at signup time* (but no later!), you can be certain that the key belongs to the person who signed up – whoever that is. (Keys uploaded later do not confer the same trust, because that key might belong to the person who signed up, or it might belong to an impostor who stole their credentials – you can’t know.) These could be signed with an extra CPAN key that confers more trust. 2. The best opportunity for strong trust is probably the fact that a lot of the really active Perl hackers run into each other face-to-face quite a bit; e.g. the London.pm’ers should have absolutely no trouble exchanging keys face-to-face, but the same is true of many Perlmongers groups. Likewise, many of the core contributors of Perl attend the pertinent conferences (YAPC, OSCON et al). And of course the meaning of “web of trust” is that once direct trust relationships have been established in local groups where they are easily feasible, then every time someone travels around or goes to a confidence and exchanges keys, you get “six degrees of separation” style trust chains. If we decided to make a big awareness push, we’d probably get the prolific CPAN contributors covered well very quickly, and then it’s a matter of continual evangelism to keep the web expanding. It is easy to implement #1 immediatly, but coverage will take a very long time to go up with that method because it will only apply to new authors. Besides, private digital keys can expire or be revoked, both are important parts of the life cycle that CPAN must pay attention to. I would hate to tell people that they need a new CPAN account when their private key expires or is revoked or that everybody needs a new CPAN account because they didn't supply a digital key at signup. Then there are pseudonyms like TELS or ERYQ or ABIGAIL. While they do have a civic name, not many know it or care about it and so doesn't CPAN either. Then there is my favorite security builder: security by visibility. By sending emails to authors for every important transaction, we give them the chance to shout when suspicious things happen and make it harder for intruders to impersonate somebody else. Another helping fact might be that when you use a digital signature often in public conversation or for your uploads, you leave a trace, a fingerprint of your personality associated with the signature. It's hard for me to imagine how this effect can be harvested by programming interfaces, but see, I read your words in this thread and others and that's how my trust in your name emerges. Were your postings signed, I would be ready to sign your signature after a while of ongoing conversation *without* seeing your passport. In contrast, coverage should expand pretty quickly with #2, but it will take a lot of community cooperation and lots of evangelism to implement. When we come up with a process that works similarly as #2 but only for the trust we have into an email address, then we could get even better and faster spread. -- andreas
Re: Module Signatures
On Wed, 26 Jul 2006 04:08:05 +0200, A. Pagaltzis [EMAIL PROTECTED] said: I’ll assume you didn’t actually mean it the way it came out; that you were actually complaining about the tools. I agree that Module::Signature falls far short of doing an adequate job; no argument from me about that. But I think so not because it decreases utility but because it doesn’t actually increase security. When it decreases utility, it’s just because it fails to work, not because in exchange for security. If I could trade some utility for an actual increase in security, I would. I'll assume you didn’t actually mean it the way it came out;) that you were actually complaining that M:S falls short because our security model needs *further* action not because M:S has deficiencies. If M:S has deficiencies, maybe we should address them now. -- andreas
Re: Module Signatures
On Thu, 20 Jul 2006 02:35:02 +1000, Adam Kennedy [EMAIL PROTECTED] said: On the other hand, give me an easy to use, works _everywhere_, never fails falsely positive or negative, never crashes, low-dependency security enhancement to CPAN clients that I never have to think about, then I'm in and I'll do anything you want. Security is not a never have to think about. We can inprove the tools and make them work under battle conditions, but that's only one dimension. The other dimension is about improving security even with tools that fail on Windows. We can and should do that. If we improve security only for a small subset of users, we improve the overall security of CPAN because the small subset can pull the alarm bell faster. -- andreas
Re: Module Signatures
Andreas J. Koenig wrote: On Thu, 20 Jul 2006 02:35:02 +1000, Adam Kennedy [EMAIL PROTECTED] said: On the other hand, give me an easy to use, works _everywhere_, never fails falsely positive or negative, never crashes, low-dependency security enhancement to CPAN clients that I never have to think about, then I'm in and I'll do anything you want. Security is not a never have to think about. We can inprove the tools and make them work under battle conditions, but that's only one dimension. The other dimension is about improving security even with tools that fail on Windows. We can and should do that. If we improve security only for a small subset of users, we improve the overall security of CPAN because the small subset can pull the alarm bell faster. I do agree, but if you are going to do that we should know NOT to tell people on failing platforms to do something we know is going to fail. So if we know it doesn't work on Windows (for example) we shouldn't be telling them to install Module::Signature, because it just leads them down the wrong (painful) path. Adam K
Re: Module Signatures
Hi Andreas, * Andreas J. Koenig [EMAIL PROTECTED] [2006-07-07 08:35]: By the way, I liked your summary of the situation in your posting [EMAIL PROTECTED] and I wonder how we could promote the web of trust on CPAN which clearly is the only way forward. Maybe we need a perlish kind of building it. It's not perlish to show each other a passport and make sure that the image there matches the face. hmm, I don’t know how else you’d do it; at least for high confidence, you really have to be absolutely sure that you’re signing the key of the person who is who they’re claiming to be, and there isn’t much opportunity to be completely certain in online interactions. 1. If you ask CPAN contributors to supply their PK *at signup time* (but no later!), you can be certain that the key belongs to the person who signed up – whoever that is. (Keys uploaded later do not confer the same trust, because that key might belong to the person who signed up, or it might belong to an impostor who stole their credentials – you can’t know.) These could be signed with an extra CPAN key that confers more trust. 2. The best opportunity for strong trust is probably the fact that a lot of the really active Perl hackers run into each other face-to-face quite a bit; e.g. the London.pm’ers should have absolutely no trouble exchanging keys face-to-face, but the same is true of many Perlmongers groups. Likewise, many of the core contributors of Perl attend the pertinent conferences (YAPC, OSCON et al). And of course the meaning of “web of trust” is that once direct trust relationships have been established in local groups where they are easily feasible, then every time someone travels around or goes to a confidence and exchanges keys, you get “six degrees of separation” style trust chains. If we decided to make a big awareness push, we’d probably get the prolific CPAN contributors covered well very quickly, and then it’s a matter of continual evangelism to keep the web expanding. It is easy to implement #1 immediatly, but coverage will take a very long time to go up with that method because it will only apply to new authors. In contrast, coverage should expand pretty quickly with #2, but it will take a lot of community cooperation and lots of evangelism to implement. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Module Signatures
If we decided to make a big awareness push, we’d probably get the prolific CPAN contributors covered well very quickly, and then it’s a matter of continual evangelism to keep the web expanding. Sounds great, but speaking as one of the aformentioned prolific CPAN constributors there's no way in hell I'm moving to any form of signatures until someone shows me a fully-cross-platform, low-impact, never-breaks, doesn't-require-the-internet implementation of the web of trust concept. In real code, not just design concept. Because the current implementation of Module::Signature, although a reasonably nice proof of concept, is not holding up under battle conditions and is being disabled for the time being. My biggest criticism of every attempt I've seen at adding more security is that it reduces utility. And since we've NEVER (yet) had a security violation that I'm aware of, the net result is we just sacrifice utility for potential security gain. On the other hand, give me an easy to use, works _everywhere_, never fails falsely positive or negative, never crashes, low-dependency security enhancement to CPAN clients that I never have to think about, then I'm in and I'll do anything you want. Adam K
Re: Module Signatures
On Fri, 07 Jul 2006 11:22:16 +1000, Adam Kennedy [EMAIL PROTECTED] said: Andreas J. Koenig wrote: On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy [EMAIL PROTECTED] said: (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? That sounds more or less equivalent. Are they signed now? Yes, since about February 2003, courtesy Audrey. -- andreas
Re: Module Signatures
On Fri, 7 Jul 2006 03:52:52 +0200, A. Pagaltzis [EMAIL PROTECTED] said: * Adam Kennedy [EMAIL PROTECTED] [2006-07-07 03:25]: Andreas J. Koenig wrote: On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy [EMAIL PROTECTED] said: (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? That sounds more or less equivalent. Are they signed now? And if so, by whom? It's a batch signing key. This doesn't bring you what a web of trust brings you but I never pretended it did. By the way, I liked your summary of the situation in your posting [EMAIL PROTECTED] and I wonder how we could promote the web of trust on CPAN which clearly is the only way forward. Maybe we need a perlish kind of building it. It's not perlish to show each other a passport and make sure that the image there matches the face. -- andreas
Re: Module Signatures [was Re: On Gaming CPANTS...]
Moin, On Thursday 06 July 2006 03:22, Jonathan Rockway wrote: It adds a dependency on a binary application (gpg) that users have to install by hand, doesn't check for the presence of it properly, and if you don't have it, installs an enormous chain of dependencies, with said deps having some major issues of their own. It's become bad enough that Module::Signature is being pulled from Bundle::CPAN and being disabled by default in CPAN.pm, until Module::Signature gets a maintainer capable that can make it somewhat saner. Er, you realize that you _dont_ have to check the signature if you system is so broken as not allowing it? I really don't understand that argument anyhow: Replace Module::Signature with RPM and read it again: It adds a dependency on a binary application (gpg) that users have to install by hand, doesn't check for the presence of it properly, and if you don't have it, installs an enormous chain of dependencies, with said deps having some major issues of their own. I don't think anybody would suggest SuSE do no longer sign their RPM packages with their gpg key anymore... instead they make sure you have gpg installed and configured properly before doing the signature check. If you insist on running a system w/o gpg, and you want to check the signature on a Perl package, you gotta go, configure your system and install some software for the purpose. Next someone tells me I can't use XS because it makes the distribution depend on a compiler? :-) Leaving of the signature of software distributions just because someone isn't able to configure their system is so... so I fail the words for it. Best wishes, tels -- Signed on Fri Jul 7 15:47:00 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. The difference between pornography and erotica is lighting -- Gloria Leonard pgptiZGndZIl9.pgp Description: PGP signature
Re: Module Signatures [was Re: On Gaming CPANTS...]
* Jonathan Rockway [EMAIL PROTECTED] [2006-07-06 03:25]: I think the solution (to dependency hell) is to dictate that CPAN modules be signed with a standard algorithm. OpenPGP allows too many different algorithms, hence the 22 modules Crypt::OpenPGP is dependent on. The only strong reason to stick with OpenPGP is that it has the whole web-of-trust and keyserver infrastructure. If we can live without that, What’s the point? If all that’s verified is that the distribution was signed with the key uploaded to the same directory, then all you can have confidence in is that distribution was uploaded by someone who has permission to upload a key. That might be the author, or it might be an impostor who got ahold of the author’s account details and uploaded his own key. But to upload a distribution you need the author’s account details anyway! So the cryptosig doesn’t give you confidence in any facts that you didn’t already have confidence in. In other words, for the signatures to improve confidence, they have to be generated from keys that either form of a web of trust in which the downloader participates, or they have to be issued by a certification authority that imposes additional background verification before it will issue a key. I don’t think running a cert auth is feasible for CPAN. So the only worthwhile option is to participate in the PGP web of trust. If you do away with that, you can just as well do away with cryptosigs alltogether. NB.: of course, Mod::Sig currently doesn’t check the trustworthiness of a key, only whether a distribution is signed with the uploaded key, so it’s pointless in precisely the way outlined above. Until such time as trust checks are implemented, there is no point to signing CPAN distros. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Module Signatures
Sorry, meant to send this to the list. :) What’s the point? Good question. Crypt::OpenPGP doesn't maintain a web-of-trust either. People that have webs of trust have GPG, otherwise, what are they using? If all that’s verified is that the distribution was signed with the key uploaded to the same directory, then all you can have confidence in is that distribution was uploaded by someone who has permission to upload a key. That might be the author, or it might be an impostor who got ahold of the author’s account details and uploaded his own key. This protects end-users against a malicious CPAN mirror, though. If PAUSE is compromised, that's a whole other set of problems. (Yes, WoT would protect you from PAUSE being compromised. Only if your network is extensive enough to cover every person who has ever uploaded anything to CPAN. I use PGP extensively, but have never actually verified any CPAN authors' keys in person. I tried at YAPC but I never managed to actually find anyone that was intersted in exchanging keys :) I doubt the average JAPH is going to go to that much effort just to be sure that nobody's secretly compromised the PAUSE or their friendly local CPAN mirror. I don’t think running a cert auth is feasible for CPAN. So the only worthwhile option is to participate in the PGP web of trust. If you do away with that, you can just as well do away with cryptosigs alltogether. True. Right now they're pretty useless. I have downloaded some modules that didn't verify and installed them anyway. Jifty, for example, contains a bunch of ._foo and ._bar files that aren't in the MANIFEST, and therefore CPANPLUS chokes when you try to install it. On a more positive note, we can eliminate a lot of Crypt::OpenPGP's dependencies by stripping out keygen (Crypt::Random - Math::Pari, which is a nightmare to isntall on some systems). If everyone somehow gets a web-of-trust, then modifying Crypt::OpenPGP to require a certain level of trust would be simple. Right now, though, it's just not worth it IMHO. (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Regards, Jonathan Rockway
Re: Module Signatures
On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy [EMAIL PROTECTED] said: (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? -- andreas
Re: Module Signatures
Andreas J. Koenig wrote: On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy [EMAIL PROTECTED] said: (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? That sounds more or less equivalent. Are they signed now? Adam K
Re: Module Signatures
* Adam Kennedy [EMAIL PROTECTED] [2006-07-07 03:25]: Andreas J. Koenig wrote: On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy [EMAIL PROTECTED] said: (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? That sounds more or less equivalent. Are they signed now? And if so, by whom? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
