Re: [RFC] Switching back to OpenSSL

[fosslinux <fosslinux@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]

New comment by fosslinux on void-packages repository

https://github.com/void-linux/void-packages/issues/20935#issuecomment-618245112

Comment:
I agree with @the-maldridge, after some hard thinking and a discussion on IRC.

I'm not really concerned about OpenSSL in the repositories.

However, LibreSSL should be of first-class support, and OpenSSL should only be used where necessary for maintainability (eg, qt5). IMO, OpenSSL shouldn't be in the base system - xbps should stay with LibreSSL; no real reason to move it off it.

Saying all this, it is essential that the maintainers come to a decision how OpenSSL should be used **before it is merged**, and what will happen to LibreSSL (once again, I will strongly advocate for LibreSSL not being removed - rather still being first-class).

I see a number of options, ranked from most LibreSSL to most OpenSSL.

_No OpenSSL_
1. Do not merge OpenSSL.
_User choice, first-class support for LibreSSL; OpenSSL not well supported_
2. Merge OpenSSL, but do not have any packages depend upon it. Have it as a choice. Maintain full compatibility with LibreSSL, but don't require current packages to support OpenSSL. Do not include OpenSSL in the base system (default LibreSSL).
_User choice, first-class support for both_
3. Merge OpenSSL, but do not have any packages depend upon it. Have it as a choice. Maintain full compatibility with LibreSSL; quickly ensure all current packages to support OpenSSL. Do not include OpenSSL in the base system (default LibreSSL).
_Maintainer choice, but LibreSSL for base system_
4. Merge OpenSSL. Allow packages to depend upon it, and optionally drop LibreSSL specific patches. Packages will pull in either of OpenSSL or LibreSSL as required. Both could be installed on the same system. However, base packages should only include LibreSSL. Do not include OpenSSL in the base system.
_Maintainer choice, including base system - both in base system_
5. Merge OpenSSL. Allow packages to depend upon it, and optionally drop LibreSSL specific patches. Packages, including base packages, are allowed to pull in either of OpenSSL or LibreSSL as required. Both could be installed on the same system - and both will be installed as part of the base system.
_Maintainer choice, but OpenSSL for base system_
6. Merge OpenSSL. Convert all base system packages to use OpenSSL only (including xbps).  Allow packages to depend upon it, and optionally drop LibreSSL specific patches. Base system should only use OpenSSL. Both could be installed on the same system, but only OpenSSL will be in the base system. Maintainers can still choose to use LibreSSL, and most software can continue to do so (ex. base system).
_User choice, first-class support for OpenSSL; LibreSSL not well supported_
7. Merge OpenSSL. Convert all base system packages to use OpenSSL only (including xbps). All packages must work with OpenSSL - make this a priority - but not all have to work with LibreSSL. Include OpenSSL in the base system, and make it the default. Maintainers must use OpenSSL.
_OpenSSL only; no LibreSSL_
8. Merge OpenSSL. Convert all packages to use OpenSSL only. All packages must work with OpenSSL. Roadmap for LibreSSL to be removed from the repositories.

6 is likely to end up at 7 eventually.

I, personally, would hate 7 or 8. My opinion is 4. 3 and 5 would create too much maintainer work, 6 would lead to an extreme drop of support of LibreSSL in general, and  would eventually lead to 7. 1, 2 and 3 I would also be happy with (but 3 would create poor maintaership).

I would strongly recommend against 2 and 7 because all it's going to add is complex, dodgy code, broken software, and worse packaging.