Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/12 20:50, Alon Bar-Lev wrote: > On Mon, Apr 2, 2012 at 8:31 PM, Adriaan de Jong > wrote: >>> -Original Message- From: Alon Bar-Lev >>> [mailto:alon.bar...@gmail.com] Sent: maandag 2 april 2012 >>> 12:42 To: David

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

On Mon, Apr 2, 2012 at 8:31 PM, Adriaan de Jong 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]

Re: [Openvpn-devel] [PATCH 2/6] Added a configuration option to enable prediction resistance in the PolarSSL random number generator.

Prediction resistance is a useful feature to have in some circles. It's definitely an option that's useful for OpenVPN-NL, which is why I ported it to the mainline. If there is no interest, could we include it in a contrib directory or something along those lines? Adriaan > -Original

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

> -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

Re: [Openvpn-devel] [PATCH] cleanup: windows: convert argv (UCS-2 to UTF-8) at earliest

Please review/test. On Sat, Mar 24, 2012 at 10:31 PM, Alon Bar-Lev wrote: > Discussed at [1]. > > Use wmain under windows, drop the custom parsing and shell32 linkage. > > There is no need for gc magic as this allocation is static. > > [1]

[Openvpn-devel] [PATCH] cleanup: add .gitattributes to control eol style explicitly

Having the text auto detection is a risk, as the detection may detect text files that are not text and vise versa. Having global setting will create confusion and differentiate between users. So this patch also move this to local repository. Having git to check out files differently in different

Re: [Openvpn-devel] [PATCH 3/4] cleanup: avoid using ~0 - netmask

On 29/03/12 11:16, Alon Bar-Lev wrote: > Use IPV4_NETMASK_HOST constant. > > Signed-off-by: Alon Bar-Lev > --- > src/openvpn/basic.h |2 ++ > src/openvpn/mroute.c |2 +- > src/openvpn/pf.c |2 +- > src/openvpn/route.c | 12 ++-- >

Re: [Openvpn-devel] [PATCH 4/4] cleanup: avoid using ~0 - windows

On 01/04/12 14:12, Alon Bar-Lev wrote: > Use the following constants: > - METRIC_NOT_USED > - TUN_ADAPTER_INDEX_INVALID > > Modified: Use MAXDWORD for route loop. > > Signed-off-by: Alon Bar-Lev > --- > src/openvpn/route.c | 30 +- >

Re: [Openvpn-devel] [PATCH 2/4] cleanup: avoid using ~0 - ipv6

On 29/03/12 11:16, Alon Bar-Lev wrote: > Signed-off-by: Alon Bar-Lev > --- > src/openvpn/route.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > Applied to master branches on -testing and -stable trees commit ffa1184d7fde8262f5c19438a59657e318d5126f

Re: [Openvpn-devel] [PATCH 1/4] cleanup: avoid using ~0 - generic

On 29/03/12 11:16, Alon Bar-Lev wrote: > Use limits.h for maximum value. > > Signed-off-by: Alon Bar-Lev > --- > config-msvc.h |1 + > configure.ac |2 +- > src/openvpn/route.c |2 +- > src/openvpn/syshead.h |4 > 4 files changed, 7

Re: [Openvpn-devel] [PATCH] cleanup: gc usage

On 01/04/12 15:46, Alon Bar-Lev wrote: > Cleanup of "Use the garbage collector when retrieving x509 fields" > patch series. > > Discussed at [1]. > > There should be an effort to produce common function prologue > and epilogue, so that cleanups will be done at single point. > > [1]

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

-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

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

-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

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/12 11:55, Fabian Knittel wrote: > Hi Alon, > > 2012/4/2 Alon Bar-Lev : >> I also intend to work and cleanup the whole PolarSSL/OpenSSL >> mess... >> >> Design will be to introduce crypto engine callback structure,

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

-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

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

-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

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

-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

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

Hi Alon, 2012/4/2 Alon Bar-Lev : > I also intend to work and cleanup the whole PolarSSL/OpenSSL mess... > > Design will be to introduce crypto engine callback structure, > registering openssl and polarssl, in a way that code is using the > callback structure while using

Re: [Openvpn-devel] [PATCH] cleanup: gc usage

On Mon, Apr 2, 2012 at 10:06 AM, Adriaan de Jong wrote: > Thanks, looks good. Does platform_open return -1 on failure on all > platforms? If so, ack, otherwise change that to < 0. As far as I know, yes. """open() and creat() return the new file descriptor, or -1 if an error

Re: [Openvpn-devel] [PATCH 2/6] Added a configuration option to enable prediction resistance in the PolarSSL random number generator.

Hello, I think that we should not have these options specific to one crypto library. Alon. On Mon, Apr 2, 2012 at 10:28 AM, Adriaan de Jong wrote: > Signed-off-by: Eelse-jan Stutvoet > Signed-off-by: Adriaan de Jong > --- >  

Re: [Openvpn-devel] [PATCH 4/6] Removed support for PolarSSL < 1.1

Oh!!! You did removed old support. Great. But we should do this in autoconf as well. Testing POLARSSL_VERSION_NUMBER >= 0x0101 is enough? Which header to include? On Mon, Apr 2, 2012 at 10:28 AM, Adriaan de Jong wrote: > PolarSSL 1.0 and earlier use only the Havege RNG.

Re: [Openvpn-devel] [PATCH 6/6] Updated README.polarssl with build system changes.

I think this should be merged into the README. No need for these satellite README.*. On Mon, Apr 2, 2012 at 10:28 AM, Adriaan de Jong wrote: > Signed-off-by: Adriaan de Jong > --- >  README.polarssl |    4 ++-- >  1 files changed, 2 insertions(+), 2

Re: [Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

Hello Adriaan, I don't think that PolarSSL is so popular that we need to support complex backward compatibility. Supporting PolarSSL-1.1 should be sufficient, we can make the configure script verify this minimum. I also intend to work and cleanup the whole PolarSSL/OpenSSL mess... Design will

Re: [Openvpn-devel] Buildbot build flags

Hi Alon, > Safest is to go with all combinations... Testing all combinations would be best, but there are a _lot_ of them... then you need to multiply that with the number of buildslaves (atm ~10) :). > Or at least: > --disable-lzo --enable-lzo > --enable-pkcs11 --disable-pkcs11 > --enable-selinux

[Openvpn-devel] [PATCH 6/6] Updated README.polarssl with build system changes.

Signed-off-by: Adriaan de Jong --- README.polarssl |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.polarssl b/README.polarssl index 77a9575..ab7c2d7 100644 --- a/README.polarssl +++ b/README.polarssl @@ -3,11 +3,11 @@ instructions: To Build

[Openvpn-devel] [PATCH 3/6] Use POLARSSL_CFLAGS instead of POLARSSL_CRYPTO_CFLAGS in configure.ac

Ensured that the used variable name actually matches the one advertised by configure. Signed-off-by: Adriaan de Jong --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index ef34697..70c51e7 100644 ---

[Openvpn-devel] [PATCH 4/6] Removed support for PolarSSL < 1.1

PolarSSL 1.0 and earlier use only the Havege RNG. Havege is based on timing certain operations, using the RDTSC instruction. Although this is fine on bare metal PCs, the RDTSC instruction is virtualised on some virtual machine implementations. This can result in issues on those virtual

[Openvpn-devel] [PATCH 5/6] Removed stray "Fox-IT hardening" string.

Signed-off-by: Adriaan de Jong --- src/openvpn/ssl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c index 767bc8e..19512c0 100644 --- a/src/openvpn/ssl.c +++ b/src/openvpn/ssl.c @@ -392,7 +392,7 @@ init_ssl

[Openvpn-devel] [PATCH 1/6] Added support for new PolarSSL 1.1 RNG

This patch, while retaining PolarSSL 1.0 support, introduces the PolarSSL 1.1 DRBG. This RNG adds a number of features, including support for personalisation strings and multiple entropy sources. Personalisation strings have been implemented, based on PID, program name, place within memory,

Re: [Openvpn-devel] [PATCH] cleanup: gc usage

On 04/01/2012 03:46 PM, Alon Bar-Lev wrote: > Cleanup of "Use the garbage collector when retrieving x509 fields" > patch series. > > Discussed at [1]. > > There should be an effort to produce common function prologue > and epilogue, so that cleanups will be done at single point. > > [1]