1 |
On 08/14/2010 02:26 PM, Peter Hjalmarsson wrote: |
2 |
> This is about my beloved USE="ssl". A bit long and ranty, but if you |
3 |
> want the consensus, just read the last part. |
4 |
> |
5 |
> |
6 |
> Today a new snapshot of gnash was uploaded where the old USE="ssl" was |
7 |
> renamed to USE="openssl". |
8 |
> |
9 |
> So yet another package where if you want ssl support you have to |
10 |
> _personally_ audit what function this useflag has (i.e. does it enable |
11 |
> ssl or tune the ssl implementation?). |
12 |
> |
13 |
> So I wanted to figure it out, does gnash provide ssl itself and the |
14 |
> USE="openssl" only tunes how it is implemented or does USE="openssl" |
15 |
> enable ssl? |
16 |
> |
17 |
> So what does the flag really do? Their local description does not say |
18 |
> very much: |
19 |
> local:openssl:www-plugins/gnash: Enable directly using OpenSSL |
20 |
> |
21 |
> What is even "enabled directly"? Still not much smarter. |
22 |
> Unpacking the source and looking in ./configure --help and the strange |
23 |
> description for the use flag gets an explanation: |
24 |
> --enable-ssl Enable using OpenSSL directly |
25 |
> |
26 |
> Still not much smarter... |
27 |
> |
28 |
> Looking inside configure.ac makes me smarter tho: |
29 |
> |
30 |
> dnl Enable using OpenSSL with libnet. |
31 |
> AC_ARG_ENABLE(ssl, |
32 |
> AC_HELP_STRING([--enable-ssl], [Enable using OpenSSL directly]), |
33 |
> [case "${enableval}" in |
34 |
> yes) build_ssl=yes ;; |
35 |
> no) build_ssl=no ;; |
36 |
> *) AC_MSG_ERROR([bad value ${enableval} for --enable-ssl option]) ;; |
37 |
> esac], build_ssl=no) |
38 |
> |
39 |
> So apparently it seems the flag enables ssl support using openssl. |
40 |
> |
41 |
> No, I did not review the source to make sure that build_ssl does really |
42 |
> build ssl, but do I really have to to find out what a USE-flag does? |
43 |
> |
44 |
> Personally I would still like the description for the useflag to really |
45 |
> describe the flag, like: |
46 |
> global:ssl: Adds support for Secure Socket Layer connections |
47 |
> |
48 |
> (and thus in this case the use flag to still be USE="ssl") |
49 |
> |
50 |
> |
51 |
> |
52 |
> And why I post here instead of making a bug is to try to start a |
53 |
> discussion that is still not finished[1]: |
54 |
> What function should useflags bring? |
55 |
> |
56 |
> There are some packages (like networkmanager) that does not have a ssl |
57 |
> flag (it is always enabled), and the gnutls/nss useflags are used to |
58 |
> fine tune what implementation to use. If non selected the upstream |
59 |
> preferred (nss) is chosen. |
60 |
> |
61 |
> Then there are some packages (like qemu) where there is only one flag |
62 |
> (USE="gnutls") that enables support for encrypten vnc. |
63 |
> |
64 |
> Then there are packages like curl where the local description of |
65 |
> USE="ssl" says it all: |
66 |
> local:ssl:net-misc/curl: Enable crypto engine support (via openssl if |
67 |
> USE='-gnutls -nss') |
68 |
> |
69 |
> |
70 |
> |
71 |
> |
72 |
> |
73 |
> So as a user, if I want to have Secure Socket Layer or Transport Layer |
74 |
> Security, do I really need to learn the name of every implementation |
75 |
> known to man and enable their respective use flag to ensure that my |
76 |
> whole system has support for it, or should I just have to enable |
77 |
> USE="ssl"? |
78 |
> And will I still be sure that those use flag did not disable a (maybe |
79 |
> superior or by maintainer preferred) internal ssl implementation? |
80 |
> |
81 |
> |
82 |
> [1] Last time I did a bugreport about this, here is the answer: |
83 |
> https://bugs.gentoo.org/show_bug.cgi?id=310681 |
84 |
|
85 |
Long story short: |
86 |
|
87 |
If package has SSL support, and use "ssl" is ignored or not present in a |
88 |
ebuild. it's plain broken. |
89 |
|
90 |
Every ebuild in tree with USE="openssl" is a QA violation, and should be |
91 |
fixed asap. |