Ah I'm putting that update off myself for a bit for that very reason. I think XCode changes make some things kind of a pain, and might require things to be manually recompiled with clang or llvm changes if I recall. Anyway, good luck.
Yeah the merge probably really won't be bad because it's likely any conflict is just in the concatenated .js file. Yeah, I've been hoping to get that debugging refactored a bit as you mention. On Wed, Sep 5, 2012 at 9:19 PM, Jim Klo <[email protected]> wrote: > Yes, I'll try to get to that tomorrow… I'm currently trying to fend off a > bit of a cat fight I created (upgraded from Snow Leopard to Mtn Lion) which > broke a good portion of my homebrew (python, node, etc) - however nothing > else so far FWIW.. > > The merge shouldn't be terrible, however I've modified my version a bit > even more… mostly so I can hook into some of the bowels of the debug output > to get rid of some of the embedded HTML formatting within the utils > closure… at least to make it more usable for my use as a lib instead of > having to hack the lib. Technically, I think someone mentioned this all > needs a bit of refactoring anyways. > > > * > Jim Klo > Senior Software Engineer > Center for Software Engineering > SRI International > * > * > t. @nsomnac > * > > On Sep 5, 2012, at 6:07 PM, Sean Colyer <[email protected]> > wrote: > > 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 > > > > _______________________________________________ > > http://openpgpjs.org > >
_______________________________________________ http://openpgpjs.org
