| 1 |
Andreas K. Huettel wrote: |
| 2 |
> > I agree completely that it's unreasonable for Gentoo (worse, 1 person!) |
| 3 |
> > to continuosly patch the entire world for libressel. |
| 4 |
> > |
| 5 |
> > I'm asking to stop doing that, yet still enable the choice between |
| 6 |
> > openssl and libressl where that is possible without patches, even |
| 7 |
> > if that's only openntpd and one other package. |
| 8 |
> |
| 9 |
> a) The two cannot be installed concurrently. To fix that would require even |
| 10 |
> more hacks. |
| 11 |
|
| 12 |
As we've discussed in another part of the thread, that's not really true. |
| 13 |
Both can for sure be installed, just not in the same place and/or |
| 14 |
with same names. |
| 15 |
|
| 16 |
|
| 17 |
> -> all relevant ssl consumers on the user's system must be linked against |
| 18 |
> the one selected |
| 19 |
|
| 20 |
Also not the case. Considering the two installed in different paths |
| 21 |
with same names it's still easy for consumers to use one or the other |
| 22 |
with -rpath at link time. |
| 23 |
|
| 24 |
|
| 25 |
I do agree that the two are not always 1:1 replacements for each other. |
| 26 |
If they are API incompatible somewhere then for sure not. |
| 27 |
|
| 28 |
I think many mails in this thread suffer from some tunnel vision, expecting |
| 29 |
that a libressl ebuild in the tree must continue to work exactly like the |
| 30 |
openssl ebuild - I'm saying to stop that but do keep a libressl ebuild. |
| 31 |
|
| 32 |
|
| 33 |
> b) The libraries are not guaranteed to be binary compatible, so switching |
| 34 |
> implementation requires rebuilding consumers. |
| 35 |
|
| 36 |
We can only consider ABI compatibility if we have API compatibility, |
| 37 |
which might not even be a given. |
| 38 |
|
| 39 |
|
| 40 |
> c) If a single package that the user wants to install is not "fixed" for |
| 41 |
> one ssl library, it blocks that option for all packages. |
| 42 |
|
| 43 |
Please think of a libressl ebuild in a new way. |
| 44 |
|
| 45 |
|
| 46 |
> I guess if you can come up with a solution that |
| 47 |
> * provides secure usage of the libraries, |
| 48 |
> * provides choice to the user, and |
| 49 |
> * doesn't lead to unupgradeable systems or unresolvable dependencies |
| 50 |
> we'd all be happier. So far we haven't found one. |
| 51 |
|
| 52 |
Right! I think letting a libressl ebuild install only libtls could be a |
| 53 |
good start, because it provides a stable situation, without risking |
| 54 |
conflicts. Would you agree? |
| 55 |
|
| 56 |
|
| 57 |
Thanks |
| 58 |
|
| 59 |
//Peter |
Archives