Il 03.04.2012 00:22, David Sommerseth ha scritto: > On 02/04/12 20:50, Alon Bar-Lev wrote: > > 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... > > Adriaan got a good point, and we've kind of settled on the features > we've kicked into the coming 2.3 release. I hope that we can push out > an alpha-2 release when things have begun to stabilise on master again. > I think we should release 2.3-alpha2 soon after Alon's buildsystem work has been merged and tested. Have any other major changes gone into that release?
Now, although version numbers may be unimportant to developers, users tend to avoid versions that they _believe_ could be unstable. That is, development snapshots, alpha, betas and even RCs. That was clearly reflected in the 2.2 release cycle... if I recall correctly, at least 75% of users downloaded the "stable" version even though 2.2 was in beta/rc. So, in this light, it's important to push out "stable" versions quickly., so that the code gets into wide circulation. > It would be good to have a beta release out before the summer and an > RC release during the autumn. Aiming for a 2.3 release towards the > end of the year. This is not a plan carved into stone, and if we're > able to move faster; I'd appreciate that very much. But this is the > general idea which has been discussed/suggested a couple of times on > IRC. However, I'm trying to be realistic as well. So there's room > for 2-3 releases in each stage before the final release. And we'll > see how many we end up with in the end. > > But I agree that additional features we don't want into 2.3 could go > into the experimental branch in openvpn-testing.git. That's mostly a > copy of 'master' (I've been lazy to update it lately, but pushed out > an update again now), that's the purpose of this branch. > This sounds like a good place for further development and invasive cleanups. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
