>>From my perspective, my contribution is relatively small and contains no >>significant IP. The only restriction I have is that there's a funding clause >>that I'm required to submit with all code that was done under contract paid >>by US Federal dollars (I call it the plausible deniability clause, so the US >>Gov't can disavow any association to the work even though they paid for it).
>>From my POV, the Samba clause just adds a bit of ambiguity on top of GPL/LGPL >>which already has mechanisms for contribution. Essentially if I'm submitting >>code to your project, I'm submitting it to be licensed under your terms >>unless specified otherwise - at least that's how I understand GPL... now if >>my intent was to release my own version of OpenPGP.js as an alternate to the >>official solution, that's a whole different story (and I'm sure a github pull >>request could be argued that way), I'd have to license it with all the right >>GPL foo, which assuming the original fork was done right, all licenses should >>still be intact.. In any case, I'm authorized to release my work as Apache 2.0 without having to go through any red tape, which pretty much lets anyone do anything they want with what I release. And from the way I read http://www.gnu.org/licenses/quick-guide-gplv3.html Apache 2 is compatible w/ LGPLv3, which in turn works with Samba policy you point out. Hence I believe it should be compatible with the Samba like license. For minor work (like this pull request) I'm authorized to just submit to whatever license the project uses (LGPL for OpenPGP.js's case) and not bother relicensing. Like I mentioned previously, I must include the following statement, which only applies to items of my authorship: This project has been funded at least or in part with Federal funds from the U.S. Department of Education under Contract Number ED-04-CO-0040/0010. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government. I could probably add this to a file like NOTICE.txt with pointers to the the relevant SHA commits? FWIW, The Dept of Ed projects I work on are using Apache 2.0 http://www.apache.org/licenses/LICENSE-2.0.html to avoid the GPL licensing pitfalls, which is more permissive and makes contributions easy. Not sure if that works for you guys, as I think much of the OpenPGP stuff you're starting with uses older GPL. However I don't know if you have an idea where OpenPGP.js actually 'modified' the original work, since you've built upon stuff like the Stanford Crypto and Hanewin JS libraries. AFAIK, you just have to delineate where lines are crossed. IE, I don't think my pull request actually 'modified' any code (maybe a makefile), but for the most part I've added new, files modified can be described as output of mechanical inclusion and optimization. In the end, please advise how you want me to revise the pull request, you can do it as a comment in the pull request to adequately track history (https://github.com/openpgpjs/openpgpjs/pull/48), as it's not a huge piece I've submitted (It took me longer to write this email than it was to make those changes :D ). - Jim Jim Klo Senior Software Engineer Center for Software Engineering SRI International t. @nsomnac On Jul 30, 2012, at 4:18 PM, Sean Colyer wrote: 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]<mailto:[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]<mailto:[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]<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/> _______________________________________________ http://openpgpjs.org<http://openpgpjs.org/> _______________________________________________ http://openpgpjs.org<http://openpgpjs.org/> _______________________________________________ http://openpgpjs.org
_______________________________________________ http://openpgpjs.org
