1 |
Hi Peter, |
2 |
|
3 |
I believe that as a maintainer I stated same in a previous email, and |
4 |
based on what I've read it seems very few maintainers/developers would |
5 |
object to it if someone was willing to do the work to enable things to |
6 |
co-exist. So a few points that I picked up during this discussion. |
7 |
|
8 |
1. Nobody is AGAINST libressl per sé, |
9 |
2. A number of people are AGAINTS the effort involved to make libressl |
10 |
work for various packages. |
11 |
|
12 |
Without the latter, libressl is dead since it can't install concurrently |
13 |
with openssl. Which is why someone needs to make the effort. My |
14 |
earlier suggestion for openssl-provider being an eclass I still think is |
15 |
the best way to go, but this will require someone to write it. |
16 |
|
17 |
With dubious benefits, I don't see a great many number of people jumping |
18 |
at the opportunity, but I'm sure that if someone can manage the basis |
19 |
for this, then sure. Again, this will mean for libraries that they will |
20 |
need to have multi-implementation installations again, consider the case |
21 |
where package A links both package B and open/libressl, and package B |
22 |
also links open/libressl. In such a case package B would need to |
23 |
install both variants if required. Similar to x86_32 vs x86_64, or the |
24 |
various different python versions if you will. So we'd need |
25 |
openssl-impl-multi and openssl-impl-single to accomodate these cases. |
26 |
So how do you deal with package-b-libressl vs package-b-openssl in terms |
27 |
of dependencies? Or must all libraries now that links one or both of |
28 |
those also pull the same stunts (ie, install into |
29 |
/usr/lib{,32,64}/{open,libre}ssl/) in order to not have conflicting linkage? |
30 |
|
31 |
There are possibly cases where the consumer of package b can link |
32 |
openssl where the library links libressl, but this would have name space |
33 |
issues probably (you can refer to https://bugs.gentoo.org/649924 for the |
34 |
kind of really hard to diagnose and fix bugs this results in). |
35 |
|
36 |
Alternatively a virtual/libssl ... but these really only work where |
37 |
there are COMPATIBLE APIs, which it's clear openssl and libressl is not. |
38 |
|
39 |
There are other nuances involved too (ie, a -lssl without an explicitly |
40 |
-L/usr/lib{,lib64}/sslimpl should fail, ditto for #includes without |
41 |
specific -I) - it's going to be very involved (or at the very least the |
42 |
DEFAULT implementation should be openssl). Lots of very finicky risks |
43 |
that needs to be eliminated wih installing both openssl and libressl |
44 |
concurrently. |
45 |
|
46 |
Which means: |
47 |
|
48 |
3. Very few people (if any) are going to be willing to put in the |
49 |
effort to make the above happen. |
50 |
4. Even if you can make that happen, it now means that as a maintainer, |
51 |
I still need to at least compile-test every package release that I |
52 |
maintain against both openssl and libressl - and either ban one |
53 |
implementation or the other or patch it, again ... which is exactly what |
54 |
developers/maintainers are complaining about. |
55 |
|
56 |
So, if you are offering to put in the work required to make this happen, |
57 |
sure, I'm sure the patches would be welcome, and I'm sure a number of |
58 |
people would be willing to help you test and provide suggestions even. |
59 |
|
60 |
If you want to drive libressl, the way musl and the like are driven, |
61 |
filing bugs against packages that doesn't work well, and assisting with |
62 |
patching, I'm fairly certain most developers won't mind, however, myself |
63 |
included, would want to do as little as humanly possible around it. Of |
64 |
course I'm fortunate in that my primary upstream is very supportive and |
65 |
welcomes patches (of which I've submitted a number of over the last |
66 |
decade), which means I don't have to carry patches in gentoo.git for the |
67 |
most part. |
68 |
|
69 |
Unless you, or someone else, is willing to put in that effort I'm afraid |
70 |
I have to agree with most other devs: libressl is a novel idea and |
71 |
concept, but it's dead. Someone (Michał?) mentioned it's more pain than |
72 |
gain currently. And unless someone is willing to change that, I |
73 |
seriously doubt anything you say is going to carry much weight. What |
74 |
people are asking for is the motivation that you have whereby you feel |
75 |
the gain is worth the (significant) pain. I too like the concept of |
76 |
alternative choices, but each choice comes with a cost, and if the user |
77 |
isn't paying that cost, a developer somewhere is. And having written my |
78 |
fair share of code - the level of ask that you're asking for is much, |
79 |
much larger than I think you realise. |
80 |
|
81 |
mysql and mariadb started out very similar, and now there are two major |
82 |
projects, and parts of it are installable separately (client libs). I |
83 |
believe there was even work done to be able to install multiple server |
84 |
versions concurrently (But since I don't have a requirement for this, I |
85 |
haven't followed in detail). Needless to say, it's a LOT of work for |
86 |
even the basics of what you're requesting. |
87 |
|
88 |
To the best of my knowledge most Gentoo devs aren't getting paid to just |
89 |
sit and do this work. If we get paid for doing work on Gentoo at all |
90 |
(or rather, sanctioned to as part of our employment duties) we are |
91 |
fortunate, I believe it's usually an employer that has vested interest |
92 |
in Gentoo, and then we get paid to make that which our employers care |
93 |
about work (In my case I'm fortunate in that I have some leeway to be |
94 |
allowed to scratch a few extra itches here and there - but mostly |
95 |
because those itches affect me and my fellow employee's productivity to |
96 |
some extent or another). |
97 |
|
98 |
I trust (hope) that this will give you a small amount of insight into |
99 |
what you're asking. It's both a monumental technical challenge, as well |
100 |
as a time/effort one even when there aren't significant technical |
101 |
challenges. In short, the old adage about time and money wins out. If |
102 |
you want someone else to spend the time, pay them, else put in your own |
103 |
time. Every single person on this ML that I'm personally familiar with |
104 |
puts in their own time because they want to - because it scratches an |
105 |
itch they care about. |
106 |
|
107 |
Kind Regards, |
108 |
Jaco |
109 |
|
110 |
On 2020/12/31 13:46, Peter Stuge wrote: |
111 |
|
112 |
> Mike Gilbert wrote: |
113 |
>>> It is important to me that you can choose dev-libs/libretls instead of |
114 |
>>> having any libretls code on your systems, but I reject you forcing that |
115 |
>>> choice of yours on everyone else. |
116 |
>> I'm having trouble making sense of this sentence. Did you mean to |
117 |
>> write "libressl" instead of "libretls" somewhere? |
118 |
> Sorry, yes, that's right. "having any libressl code" is what I intended. |
119 |
> |
120 |
> |
121 |
>> Anyway, it seems like the people maintaining libressl in Gentoo are |
122 |
>> really not interested in keeping it going. |
123 |
> I don't know? There wasn't much discussion about my suggestion to keep |
124 |
> libressl code available in Gentoo in some ways causing no interference |
125 |
> with same SONAMEs openssl. |
126 |
> |
127 |
> So again what I'm advocating for is creative ways to at the very least |
128 |
> not have to remove it completely, which I think becomes easy, by |
129 |
> redefining what a libressl ebuild installs for now. At the moment I'm |
130 |
> thinking about these two: |
131 |
> |
132 |
> 1. no-brainer: libtls .so with libressl implementation |
133 |
> |
134 |
> 2. more novel: lib{crypto,ssl} static-libs in non-standard location |
135 |
> with libressl.pc in default search path |
136 |
> |
137 |
> |
138 |
>> A libtls wrapper around openssl seems much more manageable to me, |
139 |
>> and that should probably be the default option for people. |
140 |
> I disagree on both points. |
141 |
> |
142 |
> I'm still working on checking what 1. above requires. So far it looks like |
143 |
> the answer will be "nothing"; an ebuild wouldn't need any patch at all, |
144 |
> meaning zero overhead on bumps. |
145 |
> |
146 |
> And I for one certainly expect libressl libtls to be the default - that |
147 |
> is the canonical upstream. |
148 |
> |
149 |
> |
150 |
> Thanks |
151 |
> |
152 |
> //Peter |
153 |
> |