| 2024-03-15 09:21:41 |
Adrien Nader |
bug |
|
|
added bug |
| 2024-03-15 10:28:26 |
Adrien Nader |
summary |
openssl is not LTO-safe |
[FFe] openssl is not LTO-safe |
|
| 2024-03-15 10:36:00 |
Adrien Nader |
description |
tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves.
We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. |
tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves.
We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only.
I will add results of "openssl speed" soon (in a few hours). |
|
| 2024-03-15 10:41:12 |
Adrien Nader |
summary |
[FFe] openssl is not LTO-safe |
openssl is not LTO-safe |
|
| 2024-03-15 11:02:19 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+merge/462486 |
|
| 2024-03-15 11:19:41 |
Adrien Nader |
openssl (Ubuntu): milestone |
|
ubuntu-24.04 |
|
| 2024-03-15 11:19:45 |
Adrien Nader |
openssl (Ubuntu): assignee |
|
Adrien Nader (adrien-n) |
|
| 2024-03-15 11:19:49 |
Adrien Nader |
openssl (Ubuntu): status |
New |
In Progress |
|
| 2024-03-17 20:58:55 |
Adrien Nader |
description |
tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves.
We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only.
I will add results of "openssl speed" soon (in a few hours). |
tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves.
We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only.
I ran "openssl speed" with a long benchmark time in order to get good results (there is a variation of several percents with the default times). I then scripted a diff which output is shown below (hopefully it will display fine...); entries within 2% are not displayed. Also note that some important ciphers are not present due to how openssl speed works; small aes-*-cbc are negatively impacted, up to -10% but that would -50% if you compared between "software" and "hardware" implementations, the results would be reversed at anything but the smallest data sizes, and the fact that you want to use hardware implementations as much as possible means that you also want to avoid places where LTO could have an effect.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
md5
sha1
rmd160
sha256 +2.3%
sha512
hmac(md5)
des-ede3
aes-128-cbc -10.0%
aes-192-cbc -7.6%
aes-256-cbc -5.2%
camellia-128-cbc
camellia-192-cbc
camellia-256-cbc
ghash +21.2% -27.3% +30.5% +39.3%
rand -2.8% -2.9% -2.9% -2.8%
sign verify sign/s verify/s
rsa 512 bits 0.000031s 0.000002s -2.7%
rsa 1024 bits 0.000005s
rsa 2048 bits +2.4% 0.000015s -2.3%
rsa 3072 bits 0.000032s
rsa 4096 bits
rsa 7680 bits 30.2
rsa 15360 bits 5.9
sign verify sign/s verify/s
dsa 512 bits +4.8% 0.000024s -3.9%
dsa 1024 bits +2.5% -3.3% +2.4%
dsa 2048 bits +2.0%
sign verify sign/s verify/s
160 bits ecdsa (secp160r1) +100.0% +100.0% -2.2%
192 bits ecdsa (nistp192) 0.0002s 0.0002s -3.6% -3.3%
224 bits ecdsa (nistp224) 0.0000s 0.0001s
256 bits ecdsa (nistp256) 0.0000s 0.0001s
384 bits ecdsa (nistp384) +14.3% 0.0006s -3.2%
521 bits ecdsa (nistp521) 0.0002s 0.0005s
163 bits ecdsa (nistk163) 0.0002s 0.0003s -3.2% -3.0%
233 bits ecdsa (nistk233) 0.0002s +25.0% -2.2%
283 bits ecdsa (nistk283) 0.0004s 0.0008s -3.5%
409 bits ecdsa (nistk409) 0.0007s 0.0013s -2.1% -2.0%
571 bits ecdsa (nistk571) 0.0015s 0.0029s
163 bits ecdsa (nistb163) 0.0002s 0.0003s
233 bits ecdsa (nistb233) 0.0002s 0.0005s
283 bits ecdsa (nistb283) 0.0004s 0.0008s -2.4% -2.7%
409 bits ecdsa (nistb409) 0.0007s +7.7% -2.5% -3.5%
571 bits ecdsa (nistb571) 0.0016s 0.0031s
256 bits ecdsa (brainpoolP256r1) 0.0003s 0.0003s -2.5%
256 bits ecdsa (brainpoolP256t1) 0.0003s 0.0003s -2.9% -3.2%
384 bits ecdsa (brainpoolP384r1) +14.3% 0.0007s -2.9%
384 bits ecdsa (brainpoolP384t1) +14.3% 0.0006s -2.9% -2.0%
512 bits ecdsa (brainpoolP512r1) 0.0011s 0.0009s -2.8% -3.1%
512 bits ecdsa (brainpoolP512t1) +10.0% +12.5% -3.4% -4.5%
op op/s
160 bits ecdh (secp160r1) 0.0001s -5.8%
192 bits ecdh (nistp192) 0.0002s -7.4%
224 bits ecdh (nistp224) 0.0001s
256 bits ecdh (nistp256) 0.0000s
384 bits ecdh (nistp384) 0.0007s -4.0%
521 bits ecdh (nistp521) 0.0003s -4.1%
163 bits ecdh (nistk163) 0.0002s -4.6%
233 bits ecdh (nistk233) 0.0002s -4.7%
283 bits ecdh (nistk283) 0.0004s -2.9%
409 bits ecdh (nistk409) 0.0006s -3.6%
571 bits ecdh (nistk571) 0.0014s
163 bits ecdh (nistb163) 0.0002s
233 bits ecdh (nistb233) 0.0002s
283 bits ecdh (nistb283) 0.0004s -2.5%
409 bits ecdh (nistb409) +16.7% -3.2%
571 bits ecdh (nistb571) 0.0015s
256 bits ecdh (brainpoolP256r1) 0.0003s -3.9%
256 bits ecdh (brainpoolP256t1) 0.0003s -4.9%
384 bits ecdh (brainpoolP384r1) 0.0007s -3.7%
384 bits ecdh (brainpoolP384t1) 0.0007s -3.9%
512 bits ecdh (brainpoolP512r1) 0.0010s
512 bits ecdh (brainpoolP512t1) 0.0010s -2.1%
253 bits ecdh (X25519) 0.0000s
448 bits ecdh (X448) 0.0002s
sign verify sign/s verify/s
253 bits EdDSA (Ed25519) 0.0000s 0.0001s
456 bits EdDSA (Ed448) 0.0002s 0.0002s
sign verify sign/s verify/s
256 bits SM2 (CurveSM2) 0.0003s 0.0003s -2.9% -3.2%
op op/s
2048 bits ffdh 0.0002s
3072 bits ffdh 0.0006s -2.4%
4096 bits ffdh 0.0013s
6144 bits ffdh 0.0029s
8192 bits ffdh |
|
| 2024-03-17 21:00:58 |
Adrien Nader |
description |
tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves.
We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only.
I ran "openssl speed" with a long benchmark time in order to get good results (there is a variation of several percents with the default times). I then scripted a diff which output is shown below (hopefully it will display fine...); entries within 2% are not displayed. Also note that some important ciphers are not present due to how openssl speed works; small aes-*-cbc are negatively impacted, up to -10% but that would -50% if you compared between "software" and "hardware" implementations, the results would be reversed at anything but the smallest data sizes, and the fact that you want to use hardware implementations as much as possible means that you also want to avoid places where LTO could have an effect.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
md5
sha1
rmd160
sha256 +2.3%
sha512
hmac(md5)
des-ede3
aes-128-cbc -10.0%
aes-192-cbc -7.6%
aes-256-cbc -5.2%
camellia-128-cbc
camellia-192-cbc
camellia-256-cbc
ghash +21.2% -27.3% +30.5% +39.3%
rand -2.8% -2.9% -2.9% -2.8%
sign verify sign/s verify/s
rsa 512 bits 0.000031s 0.000002s -2.7%
rsa 1024 bits 0.000005s
rsa 2048 bits +2.4% 0.000015s -2.3%
rsa 3072 bits 0.000032s
rsa 4096 bits
rsa 7680 bits 30.2
rsa 15360 bits 5.9
sign verify sign/s verify/s
dsa 512 bits +4.8% 0.000024s -3.9%
dsa 1024 bits +2.5% -3.3% +2.4%
dsa 2048 bits +2.0%
sign verify sign/s verify/s
160 bits ecdsa (secp160r1) +100.0% +100.0% -2.2%
192 bits ecdsa (nistp192) 0.0002s 0.0002s -3.6% -3.3%
224 bits ecdsa (nistp224) 0.0000s 0.0001s
256 bits ecdsa (nistp256) 0.0000s 0.0001s
384 bits ecdsa (nistp384) +14.3% 0.0006s -3.2%
521 bits ecdsa (nistp521) 0.0002s 0.0005s
163 bits ecdsa (nistk163) 0.0002s 0.0003s -3.2% -3.0%
233 bits ecdsa (nistk233) 0.0002s +25.0% -2.2%
283 bits ecdsa (nistk283) 0.0004s 0.0008s -3.5%
409 bits ecdsa (nistk409) 0.0007s 0.0013s -2.1% -2.0%
571 bits ecdsa (nistk571) 0.0015s 0.0029s
163 bits ecdsa (nistb163) 0.0002s 0.0003s
233 bits ecdsa (nistb233) 0.0002s 0.0005s
283 bits ecdsa (nistb283) 0.0004s 0.0008s -2.4% -2.7%
409 bits ecdsa (nistb409) 0.0007s +7.7% -2.5% -3.5%
571 bits ecdsa (nistb571) 0.0016s 0.0031s
256 bits ecdsa (brainpoolP256r1) 0.0003s 0.0003s -2.5%
256 bits ecdsa (brainpoolP256t1) 0.0003s 0.0003s -2.9% -3.2%
384 bits ecdsa (brainpoolP384r1) +14.3% 0.0007s -2.9%
384 bits ecdsa (brainpoolP384t1) +14.3% 0.0006s -2.9% -2.0%
512 bits ecdsa (brainpoolP512r1) 0.0011s 0.0009s -2.8% -3.1%
512 bits ecdsa (brainpoolP512t1) +10.0% +12.5% -3.4% -4.5%
op op/s
160 bits ecdh (secp160r1) 0.0001s -5.8%
192 bits ecdh (nistp192) 0.0002s -7.4%
224 bits ecdh (nistp224) 0.0001s
256 bits ecdh (nistp256) 0.0000s
384 bits ecdh (nistp384) 0.0007s -4.0%
521 bits ecdh (nistp521) 0.0003s -4.1%
163 bits ecdh (nistk163) 0.0002s -4.6%
233 bits ecdh (nistk233) 0.0002s -4.7%
283 bits ecdh (nistk283) 0.0004s -2.9%
409 bits ecdh (nistk409) 0.0006s -3.6%
571 bits ecdh (nistk571) 0.0014s
163 bits ecdh (nistb163) 0.0002s
233 bits ecdh (nistb233) 0.0002s
283 bits ecdh (nistb283) 0.0004s -2.5%
409 bits ecdh (nistb409) +16.7% -3.2%
571 bits ecdh (nistb571) 0.0015s
256 bits ecdh (brainpoolP256r1) 0.0003s -3.9%
256 bits ecdh (brainpoolP256t1) 0.0003s -4.9%
384 bits ecdh (brainpoolP384r1) 0.0007s -3.7%
384 bits ecdh (brainpoolP384t1) 0.0007s -3.9%
512 bits ecdh (brainpoolP512r1) 0.0010s
512 bits ecdh (brainpoolP512t1) 0.0010s -2.1%
253 bits ecdh (X25519) 0.0000s
448 bits ecdh (X448) 0.0002s
sign verify sign/s verify/s
253 bits EdDSA (Ed25519) 0.0000s 0.0001s
456 bits EdDSA (Ed448) 0.0002s 0.0002s
sign verify sign/s verify/s
256 bits SM2 (CurveSM2) 0.0003s 0.0003s -2.9% -3.2%
op op/s
2048 bits ffdh 0.0002s
3072 bits ffdh 0.0006s -2.4%
4096 bits ffdh 0.0013s
6144 bits ffdh 0.0029s
8192 bits ffdh |
tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves.
We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only.
I ran "openssl speed" with a long benchmark time in order to get good results (there is a variation of several percents with the default times). I then scripted a diff which output is shown below (hopefully it will display fine...); entries within 2% are not displayed. Also note that some important ciphers are not present due to how openssl speed works; small aes-*-cbc are negatively impacted, up to -10% but that would -50% if you compared between "software" and "hardware" implementations, the results would be reversed at anything but the smallest data sizes, and the fact that you want to use hardware implementations as much as possible means that you also want to avoid places where LTO could have an effect.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
md5 ..... ..... ..... ..... ..... .....
sha1 ..... ..... ..... ..... ..... .....
rmd160 ..... ..... ..... ..... ..... .....
sha256 +2.3% ..... ..... ..... ..... .....
sha512 ..... ..... ..... ..... ..... .....
hmac(md5) ..... ..... ..... ..... ..... .....
des-ede3 ..... ..... ..... ..... ..... .....
aes-128-cbc -10.0% ..... ..... ..... ..... .....
aes-192-cbc -7.6% ..... ..... ..... ..... .....
aes-256-cbc -5.2% ..... ..... ..... ..... .....
camellia-128-cbc ..... ..... ..... ..... ..... .....
camellia-192-cbc ..... ..... ..... ..... ..... .....
camellia-256-cbc ..... ..... ..... ..... ..... .....
ghash ..... ..... +21.2% -27.3% +30.5% +39.3%
rand -2.8% -2.9% -2.9% -2.8% ..... .....
sign verify sign/s verify/s
rsa 512 bits 0.000031s 0.000002s -2.7% .....
rsa 1024 bits ..... 0.000005s ..... .....
rsa 2048 bits +2.4% 0.000015s -2.3% .....
rsa 3072 bits ..... 0.000032s ..... .....
rsa 4096 bits ..... ..... ..... .....
rsa 7680 bits ..... ..... 30.2 .....
rsa 15360 bits ..... ..... 5.9 .....
sign verify sign/s verify/s
dsa 512 bits +4.8% 0.000024s -3.9% .....
dsa 1024 bits +2.5% -3.3% ..... +2.4%
dsa 2048 bits ..... ..... ..... +2.0%
sign verify sign/s verify/s
160 bits ecdsa (secp160r1) +100.0% +100.0% ..... -2.2%
192 bits ecdsa (nistp192) 0.0002s 0.0002s -3.6% -3.3%
224 bits ecdsa (nistp224) 0.0000s 0.0001s ..... .....
256 bits ecdsa (nistp256) 0.0000s 0.0001s ..... .....
384 bits ecdsa (nistp384) +14.3% 0.0006s -3.2% .....
521 bits ecdsa (nistp521) 0.0002s 0.0005s ..... .....
163 bits ecdsa (nistk163) 0.0002s 0.0003s -3.2% -3.0%
233 bits ecdsa (nistk233) 0.0002s +25.0% ..... -2.2%
283 bits ecdsa (nistk283) 0.0004s 0.0008s ..... -3.5%
409 bits ecdsa (nistk409) 0.0007s 0.0013s -2.1% -2.0%
571 bits ecdsa (nistk571) 0.0015s 0.0029s ..... .....
163 bits ecdsa (nistb163) 0.0002s 0.0003s ..... .....
233 bits ecdsa (nistb233) 0.0002s 0.0005s ..... .....
283 bits ecdsa (nistb283) 0.0004s 0.0008s -2.4% -2.7%
409 bits ecdsa (nistb409) 0.0007s +7.7% -2.5% -3.5%
571 bits ecdsa (nistb571) 0.0016s 0.0031s ..... .....
256 bits ecdsa (brainpoolP256r1) 0.0003s 0.0003s -2.5% .....
256 bits ecdsa (brainpoolP256t1) 0.0003s 0.0003s -2.9% -3.2%
384 bits ecdsa (brainpoolP384r1) +14.3% 0.0007s -2.9% .....
384 bits ecdsa (brainpoolP384t1) +14.3% 0.0006s -2.9% -2.0%
512 bits ecdsa (brainpoolP512r1) 0.0011s 0.0009s -2.8% -3.1%
512 bits ecdsa (brainpoolP512t1) +10.0% +12.5% -3.4% -4.5%
op op/s
160 bits ecdh (secp160r1) 0.0001s -5.8%
192 bits ecdh (nistp192) 0.0002s -7.4%
224 bits ecdh (nistp224) 0.0001s .....
256 bits ecdh (nistp256) 0.0000s .....
384 bits ecdh (nistp384) 0.0007s -4.0%
521 bits ecdh (nistp521) 0.0003s -4.1%
163 bits ecdh (nistk163) 0.0002s -4.6%
233 bits ecdh (nistk233) 0.0002s -4.7%
283 bits ecdh (nistk283) 0.0004s -2.9%
409 bits ecdh (nistk409) 0.0006s -3.6%
571 bits ecdh (nistk571) 0.0014s .....
163 bits ecdh (nistb163) 0.0002s .....
233 bits ecdh (nistb233) 0.0002s .....
283 bits ecdh (nistb283) 0.0004s -2.5%
409 bits ecdh (nistb409) +16.7% -3.2%
571 bits ecdh (nistb571) 0.0015s .....
256 bits ecdh (brainpoolP256r1) 0.0003s -3.9%
256 bits ecdh (brainpoolP256t1) 0.0003s -4.9%
384 bits ecdh (brainpoolP384r1) 0.0007s -3.7%
384 bits ecdh (brainpoolP384t1) 0.0007s -3.9%
512 bits ecdh (brainpoolP512r1) 0.0010s .....
512 bits ecdh (brainpoolP512t1) 0.0010s -2.1%
253 bits ecdh (X25519) 0.0000s .....
448 bits ecdh (X448) 0.0002s .....
sign verify sign/s verify/s
253 bits EdDSA (Ed25519) 0.0000s 0.0001s ..... .....
456 bits EdDSA (Ed448) 0.0002s 0.0002s ..... .....
sign verify sign/s verify/s
256 bits SM2 (CurveSM2) 0.0003s 0.0003s -2.9% -3.2%
op op/s
2048 bits ffdh 0.0002s .....
3072 bits ffdh 0.0006s -2.4%
4096 bits ffdh 0.0013s .....
6144 bits ffdh 0.0029s .....
8192 bits ffdh ..... .....
PS: I used a ZSH script for that (because bash cannot do floating point arithmetic operations) which is below, using two files "speed-lto" and "speed-no-lto":
a=speed-lto; b=speed-no-lto; l=$(wc -l speed-lto | cut -f1 -d' '); exec 3<$a; exec 4<$b; for i in $(seq 1 $l); do read -A -u 3 c; read -A -u 4 d; for j in $(seq 1 ${#c}); do x="${c[$j]}"; y="${d[$j]}"; if [[ "$x" == "$y" ]]; then printf '%s ' "$x"; else xm=$(echo "$x" | tr -dc '0-9'); ym=$(echo "$y" | tr -dc '0-9'); p=$(((100. * (ym - xm)) / xm)); if (( p > 2 || p < -2)); then printf '%+0.1f%% ' "$p"; else printf '..... '; fi; fi; done; printf '\n'; done | column -t; exec 3>&-; exec 4>&- |
|
| 2024-03-17 21:32:33 |
Adrien Nader |
description |
tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves.
We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only.
I ran "openssl speed" with a long benchmark time in order to get good results (there is a variation of several percents with the default times). I then scripted a diff which output is shown below (hopefully it will display fine...); entries within 2% are not displayed. Also note that some important ciphers are not present due to how openssl speed works; small aes-*-cbc are negatively impacted, up to -10% but that would -50% if you compared between "software" and "hardware" implementations, the results would be reversed at anything but the smallest data sizes, and the fact that you want to use hardware implementations as much as possible means that you also want to avoid places where LTO could have an effect.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
md5 ..... ..... ..... ..... ..... .....
sha1 ..... ..... ..... ..... ..... .....
rmd160 ..... ..... ..... ..... ..... .....
sha256 +2.3% ..... ..... ..... ..... .....
sha512 ..... ..... ..... ..... ..... .....
hmac(md5) ..... ..... ..... ..... ..... .....
des-ede3 ..... ..... ..... ..... ..... .....
aes-128-cbc -10.0% ..... ..... ..... ..... .....
aes-192-cbc -7.6% ..... ..... ..... ..... .....
aes-256-cbc -5.2% ..... ..... ..... ..... .....
camellia-128-cbc ..... ..... ..... ..... ..... .....
camellia-192-cbc ..... ..... ..... ..... ..... .....
camellia-256-cbc ..... ..... ..... ..... ..... .....
ghash ..... ..... +21.2% -27.3% +30.5% +39.3%
rand -2.8% -2.9% -2.9% -2.8% ..... .....
sign verify sign/s verify/s
rsa 512 bits 0.000031s 0.000002s -2.7% .....
rsa 1024 bits ..... 0.000005s ..... .....
rsa 2048 bits +2.4% 0.000015s -2.3% .....
rsa 3072 bits ..... 0.000032s ..... .....
rsa 4096 bits ..... ..... ..... .....
rsa 7680 bits ..... ..... 30.2 .....
rsa 15360 bits ..... ..... 5.9 .....
sign verify sign/s verify/s
dsa 512 bits +4.8% 0.000024s -3.9% .....
dsa 1024 bits +2.5% -3.3% ..... +2.4%
dsa 2048 bits ..... ..... ..... +2.0%
sign verify sign/s verify/s
160 bits ecdsa (secp160r1) +100.0% +100.0% ..... -2.2%
192 bits ecdsa (nistp192) 0.0002s 0.0002s -3.6% -3.3%
224 bits ecdsa (nistp224) 0.0000s 0.0001s ..... .....
256 bits ecdsa (nistp256) 0.0000s 0.0001s ..... .....
384 bits ecdsa (nistp384) +14.3% 0.0006s -3.2% .....
521 bits ecdsa (nistp521) 0.0002s 0.0005s ..... .....
163 bits ecdsa (nistk163) 0.0002s 0.0003s -3.2% -3.0%
233 bits ecdsa (nistk233) 0.0002s +25.0% ..... -2.2%
283 bits ecdsa (nistk283) 0.0004s 0.0008s ..... -3.5%
409 bits ecdsa (nistk409) 0.0007s 0.0013s -2.1% -2.0%
571 bits ecdsa (nistk571) 0.0015s 0.0029s ..... .....
163 bits ecdsa (nistb163) 0.0002s 0.0003s ..... .....
233 bits ecdsa (nistb233) 0.0002s 0.0005s ..... .....
283 bits ecdsa (nistb283) 0.0004s 0.0008s -2.4% -2.7%
409 bits ecdsa (nistb409) 0.0007s +7.7% -2.5% -3.5%
571 bits ecdsa (nistb571) 0.0016s 0.0031s ..... .....
256 bits ecdsa (brainpoolP256r1) 0.0003s 0.0003s -2.5% .....
256 bits ecdsa (brainpoolP256t1) 0.0003s 0.0003s -2.9% -3.2%
384 bits ecdsa (brainpoolP384r1) +14.3% 0.0007s -2.9% .....
384 bits ecdsa (brainpoolP384t1) +14.3% 0.0006s -2.9% -2.0%
512 bits ecdsa (brainpoolP512r1) 0.0011s 0.0009s -2.8% -3.1%
512 bits ecdsa (brainpoolP512t1) +10.0% +12.5% -3.4% -4.5%
op op/s
160 bits ecdh (secp160r1) 0.0001s -5.8%
192 bits ecdh (nistp192) 0.0002s -7.4%
224 bits ecdh (nistp224) 0.0001s .....
256 bits ecdh (nistp256) 0.0000s .....
384 bits ecdh (nistp384) 0.0007s -4.0%
521 bits ecdh (nistp521) 0.0003s -4.1%
163 bits ecdh (nistk163) 0.0002s -4.6%
233 bits ecdh (nistk233) 0.0002s -4.7%
283 bits ecdh (nistk283) 0.0004s -2.9%
409 bits ecdh (nistk409) 0.0006s -3.6%
571 bits ecdh (nistk571) 0.0014s .....
163 bits ecdh (nistb163) 0.0002s .....
233 bits ecdh (nistb233) 0.0002s .....
283 bits ecdh (nistb283) 0.0004s -2.5%
409 bits ecdh (nistb409) +16.7% -3.2%
571 bits ecdh (nistb571) 0.0015s .....
256 bits ecdh (brainpoolP256r1) 0.0003s -3.9%
256 bits ecdh (brainpoolP256t1) 0.0003s -4.9%
384 bits ecdh (brainpoolP384r1) 0.0007s -3.7%
384 bits ecdh (brainpoolP384t1) 0.0007s -3.9%
512 bits ecdh (brainpoolP512r1) 0.0010s .....
512 bits ecdh (brainpoolP512t1) 0.0010s -2.1%
253 bits ecdh (X25519) 0.0000s .....
448 bits ecdh (X448) 0.0002s .....
sign verify sign/s verify/s
253 bits EdDSA (Ed25519) 0.0000s 0.0001s ..... .....
456 bits EdDSA (Ed448) 0.0002s 0.0002s ..... .....
sign verify sign/s verify/s
256 bits SM2 (CurveSM2) 0.0003s 0.0003s -2.9% -3.2%
op op/s
2048 bits ffdh 0.0002s .....
3072 bits ffdh 0.0006s -2.4%
4096 bits ffdh 0.0013s .....
6144 bits ffdh 0.0029s .....
8192 bits ffdh ..... .....
PS: I used a ZSH script for that (because bash cannot do floating point arithmetic operations) which is below, using two files "speed-lto" and "speed-no-lto":
a=speed-lto; b=speed-no-lto; l=$(wc -l speed-lto | cut -f1 -d' '); exec 3<$a; exec 4<$b; for i in $(seq 1 $l); do read -A -u 3 c; read -A -u 4 d; for j in $(seq 1 ${#c}); do x="${c[$j]}"; y="${d[$j]}"; if [[ "$x" == "$y" ]]; then printf '%s ' "$x"; else xm=$(echo "$x" | tr -dc '0-9'); ym=$(echo "$y" | tr -dc '0-9'); p=$(((100. * (ym - xm)) / xm)); if (( p > 2 || p < -2)); then printf '%+0.1f%% ' "$p"; else printf '..... '; fi; fi; done; printf '\n'; done | column -t; exec 3>&-; exec 4>&- |
tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves.
We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues.
Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
Gentoo also prevents usage of -fstrict-aliasing and always set -fno-strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes.
Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues.
Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only.
I ran "openssl speed" with a long benchmark time in order to get good results (there is a variation of several percents with the default times). I then scripted a diff which output is shown below; "....." means the difference is within 2% which is the vast majority. Also note that some important ciphers are not present due to how openssl speed works; small aes-*-cbc are negatively impacted, up to -10% but that would -50% if you compared between "software" and "hardware" implementations, the results would be reversed at anything but the smallest data sizes, and the fact that you want to use hardware implementations as much as possible means that you also want to avoid places where LTO could have an effect.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
md5 ..... ..... ..... ..... ..... .....
sha1 ..... ..... ..... ..... ..... .....
rmd160 ..... ..... ..... ..... ..... .....
sha256 +2.3% ..... ..... ..... ..... .....
sha512 ..... ..... ..... ..... ..... .....
hmac(md5) ..... ..... ..... ..... ..... .....
des-ede3 ..... ..... ..... ..... ..... .....
aes-128-cbc -10.0% ..... ..... ..... ..... .....
aes-192-cbc -7.6% ..... ..... ..... ..... .....
aes-256-cbc -5.2% ..... ..... ..... ..... .....
camellia-128-cbc ..... ..... ..... ..... ..... .....
camellia-192-cbc ..... ..... ..... ..... ..... .....
camellia-256-cbc ..... ..... ..... ..... ..... .....
ghash ..... ..... +21.2% -27.3% +30.5% +39.3%
rand -2.8% -2.9% -2.9% -2.8% ..... .....
sign verify sign/s verify/s
rsa 512 bits 0.000031s 0.000002s -2.7% .....
rsa 1024 bits ..... 0.000005s ..... .....
rsa 2048 bits +2.4% 0.000015s -2.3% .....
rsa 3072 bits ..... 0.000032s ..... .....
rsa 4096 bits ..... ..... ..... .....
rsa 7680 bits ..... ..... 30.2 .....
rsa 15360 bits ..... ..... 5.9 .....
sign verify sign/s verify/s
dsa 512 bits +4.8% 0.000024s -3.9% .....
dsa 1024 bits +2.5% -3.3% ..... +2.4%
dsa 2048 bits ..... ..... ..... +2.0%
sign verify sign/s verify/s
160 bits ecdsa (secp160r1) +100.0% +100.0% ..... -2.2%
192 bits ecdsa (nistp192) 0.0002s 0.0002s -3.6% -3.3%
224 bits ecdsa (nistp224) 0.0000s 0.0001s ..... .....
256 bits ecdsa (nistp256) 0.0000s 0.0001s ..... .....
384 bits ecdsa (nistp384) +14.3% 0.0006s -3.2% .....
521 bits ecdsa (nistp521) 0.0002s 0.0005s ..... .....
163 bits ecdsa (nistk163) 0.0002s 0.0003s -3.2% -3.0%
233 bits ecdsa (nistk233) 0.0002s +25.0% ..... -2.2%
283 bits ecdsa (nistk283) 0.0004s 0.0008s ..... -3.5%
409 bits ecdsa (nistk409) 0.0007s 0.0013s -2.1% -2.0%
571 bits ecdsa (nistk571) 0.0015s 0.0029s ..... .....
163 bits ecdsa (nistb163) 0.0002s 0.0003s ..... .....
233 bits ecdsa (nistb233) 0.0002s 0.0005s ..... .....
283 bits ecdsa (nistb283) 0.0004s 0.0008s -2.4% -2.7%
409 bits ecdsa (nistb409) 0.0007s +7.7% -2.5% -3.5%
571 bits ecdsa (nistb571) 0.0016s 0.0031s ..... .....
256 bits ecdsa (brainpoolP256r1) 0.0003s 0.0003s -2.5% .....
256 bits ecdsa (brainpoolP256t1) 0.0003s 0.0003s -2.9% -3.2%
384 bits ecdsa (brainpoolP384r1) +14.3% 0.0007s -2.9% .....
384 bits ecdsa (brainpoolP384t1) +14.3% 0.0006s -2.9% -2.0%
512 bits ecdsa (brainpoolP512r1) 0.0011s 0.0009s -2.8% -3.1%
512 bits ecdsa (brainpoolP512t1) +10.0% +12.5% -3.4% -4.5%
op op/s
160 bits ecdh (secp160r1) 0.0001s -5.8%
192 bits ecdh (nistp192) 0.0002s -7.4%
224 bits ecdh (nistp224) 0.0001s .....
256 bits ecdh (nistp256) 0.0000s .....
384 bits ecdh (nistp384) 0.0007s -4.0%
521 bits ecdh (nistp521) 0.0003s -4.1%
163 bits ecdh (nistk163) 0.0002s -4.6%
233 bits ecdh (nistk233) 0.0002s -4.7%
283 bits ecdh (nistk283) 0.0004s -2.9%
409 bits ecdh (nistk409) 0.0006s -3.6%
571 bits ecdh (nistk571) 0.0014s .....
163 bits ecdh (nistb163) 0.0002s .....
233 bits ecdh (nistb233) 0.0002s .....
283 bits ecdh (nistb283) 0.0004s -2.5%
409 bits ecdh (nistb409) +16.7% -3.2%
571 bits ecdh (nistb571) 0.0015s .....
256 bits ecdh (brainpoolP256r1) 0.0003s -3.9%
256 bits ecdh (brainpoolP256t1) 0.0003s -4.9%
384 bits ecdh (brainpoolP384r1) 0.0007s -3.7%
384 bits ecdh (brainpoolP384t1) 0.0007s -3.9%
512 bits ecdh (brainpoolP512r1) 0.0010s .....
512 bits ecdh (brainpoolP512t1) 0.0010s -2.1%
253 bits ecdh (X25519) 0.0000s .....
448 bits ecdh (X448) 0.0002s .....
sign verify sign/s verify/s
253 bits EdDSA (Ed25519) 0.0000s 0.0001s ..... .....
456 bits EdDSA (Ed448) 0.0002s 0.0002s ..... .....
sign verify sign/s verify/s
256 bits SM2 (CurveSM2) 0.0003s 0.0003s -2.9% -3.2%
op op/s
2048 bits ffdh 0.0002s .....
3072 bits ffdh 0.0006s -2.4%
4096 bits ffdh 0.0013s .....
6144 bits ffdh 0.0029s .....
8192 bits ffdh ..... .....
PS: I used a ZSH script for that (because bash cannot do floating point arithmetic operations) which is below, using two files "speed-lto" and "speed-no-lto":
a=speed-lto; b=speed-no-lto; l=$(wc -l speed-lto | cut -f1 -d' '); exec 3<$a; exec 4<$b; for i in $(seq 1 $l); do read -A -u 3 c; read -A -u 4 d; for j in $(seq 1 ${#c}); do x="${c[$j]}"; y="${d[$j]}"; if [[ "$x" == "$y" ]]; then printf '%s ' "$x"; else xm=$(echo "$x" | tr -dc '0-9'); ym=$(echo "$y" | tr -dc '0-9'); p=$(((100. * (ym - xm)) / xm)); if (( p > 2 || p < -2)); then printf '%+0.1f%% ' "$p"; else printf '..... '; fi; fi; done; printf '\n'; done | column -t; exec 3>&-; exec 4>&- |
|
| 2024-03-18 10:08:58 |
Adrien Nader |
openssl (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2024-03-28 07:48:29 |
Launchpad Janitor |
openssl (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2024-05-29 06:40:28 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~adrien/ubuntu/+source/openssl/+git/openssl/+merge/466556 |
|
| 2024-05-29 09:25:14 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~adrien/ubuntu/+source/openssl/+git/openssl/+merge/466581 |
|
| 2024-05-29 09:28:37 |
Adrien Nader |
openssl (Ubuntu): importance |
Undecided |
High |
|
| 2024-07-01 15:18:02 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~adrien/ubuntu/+source/openssl/+git/openssl/+merge/468513 |
|
| 2024-07-05 08:01:51 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~adrien/ubuntu/+source/openssl/+git/openssl/+merge/468828 |
|
