1 |
Michał Górny wrote: |
2 |
> > I'm sure that there are numerous cases where libressl doesn't work, |
3 |
> > but that's no reason to dismiss cases where it *does*. |
4 |
> |
5 |
> Are you asking people to put an effort into maintaining something that |
6 |
> can't be practically installed? |
7 |
|
8 |
No, I'm rather asking to change the level of commitment. |
9 |
|
10 |
I agree completely that it's unreasonable for Gentoo (worse, 1 person!) |
11 |
to continuosly patch the entire world for libressel. |
12 |
|
13 |
I'm asking to stop doing that, yet still enable the choice between |
14 |
openssl and libressl where that is possible without patches, even |
15 |
if that's only openntpd and one other package. |
16 |
|
17 |
The method for that choice could of course depend on the number of |
18 |
packages where it applies. |
19 |
|
20 |
|
21 |
> A side effect of this approach is that users will be tricked into using |
22 |
> LibreSSL, only to discover that they eventually have to transition |
23 |
> their systems back. |
24 |
|
25 |
I believe I'm asking for the opposite. I think it's fine to say that |
26 |
libressl has to be a deliberate choice rather than a default. |
27 |
|
28 |
|
29 |
> > Did anyone gather actual numbers? |
30 |
> |
31 |
> $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l |
32 |
> 61 |
33 |
|
34 |
I'm more interested in the number of packages which can use either |
35 |
library without patches (like openntpd?). This may be tricky to find out. :\ |
36 |
|
37 |
|
38 |
> > > > B. It brings its own TLS API, a unique feature which by itself |
39 |
> > > > warrants the package. |
40 |
> > > |
41 |
> > > ...which by itself has no future |
42 |
> > |
43 |
> > That's arrogant and silly coming from anywhere but upstream. |
44 |
> > |
45 |
> > You can argue that you will never use the API in your TLS programs, |
46 |
> > but even then that says really nothing about the API provider itself. |
47 |
> |
48 |
> That's my opinion and I have a right to have it without being insulted. |
49 |
|
50 |
You absolutely have a right to your opinion but you stated it as fact, |
51 |
that made me react so strongly. |
52 |
|
53 |
|
54 |
> I don't dispute whether it's good. I dispute whether tightly binding |
55 |
> it to a problematic LibreSSL is a good idea. |
56 |
|
57 |
I agree with this, but only in cases where libressl is indeed problematic. |
58 |
|
59 |
I can think of systems where it isn't, there the choice is a good thing. |
60 |
|
61 |
|
62 |
> Actually, I see that someone has apparently forked libtls into libretls |
63 |
> (the irony!) that works against OpenSSL [1]. |
64 |
|
65 |
To me, that proves value in the libtls API and in keeping libressl in |
66 |
the tree in some capacity, even if not as an alternative to openssl. |
67 |
|
68 |
Maybe with a USE flag which makes it install only libtls (built from |
69 |
libressl static libs), which could be one provider for a virtual/libtls. |
70 |
|
71 |
Note: I'm not at all expecting anyone to do such work for me, I just |
72 |
don't want it to become impossible (libressl mask) or any existing |
73 |
effort supporting something like the above to be sunset. |
74 |
|
75 |
Does that make sense? |
76 |
|
77 |
|
78 |
Thanks! |
79 |
|
80 |
//Peter |