Oops, I just took a look at the pull requests and realized we never merged this in. I agree with your general assessment of the licensing situation. Can you re-merge your version with the latest master and I'll go ahead and merge it in.
Sorry for waiting so long, I thought we already brought it in. Thanks, Sean On Mon, Jul 30, 2012 at 8:51 PM, Jim Klo <[email protected]> wrote: > >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]> 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 > > > > _______________________________________________ > > http://openpgpjs.org > >
_______________________________________________ http://openpgpjs.org
