On Mon, Apr 2, 2012 at 8:31 PM, Adriaan de Jong <dej...@fox-it.com> wrote: >> -----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 >
Well, I don't care about version numbers... they are just snapshots in time. We need a branch with this one way or the other... If that branch is good, it can enter the next version whatever it may be... Alon.
