On Fri, 2016-02-19 at 15:53 +0100, Nikos Mavrogiannopoulos wrote: > On Fri, 2016-02-19 at 13:12 +0000, Matt Caswell wrote: > > > As far as I know there are some customers using the Chil engine > > > with > > > RHEL (openssl-1.0.1). > > > > How do you feel about the engine being spun out into a separate > > repo? > > That of course assumes that a volunteer can be found to maintain it > > (I > > don't believe anyone on the dev team wishes to do so). > > > > If no such volunteer can be found how big a deal is it to remove it > > from > > 1.1.0 without a replacement? Obviously it won't be taken out of > > 1.0.1/1.0.2. Of course there's no reason, even if we take it out > > now, > > that if someone needs it badly enough in the future that they > > couldn't forward port the 1.0.2 version to 1.1.0 and maintain it > > themselves at that point. > > It may even be better, instead of pushing for different engines for > different hardware, to make PKCS#11 the only API used to talk to > hardware. There is a quite functional (and active as project) pkcs11 > engine for openssl [0].
Agreed. With the caveat that I *really* want libp11 and engine_pkcs11 to die, and be replaced by native code in openssl/crypto/pkcs11/ That way we can integrate it *properly*, with various SSL certificate handling functions just naturally taking PKCS#11 URIs alongside filenames. Integrating libp11 itself would require relicensing it, which might be non-trivial but perhaps still achievable. Or maybe we should reimplement it, basing the new version around p11-kit. It would be an *optional* thing, of course. Windows builds might default to no-pkcs11. But p11-kit ought to exist fairly much everywhere *else*. Apart from UEFI :) -- David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
