1 |
On Tue, 2020-12-29 at 22:41 +0000, Peter Stuge wrote: |
2 |
> Michał Górny wrote: |
3 |
> > > I would be happier if some other developers were able and willing |
4 |
> > > to |
5 |
> > > participate actively in the LibreSSL project. |
6 |
> > |
7 |
> > But why would they do that? What I'm really missing in all the |
8 |
> > replies |
9 |
> > is a single reason why LibreSSL would be better for anyone. |
10 |
> |
11 |
> Maybe because it is so well-known that monoculture is harmful per se, |
12 |
> which is why the commitment to choice in Gentoo is very valuable. |
13 |
|
14 |
How is that an argument for LibreSSL? If I create another fork of |
15 |
OpenSSL and replace LibreSSL with it, your argument still stands. |
16 |
|
17 |
> Further, LibreSSL comes out of the OpenBSD project, which has a good |
18 |
> reputation on code quality. |
19 |
|
20 |
I could buy that if it actually said anything about LibreSSL code |
21 |
quality. So far you're guessing that it might or might not, especially |
22 |
given it is forked from an apparently 'inferior quality' code. |
23 |
|
24 |
However, I do have serious doubts about LibreSSL quality given that: |
25 |
|
26 |
1. Non-OpenBSD systems are not first class citizens, as you yourself |
27 |
pointed out. |
28 |
|
29 |
2. The library is an intrusive replacement for OpenSSL. In the default |
30 |
setup, it is neither co-installable with OpenSSL, nor a drop-in |
31 |
replacement. |
32 |
|
33 |
3. The upstream declares OpenSSL version constants pretty randomly, |
34 |
without actually matching OpenSSL API. |
35 |
|
36 |
4. The upstream has actively tried to force people into using their |
37 |
product by tight coupling and forced incompatibility. |
38 |
|
39 |
5. Apparently nobody is issuing CVEs for LibreSSL while |
40 |
the vulnerabilities clearly do happen. |
41 |
|
42 |
> > a real proper, verifiable argument 'LibreSSL is better in this |
43 |
> > regard'. |
44 |
> |
45 |
> Choice is about enabling people to decide for themselves. |
46 |
|
47 |
Choice for the sake of choice is meaningless. I can create 10 OpenSSL |
48 |
forks right now and tell people to choose between them. However, it is |
49 |
meaningless unless users are actually provided good and useful |
50 |
information on what particular choices represent. |
51 |
|
52 |
So far nobody has been able to find a strong argument for choosing |
53 |
LibreSSL. There are strong arguments for using OpenSSL instead. |
54 |
So what do users exactly gain from this choice? The thrill |
55 |
of adventure? The ability to discover that they've made a bad choice |
56 |
eventually and revert to OpenSSL? |
57 |
|
58 |
Let's say you have food product A. Then a new alternative B appears. |
59 |
Surely, some people will try it. But if it turns out to be bad, it |
60 |
will eventually unprofitable and disappear. Sure, a few people will |
61 |
complain that B is no longer there because they liked it better. But |
62 |
they wouldn't pay extra (much extra) to keep it. |
63 |
|
64 |
OpenSSL/LibreSSL is the same. Maybe LibreSSL had promised a better |
65 |
taste in the beginning but today 9 out of 10 consumers say OpenSSL |
66 |
tastes much better. The only difference is that you don't have to pay |
67 |
for it (but we do!), so you think that it's free. |
68 |
|
69 |
|
70 |
-- |
71 |
Best regards, |
72 |
Michał Górny |