On Tue, 2016-08-30 at 11:11 +0300, Samuli Seppänen wrote: > > >> With that in mind, if shipping a patched pkcs11-helper in Windows > >> makes your life easier I'd consider doing this. But step carefully, > >> avoid getting in a situation where you suddenly have to maintain these > >> patches yourself. Rather try to see what Fedora does and see if that > >> can be re-used as much as possible. > > > > The Fedora patch for adding RFC7512 support is precisely the same as in > > the open pull request at https://github.com/OpenSC/pkcs11-helper/pull/4 > > > > It shouldn't need much ongoing maintenance. But I do definitely think > > it would be good to move away from pkcs11-helper completely. I'd > > actually like to remove it from Fedora entirely. There are only a small > > handful of projects which use it, and they can all be fixed. > > Given the state of 2.4 ("almost there") I think we should, at most, > apply Fedora's patch to pkcs11-helper in Windows 2.4 installers. The > long-term fix should (imho) wait until 2.5.
Agreed. In the meantime I'll try to work out what the way forward should look like — for all applications, not just OpenVPN. I've already come to the conclusion that I need to expand the Fedora certificate handling guidelines (which aren't really Fedora-specific but it's a good way to drive improvements).... Rather than *only* specifying that applications should accept RFC7512 PKCS#11 URIs anywhere they take a filename, it looks like we also need to be a bit more prescriptive about the *files* that are accepted too. I'm accumulating a torture test suite (which I expect OpenVPN to fail) at http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am I note that all crypto libraries make it bloody hard to just load a certificate from a file and do the right thing. You have to jump through various hoops in the application to work out what the file is and ask the crypto library nicely to load that specific type of file. I'm almost tempted to make a new library 'libkeyfile' which *does* provide a simple function that does the right thing. It ends up being multiple libraries, of course. You have 'libkeyfile-openssl', 'libkeyfile-mbedtls', etc. — and it would support PKCS#11 as well as files. The aim would be for this library to become obsolete as the crypto libraries' APIs stop sucking so hard, and they actually start to make it *easy* for applications to do the right thing. I'd do it under a BSD licence so that it can be copied — I *want* it to be merged into the crypto library upstream, and it can also copied by projects which want to do so instead of having it as an external dependency. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
