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]<mailto:[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
