net-libs/libsrtp: Bump to 1.5.4 and 2.0.0

[lluixhi]

Add LibreSSL Support
Switch to EAPI 6
Cleanup of src_prepare

Gentoo-Bug: 596398

Question:
What should I do with openssl-kdf? It requires OpenSSL-1.1.0 and doesn't work with LibreSSL

[lluixhi]

This'll necessitate changing some slots on packages.
As far as I can tell, qtwebengine needs libsrtp:0= while the newer versions of chromium (55+?) need libsrtp:2=

I'm not sure about anything else.

[SoapGentoo]

call default first thing in src_prepare

[lluixhi]

Alright.

[SoapGentoo]

don't need this

[SoapGentoo]

get rid of this. USE="libressl" = "use libressl, if and only if, building with SSL support"

[lluixhi]

This ebuild depends on libcrypto -- which is provided by both OpenSSL and LibreSSL -- what would an alternative be?

I don't think we should restrict the benefits of using Open/LibreSSL crypto functions to only OpenSSL users.

[SoapGentoo]

if the ebuild unconditionally needs openssl, drop the openssl flag. I have yet to see an ebuild that requires REQUIRED_USE="libressl? ( openssl )", because the libressl and openssl USE flags are orthogonal to each other. USE="libressl" does NOT imply "build with libressl unconditionally", rather it means, if you are building with SSL, then use libressl.

[lluixhi]

media-video/ffmpeg has a similar problem to what I'm trying to avoid in this ebuild. It should actually have a REQUIRED_USE="libressl? ( openssl )", because if you don't enable both, the libressl USE flag does nothing.

This ebuild does not unconditionally depend on OpenSSL, it has an optional dependency on OpenSSL to accelerate their crypto functions.

Alternatively, I can modify the line $(use_enable openssl) to pass '--enable-openssl' to configure regardless of whether we are using OpenSSL or LibreSSL.

I think I'll do that.

[SoapGentoo]

same thing here

[lluixhi]

Re openssl-kdf:
We can depend on Openssl-1.1.0+ after upstream's next release.
It doesn't work yet:
cisco/libsrtp@0b45423

[gktrk]

@gentoochainsaw

[lluixhi]

Okay this still seems wrong.
@blueness do you have any advice?

[SoapGentoo]

@lluixhi I will repeat it one last time. USE="libressl" does NOT mean "use libressl". What USE="libressl" means, is "use libressl, if and only if, building against an openssl backend". If you do not follow this line of reasoning, see the project page https://wiki.gentoo.org/wiki/Project:LibreSSL which just reiterates all of this. The correct solution is:

openssl? (
    !libressl? ( dev-libs/openssl:0= )
    libressl? ( dev-libs/libressl:0= )
)

i.e. USE="openssl libressl" -> libressl, USE="openssl -libressl" -> openssl, USE="-openssl" -> no SSL. If you won't change it to this, I will close the PR for not being in line with the libressl project guidelines.

[lluixhi]

@SoapGentoo
That page only shows the

ssl? (
    !libressl? ( dev-libs/openssl:0= )
    libressl? ( dev-libs/libressl:0= )
)

construct

Anyway, my understanding from that page and what @hasufell said in the past was that if a user had USE="libressl ssl" set globally, it should enable working libressl support on all packages that support an openssl-like backend without also including USE="openssl".

From the page:
"For most packages, migration is as simple as just replacing the openssl atom with a choice between openssl and libressl"
"Eventually the process should be as easy as just adding USE=libressl to your make.conf file and then doing an emerge -uvNDq world"

It is unclear to me that USE="openssl libressl" is necessary to use an openssl-like backend with libressl, but I'm changing it to what you have.

[SoapGentoo]

while this is formally correct, could you still swap RDEPEND and DEPEND? It's nicer reading deps with := in RDEPEND, as subslot operators have no effect in DEPEND.

[lluixhi]

As of 5842294
we do have a precedent for putting crypto implementations into REQUIRED_USE

[SoapGentoo]

@lluixhi thanks for pointing out, that || ( gcrypt libressl nettle openssl ) is wrong. The openssl USE flag doesn't actually control anything. Stay with how I said it and how the LibreSSL Project page documents it.