| 1 |
Michał Górny wrote: |
| 2 |
> 1. Stuff that does not build against LibreSSL. |
| 3 |
> 2. Stuff that builds just fine but fails at runtime in unpredictable |
| 4 |
> ways (e.g. Tor mentioned today). |
| 5 |
> 3. Stuff that builds and works 'fine' but ends up being crippled (e.g. |
| 6 |
> doesn't support new algorithms). |
| 7 |
> |
| 8 |
> The first one is somewhat easy to test (e.g. via tinderbox). The other |
| 9 |
> two are very hard. |
| 10 |
|
| 11 |
Nod. |
| 12 |
|
| 13 |
|
| 14 |
> > > Actually, I see that someone has apparently forked libtls into |
| 15 |
> > > libretls (the irony!) that works against OpenSSL [1]. |
| 16 |
> > |
| 17 |
> > To me, that proves value in the libtls API and in keeping libressl in |
| 18 |
> > the tree in some capacity, even if not as an alternative to openssl. |
| 19 |
> > |
| 20 |
> > Maybe with a USE flag which makes it install only libtls (built from |
| 21 |
> > libressl static libs), which could be one provider for a |
| 22 |
> > virtual/libtls. |
| 23 |
> |
| 24 |
> I don't see why we would put an effort into that. |
| 25 |
|
| 26 |
In my very next sentence (not quoted in your reply) I wrote explicitly |
| 27 |
that I do /not/ ask anyone to do so, but ask that you don't hinder it |
| 28 |
by masking libressl and also don't remove existing work potentially |
| 29 |
supporting such efforts, ie. the libressl ebuild. |
| 30 |
|
| 31 |
|
| 32 |
> I've just packaged dev-libs/libretls |
| 33 |
|
| 34 |
Thanks! That seems useful. |
| 35 |
|
| 36 |
|
| 37 |
> Trying to get the same result from libressl is just repeating the work. |
| 38 |
|
| 39 |
Maybe for you, and I'm saying that you should be able to make that choice |
| 40 |
for your systems, but also that you should not hinder others from making |
| 41 |
another choice, where that's possible and as I wrote without needing |
| 42 |
Gentoo to patch the world. |
| 43 |
|
| 44 |
|
| 45 |
Thanks a lot |
| 46 |
|
| 47 |
//Peter |
Archives