Ah, I realize we've been dwelling on this pull request for quite a bit now.
I've been looking a bit about the "right way" to combine code from multiple people. It looks like samba is the closest to our situation: https://www.samba.org/samba/devel/copyright-policy.html Basically, they prefer commits be owned by individuals and those not owned by individuals just have explicit approval from their employer. Also, they mention the advantage that we share of using git which makes it pretty easy to track who technically would have the copyright of any given bit of code. Jim -- can you modify the pull request to reflect the license as you think it would need to be? Do you think something like the samba policy would be reasonable? How do others feel about this? Sean On Sun, Jul 8, 2012 at 6:02 PM, Tankred Hase <[email protected]> wrote: > Welcome Jim, > > the native crypto apis do indeed look promising. It will be interesting to > see if pgp can be fully implemented using the provided primitives. > > Although I am hopeful that these standards will be adopted by all major > browsers, experience shows that the speed of adoption varies highly. > > The fact that Firefox OS is gaining traction, could possibly act as a > catalyst though. As any application stack would not be complete without > native crypto. It should stay interesting :) > > Tankred > Am 07.07.2012 01:25 schrieb "Jim Klo" <[email protected]>: > >> Hi Sean, >> >> Understood the project is initially targeting Chrome - however it >> looked like you've got a more broad vision. There's a lot of interesting >> stuff going on with crypto in the browser these days, and I'd expect over >> the next year or so to see native support of crypto primitives (fast math) >> and secure keychain access from all major vendors. >> >> My needs maybe more sideline, since I'm wanting to do crypto stuff >> inside CouchDB. My alternative would be to do it in Erlang - which I'm not >> super eager to learn. >> >> After noodling in the code a bit - I noticed that the objects that are >> added to the keyring are different than those returned by read_publicKey(), >> verifySignature() is expecting an object like what's in the keyring, not >> what's returned from read_publicKey(). For my needs I just ended up >> importing the keys and then validating my message without passing any keys. >> >> I've not used JSLint much for static analysis, however I do see several >> warnings when it runs. I didn't really check to see what options it's >> running with (say checking for Rhino, since Spidermonkey shares it's >> codebase). >> >> >> 1. "navigator" object is used in an unchecked manner. >> I think the only place the navigator object is part of the JSBN ( >> http://www-cs-students.stanford.edu/~tjw/jsbn/) library. I don't think >> we've made any modifications to it thus far, but changes we make we should >> consider send back to original author (I do not believe the code is hosted >> on github or sf or anything). I was under the impression that >> navigator.appName is generally thought to be relatively safe, but I >> suppose we could change this to try to check navigator more closely. >> >> >> Understood. I just poked around to find where it was being called and >> made sure I check for existence and at least define a mock object. >> >> 2. there's a jQuery dependency for messaging (which probably shouldn't >> exist). >> As the comment notes, I think we're just using this for cleaning of our >> text to ensure that we don't get unexpected HTML to be rendered. I think in >> general the messaging/error system needs some refactoring to be less >> dependent on strings but I don't think anyone has jumped on that. >> >> >> In general, I'd remove the dependency, and move 'cleansing' out into >> view code. As an framework, I really don't want my error messages wrapped >> in HTML, as I would rather use Mustache or some other template solution to >> format the error string. >> >> 3. showMessage(text) function has no default implementation. >> I believe this was a design decision by Carsten so that people consuming >> the application are at least knowledgeable that they should consider >> handling errors/messages. Eating them in your implementation if that's what >> you intend would be fine. >> >> >> I'm just eating them for demo. A better design pattern might be to >> provide some default implementation that writes to console.log or provide a >> configuration option to provide a callback function to provide the code for >> showMessage() implementation. Understood that #2 & #3 go hand in hand when >> refactoring at some future point in time. >> >> 4. dependency upon HTML5's localStorage >> As mentioned at the top, this is something of a building for chrome >> dependency. No reason we couldn't have changes to make it more flexible. >> >> >> I think that's fine - however you should probably refine this need; >> possibly look at whats going on with W3 working group thats defining a >> standard Crypto API for the browser to see if there's any interface to the >> keystore that can be abstracted. >> >> FWIW: I've submitted my modifications in a pull request here: >> https://github.com/openpgpjs/openpgpjs/pull/48 >> >> Essentially I've just added a build target in the makefile and adapted >> the minification process to include some additional globals first to make >> SpiderMonkey happy, plus added a simple if (exports) exports.openpgp = >> openpgp; for basic CommonJS support. >> >> - Jim >> >> * >> Jim Klo >> Senior Software Engineer >> Center for Software Engineering >> SRI International >> * >> >> On Jul 5, 2012, at 8:54 PM, Sean Colyer wrote: >> >> Wow, lot's to talk about here, welcome Jim. >> >> Generally, the JS has been designed with Chrome in mind, with the hopes >> that once that is cemented, support for other browsers/JS engines can be >> handled. So in your case it's certainly possible that some changes will be >> needed. >> >> Just curious if you're using JSLint or what for static analysis? >> >> 1. "navigator" object is used in an unchecked manner. >> I think the only place the navigator object is part of the JSBN ( >> http://www-cs-students.stanford.edu/~tjw/jsbn/) library. I don't think >> we've made any modifications to it thus far, but changes we make we should >> consider send back to original author (I do not believe the code is hosted >> on github or sf or anything). I was under the impression that >> navigator.appName is generally thought to be relatively safe, but I >> suppose we could change this to try to check navigator more closely. >> >> 2. there's a jQuery dependency for messaging (which probably shouldn't >> exist). >> As the comment notes, I think we're just using this for cleaning of our >> text to ensure that we don't get unexpected HTML to be rendered. I think in >> general the messaging/error system needs some refactoring to be less >> dependent on strings but I don't think anyone has jumped on that. >> >> 3. showMessage(text) function has no default implementation. >> I believe this was a design decision by Carsten so that people consuming >> the application are at least knowledgeable that they should consider >> handling errors/messages. Eating them in your implementation if that's what >> you intend would be fine. >> >> 4. dependency upon HTML5's localStorage >> As mentioned at the top, this is something of a building for chrome >> dependency. No reason we couldn't have changes to make it more flexible. >> >> In regards to your signature verification issue: >> I think there is definitely an issue here. On looking at it briefly I >> think we want key.obj.publicKeyPacket.MPIs to actually be something >> like key.publicKeyPacket.MPIs which would work for openpgp_msg_publickey >> objects. I agree that it seems that it is slightly off currently. Changes >> would also have to be made to openpgp.msg.message.js to make sure that we >> are passing in the appropriate object. >> >> Hope this helps a bit, >> Sean >> >> On Mon, Jul 2, 2012 at 8:51 PM, Jim Klo <[email protected]> wrote: >> >>> Hi Niklas, >>> >>> I've tried that in my example... and it does appear to parse the public >>> keys, as I get a list of 1 key, but passing the key (or key list) that to >>> openpgp_msg_message.validateSignature(pubkey) fails. >>> >>> see: https://gist.github.com/3036199 for full source >>> >>> var messages = openpgp.read_message(msg); >>> var success = messages[0].verifySignature(); >>> print("using keyring: "+success); >>> >>> var keys = openpgp.read_publicKey(pubKey); >>> success = messages[0].verifySignature(keys[0]); >>> print("using passed key object: "+success); >>> >>> success = messages[0].verifySignature(keys); >>> print("using passed key list: "+success); >>> >>> >>> output: >>> >>> jklo$ js spidermonkey-test.js >>> using keyring: true >>> using passed key object: false >>> openpgp.js:12749: TypeError: key.obj is undefined >>> >>> here's what's at openpgp.js:12748-12749 >>> >>> return openpgp_crypto_verifySignature(this.publicKeyAlgorithm, >>> this.hashAlgorithm, >>> >>> this.MPIs, >>> key.obj.publicKeyPacket.MPIs, data+this.signatureData+trailer); >>> >>> >>> Thanks, >>> >>> - Jim >>> >>> * >>> Jim Klo >>> Senior Software Engineer >>> Center for Software Engineering >>> SRI International >>> * >>> >>> On Jul 2, 2012, at 5:18 PM, Niklas wrote: >>> >>> Try reading keys using openpgp.read_publicKey(text) instead of the >>> keyring. >>> >>> On 7/3/12 6:59 AM, Jim Klo wrote: >>> >>> I seem to have to use the keys stored in the keyring, which is extra >>> overhead that I'd like to avoid since my keyring can't really be modified >>> in my use case. >>> >>> >>> Try reading keys using openpgp.read_publicKey(text) instead. >>> >>> >>> Most of this stuff seems to derive more or less directly from >>> GPG4Browsers, I recommend using their dev docs as a reference. >>> http://gpg4browsers.recurity.com/GPG4Browsers-Developer_Documentation.pdf >>> >>> >>> >>> _______________________________________________ >>> >>> http://openpgpjs.org >>> >>> >> _______________________________________________ >> >> http://openpgpjs.org >> >> >> >> _______________________________________________ >> >> http://openpgpjs.org >> >> > _______________________________________________ > > http://openpgpjs.org > >
_______________________________________________ http://openpgpjs.org
