date:20180115

Re: [Openvpn-devel] [PATCH v2 2/3] OpenSSL: remove some EVP_PKEY type checks

2018-01-15 Thread Selva Nair

Hi,

On Mon, Jan 15, 2018 at 7:56 PM, Emmanuel Deloget  wrote:

> Hello Selva,
>
> On Tue, Jan 16, 2018 at 12:10 AM, Selva Nair  wrote:
>
>>
>>
>> Can I try one last time to convince you guys to keep EVP_PKEY_id()? If I
>> was targeting only 1.1.0+ that's how most of those checks would have been
>> done, isn't? Makes life easier, code simpler as I have said before..
>>
>> Just throwing in my 0.02c, feel free to ignore.
>>
>> Best,
>>
>> Selva
>>
>
>
> OpenSSL 1.1.0+ and previous versions allows you to create a typed EVP_PKEY
> without any key inside. For example, you can do
>
>   EVP_PKEY *pkey = EVP_PKEY_new();
>   EVP_PKEY_set_type(pkey, EVP_PKEY_RSA);
>
> This is plainly valid: the key is prepared for later use.
>
> So testing for EVP_PKEY_id() is not sufficient to make sure that current
> and future code won't mess with us.
>

That was not my intent.

Use EVP_KEY_id() to determine the type and choose the code path. Then when
ready, get the key pointer and check it. Of course there may be situations
where its possible to get the pointer and check it in one line as in your
case (3) below.

Anyway, calling EVP_PKEY_get0_RSA() multiple times is lame. Now think of
cases where we may have to delegate the job to separate functions depending
on the key type. To me it looks natural to do that using a
switch(EVP_PKEY_id()) or if-else blocks to decide which function to call
and then get the key and check it inside the function. Anyway, I will leave
it at that.

> To be extra sure, one can do
>
> if (EVP_PKEY_id() == EVP_PKEY_RSA && EVP_PKEY_get0_RSA(pkey)) { ... }
>

> Which is exactly what the current code does. Yet the idea (at least mine)
> is to remove that to simplify code a bit.
>
> Now, I agree, this is quite easy to read and to understand.
>
> We have 3 solutions:
>
> 1) keep the code as is
>
> if (EVP_PKEY_id() == EVP_PKEY_RSA && EVP_PKEY_get0_RSA(pkey) != NULL) {
> ... }
>

In this case the call to EVP_PKEY_id() is redundant, isn't it? Or am I
missing something? If the latter returns non-null then its indeed an RSA
key (I'm assuming the 1.1.0 or the corrected compat layer behaviour here).

>
>
> 2) remove EVP_PKEY_id() but keep a test on EVP_PKEY_getO_RSA()
>
> if (EVP_PKEY_get0_RSA(pkey) != NULL) {
> RSA *rsa = EVP_PKEY_get0_RSA(pkey);
> ...
> }
>

This looks bad to me.

>
>
> 3) rework it as proposed in the patch
>
> RSA *rsa = NULL;
> if ((rsa = EVP_PKEY_get0_RSA(pkey)) != NULL) { ... }
>

In this particular case this may be the best approach but there are
situations where it may not be the natural choice. Hence the "if it were up
to me EVP_KEY_id() will stay" musing...:)

Thanks,

Selva
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/3] OpenSSL: remove some EVP_PKEY type checks

2018-01-15 Thread Emmanuel Deloget

Hello Selva,

On Tue, Jan 16, 2018 at 12:10 AM, Selva Nair  wrote:

>
>
> On Mon, Jan 15, 2018 at 5:33 PM, Emmanuel Deloget  wrote:
>
>> Hello Steffan,
>>
>> On Sun, Jan 14, 2018 at 11:26 AM, Steffan Karger 
>> wrote:
>>
>>> Hi,
>>>
>>> On 12-01-18 22:37, Emmanuel Deloget wrote:
>>> > Calling EVP_KEY_id() before EVP_PKEY_get0_*() is unnecessary as
>>> > the same check is also performed in the later.
>>> >
>>> > We also make the code a bit better by not calling the various
>>> > EVP_PKEY_get0_*() functions twice (this needs a bit or reordering to
>>> > avoid introducing yet another #ifndef OPENSSL_NO_EC in the code).
>>>
>>> Checking double is a bit silly, but we can fix that by simply removing
>>> the "EVP_PKEY_id() == ... && " occurrences. (That still allows us to
>>> remove it from the compat wrapper.)
>>>
>>> I'm not sure that moving the variables outside the if() scope actually
>>> improves the code.  At least I think the original flow is easier to
>>> read.  Mostly due to the #ifdef noise, but still.  In a path that's not
>>> performance-critical, I prefer readability over performance.
>>>
>>
>>
>> Well, to be honest, I was definitely not trying to make any kind of
>> performance gain :)
>>
>> The whole idea was to make code easier to read and to remove some now
>> weird duplication of functions (the kind of duplication that will come and
>> bites you later).
>>
>> For the variables outside the ifs, the next C standard should allow us to
>> write something like:
>>
>> if ((RSA *rsa = EVP_PKEY_get0_RSA(pkey)) != NULL) {
>> ...
>>
>> That should be easier to read (but then, I'm not sure when this will be
>> considered as widespread ; I guess we're slated for 2025 or so :))
>>
>> Anyway, moving the variables within the if means we're going to call
>> EVP_PKEY_get0_RSA() twice which, I feel, is not a good thing to do. But
>> even if I'm not very comfortable with this, I can still propose a patch
>> that des it (it's lighter than the currently proposed change). You tell me
>> :)
>>
>
> Can I try one last time to convince you guys to keep EVP_PKEY_id()? If I
> was targeting only 1.1.0+ that's how most of those checks would have been
> done, isn't? Makes life easier, code simpler as I have said before..
>
> Just throwing in my 0.02c, feel free to ignore.
>
> Best,
>
> Selva
>


OpenSSL 1.1.0+ and previous versions allows you to create a typed EVP_PKEY
without any key inside. For example, you can do

  EVP_PKEY *pkey = EVP_PKEY_new();
  EVP_PKEY_set_type(pkey, EVP_PKEY_RSA);

This is plainly valid: the key is prepared for later use.

So testing for EVP_PKEY_id() is not sufficient to make sure that current
and future code won't mess with us. To be extra sure, one can do

if (EVP_PKEY_id() == EVP_PKEY_RSA && EVP_PKEY_get0_RSA(pkey)) { ... }

Which is exactly what the current code does. Yet the idea (at least mine)
is to remove that to simplify code a bit.

Now, I agree, this is quite easy to read and to understand.

We have 3 solutions:

1) keep the code as is

if (EVP_PKEY_id() == EVP_PKEY_RSA && EVP_PKEY_get0_RSA(pkey) != NULL) { ...
}

2) remove EVP_PKEY_id() but keep a test on EVP_PKEY_getO_RSA()

if (EVP_PKEY_get0_RSA(pkey) != NULL) {
RSA *rsa = EVP_PKEY_get0_RSA(pkey);
...
}

3) rework it as proposed in the patch

RSA *rsa = NULL;
if ((rsa = EVP_PKEY_get0_RSA(pkey)) != NULL) { ... }

While I prefer the latest, I can understand that it might not be the best
solution. I don't have a strong opinion on the subject (that's why it's a
separate patch ;)).

Best regards,

-- Emmanuel Deloget
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] PKCS#11 - a little bit of help?

2018-01-15 Thread Emmanuel Deloget

Hi James,

On Tue, Jan 16, 2018 at 12:18 AM, James Bottomley <
james.bottom...@hansenpartnership.com> wrote:

> On Tue, 2018-01-16 at 00:07 +0100, Emmanuel Deloget wrote:
> > While the number of required changes were quite small (and have no
> > impact on openvpn), this was quite a journey. I guess some of the
> > merits should go to RSA, Microsoft and Intel, for their incredible
> > effort in building comprehensive industry standards that are as
> > convoluted as they are comprehensive :) (I'm kidding ; I think I
> > begin to enjoy PKCS#11 and I definitely had some fun while playing
> > with my TPM2).
> >
> > Those who are interested can contact me. I will probably try to
> > write something about this somewhere (I don't know where yet).
>
> Just a note that there is an easier way of doing this.  The engine key
> patch:
>
> https://sourceforge.net/p/openvpn/mailman/message/36147533/
>
> Achieves the same thing somewhat more simply.  You use the tpm2 engine:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/
> openssl_tpm2_engine.git/
>
> And convert an existing private key into engine format with
> create_tpm2_key and place it in /etc/openvpn/ where the private key
> file usually goes.  Then all private key signature transactions go via
> the TPM.
>

The engine is of interest (although it would require me to change all my
scripts to remove the intel TPM2 stack and replace it with IBM tools ;
there is no sane reason to keep both of them in my setup). I missed it when
I tried to find an openssl engine for TPM2. The fact that I choose a
PKCS#11 engine is now final, unfortunately, at least for now. But I'll keep
an eye on it.

For the openvpn patches, I would not go this way for multiple reasons
(number one being: I already have to many patches on many things around ;
it becomes difficult to handle after a while, so I try to be as upstream as
possible) ; but this is interesting as well.



>
> James
>
>
Thanks for your links,

-- Emmanuel Deloget
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] PKCS#11 - a little bit of help?

2018-01-15 Thread James Bottomley

On Tue, 2018-01-16 at 00:07 +0100, Emmanuel Deloget wrote:
> While the number of required changes were quite small (and have no
> impact on openvpn), this was quite a journey. I guess some of the
> merits should go to RSA, Microsoft and Intel, for their incredible
> effort in building comprehensive industry standards that are as
> convoluted as they are comprehensive :) (I'm kidding ; I think I
> begin to enjoy PKCS#11 and I definitely had some fun while playing
> with my TPM2).
> 
> Those who are interested can contact me. I will probably try to
> write something about this somewhere (I don't know where yet).

Just a note that there is an easier way of doing this.  The engine key
patch:

https://sourceforge.net/p/openvpn/mailman/message/36147533/

Achieves the same thing somewhat more simply.  You use the tpm2 engine:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/

And convert an existing private key into engine format with
create_tpm2_key and place it in /etc/openvpn/ where the private key
file usually goes.  Then all private key signature transactions go via
the TPM.

James


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/3] OpenSSL: remove some EVP_PKEY type checks

2018-01-15 Thread Selva Nair

On Mon, Jan 15, 2018 at 5:33 PM, Emmanuel Deloget  wrote:

> Hello Steffan,
>
> On Sun, Jan 14, 2018 at 11:26 AM, Steffan Karger 
> wrote:
>
>> Hi,
>>
>> On 12-01-18 22:37, Emmanuel Deloget wrote:
>> > Calling EVP_KEY_id() before EVP_PKEY_get0_*() is unnecessary as
>> > the same check is also performed in the later.
>> >
>> > We also make the code a bit better by not calling the various
>> > EVP_PKEY_get0_*() functions twice (this needs a bit or reordering to
>> > avoid introducing yet another #ifndef OPENSSL_NO_EC in the code).
>>
>> Checking double is a bit silly, but we can fix that by simply removing
>> the "EVP_PKEY_id() == ... && " occurrences. (That still allows us to
>> remove it from the compat wrapper.)
>>
>> I'm not sure that moving the variables outside the if() scope actually
>> improves the code.  At least I think the original flow is easier to
>> read.  Mostly due to the #ifdef noise, but still.  In a path that's not
>> performance-critical, I prefer readability over performance.
>>
>
>
> Well, to be honest, I was definitely not trying to make any kind of
> performance gain :)
>
> The whole idea was to make code easier to read and to remove some now
> weird duplication of functions (the kind of duplication that will come and
> bites you later).
>
> For the variables outside the ifs, the next C standard should allow us to
> write something like:
>
> if ((RSA *rsa = EVP_PKEY_get0_RSA(pkey)) != NULL) {
> ...
>
> That should be easier to read (but then, I'm not sure when this will be
> considered as widespread ; I guess we're slated for 2025 or so :))
>
> Anyway, moving the variables within the if means we're going to call
> EVP_PKEY_get0_RSA() twice which, I feel, is not a good thing to do. But
> even if I'm not very comfortable with this, I can still propose a patch
> that des it (it's lighter than the currently proposed change). You tell me
> :)
>

Can I try one last time to convince you guys to keep EVP_PKEY_id()? If I
was targeting only 1.1.0+ that's how most of those checks would have been
done, isn't? Makes life easier, code simpler as I have said before..

Just throwing in my 0.02c, feel free to ignore.

Best,

Selva
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] PKCS#11 - a little bit of help?

2018-01-15 Thread Emmanuel Deloget

Hello Steffan,

Sorry for the delay - I was busy doing "things" :)


On Sat, Jan 6, 2018 at 12:11 AM, Steffan Karger  wrote:

> Hi Emmanuel,
>
> On 03-01-18 18:13, Emmanuel Deloget wrote:
> > Hello Steffan,
> >
> > On Mon, Jan 1, 2018 at 4:36 PM, Steffan Karger  > > wrote:
> >
> > Hi,
> >
> > On 01-01-18 14:57, Emmanuel Deloget wrote:
> > > I'm trying to get openvpn read my certificates from a TPM2 using a
> > > specially crafted PKCS#11 provider (the existing tpm2-pk11 is quite
> > > limited for now but I might be able to extend it).
> > >
> > > However, the PKCS#11 API is not something I'm comfortable with,
> and I'd
> > > like to know if there is some document (design or anything,
> really) that
> > > could help me to understand what openvpn wants exactly in order
> for me
> > > to provide the missing bits. I've read the documents at [1] but
> found
> > > nothing here of interest (for me).
> > >
> > > So, does someone have any pointer?
> >
> > You're right that OpenVPN's pkcs11 options lack some high-level
> > documentation.  Maybe I can shed some light on the basics (probably
> > taking a step further back than you need).
> >
> > First, you need some shared object (.so, .dll) that provides the
> > interface specified by the PKCS11 standard.  OpenVPN will load that
> > module, and call its functions to provide private key operations.
> That
> > shared object is usually provided by your smartcard vendor.  That
> shared
> > object takes care of communication with the underlying key store
> (smart
> > card, tpm, hsm, ...).  The openvpn manpage calls this a pkcs11
> > 'provider'.
> >
> > $ openvpn --show-pkcs11-ids
> > /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so
> >
> > The following objects are available for use.
> > Each object shown below may be used as parameter to
> > --pkcs11-id option please remember to use single quote mark.
> >
> >
> >
> > I seen that while testing. 
> >
> >
> >
> >
> > Certificate
> >DN: C=KG, ST=NA, O=OpenVPN-TEST, CN=Test-Client,
> > emailAddress=me@myhost.mydomain
> >Serial: 02
> >Serialized id:
> > Gnome\x20Keyring/1\x2E0/1\x3AUSER\x3ADEFAULT/Gnome2\
> x20Key\x20Storage/1A9D824585217F1BD54603E83F042F570A2EE9F2
> >
> > (I have the openvpn client testkey in my local gnome keyring, to
> easily
> > test pkcs11 without a hardware token.)
> >
> > From that list, you pick the object you want to use, and specify the
> > provider and id in your config file.  In this case:
> >
> > pkcs11-providers
> > "/usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so"
> > pkcs11-id
> > "Gnome\\x20Keyring/1\\x2E0/1\\x3AUSER\\x3ADEFAULT/Gnome2\\
> x20Key\\x20Storage/1B3B2BEBF36576443D3A903AFA8997221B93FCC1"
> >
> > You specify this *instead* of the regular 'key' and 'cert' options.
> > Note that you'll need toe escape backslashes.
> >
> >
> > Good to know :)
> >
> >
> >
> > You should now be able to use pkcs11 for the private key operations.
> >
> > Since each keystore behaves differently, I did not specify how to get
> > the private key in there.  But I guess your TPM vendor providers
> tooling
> > for that.
> >
> >
>





> >
> > In my understanding, and within a context of dual authentication (server
> > identifies client, client identifies server), I should see the following
> > set of operation:
> >
> > * fetch the certificate
> > * initiate communication and so some RSA magic
> > * everything's ok? continue
> >
> > Of course, I might be wrong. What I see is (with some printf within the
> > PKCS#11 provider, you can ignore them but they give you an idea of what
> > happens)
> >
> >
>  
>
> >
> >
> > Unfortunately, there is no RSA-related log, so I cannot check what
> > openvpn is doing with the certificate it found - so at this point, I'm a
> > bit confused.
>
> It does not do any RSA operations, because it does not connect:
>
> Wed Jan  3 17:53:39 2018 us=959952 Attempting to establish TCP
> connection with [AF_INET6]2a01:240:1906:1:0:1850:6118:4075:443 [nonblock]
> Wed Jan  3 17:53:40 2018 us=961428 TCP: connect to
> [AF_INET6]2a01:240:1906:1:0:1850:6118:4075:443 failed: Connection refused
>
> ... and then it tears down the instance.
>
> TLS will only do the RSA operations after a few handshake messages have
> been exchanged, and it has something to sign.  If you connect to a real
> server (even with the wrong certificate), you should see more.
>


I got it a bit later. We have a particular way to connect to our openvpn
instance. Before we do it, we have to tell the server we're going to
connect. And I forgot to do that ; as a result, the client does not even
find the server.

Anyway, I did some progress in my quest to have a working
TPM2-as-PKCS#11-provider. First

Re: [Openvpn-devel] [PATCH v2 2/3] OpenSSL: remove some EVP_PKEY type checks

2018-01-15 Thread Emmanuel Deloget

Hello Steffan,

On Sun, Jan 14, 2018 at 11:26 AM, Steffan Karger  wrote:

> Hi,
>
> On 12-01-18 22:37, Emmanuel Deloget wrote:
> > Calling EVP_KEY_id() before EVP_PKEY_get0_*() is unnecessary as
> > the same check is also performed in the later.
> >
> > We also make the code a bit better by not calling the various
> > EVP_PKEY_get0_*() functions twice (this needs a bit or reordering to
> > avoid introducing yet another #ifndef OPENSSL_NO_EC in the code).
>
> Checking double is a bit silly, but we can fix that by simply removing
> the "EVP_PKEY_id() == ... && " occurrences. (That still allows us to
> remove it from the compat wrapper.)
>
> I'm not sure that moving the variables outside the if() scope actually
> improves the code.  At least I think the original flow is easier to
> read.  Mostly due to the #ifdef noise, but still.  In a path that's not
> performance-critical, I prefer readability over performance.
>


Well, to be honest, I was definitely not trying to make any kind of
performance gain :)

The whole idea was to make code easier to read and to remove some now weird
duplication of functions (the kind of duplication that will come and bites
you later).

For the variables outside the ifs, the next C standard should allow us to
write something like:

if ((RSA *rsa = EVP_PKEY_get0_RSA(pkey)) != NULL) {
...

That should be easier to read (but then, I'm not sure when this will be
considered as widespread ; I guess we're slated for 2025 or so :))

Anyway, moving the variables within the if means we're going to call
EVP_PKEY_get0_RSA() twice which, I feel, is not a good thing to do. But
even if I'm not very comfortable with this, I can still propose a patch
that des it (it's lighter than the currently proposed change). You tell me
:)



>
> > Signed-off-by: Emmanuel Deloget 
> >
> > diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> > index 711bba11..7943fb2c 100644
> > --- a/src/openvpn/ssl_openssl.c
> > +++ b/src/openvpn/ssl_openssl.c
> > @@ -1699,22 +1699,13 @@ print_details(struct key_state_ssl *ks_ssl,
> const char *prefix)
> >  EVP_PKEY *pkey = X509_get_pubkey(cert);
> >  if (pkey != NULL)
> >  {
> > -if ((EVP_PKEY_id(pkey) == EVP_PKEY_RSA) &&
> (EVP_PKEY_get0_RSA(pkey) != NULL))
> > -{
> > -RSA *rsa = EVP_PKEY_get0_RSA(pkey);
> > -openvpn_snprintf(s2, sizeof(s2), ", %d bit RSA",
> > - RSA_bits(rsa));
> > -}
> > -else if ((EVP_PKEY_id(pkey) == EVP_PKEY_DSA) &&
> (EVP_PKEY_get0_DSA(pkey) != NULL))
> > -{
> > -DSA *dsa = EVP_PKEY_get0_DSA(pkey);
> > -openvpn_snprintf(s2, sizeof(s2), ", %d bit DSA",
> > - DSA_bits(dsa));
> > -}
> > +RSA *rsa = NULL;
> > +DSA *dsa = NULL;
> >  #ifndef OPENSSL_NO_EC
> > -else if ((EVP_PKEY_id(pkey) == EVP_PKEY_EC) &&
> (EVP_PKEY_get0_EC_KEY(pkey) != NULL))
> > +EC_KEY *ec = NULL;
> > +
> > +if ((ec = EVP_PKEY_get0_EC_KEY(pkey)) != NULL)
> >  {
> > -EC_KEY *ec = EVP_PKEY_get0_EC_KEY(pkey);
> >  const EC_GROUP *group = EC_KEY_get0_group(ec);
> >  const char* curve;
> >
> > @@ -1726,9 +1717,19 @@ print_details(struct key_state_ssl *ks_ssl, const
> char *prefix)
> >
> >  openvpn_snprintf(s2, sizeof(s2), ", %d bit EC, curve:
> %s",
> >   EC_GROUP_order_bits(group), curve);
> > -
> > -}
> > +} else
> >  #endif
> > +if ((rsa = EVP_PKEY_get0_RSA(pkey)) != NULL)
> > +{
> > +openvpn_snprintf(s2, sizeof(s2), ", %d bit RSA",
> > + RSA_bits(rsa));
> > +}
> > +else if ((dsa = EVP_PKEY_get0_DSA(pkey)) != NULL)
> > +{
> > +openvpn_snprintf(s2, sizeof(s2), ", %d bit DSA",
> > + DSA_bits(dsa));
> > +}
> > +
> >  EVP_PKEY_free(pkey);
> >  }
> >  X509_free(cert);
> >
>
> -Steffan
>


Best regards,

-- Emmanuel Deloget
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] travis builds

2018-01-15 Thread Selva Nair

Hi,

Out of the 12 or so jobs we have in the travis build matrix a few
sometime fail with "write error" (happened a number of times for some
local feature branches). On restarting only the failed jobs, one by
one, they succeed indicating possible resource starvation?

Is there anything one can do to avoid this?

Thanks,

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Document missing OpenVPN states

2018-01-15 Thread Arne Schwabe

Am 15.01.2018 um 12:47 schrieb Simon Rozman:
> ---
>  doc/management-notes.txt | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/doc/management-notes.txt b/doc/management-notes.txt
> index a9ba18a..908b981 100644
> --- a/doc/management-notes.txt
> +++ b/doc/management-notes.txt
> @@ -362,6 +362,8 @@ ADD_ROUTES-- Adding routes to system.
>  CONNECTED -- Initialization Sequence Completed.
>  RECONNECTING  -- A restart has occurred.
>  EXITING   -- A graceful exit is in progress.
> +RESOLVE   -- (Client only) DNS lookup
> +TCP_CONNECT   -- (Client only) Connecting to TCP server
>  
>  Command examples:
>  

Acked-by: Arne Schwabe 
Reviewed-by: Arne Schwabe 

ACK. I seen the state message often enough to that my double checking of
the code was almost pointless.

Arne


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Document missing OpenVPN states

2018-01-15 Thread Simon Rozman

---
 doc/management-notes.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index a9ba18a..908b981 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -362,6 +362,8 @@ ADD_ROUTES-- Adding routes to system.
 CONNECTED -- Initialization Sequence Completed.
 RECONNECTING  -- A restart has occurred.
 EXITING   -- A graceful exit is in progress.
+RESOLVE   -- (Client only) DNS lookup
+TCP_CONNECT   -- (Client only) Connecting to TCP server
 
 Command examples:
 
-- 
2.9.0.windows.1


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] travis-ci: modify openssl build script to support openssl-1.1.0

2018-01-15 Thread Steffan Karger

Hi,

On 15-01-18 09:05, Ilya Shipitsin wrote:
> get rid of no-multilib, as it is not supported on openssl-1.1.0
> 
> Signed-off-by: Ilya Shipitsin 
> ---
> v2: get rid of no-multilib instead of including it conditionally,
> thanks to Steffan Karger
> 
>  .travis/build-deps.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
> index bc538853..96a030cc 100755
> --- a/.travis/build-deps.sh
> +++ b/.travis/build-deps.sh
> @@ -111,7 +111,7 @@ build_openssl_mingw () {
>  fi
>  
>  ./Configure --cross-compile-prefix=${CHOST}- shared \
> -   ${TARGET} no-multilib no-capieng --prefix="${PREFIX}" 
> --openssldir="${PREFIX}" -static-libgcc
> +   ${TARGET} no-capieng --prefix="${PREFIX}" 
> --openssldir="${PREFIX}" -static-libgcc
>  make install
>  )
>  }
> 

Looks like the right thing to do to me.

Acked-by: Steffan Karger 

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: modify openssl build script to support openssl-1.1.0

2018-01-15 Thread Илья Шипицин

I've built an installer without "no-multilib" and tested on both x86 and
x64.

2018-01-14 23:33 GMT+05:00 Илья Шипицин :

>
>
> 2018-01-14 21:05 GMT+05:00 Steffan Karger :
>
>> Hi,
>>
>> On 14-01-18 15:06, Ilya Shipitsin wrote:
>> > no-multilib is only supported on openssl-1.0.X, do not use it
>> > if OPENSSL_VERSION is 1.1.0
>> >
>> > Signed-off-by: Ilya Shipitsin 
>> > ---
>> >  .travis/build-deps.sh | 5 +++--
>> >  1 file changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
>> > index bc538853..1761932e 100755
>> > --- a/.travis/build-deps.sh
>> > +++ b/.travis/build-deps.sh
>> > @@ -110,8 +110,9 @@ build_openssl_mingw () {
>> >  export TARGET=mingw64
>> >  fi
>> >
>> > -./Configure --cross-compile-prefix=${CHOST}- shared \
>> > -   ${TARGET} no-multilib no-capieng --prefix="${PREFIX}"
>> --openssldir="${PREFIX}" -static-libgcc
>> > +./Configure --cross-compile-prefix=${CHOST}- shared ${TARGET}
>> \
>> > +   $([[ ${OPENSSL_VERSION} == "1.0."* ]] && echo
>> "no-multilib") \
>> > +   no-capieng --prefix="${PREFIX}" --openssldir="${PREFIX}"
>> -static-libgcc
>> >  make install
>> >  )
>> >  }
>> >
>>
>> Do we need no-multilib for 1.0.x builds?  If not, I'd prefer to just get
>> rid of it.
>>
>
> it came from windows installer.
> let me build windows installer without no-multilib and test
>
>
>
>>
>> -Steffan
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/3] OpenSSL: remove some EVP_PKEY type checks

Re: [Openvpn-devel] [PATCH v2 2/3] OpenSSL: remove some EVP_PKEY type checks

Re: [Openvpn-devel] PKCS#11 - a little bit of help?

Re: [Openvpn-devel] PKCS#11 - a little bit of help?

Re: [Openvpn-devel] [PATCH v2 2/3] OpenSSL: remove some EVP_PKEY type checks

Re: [Openvpn-devel] PKCS#11 - a little bit of help?

Re: [Openvpn-devel] [PATCH v2 2/3] OpenSSL: remove some EVP_PKEY type checks

[Openvpn-devel] travis builds

Re: [Openvpn-devel] [PATCH] Document missing OpenVPN states

[Openvpn-devel] [PATCH] Document missing OpenVPN states

Re: [Openvpn-devel] [PATCH v2] travis-ci: modify openssl build script to support openssl-1.1.0

Re: [Openvpn-devel] [PATCH] travis-ci: modify openssl build script to support openssl-1.1.0

12 matches

Site Navigation

Mail list logo

Footer information