Dear all, I'm moving this discussion to the complete list. In short: Do we need OpenPGP.js after Google released their implementation of OpenPGP in JavaScript ( https://github.com/google/end-to-end ). Some good arguments are given below.
I initially established OpenPGP.js (despite not being part of the active development team) since there was no proper single, usable implementation back then. Due to the commitment of a handful gifted fellows and a great community this changed rapidly. This is outstanding. I see multiple technical and political reasons that argue for both, dropping/merging and even enhancing OpenPGP.js. I'd like to see an atmospheric picture here. For example, on a technical level it probably doesn't make sense to reimplement the wheel and on a political level it is questionable whether an implementation driven by Google would be for example an alternative for the GnuPG folks. Best regards, Alex >> On 03.05.2015, at 18:21, Fabio (naif) Pietrosanti <[email protected]> >> wrote: >> >> @tanx i think that diversity is important in the opensource ecosystem, not >> only in the code but also in the way specific projects get used or focus on. >> >> As you say E2E have a set of bureaucracy around it given the google internal >> constraints: >> >> • cannot be spitted into a lib >> • it's not updated immediately on github but there's a synchronization >> process between internal development and opensource release >> • there could be issues in contribution and collaboration >> From my point of view those are important enough constraint to let me skip >> using it as-it-is. >> >> A project like GnuPG or OpenPGP.js, with it's own diversity of management, >> diffusion and contributors, have a quite free-community oriented approach, >> without backing from a major multinational (that we love for it's opensource >> commitment, but impose rules limiting freedom a bit). >> >> I am wondering if we could not think about "re-using" some of the Google E2E >> components in order to cleanup / bring consistency in the crypto being used >> within OpenPGP.js, but keeping it's independency? >> >> From a software engineering point of view does it make sense for how >> OpenPGP.js is done? >> >> If i understood properly, if @tanx and @toberndo switch to e2e for whiteout >> and mailvelope most current code contribution to openpgp.js would go away, >> bringing the project to a point where there's no active development? >> >> If so, would it help defining a roadmap and make it financed? >> >> We could approach some funding (Like www.opentechfund.org) to ask for >> financing growth of the OpenPGP.js library itself, it would make a lot of >> sense given it's dependency with mailvelope and globaleaks, both funded by >> OTF? >> > On 03.05.2015, at 10:21, Tankred Hase <[email protected]> wrote: > > We talked about ECC alot at the OpenPGP summit in April. There were some > concerns about compatibility but overall everyone agreed it's an inevitable > step in the right direction. Especially in light of the web platform and > performance when compared to RSA. > > I see two options going forward... > > 1.) We all rally behind one OpenPGP JavaScript implementation like the native > code community does for GPG. There is no particular reason to have multiple > PGP JS libs which each need to be maintained and audited. > > Whiteout is thinking about adopting the End-to-End lib because of ECC, its > clean code and the resources Google is putting behind security audits and > bounty. But we still have some reservations. > > First of all the OpenPGP.js community is small but a very helpful, friendly > and productive one. If there something that needs to change in the code I > have a quick discussion with @toberndo over hangout and we make a decision. > This allows us to quickly add new features or clean up legacy code e.g. like > when we migrated to ES6 promises. OpenPGP.js has been audited twice by Cure53 > and it's being used in production by Deutsche Telekom and 1&1 in > Mailvelope/DEmail which means that not only Whiteout relies on stability and > security. This is a great way to share the costs. > > The full E2E PGP solution is not in production yet and it's not clear when it > will. I talked with the Google developers quite a bit about their workflow > internally and their willingness to accept community contributions. From what > I gathered it seems that the master branch that is exposed to the github > repository lags behind the upstream the Googlers work on internally. Changes > are pushed to github regularly but with some delay as their internal review > process is quite thorough. This has the obvious upside that the code quality > is very very high, but it's also not obvious how outside contributions would > fit into this process. > > Another thing the devs also made clear is that they currently cannot split > the lib into it's own GitHub repo due to other internal workflow constraints. > > In terms of maturity the E2E library is being used in a number of production > use cases internally and the team was very confident to recommend it for > third party apps. Although as mentioned... The full PGP stack is not yet in > production and from my experience this is where to most maintenance and > interoperabilty work is. > > If we go with E2E we (Whiteout) don't want to do that alone. We would > probably only do it if Mailvelope is also willing to migrate. > > 2.) The second option would be to integrate the ECC modules from E2E into > OpenPGP.js as was discussed above. The solution is the most straightforward > but OpenPGP.js is already a mashup of js crypto code gathered from all over > the internet. This would probably reduce consistency in the codebase even > more. This is also not trivial and no one has raised their hand to handle the > actual work and pay for an audit. > > So those are the two options I see. We're going to try a proof of concept for > integrating E2E lib in Whiteout once we find the time. Then we'll have more > insight to share. Until the I'd like to get a feeling for the other > OpenPGP.js users... What are you in favor of? > _______________________________________________ http://openpgpjs.org Subscribe/unsubscribe: http://list.openpgpjs.org
