Re: easy-rsa LibreSSL issues
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
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.
Re: easy-rsa LibreSSL issues
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
> 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.
Re: easy-rsa LibreSSL issues
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
>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...