gcrypt vs. openssl

[NightMonkey]

Howdy. There are a lot of packages which make use of these flags, many of which are installed on my system. Apparently, there is a new app-admin/sudo released which requires an either/or choice between these two flags. What is the Gentoo community consensus on which one is generally appropriate? Thanks in advance.

Code: Select all

!!! The ebuild selected to satisfy "app-admin/sudo" has unmet requirements.
- app-admin/sudo-1.8.20_p1::gentoo USE="gcrypt ldap nls offensive openssl pam se
ndmail (-selinux) -skey" ABI_X86="64"

  The following REQUIRED_USE flag constraints are unsatisfied:
    at-most-one-of ( gcrypt openssl )

  The above constraints are a subset of the following complete expression:
    pam? ( !skey ) skey? ( !pam ) at-most-one-of ( gcrypt openssl )

(dependency required by "net-print/fax4cups-1.29-r1::gentoo" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

[Sadako]

From /usr/portage/profiles/use.local.desc;

Code: Select all

app-admin/sudo:gcrypt - Use SHA2 from dev-libs/libgcrypt instead of sudo's internal SHA2.
app-admin/sudo:openssl - Use SHA2 from dev-libs/openssl instead of sudo's internal SHA2.

These were only added as options in 1.8.20, you can probably disable both with no ill effects, the "best" choice would prob be the fastest if you feel like running some benchmarks ( ), but if it`s just for simple password hashing then real-world differences between the three would likely be negligable.

I'd go with gcrypt as potentially the most "secure" of the three, but I don't have much to base that on.

[NightMonkey]

Sadly... when I flip off openssl:

Code: Select all

!!! Problem resolving dependencies for dev-db/mariadb from @selected
... done!

!!! The ebuild selected to satisfy "dev-db/mariadb" has unmet requirements.
- dev-db/mariadb-10.0.30::gentoo USE="odbc pam server systemtap xml -bindist -debug -embedded -extraengine -jdbc -jemalloc -latin1 (-libressl) -openssl -oqgraph -perl -profiling (-selinux) -sphinx -static -static-libs -tcmalloc -test -tokudb -yassl" ABI_X86="32 64 -x32"

  The following REQUIRED_USE flag constraints are unsatisfied:
    exactly-one-of ( yassl openssl libressl )

  The above constraints are a subset of the following complete expression:
    server? ( tokudb? ( jemalloc ) ) static? ( !pam ) jdbc? ( extraengine server !static ) exactly-one-of ( yassl openssl libressl ) !server? ( !extraengine !embedded ) at-most-one-of ( tcmalloc jemalloc ) static? ( !libressl !openssl yassl )

(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

I think this is gonna get ugly. :/

[Sadako]

Uhm, did you disable the openssl USE flag globally?

Yeah, don't do that.

You'll get a ton of conflicts just like that if you do, and what I said about disabling those flags having no ill effects was about sudo specifically, other packages would lose some real and potentially important functionality without ssl.

[NightMonkey]

Uhm, did you disable the openssl USE flag globally?

Yeah, don't do that.

You'll get a ton of conflicts just like that if you do, and what I said about disabling those flags having no ill effects was about sudo specifically, other packages would lose some real and potentially important functionality without ssl.

I just really hate to make more swiss cheese out of Portage with global USE flag exceptions for base packages. And I likely make my system more brittle that way.

Am I the only one to see this problem atm? :/

[pigeon768]

Disabling the openssl USE flag globally is a really really really bad idea. I guarantee you that you're making your system more brittle by disabling it globally.

You should leave both openssl and gcrypt out of your USE= line in /etc/portage/make.conf. It's fine to leave them at their default values. sudo uses neither gcrypt nor openssl by default, and that's fine.

Usually when a package requires exactly-one-of or at-most-one-of a given list of packages, the package maintainer's recommendation will be selected by default, allowing you to override the default if you wish. It's generally advisable to have as few global flags set in make.conf as possible.

[toralf]

Disabling the openssl USE flag globally is a really really really bad idea.

Nope - as long as you have libressl in place - it works fine - at least at a server.
At a desktop there are however more packages which don't compile with libressl.

[Leio]

Disabling USE=ssl globally sounds like a bad idea. Enabling openssl globally might be a bad idea too - it's not even a global USE flag, so doesn't have a concrete meaning across the board.
Though generally it's used to select what library to use for hash functions or such. Also the case with sudo - if neither is given, an internal implementation of SHA2 is used, if gcrypt is given, then the one in libgcrypt is used, if USE=openssl is given, then from openssl. libressl support there is currently missing.
Usually libressl is chosen by USE=libressl and openssl by the lack of that; for real SSL purposes anyway, as opposed to just hash functions.
The benefit of having one of them on sudo is to not use the internal SHA2 code that might not be so security audited as those in openssl or libgcrypt, I suppose.

Because I don't like at-most-one-of and exactly-one-of things there that give such deptree errors when more things are there, I had already filed [bug=620362]bug 620362[/bug] earlier to consider changing that. But as neither is global flags, I won't be disappointed if the maintainers deem it fine as-is.