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