The server I’m using has out of date ca-certificates so I’m unable to use https to download julia packages - is there a way of changing the install process so I can use ssh to download packages off github?
You can use a url
rule in your ~/.gitconfig
file to tell git to substitute one URL pattern for another:
[url "git@github.com:"]
insteadOf = https://github.com/
but I’m not entirely sure whether this will work in Julia’s built in LibGit2. Does that work for you?
Thanks for the suggestion but I’m afraid it doesn’t.
The issue lies with the login node I’m using having outdated ca-certificates and the support team can’t be bothered to sort out the dependency issues to update them.
I’m going to try seeing if I can clone my entire julia repository and running updates via my personal laptop. This is a little bit of a silly workaround - apparently only for outdated hardware.
Would it be good to have the package manager provide a way to use plain http than https at the discretion of the user?
You should be able to download an up-to-date certificates file and pass it to libgit2 when starting Julia via SSL_CERT_FILE=/path/to/file.pem julia
. You can download certificates from curl - Extract CA Certs from Mozilla. There’s also the SSL_CERT_DIR
variable, and by default Julia will look for this file at abspath(joinpath(Base.JULIA_HOME,Base.DATAROOTDIR,"julia","cert.pem"))
.
Julia 0.7 ships certificates files since this PR, though there’s been some discussion about the fact that it should be the OS’s job.
Downloading packages over http means that anyone (e.g. a malicious ISP or wireless device) could inspect and alter the contents of your packages as you download them. This situation is even worse than normal web traffic over http because your Julia code is executed directly by the system instead of living in your browser’s sandbox.
Of course, Julia is probably not (yet) a popular target of attack, but this still seems like an unnecessary potential security hole.
Thanks for the comments all - I think the solution from nalimilan would have been the right one although the system I was working on was too old to work properly anyway. I’ve avoided the problem though being given access to a more up to date section of my unis supercomputer.