On Thu, Oct 31, 2013 at 2:01 PM, Denis Gervalle <[email protected]> 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 ?
I also prefer 2) and 3). I will let others decide if BC is standard enough in practice to go with 3) but I'm clearly not against it, we are strongly tied to slf4j for example and it seems to be that BC is quite used in Java world and clean and easy enough to extend to never really be stuck. > > -- > Denis Gervalle > SOFTEC sa - CEO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
