-
Notifications
You must be signed in to change notification settings - Fork 38
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
SSL Certificate Bundles Aren't Found? #15
Comments
One potential approach is to patch OpenSSL to use paths relative to the binary it is loaded from and bundle some ca-bundle.crt inside tarball. I can imagine it will make people concerned about security cringe. But I cannot rely on system-wide locations if i want to be portable. |
Yeah -- you having to deal with it obviously isn't ideal, but not having access to the system bundle is fairly bad, no? I again know nothing here, but is there an option to just not statically link against OpenSSL? It seems possibly desirable for that on it's own too no? If there are OpenSSL vulnerabilities users will be in better shape to get the new patched version in place? |
This ain't my rodeo 🐮, but this seems like an OS-specific thing. For example on Debian and Ubuntu, certs are installed via the |
As a work-around, perhaps rely on the user to set |
OpenSSL is not statically linked in the tarball anymore, it is inside lib folder of the tarball as self-standing .so which is dynamically loaded. Sadly OpenSSL is one of the biggest offenders to portability and that's why it needs to be bundled. Each version regularly breaks versioning of symbols and ABI so all the dependant binaries needs to be recompiled. That's why many distributions choose to patch their shipped version of OpenSSL instead of upgrading to the latest one whenever there is new vulnerability discovered. I deliberately chose to bundle it because my main concern is out of the box experience. On the other side there are libraries like bzip2 which continue maintaing stable ABI for last 10 years and I dont need to bundle them. |
To answer it from under angle - having portable binaries is very very unnatural on Linux, the whole ecosystem of distributions is tightly coupled around certain versions and hard-coded paths. But sometimes what you want is Windows-like experience and it's hard. |
@Julian are you using "stock" system-wide certificate store or do you need it because you have some custom setup there? |
Stock yeah. Which is why to me, the current situation where stock system bundles aren't
|
I might try to apply a plan like this:
|
This blog post provides an overview of the issue and the paths used on many common systems: As a work around, I've been doing this: mkdir -p /opt/prefix/ssl
ln -nsf /etc/ssl/certs /opt/prefix/ssl/ And now portable-pypy will validate certificates correctly. |
HI @Julian. After more than one year I finally decided to look into it. I read PyPy's ssl module source and the CPython documentation on ssl module to be sure I understand well what's going on. I also got very useful information from the article that @pquerna linked. I came with a patch that tries looking at the locations that are mentioned in the article before falling back to bundled OpenSSL defaults (which obviously will never make sense). Finally if it doesnt find anything it will fall back to the latest ca bundle from The patch is quite simple:
It just tries two locations that happen to cover all the main distros (I tested it with Fedora, Centos, Debian, Ubuntu and OpenSUSE) and then fallbacks to bundled trust store from I built a version of Portable PyPy with this patch so you can try it in your setup. This tarball also contains a small script to test certificte verifiction
Grab the patched version here: https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-5.4-ssl-trust-linux_x86_64-portable.tar.bz2 and let me know what you think. Otherwise I am gonna merge this to next release version (which will be 5.4.1). |
So, PyPy 5.4.1 happened faster then I thought, I am merging this to master |
@squeaky-pl thanks a ton for getting to this -- I saw the message, but didn't read it carefully yet :) |
@squeaky-pl given that I know very very little about this stuff clearly, I went to ask some people that do. (Thanks @dstufft @tiran @Lukasa). I'm just quoting directly below, but the conclusion AIUI from Donald & Cory is "this list is probably too short, but regardless, other stuff has abandoned this approach because sometimes it turns out those files aren't certificate bundles".
|
Hi, thanks for the feedback. I looked at the conversation. This is the best effort I can do. It's still possible to override the paths with |
I think that sounds good to me, and obviously appreciated -- FWIW though, I don't think the point is that an attacker can write to those files. It's that in some places, those files just plain exist but are not certificate bundles, they're something else, and OpenSSL won't tell you that it failed at reading the file. |
Hmm I tested it with Fedora, Centos, Debian, Ubuntu and OpenSUSE. Will probably test more distros and add them to supported "auto-discovery" distros in README paragraph about ssl. I will also look into curl behavior for more paths and mention that you should use |
I included a paragraph in the README about OpenSSL:
|
This has been ported to py3.5 branch. Nobody complained so I am closing this for now. |
I know very little about the mechanisms here, so apologies if I've got this very wrong, but since portable PyPy vendors OpenSSL, and compiles it looking at
/opt/prefix
, it appears that at runtime no certificates are actually found from the system bundle, because that directory obviously will not exist on machines that use Portable PyPy.I.e.,
whereas the system certs are not there (this is CentOS 6, so they're in
/etc/ssl/certs/ca-bundle.crt
).Setting
SSL_CERT_FILE
appears to be one way to fix the issue, but what's the actual recommendation for that?The text was updated successfully, but these errors were encountered: