On Sat, 2015-05-02 at 01:54 +0300, Alon Bar-Lev wrote: > what is specified explicitly in PKCS#11 spec must be applied by > providers, there is no room for interpretation in this specific case. > > > From the OpenVPN point of view, actually there's a cheap trick which > > can let us call it Someone Else's Problem... just use vfork() instead > > of fork(). Because we *know* we're about to call execve() and it > > doesn't matter, and the atfork handlers don't get called for a vfork(). > > NAK my side, openvpn code is ok.
I completely understand your point of view, however I don't really agree with the conclusion. OpenVPN is not a test suite designed to test for absolute compliance with all esoteric aspects of the PKCS#11 specification, so it isn't useful for it to just blow up whenever anything is slightly wrong. OpenVPN is a tool which people want to *work*. If there's a trivial change which can make it more tolerant of issues in the software it has to interoperate with, then we should make that change. I have filed a separate ticket #549 for this, since I was wrong to attribute it to #538 — #538 really is a bug in OpenVPN since it's blatantly forking in a callback which is documented as not permitting that. And the vfork() trick can't easily be applied in that case since we need to do other things between the fork and the exec. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
