On 08/14/2010 02:26 PM, Peter Hjalmarsson wrote:
> This is about my beloved USE="ssl". A bit long and ranty, but if you
> want the consensus, just read the last part.
>
>
> Today a new snapshot of gnash was uploaded where the old USE="ssl" was
> renamed to USE="openssl".
>
> So yet another package where if you want ssl support you have to
> _personally_ audit what function this useflag has (i.e. does it enable
> ssl or tune the ssl implementation?).
>
> So I wanted to figure it out, does gnash provide ssl itself and the
> USE="openssl" only tunes how it is implemented or does USE="openssl"
> enable ssl?
>
> So what does the flag really do? Their local description does not say
> very much:
> local:openssl:www-plugins/gnash: Enable directly using OpenSSL
>
> What is even "enabled directly"? Still not much smarter.
> Unpacking the source and looking in ./configure --help and the strange
> description for the use flag gets an explanation:
> --enable-ssl Enable using OpenSSL directly
>
> Still not much smarter...
>
> Looking inside configure.ac makes me smarter tho:
>
> dnl Enable using OpenSSL with libnet.
> AC_ARG_ENABLE(ssl,
> AC_HELP_STRING([--enable-ssl], [Enable using OpenSSL directly]),
> [case "${enableval}" in
> yes) build_ssl=yes ;;
> no) build_ssl=no ;;
> *) AC_MSG_ERROR([bad value ${enableval} for --enable-ssl option]) ;;
> esac], build_ssl=no)
>
> So apparently it seems the flag enables ssl support using openssl.
>
> No, I did not review the source to make sure that build_ssl does really
> build ssl, but do I really have to to find out what a USE-flag does?
>
> Personally I would still like the description for the useflag to really
> describe the flag, like:
> global:ssl: Adds support for Secure Socket Layer connections
>
> (and thus in this case the use flag to still be USE="ssl")
>
>
>
> And why I post here instead of making a bug is to try to start a
> discussion that is still not finished[1]:
> What function should useflags bring?
>
> There are some packages (like networkmanager) that does not have a ssl
> flag (it is always enabled), and the gnutls/nss useflags are used to
> fine tune what implementation to use. If non selected the upstream
> preferred (nss) is chosen.
>
> Then there are some packages (like qemu) where there is only one flag
> (USE="gnutls") that enables support for encrypten vnc.
>
> Then there are packages like curl where the local description of
> USE="ssl" says it all:
> local:ssl:net-misc/curl: Enable crypto engine support (via openssl if
> USE='-gnutls -nss')
>
>
>
>
>
> So as a user, if I want to have Secure Socket Layer or Transport Layer
> Security, do I really need to learn the name of every implementation
> known to man and enable their respective use flag to ensure that my
> whole system has support for it, or should I just have to enable
> USE="ssl"?
> And will I still be sure that those use flag did not disable a (maybe
> superior or by maintainer preferred) internal ssl implementation?
>
>
> [1] Last time I did a bugreport about this, here is the answer:
> https://bugs.gentoo.org/show_bug.cgi?id=310681
Long story short:
If package has SSL support, and use "ssl" is ignored or not present in a
ebuild. it's plain broken.
Every ebuild in tree with USE="openssl" is a QA violation, and should be
fixed asap.
