Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
Dear all, I'm a bit late to the party, but here is my $0.02: REQUIRED_USE= curl_ssl_winssl? ( elibc_Winnt ) ssl? ( ^^ ( [...] ) ) I don't like this. If the user specifies several SSL providers in make.conf, it should mean that any of these is fine and the ebuild can choose an arbitrary one. The exactly-one-of operator would cause emerge to complain in this case and possibly force the user to have complex package.use setups. With the number of ssl providers growing, like libressl, and with issues like bug #510974, I think its time we consider making this a uniform way of dealing with ssl providers in gentoo. We would proceed something like this: 1. Introduce a new USE_EXPAND called SSL which mirrors CURL_SSL --- becuase CURL_SSL is too provincial a name. 2. migrate curl and all its dependencies to the SSL use expand. 3. Migrate over all consumers of ssl to the new SSL use expand system. What do people think? I think a better name for the USE_EXPAND would be CRYPTO_PROVIDER (or similar) instead of just SSL, as the libraries are not strictly used for SSL but also for other forms of crypto (e.g. [1]). Best regards, Chí-Thanh Christopher Nguyễn [1] https://bugs.gentoo.org/show_bug.cgi?id=512664
Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
On 06/11/14 07:12, Chí-Thanh Christopher Nguyễn wrote: Dear all, I'm a bit late to the party, but here is my $0.02: REQUIRED_USE= curl_ssl_winssl? ( elibc_Winnt ) ssl? ( ^^ ( [...] ) ) I don't like this. If the user specifies several SSL providers in make.conf, it should mean that any of these is fine and the ebuild can choose an arbitrary one. The exactly-one-of operator would cause emerge to complain in this case and possibly force the user to have complex package.use setups. That's a good point and not one that I wasn't aware of. But how would we better design this? The only thing I can thing of (suggested earlier) is an eclass with some intelligence. I'm not sure of the most userfriendly way of doing this. With the number of ssl providers growing, like libressl, and with issues like bug #510974, I think its time we consider making this a uniform way of dealing with ssl providers in gentoo. We would proceed something like this: 1. Introduce a new USE_EXPAND called SSL which mirrors CURL_SSL --- becuase CURL_SSL is too provincial a name. 2. migrate curl and all its dependencies to the SSL use expand. 3. Migrate over all consumers of ssl to the new SSL use expand system. What do people think? I think a better name for the USE_EXPAND would be CRYPTO_PROVIDER (or similar) instead of just SSL, as the libraries are not strictly used for SSL but also for other forms of crypto (e.g. [1]). Agreed. Best regards, Chí-Thanh Christopher Nguyễn [1] https://bugs.gentoo.org/show_bug.cgi?id=512664 -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
Dnia 2014-06-11, o godz. 13:12:38 Chí-Thanh Christopher Nguyễn chith...@gentoo.org napisał(a): REQUIRED_USE= curl_ssl_winssl? ( elibc_Winnt ) ssl? ( ^^ ( [...] ) ) I don't like this. If the user specifies several SSL providers in make.conf, it should mean that any of these is fine and the ebuild can choose an arbitrary one. The exactly-one-of operator would cause emerge to complain in this case and possibly force the user to have complex package.use setups. Your idea comes with three significant drawbacks: 1. USE flag setups become unclear -- user sees five different SSL providers turned on and has no clue which one is actually used. 2. You create 2^n-1 valid USE flag combinations which map to n different file sets. This means that there are 2^n-n-1 useless USE flag combination which make matching binary packages a PITA. 3. There is no clean way of enforcing SSL provider match between packages. Wasn't this thread initially about curl and rtmpdump requiring matching flags? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
Michał Górny schrieb: I don't like this. If the user specifies several SSL providers in make.conf, it should mean that any of these is fine and the ebuild can choose an arbitrary one. The exactly-one-of operator would cause emerge to complain in this case and possibly force the user to have complex package.use setups. Your idea comes with three significant drawbacks: 1. USE flag setups become unclear -- user sees five different SSL providers turned on and has no clue which one is actually used. Does that really matter? What I got from bug 512664 comment 0 is the desire to ensure that a certain crypto provider (in this case, openssl) is *not* used. 2. You create 2^n-1 valid USE flag combinations which map to n different file sets. This means that there are 2^n-n-1 useless USE flag combination which make matching binary packages a PITA. This is indeed a problem, if producer and consumer of the binpkg are different entities. It could be mitigated by pre-populating the default list of crypto providers so that most users will not need to change it. 3. There is no clean way of enforcing SSL provider match between packages. Wasn't this thread initially about curl and rtmpdump requiring matching flags? It could be enforced if an eclass does the actual choice of crypto provider in a reproducible way. That would be not trivial though. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
Dnia 2014-06-11, o godz. 15:30:26 Chí-Thanh Christopher Nguyễn chith...@gentoo.org napisał(a): 3. There is no clean way of enforcing SSL provider match between packages. Wasn't this thread initially about curl and rtmpdump requiring matching flags? It could be enforced if an eclass does the actual choice of crypto provider in a reproducible way. That would be not trivial though. No, it can't. Let's say package A depends on package B and requires the same SSL provider. A has 'openssl gnutls' B has 'openssl gnutls polarssl' Now let's say the eclass prefers polarssl over the other two. How are you going to make A dep on B? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
Michał Górny schrieb: Dnia 2014-06-11, o godz. 15:30:26 Chí-Thanh Christopher Nguyễn chith...@gentoo.org napisał(a): 3. There is no clean way of enforcing SSL provider match between packages. Wasn't this thread initially about curl and rtmpdump requiring matching flags? It could be enforced if an eclass does the actual choice of crypto provider in a reproducible way. That would be not trivial though. No, it can't. Let's say package A depends on package B and requires the same SSL provider. A has 'openssl gnutls' B has 'openssl gnutls polarssl' Now let's say the eclass prefers polarssl over the other two. How are you going to make A dep on B? It is not trivial, but I don't think it is impossible. I had thought of the following, but have not carefully checked that it covers all cases. crypto-providers.eclass would have a list CRYPTO_PROVIDERS_SUPPORTED sorted descending by priority, and A and B would pass in a variable CRYPTO_PROVIDERS the acceptable providers. The eclass would provide functions which expand into USE dependencies to ensure that no higher-prioritized crypto provider is selected in B. Example: crypto-providers.eclass: CRYPTO_PROVIDERS_SUPPORTED=polarssl openssl gnutls libgcrypt libnettle ... crypto-providers_only() returns USE dependency on its arguments, and negative USE dependencies for all providers with higher priority, e.g. crypto-providers_only(gnutls) returns -crypto_providers_polarssl(-) -crypto_providers_openssl(-) crypto_providers_gnutls(-) crypto-providers_match(packagename) returns priority nested USE conditionals for all CRYPTO_PROVIDERS that can be fed into DEPEND, e.g. crypto_providers_match(B) would return crypto-providers_openssl? ( B[$(crypto_providers-only(openssl)] ) !crypto-providers_openssl? ( crypto-providers_gnutls? ( B[$(crypto_providers-only(gnutls)] ) ) A.ebuild CRYPTO_PROVIDERS=openssl gnutls DEPEND=$(crypto-providers_match(B)) B.ebuild CRYPTO_PROVIDERS=openssl gnutls polarssl Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
On Thu, 29 May 2014 13:42:01 -0400 Anthony G. Basile bluen...@gentoo.org wrote: Back in Jun 2012 I added a CURL_SSL to the USE_EXPAND to represent You could start by fixing boring old bugs instead of working on exciting new features. See bug 510580, née 499398, which stops everyone from stabilising because you have the USE defaults / REQUIRED_USE wrong. jer
[gentoo-dev] Creating a USE_EXPAND for ssl providers
Hi everyone,
Back in Jun 2012 I added a CURL_SSL to the USE_EXPAND to represent the
different ssl providers for curl. This was to get away from the old ssl
USE flag logic which you still see in packages like
media-video/rtmpdump. Quoting from there so you don't have to go find it
yourself (and removing extraneous stuff) we have:
IUSE=gnutls polarssl ssl
DEPEND=ssl? (
gnutls? ( net-libs/gnutls )
polarssl? ( !gnutls? ( =net-libs/polarssl-0.14.0 ) )
!gnutls? ( !polarssl? ( dev-libs/openssl ) )
)
pkg_setup() {
if ! use ssl ( use gnutls || use polarssl ) ; then
ewarn USE='gnutls polarssl' are ignored without USE='ssl'.
ewarn Please review the local USE flags for this package.
fi
}
The idea is that if you say USE=ssl but nothing more, you default to
openssl. This is asymmetrical and doesn't scale well. So I made the
leap in curl to the following (modulo extra stuff):
IUSE=${IUSE} curl_ssl_axtls curl_ssl_cyassl curl_ssl_gnutls
curl_ssl_nss +curl_ssl_openssl curl_ssl_polarssl curl_ssl_winssl
RDEPEND=
ssl? (
curl_ssl_axtls? ( net-libs/axtls app-misc/ca-certificates )
curl_ssl_cyassl? ( net-libs/cyassl app-misc/ca-certificates )
curl_ssl_gnutls? (
|| (
( =net-libs/gnutls-3[static-libs?] dev-libs/nettle )
( =net-libs/gnutls-2.12*[nettle,static-libs?]
dev-libs/nettle )
( =net-libs/gnutls-2.12*[-nettle,static-libs?]
dev-libs/libgcrypt[static-libs?] )
)
app-misc/ca-certificates
)
curl_ssl_openssl? ( dev-libs/openssl[static-libs?] )
curl_ssl_nss? ( dev-libs/nss app-misc/ca-certificates )
curl_ssl_polarssl? ( net-libs/polarssl:= app-misc/ca-certificates )
)
REQUIRED_USE=
curl_ssl_winssl? ( elibc_Winnt )
ssl? (
^^ (
curl_ssl_axtls
curl_ssl_cyassl
curl_ssl_gnutls
curl_ssl_openssl
curl_ssl_nss
curl_ssl_polarssl
curl_ssl_winssl
)
)
With the number of ssl providers growing, like libressl, and with issues
like bug #510974, I think its time we consider making this a uniform way
of dealing with ssl providers in gentoo. We would proceed something
like this:
1. Introduce a new USE_EXPAND called SSL which mirrors CURL_SSL ---
becuase CURL_SSL is too provincial a name.
2. migrate curl and all its dependencies to the SSL use expand.
3. Migrate over all consumers of ssl to the new SSL use expand system.
What do people think?
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
Anthony G. Basile wrote: 2. migrate curl and all its dependencies to the SSL use expand. 3. Migrate over all consumers of ssl to the new SSL use expand system. As long as consumers can support only a few of the expansions that just seems to tidy things up, which is a good thing. //Peter
