No no no....
I did not imply that this will be dynamic interface.
Nor that there is a use case.
The current state of the code (even before the merge of polarssl) was
very complex.
Now it is even more complex, with none clean/strict separation between
the common crypto code and the library specific crypto code... Yes, I
know these resides in different sources, but it is more similar to
what we call "spaghetti" programming.
What I suggest of doing is to create static callback structure which
is the interface of crypto library used by openvpn. This is *STATIC*
linkage.
For example:
typedef struct {
result_t
(*x509_get_username) (char *cn, int cn_len,
char *x509_username_field, x509_cert *cert)
...
} openvpn_crypto_enigne_t;
I guess you understand how this struct will look like.
Now, a nice side effect would be the ability to have both libraries
linked against openvpn, while choosing the engine at configuration...
Of course there is no real world use for this, except for build (one
build checks both libraries) and test (we can use test one build for
both).
The main mission is to clean up the code, reducing the complexity,
making sure we can follow each crypto call to either common,
crypto-library-atom, or openvpn specific.
Is that more clear?
Alon.
On Mon, Apr 2, 2012 at 1:07 PM, David Sommerseth
<openvpn.l...@topphemmelig.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/04/12 11:55, Fabian Knittel wrote:
>
>
> The only advantage I see at runtime switching, is that it's easier for
> distributors to support both SSL/crypto library platforms. Except of
> that, I don't see much benefits of it.
>
> And f.ex. in the use case of OpenVPN-NL, I doubt this will be
> considered interesting at all, as they do static linking against the
> SSL/crypt libraries - to ensure that the libraries Fox-IT have
> reviewed and certified for governmental usage are used, and not a
> potentially compromised or weakened third-party library.
>
> To be very honest, I don't think it's worth the effort of adding
> dynamic loading of SSL/crypto libraries at run time. Having it at
> compile-time provides the needed flexibility. Yes, distribution can
> benefit from it, but is that burden so big we need to modify OpenVPN
> for it? Let's rather stay cool now and rather discuss and consider
> such a move for OpenVPN 2.4. Then we will know more what distributors
> thing about it.
>
>
> kind regards,
>
> David Sommerseth
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk95elsACgkQDC186MBRfrpVfACdEJgl6vYDeGH3DxL1foYET118
> u5gAn2mA6Zy5TIhtqYnV8qCP2XTJiyyr
> =K25q
> -----END PGP SIGNATURE-----
