ssl-cert.eclass depends on dev-libs/openssl. It has no provisions for dev-libs/libressl. If a user tries to install eg www-servers/apache with USE="ssl libressl" it will fail, because the apache-2 eclass will try to pull in libressl and ssl-cert.eclass, and ssl-cert.eclass will try to pull in openssl. They can't both be installed. A workaround is to install all of apache's dependencies manually, then install apache with --nodeps. All the ssl-cert eclass funcs appear to run correctly using libressl's executable, so installation succeeds despite not having the required dependencies installed. Reproducible: Always
Created attachment 422512 [details, diff] add libressl support
CC'ing libressl maintainers. They might be interested.
Created attachment 423850 [details, diff] libressl dropped -rand option from openssl genrsa command The libressl version of the 'openssl genrsa' command does not support the -rand argument, causing the eclass to fail when generating rsa keys. The argument was dropped because libressl guarantees randomness without needing a seed file. The attached patch uses the output of 'openssl version' to detect libressl. If present, the -rand argument is dropped. The use of the openssl version command was chosen over use flag detection because we need to know the installed and active openssl version regardless of useflag settings. This patch also adds the libressl use flag to packages that reference the eclass. This allows explicit selection of openssl vs libressl.
Are the patches merged?
(In reply to timofonic from comment #4) > Are the patches merged? Does the bug look like it's marked fixed?
(In reply to maurerpe from comment #3) > Created attachment 423850 [details, diff] [details, diff] > libressl dropped -rand option from openssl genrsa command > > The libressl version of the 'openssl genrsa' command does not support the > -rand argument, causing the eclass to fail when generating rsa keys. The > argument was dropped because libressl guarantees randomness without needing > a seed file. > > The attached patch uses the output of 'openssl version' to detect libressl. > If present, the -rand argument is dropped. The use of the openssl version > command was chosen over use flag detection because we need to know the > installed and active openssl version regardless of useflag settings. > > This patch also adds the libressl use flag to packages that reference the > eclass. This allows explicit selection of openssl vs libressl. I'll take a look. Your patch looks complete, but I'm wondering whether or not openssl or libressl should have slots operators. Ebuilds that inherit it will wind up depending on openssl and libressl and we would like consistent slot dependency.
Yes, this needs a slot dep, or at the very least a way to tell the eclass that the ebuild will handle the openssl dep on it's own.
(In reply to Robin Johnson from comment #7) > Yes, this needs a slot dep, or at the very least a way to tell the eclass > that the ebuild will handle the openssl dep on it's own. okay after talking with the openssl folks, it looks like they want :0= on all openssl deps. i'll add it.
(In reply to Anthony Basile from comment #8) > (In reply to Robin Johnson from comment #7) > > Yes, this needs a slot dep, or at the very least a way to tell the eclass > > that the ebuild will handle the openssl dep on it's own. > > okay after talking with the openssl folks, it looks like they want :0= on > all openssl deps. i'll add it. okay done. please tests and reopen if anything is broken.
With this commit (https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/ssl-cert.eclass?id=7a4d6bd5fcb25d8381bc08e20ad6a5c1c80ad78f), the mail-mta/postfix and net-mail/dovecot is still trying to install openssl as dependency.
No good for me either on samba.
(In reply to Joe Kappus from comment #11) > No good for me either on samba. there was some disagreement with other devs about how this should be done so i reverted temporarily. i'll commit again later and post here when i have.
Looks like finally this was fixed with: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e21b7de461c1ea87cca4423a57dbc6d355611c9b
(In reply to Pacho Ramos from comment #13) > Looks like finally this was fixed with: > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=e21b7de461c1ea87cca4423a57dbc6d355611c9b it was, i forgot to close this. thanks pacho :)
*** Bug 579786 has been marked as a duplicate of this bug. ***
