-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI: Upgrade OpenSSL and LibreSSL versions. #636
Conversation
Yes. LibreSSL stable releases are supported for one year. After a year they are no longer maintained by us. The currently supported release branches are 3.6 and 3.7. End of october 2023, LibreSSL 3.8 will become stable and 3.6 will fall out of support.
(From the LibreSSL releases page) That said, it may make sense for you to keep some compat things for a few more releases, as users do sometimes use the LibreSSL versions that are bundled as components of macOS and Windows, although they are not really supposed to. The upstream vendors almost never communicate with us and it is unclear to what extent security and other fixes are backported. |
Thanks for the explanation. I understand it. I assume that as LibreSSL 3.6.0 was released on October 5th 2022 according to the release page, at end of October 2023, Libre 3.6 will fall out of support.
It seems that currently this project keeps the OpenSSL/LibreSSL versions after EOL statue as much. So, I would like to follow the policy. |
If x is a modular square root of a (mod p) then so is (p - x). Both answers are valid. In particular, both 2 and 3 are valid square roots of 4 (mod 5). Do not assume that a particular square root is chosen by the algorithm. Indeed, the algorithm in OpenSSL and LibreSSL <= 3.7 returns a non-deterministic answer in many cases. LibreSSL 3.8 and later will always return the smaller of the two possible answers. This breaks the current test case. Instead of checking for a particular square root, check that the square of the claimed square root is the given value. This is always true. Add the simplest test case where the answer is indeed non-deterministic.
d9639fe
to
93548ae
Compare
Maintainance branches must remain compatible with all OpenSSL/LibreSSL versions supported at the time the branch was cut. For master, I don't necessarily think we must maintain compatibility with LibreSSL versions that are already EOL, but they haven't been removed from CI because they did not create problems, either, in the last two years. However, now that we have 44 GitHub Actions workflow jobs, it might be about time to do a cleanup. The outdated LibreSSL version bundled with macOS particularly is not an issue for us because it (AFAIK) can't be used by third-party programs. |
PR #614 fixing the square root test was finally merged via ruby/openssl#636
This PR has 2 commits. The first commit is to upgrade OpenSSL and LibreSSL versions to the latest versions. And the second commit is the cherry-pick from #614 (thanks!). I am not sure that now is a good to upgrade the versions in the CI.
For the first commit, I have a question. How did you know the LibreSSL versions that are End of Life (EOL)? The latest release of the LibreSSL is for LibreSSL 3.8, 3.7 and 3.6. So, I assumed that Libre 3.5 is EOL now. Is that correct?
http://www.libressl.org/releases.html
I added the URLs to check the OpenSSL and LibreSSL to the comments in the CI YAML file to make this regular task to upgrade the versions easy.
https://www.openssl.org/source/
http://www.libressl.org/releases.html