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