> -----Original Message----- > From: Alon Bar-Lev [mailto:alon.bar...@gmail.com] > Sent: maandag 2 april 2012 12:42 > To: David Sommerseth > Cc: openvpn-devel@lists.sourceforge.net > Subject: Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL > 1.1 RNG > > 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. >
I'd prefer to leave further modularisation for 2.4. We could even make that a more general goal for 2.4, modularising not just crypto/SSL, but also authentication, and maybe even some of the network stuff. It would be nice to leave a few targets for 2.4 :). I don't see the need to further delay 2.3 for this, as it is not a bug fix. Others might disagree here, and the topic is open for debate :). In general, it might be a good idea to freeze development of 2.3 at some point to prevent endless alpha syndrome. Adriaan
