Gentoo Archives: gentoo-dev

From: Peter Stuge <peter@×××××.se>
To: gentoo-dev@l.g.o, libressl@g.o
Subject: Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
Date: Thu, 31 Dec 2020 16:53:46
Message-Id: 20201231165338.10012.qmail@stuge.se
In Reply to: Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support? by Jaco Kroon
1 Hi Jaco,
2
3 Jaco Kroon wrote:
4 > So a few points that I picked up during this discussion.
5 >
6 > 1.  Nobody is AGAINST libressl per sé,
7
8 Michał gives me a distinctly different impression.
9
10
11 > 2.  A number of people are AGAINTS the effort involved to make
12 > libressl work for various packages.
13
14 Yes, and I've written that I am as well.
15
16
17 > Without the latter, libressl is dead
18
19 On this I disagree.
20
21
22 > since it can't install concurrently with openssl.
23
24 Again, that need not be the case, and I'm looking into what's
25 possible with little to no effort:
26
27
28 Installing both openssl and libressl lib{crypto,ssl}.{a,so} in the same
29 directory is not possible since file names are the same.
30
31 Installing both openssl and libressl .so:s in different directories is
32 not extremely useful (but perhaps still worthwhile) since one dep for a
33 given package may pull in openssl and another dep may pull in libressl -
34 even if path stuff is resolved neatly this doesn't work at load time.
35 This is only useful for the case of packages explicity needing
36 libressl, e.g. because of (ab?)use of internals, which have no deps
37 which can not also use libressl without constant overhead in Gentoo.
38 Maybe openntpd actually falls in this category.
39
40 Installing both openssl and libressl .a files in different directories
41 seems both useful and straightforward. I don't object to openssl being
42 favored for /usr/lib here, libressl gets a directory of its own, but
43 libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically.
44 Obviously this will only be useful for packages wanting to statically link
45 with libressl lib{crypto,ssl} but I think that's far better than removing
46 libressl.
47
48 Installing libressl libtls.{a,so} (built using libressl lib{crypto,ssl}
49 code of course) in /usr/lib also seems both useful and straightforward.
50 I expect this to be the default provider for (a new) virtual/libtls.
51
52
53 The latter two cause no conflicts and have no running overhead cost.
54
55
56 > Again, this will mean for libraries that they will need to have
57 > multi-implementation installations again
58
59 This is interesting; I suppose that this is supported very well by Nyx,
60 and I think it would be a great addition to Gentoo, but in any case it
61 will not be trivial, and I wouldn't want to make it a requirement for
62 having /some/ libressl code on Gentoo systems.
63
64 Hence I propose to redefine the meaning of "support for LibreSSL" to
65 what works well without causing lots of overhead. Again: It's not
66 reasonable for Gentoo to patch the world, but we should model it as
67 accurately as possible.
68
69
70 > So how do you deal with package-b-libressl vs package-b-openssl in terms
71 > of dependencies?
72
73 I've mentioned a couple of ideas in this thread but they're all
74 non-trivial and I propose to not solve this problem for now and
75 settle for less than a full install until someone finds a good,
76 manageable solution.
77
78
79 > Lots of very finicky risks that needs to be eliminated wih installing
80 > both openssl and libressl concurrently.
81
82 So again, the point is to redefine what "libressl installed" means
83 such that the problems are avoided, accepting that libressl
84 lib{crypto,ssl}.so may not get installed, at least for now,
85 until there's a good solution - which is really orthogonal to
86 libressl. Quite probably the same solution could then apply to the
87 other packages in similar situations (ffmpeg/libav, imagemagic, etc.).
88
89
90 > Someone (Michał?) mentioned it's more pain than gain currently.  And
91 > unless someone is willing to change that, I seriously doubt anything
92 > you say is going to carry much weight.
93
94 I hope it's becoming clear that what I am saying is about /how/ to
95 change that, and that should carry weight. Consider it brainstorming
96 solutions if you will.
97
98
99 > having written my fair share of code -
100
101 Same.
102
103
104 > the level of ask that you're asking for is much, much larger than I
105 > think you realise.
106
107 I hope what I am asking for is becoming clear. I wrote fairly early
108 in the thread that it's something other than the status quo.
109
110
111 > mysql and mariadb started out very similar, and now there are two major
112 > projects, and parts of it are installable separately (client libs).
113
114 Off-topic, but I'm really happy about MariaDB! I remember helping with
115 a MariaDB developer meeting in the early days and I was very excited
116 that most long-time developers decided to join Monty on MariaDB. Ever
117 since, MySQL is irrelevant to me. But I do appreciate that people who
118 are stuck with some Oracle support contract can still use it in Gentoo.
119
120
121 > I trust (hope) that this will give you a small amount of insight into
122 > what you're asking.
123
124 I thought it was clear for a good number of mails that I'm /not/ asking
125 to continue ensuring that openssl and libressl are interchangeable in
126 Gentoo;
127
128 I'm asking to ensure that libressl stays available /in some capacity/ even
129 if that can only be as a special case, and it looks like that would
130 require only very little upfront effort and zero recurring effort.
131
132
133 Thanks a lot for your thoughtful response! I hope I could clarify some things.
134
135
136 Kind regards
137
138 //Peter

Replies

Subject Author
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support? Alessandro Barbieri <lssndrbarbieri@×××××.com>