Yeah, you can set up as a separate branch. You shouldn't need any permissions from us to do that. On github you can just make a fork of the project to your account and then create as many branches as you'd like.
As I mentioned, if you'd like you can email me directly with your github id and we can add you to the project. Sean On Thu, Apr 25, 2013 at 9:42 AM, Erik Larsson <[email protected]>wrote: > I currently have it forked in my own repo but if I could add it as a > branch, it would be fantastic. > > On Apr 20, 2013, at 9:05 PM, Sean Colyer <[email protected]> wrote: > > We can add you to the openpgpjs organization as a developer on github if > you need to set up a separate branch. Do you have it set up as a branch on > a fork in your personal repo or what is your current structure? > > > On Sun, Apr 7, 2013 at 3:57 PM, Erik Larsson <[email protected]>wrote: > >> Hey, >> >> Again sorry for the late response. If you guys are still interested in me >> committing my branch, I can send it up now. There's still a lot work that >> needs to be done, but I rather get it up so I can keep working on it. I >> don't think i have any rights to create a branch on the project, would it >> be possible to change that or how do you guys usually deal with things like >> this? >> >> Someone asked about the performance between using strings and using >> blobs. I haven't actually timed it so I don't really have a definite answer >> to this. For the project I was working on we however had to be able to >> encrypt/decrypt files that's >100mb and the browsers would simply freeze >> and crash for files of that size. It would however be interesting to >> compare the two, if nothing else, just to have some benchmarking. >> >> My branch currently supports Firefox, Chrome, Safari 6 and IE 10. >> >> I also remembered being asked about the project I'm working on and if we >> could use our logo. This is completely fine, the project is called >> SendSafely (www.sendsafely.com). I can send a logo if there's nothing >> suiting on the site. >> >> Regards >> Erik >> >> On Feb 14, 2013, at 4:52 PM, Alexander Willner <[email protected]> wrote: >> >> > Hi Erik, >> > >> >> Sorry for the delayed answer, I've been swamped with work and haven't >> had the time to deal with this for a while. Looks like I will have quite >> some time this week though, and I hope to commit by the end of the week. My >> suggestion is to commit on a separate branch and we can then build it out >> further from there. >> > >> > no problem - we're all doing this for fun ;) >> > >> >> Anyhow, here's an outline of what we've done so far; >> > >> > Sound fantastic what I read. Again: a nice performance comparison would >> be great for promotion. >> > >> >> I'd also like to point out that we've only changed the parts that are >> critical for us. This would mainly be AES encryption/decryption and >> generating SHA-1 hashes. >> > >> > Ok - so might be a long term goal to apply your changes also to the >> rest. >> > >> >> Since encryption/decryption can be a time consuming task we decided to >> do it from web workers. >> > >> > Are you aware of this branch? >> https://github.com/openpgpjs/openpgpjs/tree/webworker >> > >> >> Another problem we ran into is that window.crypto.getRandomValues() is >> not defined for Firefox (and not defined in a web worker context for any >> other browser either). Currently we will instead use SJCL (the crypto lib >> from Stanford) to get random numbers for Firefox. >> > >> > Very well. See https://github.com/openpgpjs/openpgpjs/issues/22 and >> https://github.com/openpgpjs/openpgpjs/tree/master/Dependencies (added >> the dependency already a year ago). >> > >> >> Currently all of this work with Firefox, Chrome and IE10. It is >> possible to add support for Safari as well and I hope to be able to do this >> this week, although that's nothing I can promise. Other browsers are not >> tested (except for lower versions of IE that will not work). >> >> Anyhow, >> >> Sorry for the much delayed answer, let me know if there's any >> questions.. >> > >> > Your contribution is very welcome. >> > >> > If you or anyone on this list is interested, we can apply for the >> current call for OpenITP proposals[1]. It's about $5k-$30k USD, the >> deadline is 31.03.2013, it's simple to apply and I think there is a high >> chance to get accepted with an OpenPGP.js related project. >> > >> > Best regards, Alex >> > >> > [1] >> http://openitp.org/?q=openitp_first_round_of_2013_project_funding_now_open_for_proposals >> > >> > Best regards, Alex >> > >> > [1] >> http://openitp.org/?q=openitp_first_round_of_2013_project_funding_now_open_for_proposals >> > >> > >> > On 12.02.2013, at 16:42, Erik Larsson <[email protected]> >> wrote: >> > >> >> Hi Alex, >> >> >> >> Sorry for the delayed answer, I've been swamped with work and haven't >> had the time to deal with this for a while. Looks like I will have quite >> some time this week though, and I hope to commit by the end of the week. My >> suggestion is to commit on a separate branch and we can then build it out >> further from there. >> >> >> >> Anyhow, here's an outline of what we've done so far; >> >> >> >> In order to be able to deal with larger files we now work extensively >> with blobs and typed arrays rather than strings. Blob's are a good way to >> handle large chunks of data since they are stored on the file system and >> not just kept in memory. Rather than dealing with blob objects right away >> we created two new buffer objects that basically reads in a small part of >> the blob to avoid keeping it all in memory. It reads in a small chunk and >> returns a typed array. By doing this we can perform normal array operations >> on the data which is more convenient than dealing with a blob. Currently we >> have on buffer for uint8array (used for encryption/decryption) and one for >> int32Arrays (for SHA generation). >> >> >> >> I'd also like to point out that we've only changed the parts that are >> critical for us. This would mainly be AES encryption/decryption and >> generating SHA-1 hashes. >> >> >> >> Below is a more detailed description of the code changes we made. >> >> >> >> Encryption: >> >> We've created a new function in openpgp.packet.literaldata named >> write_packet_large. It takes a buffer object as input and returns a new >> buffer containing the data + header. >> >> >> >> We've also created a new function in openpgp_packet_encrypteddata >> again called write_packet_large. This function is not very different from >> the normal one besides that it of course deals with the new buffer object >> rather than strings. >> >> >> >> From there openpgp_crypto_symmetricEncrypt is called. We always use >> AES when doing symmetric encryption so we haven't modified any of the other >> ones. >> >> >> >> Last but not least we've added a new openpgp_cfb_encrypt_large >> function which takes in a buffer object. We've modified the original >> function so it will now read in chunks from the blob and encrypt them. When >> done it returns a new buffer containing the cipher text. Besides that it is >> also possible to pass in a callback object to which progress is reported >> back. >> >> >> >> One note here is that we always use the resync option when encrypting >> which means we have so far just converted that. I could possible convert >> the non resync case before committing as well. >> >> >> >> Decryption >> >> The changes made to the decryption flow is similar to the ones we did >> for encryption. Our typical flow looks like this: >> >> We added a new read_packet_large to openpgp_packet. In here we made >> one major change. Previously there was a loop to determine the length for a >> packet of indeterminate length ( >> https://tools.ietf.org/html/rfc4880#section-4.2.1, >> https://tools.ietf.org/html/rfc4880#section-4.2.2). We found that this >> loop was delaying the decryption process quite a bit for larger files so it >> was removed. I don't believe there is really no need to know the length in >> advance, correct me if I'm wrong? Instead we're calculating the length >> while decrypting. >> >> >> >> Just as previously, the functions returns a package. The difference is >> that the encrypted data is stored as a buffer rather than a string. Again, >> only the methods we are using have been converted. The only packages using >> large amounts of data that we use is the type 9 packages. The decryption is >> then done very similar to how the encryption was accomplished. >> >> >> >> SHA-1 Generation >> >> Similarly we've modified the SHA generation to accept a buffer as >> input. Again, We've appended _large to the modified functions to ensure >> that regular strings works as before. >> >> >> >> At last >> >> Since encryption/decryption can be a time consuming task we decided to >> do it from web workers. There is currently a JQuery reference when encoding >> a html string which won't work when used in a Web Worker context. We never >> used it so we just ended up commenting it out although that is of course >> not a good solution. Another problem we ran into is that >> window.crypto.getRandomValues() is not defined for Firefox (and not defined >> in a web worker context for any other browser either). Currently we will >> instead use SJCL (the crypto lib from Stanford) to get random numbers for >> Firefox. This is however handled outside of OpenPGP since we need to >> generate the numbers from the main thread and pass them to the worker. >> >> >> >> Currently all of this work with Firefox, Chrome and IE10. It is >> possible to add support for Safari as well and I hope to be able to do this >> this week, although that's nothing I can promise. Other browsers are not >> tested (except for lower versions of IE that will not work). >> >> >> >> Anyhow, >> >> Sorry for the much delayed answer, let me know if there's any >> questions.. >> >> >> >> >> >> On Jan 9, 2013, at 2:56 PM, Alex (via OpenPGP.js) <[email protected]> >> wrote: >> >> >> >>> Hi Erik, >> >>> >> >>> Thank you for the answer. >> >>> >> >>>> I work in a project where we are using OpenPGP.js in a production >> environment. We however use it to encrypt larger files which forced us to >> make a few changes. >> >>> >> >>> Would love to read more about this. >> >>> >> >>>> If you guys want to use our logo on the OpenPGP.js site we can >> probably arrange that as well. >> >>> >> >>> Yes! >> >>> >> >>>> If you guys are interested we would like to commit this back to the >> project for others to use. >> >>> ... >> >>>> Would these changes be of interest to the project? >> >>> >> >>> Definitely! I think it would be extremely helpful to have a short >> benchmark before and after your changes that we can publish. >> >>> >> >>> Best regards, Alex >> >>> >> >>> On 08.01.2013, at 18:33, Erik Larsson <[email protected]> >> wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> I've been on this mailing list for a while without writing. I work >> in a project where we are using OpenPGP.js in a production environment. We >> however use it to encrypt larger files which forced us to make a few >> changes. The major one being to support blobs when decrypting/encrypting >> data. We had to do this since we are likely to operate on files > 100 mb >> and it was just not possible to pass around a string with that size. >> >>>> >> >>>> If you guys are interested we would like to commit this back to the >> project for others to use. Today I'm mostly reaching out to get the >> conversation started. There's some work that has to be done on our part >> before merging so I just wanted to touch base on what we've done. Right now >> we have added prefixed functions when we deal with large files so rather >> than calling write_packet we call write_packet_large and so forth. We did >> this mostly to keep our changes separate from the original source. We are >> willing to change this in however way fits the project guidelines better. >> There are some additional changes that comes to this but this would be the >> major one. Would these changes be of interest to the project? >> >>>> >> >>>> If you guys want to use our logo on the OpenPGP.js site we can >> probably arrange that as well. >> >>>> >> >>>> Best Regards >> >>>> Erik >> >>>> >> >>>> On Jan 8, 2013, at 3:16 AM, Alex (via OpenPGP.js) < >> [email protected]> wrote: >> >>>> >> >>>>> Dear all, >> >>>>> >> >>>>> Happy New Year. I think it's time to give the OpenPGP.js project a >> bit more "love" in 2013. There are many items on the todo list - so let us >> address the first ones: >> >>>>> >> >>>>> 1. Marketing: Which projects are currently using OpenPGP.js? I >> would like to add links and logos to our web page. Also I just restarted to >> use the Twitter account http://twitter.com/openpgpjs to retweet and >> answer related posts. Anyone is welcome to join. Also I've created a new >> simple logo (see attached). >> >>>>> >> >>>>> 2. Developing: It should be very easy for users to integrate the >> library into their web pages and for developers to enhance the current >> version. I think we can improve the current situation. So we also might >> want to move this mailing list to another one with archive support (btw: is >> a mailing list still an adequate perfect medium?) >> >>>>> >> >>>>> 3. Security: There are a lot of discussions about the advantages >> and drawbacks of using a JavaScript based OpenPGP library (within browsers >> or not). We should write some sort of "summarized and syntetic" (@naif: >> thanks.) >> >>>>> >> >>>>> What should we address in 2013 from your point of view? >> >>>>> >> >>>>> Best regards, Alex >> >>>>> >> >>>>> -- >> >>>>> http://openpgpjs.org >> >>>>> >> >>>>> >> >>>>> <icon_openpgpjs.png> >> >>>>> _______________________________________________ >> >>>>> >> >>>>> http://openpgpjs.org >> >>>> >> >>>> _______________________________________________ >> >>>> >> >>>> http://openpgpjs.org >> >>> >> >>> _______________________________________________ >> >>> >> >>> http://openpgpjs.org >> >> >> >> _______________________________________________ >> >> >> >> http://openpgpjs.org >> > >> >> _______________________________________________ >> >> http://openpgpjs.org >> > > _______________________________________________ > > http://openpgpjs.org > > > > _______________________________________________ > > http://openpgpjs.org > >
_______________________________________________ http://openpgpjs.org
