On 10/31/2013 09:01 AM, Denis Gervalle wrote: > Hi devs, > > In the process of preparing signed scripts and other security improvements, > I am currently refactoring the crypto API that suffer from being available > during the early days of the component manager. Our objective has also > changed, and some part will be deprecated in favor of a new more evolve API. > > In that process, I am wondering which kind of object we allow to go through > our API, and I see 3 possibilities: > > 1) Do not use any object from either Bouncy Castle (BC), nor Java > Cryptography API (JCA), and build our own, like BC does. This is obviously > the most decouple solution, but it will increase the conversion between > APIs. User that may also use BC or JCA on their own will also have to > convert their native objects to our own, to use our API. > > 2) Use the JCA objects only in addition to our own. The JCA has not evolved > since a while, and is therefore really stable. This seems to me a better > alternative. BC provide support to use those objects, so the conversion to > BC is easy. However, these objects are not as friendly as those of BC, so > we may need to provide some equivalent helpers existing in BC. > > 3) Link us more closely with BC, and use the best alternative depending on > the situation, either BC, JCA, or our own. This is more easy for us, and > better for users of BC outside of our API. This will avoid having to > duplicate some BC functionality that are already user friendly enough on > our side, therefore limiting maintenance work as well. > > I am more in favor of 2) or 3), not because I am lazy, but since the > initial API already use 2) and I prefer not to duplicate existing features > in BC which looks to me a de-facto standard for cryptography in the > open-source world. > > WDYT ? >
BouncyCastle is indeed a de-facto standard for cryptography, so +1 for 3). -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
