-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Switch from MbedTLS to OpenSSL #56708
base: master
Are you sure you want to change the base?
Conversation
Based on @fxcoudert's openssl branch and pull request at JuliaLang#53891. - diff re-applied to current Julia master (hence the new commit) - LibCURL, LibGit2, LibSSH2, OpenSSL updated to newest version - MbedTSL removed
Current to-do list:
|
If you mean with libcurl v8.10+ JuliaLang/Downloads.jl#260, JuliaLang/Downloads.jl#260 (comment) should fix it. But there are still other failures: JuliaLang/Downloads.jl#261 |
This PR requires the two other PRs Currently these other PRs are hardcoded in |
@giordano There is a likely-spurious test failure. Can you restart |
deps/checksums/SuiteSparse-e8285dd13a6d5b5cf52d8124793fc4d622d07554.tar.gz/md5
Outdated
Show resolved
Hide resolved
Ok, now we're back to the point where Julia's own CI passes, but trying to load
This is where we were stuck with #53891. |
Should PyCall/PythonCall do something like py"""
import ssl
def create_julia_https_context():
return ssl.create_default_context(cafile=$(NetworkOptions.bundled_ca_roots()))
ssl._create_default_https_context = create_julia_https_context
""" as suggested by @mkitti at #53891 (comment)? That does seem to work for me:
CC @cjdoris @stevengj we really need your input here, otherwise this PR will be stuck again for ages and we don't move on. |
Maybe asking for forgiveness is better than asking for permission here. As I understand it, this is quite important from a security standpoint so it if the ecosystem has to catch up for a while then so be it? |
Are PyCall/PythonCall the only places in the ecosystem that this PR breaks? Could we run a PkgEval on this PR, to see if any other parts of the ecosystem are broken by this PR? |
This is the summary of last time I looked at PkgEval: #53891 (comment) |
stdlib/Pkg.version
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder that before merging this PR the PRs to Pkg and NetworkOptions must be merged, and these files changed back to point to the original repo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests on Pkg doesn't pass until this is merged so it is a bit tricky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any tests that are run only on CI there, or we're good to have all tests passing on this PR (they were passing until yesterday or so)? We can do a coordinated merge of the three PRs, to reduce disruption.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is fine to merge here and then when master updates rerun CI on Pkg and merge it there (and then update the commit again). The activity in the Pkg repo is not super high nowadays.
The alternative is to write the tests so that they pass both here and on master but that might be a bit more effort than it is worth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem of merging this PR first is that it'd make its merge commit not buildable from source if Erik's branch or fork are deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And thus can possibly break git bisect in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can merge it on Pkg with tests breaking if the manifest is the only test that matters. Or both manifests are checked in and the relevant one is renamed based on the version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And thus can possibly break git bisect in the future?
Yeah, whenever someone needs to build a specific commit, git bisect is indeed my main concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know when is a good time to do so. (After doing so, many things will fail on this branch before these repos are updated. We should do so only shortly before merging.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For these files to be updated the respective changes to NetworkOptions and Pkg need to be merged first.
Can we package mbedTLS as an independent package for other packages which may still have a hard dependency on it? |
Separate from the existing mbedtls_jll and MbedTLS.jl packages that already exist? |
@nanosoldier runtests() |
I think the backticks are mandatory. |
@nanosoldier |
The package evaluation job you requested has completed - possible new issues were detected. |
Some interesting failures: EasyCurl, JLLPrefixes. |
How do we proceed here? |
pressing the merge button? :) |
If you are worried about merging three PRs simultaneously: With semver, the technically correct path would be to declare compatibilities via version numbers (i.e. bumping the major version number of |
How do we make MbedTLS_jll available? |
@mkitti This PR removes Julia's build-from-source mechanism can operate in two ways, either building all stdlibs from source, or (and that's the default) downloading jlls from the package registry. This is how I don't know whether I'm answering your question or saying something trivial. |
What's the fix for SciMLTutorials? Could we out together that PR first? |
The Pkg bump should at least be rebased on current Pkg master. |
The fix for SciMLTutorials is to update all the |
@KristofferC I updated the Pkg.jl PR. |
I went through all the new 35 failures reported by PkgEval:
If we're happy to let downstream developers fix the issues in their packages, e.g. for PyCall/PythonCall (the three BinaryBuilder-related ones are fine to ignore, issues should definitely be fixed in the package), then this is good to go from my point of view, as long as we decide what to do with the versions of the external stdlibs that need to be updated (I vote to merge the PRs to the external repos all together and then merge this PR, too, tests here are passing for julia + stdlibs) |
I merged in the master branch to resolve conflicts. |
Based on @fxcoudert's openssl branch and pull request at #53891.