On Mon, Apr 2, 2012 at 1:39 PM, David Sommerseth
<openvpn.l...@topphemmelig.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/04/12 12:25, Alon Bar-Lev wrote:
>> 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?
>
> Ahh, yeah!  That makes more sense.
>
> But I just need to be sure we're having the right focus.  Are we
> getting done with the autotools clean-up?  If not, what's missing?  I
> see more and more clean-up patches touching the C code now, so I just
> want to be sure we're basically done with autotools.  Otherwise,
> getting rid of syshead.h is probably one of the next bigger steps.

Right.
Next stage is getting rid of syshead.h... The following is to cleanup
the crypto, I though that if someone can work on this in parallel we
will do this twice as fast :)

But before we continue we need to stabilize the project again,
creating the missing repositories, deciding about the
github/sourceforge is needed. Deciding about the way to review and
merge large changes.

Alon.

Reply via email to