Re: easy-rsa LibreSSL issues

[Predrag Punosevac]

Theo de Raadt wrote:

> Maybe you can talk to the authors nicely and see if they can find a
> better way...

I did. I think they took it pretty well. Please see below. However 
quick browse through

https://github.com/OpenVPN/easy-rsa/issues

revels that easy-rsa has never been tested upstream with LibreSSL.


Predrag




 Original Message 
Date: Wed, 28 Oct 2015 04:59:11 -0700
From: Eric Crist 
To: OpenVPN/easy-rsa 
Subject: Re: [easy-rsa] LibreSSL exposes misuse of $ENV  (#76)


I read through the entire thread and it would be nice for us to support both 
LibreSSL and PolarSSL in the future.  This is likely a 3.2 fix.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenVPN/easy-rsa/issues/76#issuecomment-151820651

Re: easy-rsa LibreSSL issues

[Jona Joachim]

On 2015-10-25, Stuart Henderson  wrote:
> On 2015/10/25 09:44, Theo de Raadt wrote:
>> >I just spent 30 minutes playing with easy-rsa which is shipped broken on
>> >5.8 until I realized what was going on. I see that sthen has already
>> >reverted easy-rsa to OpenSSL run dependency per comment
>> >
>> >switch easy-rsa to using openssl to unbreak; libressl doesn't allow
>> >$ENV:: in config files and easy-asa uses this heavily.
>> >
>> >Moving forward should I even bother with easy-rsa and just use vanilla
>> >libressl to generate certificates? What is the recommendation for this
>> >port in the light of libressl "incompatibilities".
>> 
>> the ENV support was removed because a library cannot safely decide
>> whether to honour or not honour environment variables in all situations.
>> 
>> In OpenBSD, we can do this using issetugid, but there is no safe way
>> to emulate such a check on other systems (we do it with a system
>> call).
>> 
>> The practice of communicating to libraries with environment variables
>> like this is insane, and should be deprecated.  Maybe you can talk to
>> the authors nicely and see if they can find a better way...
>
> While on the subject, cert generation steps in the isakmpd(8) manual are
> also broken by this. It's absolutely right IMHO that the library should not
> honour these variables, but can anyone comment on how difficult/desirable
> it would be for the openssl(1) tool to handle these internally?

reyk@ fixed this for iked by having the code generate a temporary
configuration file for openssl(1) which has the correct variables set.

Re: easy-rsa LibreSSL issues

[Stuart Henderson]

On 2015/10/25 09:44, Theo de Raadt wrote:
> >I just spent 30 minutes playing with easy-rsa which is shipped broken on
> >5.8 until I realized what was going on. I see that sthen has already
> >reverted easy-rsa to OpenSSL run dependency per comment
> >
> >switch easy-rsa to using openssl to unbreak; libressl doesn't allow
> >$ENV:: in config files and easy-asa uses this heavily.
> >
> >Moving forward should I even bother with easy-rsa and just use vanilla
> >libressl to generate certificates? What is the recommendation for this
> >port in the light of libressl "incompatibilities".
> 
> the ENV support was removed because a library cannot safely decide
> whether to honour or not honour environment variables in all situations.
> 
> In OpenBSD, we can do this using issetugid, but there is no safe way
> to emulate such a check on other systems (we do it with a system
> call).
> 
> The practice of communicating to libraries with environment variables
> like this is insane, and should be deprecated.  Maybe you can talk to
> the authors nicely and see if they can find a better way...

While on the subject, cert generation steps in the isakmpd(8) manual are
also broken by this. It's absolutely right IMHO that the library should not
honour these variables, but can anyone comment on how difficult/desirable
it would be for the openssl(1) tool to handle these internally?

Re: easy-rsa LibreSSL issues

[Theo de Raadt]

> While on the subject, cert generation steps in the isakmpd(8) manual are
> also broken by this. It's absolutely right IMHO that the library should not
> honour these variables, but can anyone comment on how difficult/desirable
> it would be for the openssl(1) tool to handle these internally?

There should be an API to do help.

It looks like we have a brave new generation of developers who were
not taught the old lessons about what to not pass in environment
variables.

easy-rsa LibreSSL issues

[Predrag Punosevac]

I just spent 30 minutes playing with easy-rsa which is shipped broken on
5.8 until I realized what was going on. I see that sthen has already
reverted easy-rsa to OpenSSL run dependency per comment

switch easy-rsa to using openssl to unbreak; libressl doesn't allow
$ENV:: in config files and easy-asa uses this heavily.

Moving forward should I even bother with easy-rsa and just use vanilla
libressl to generate certificates? What is the recommendation for this
port in the light of libressl "incompatibilities".

Predrag

Re: easy-rsa LibreSSL issues

[Theo de Raadt]

>I just spent 30 minutes playing with easy-rsa which is shipped broken on
>5.8 until I realized what was going on. I see that sthen has already
>reverted easy-rsa to OpenSSL run dependency per comment
>
>switch easy-rsa to using openssl to unbreak; libressl doesn't allow
>$ENV:: in config files and easy-asa uses this heavily.
>
>Moving forward should I even bother with easy-rsa and just use vanilla
>libressl to generate certificates? What is the recommendation for this
>port in the light of libressl "incompatibilities".

the ENV support was removed because a library cannot safely decide
whether to honour or not honour environment variables in all situations.

In OpenBSD, we can do this using issetugid, but there is no safe way
to emulate such a check on other systems (we do it with a system
call).

The practice of communicating to libraries with environment variables
like this is insane, and should be deprecated.  Maybe you can talk to
the authors nicely and see if they can find a better way...

Re: easy-rsa LibreSSL issues

[Stuart Henderson]

On 2015/10/25 17:26, Jona Joachim wrote:
> reyk@ fixed this for iked by having the code generate a temporary
> configuration file for openssl(1) which has the correct variables set.

That's good for iked, but doesn't help the scripts in the wild that
rely on this. Since the commands for certificate operations outside
of the basic "generate a webserver cert for a single hostname" are so
arcane, people rely on published recipes and scripts to do this all
the time, and at least in the ones I've found relating to VPN cert
generation (IPsec and others), and for subjectAltName for servers
with multiple hostnames, it's pretty common to use variables.

BTW http://www.carbonwind.net/VPN/XCA_OpenVPN/XCA_OpenVPN.htm
has an example of how to use XCA (gui for PKI operations) to
generate certs for OpenVPN, this might be a workable alternative
to easy-rsa for some.