security/openssl: Enable ASM by default - Enable ASM option - By extension this enables AES-NI  - Order OPTIONS_DEFAULT alphabetically - Switch to using @sample  PR: 216559  Reported by: dtestke  Submitted by: Franco Fichtner <email@example.com> 
Are the new *.so files 100% compatible with the old ones if one enables ASM ? Or does this need a shlib version bump ?
This feels like a bad idea.
The ASM defines mask the C-routines and enable the optimized assembly replacements.
There's a bit more to it I've learned. Various commits referring to ASM:
- rP422700 add option ASM for OPNsense
- rP421025 remove options ASM and GMP (PR210859)
- (Upgrade to 1.1.0 and then downgrade to 1.0.2)
- rP408778 mark options ASM broken on sparc64 (PR204527)
- rP383877 disable option ASM by default (PR198788??)
Unfortunately the commit messages aren't very informative... It seems to me that people hitting bugs had not rebuilt their ports correctly or were mixing base and ports SSL libs (via sasl, krb, curl, ...)
- Base OpenSSL has ASM enabled by default
- There are no reports on broken ports with base OpenSSL pertaining to ASM
- There are reports that ASM does work (e.g. PR19788 #49)
- ASM is enabled by default upstream
- Insecure options are enabled by default in port but not upstream
I propose the following:
- Enable ASM by default as soon as possible
And as a separate action/commit
- Announce upcoming change on ML
- Bump .so version
- Disable MD2 and SSLv2
- Add entry to UPDATING
|asm||on||forced off||Performance impacted|
|ec_nistp||off||forced on||configure can't detect|
|ssl3||forced on||presumed on by default|
|static-engine||on||off||automatic by "shared" option|
Well, of course if there is an existing one it will not be replaced, it is what @sample does. My question was "does openssl behaves the same way if the provided openssl.cnf is here or not ?"
Not in all circumstances, it sets defaults for files, directories, and DN. The openssl command works without an openssl.cnf but will emit a warning it is missing.
I believe the default @sample behaviour is what's required here.
Bumping the .so revision puts a big onus on some vendors to recompile their software for almost zero reason.
The ASM enabled .so is absolutely compatible with the ASM disabled .so -- there should be no need to bump the .so revision.
Most notably, people like nginx whom provide a paid-for product called "nginx-plus" available as binary-package only from their own public pkg server will have to recompile their binaries and issue a new package to the world if you bump the .so revision.
As long as features are DISABLED and not removed (e.g. at $JOB we need MD2) then ok.
I think we should make two versions of this port: openssl and openssl-insecure, which has features like sslv2 and MD2 enabled for people who need that functionality. (e.g. for talking to old machines or handling old certificates etc.)
maybe with a different .so number. (just an idea).