Description of problem: m2crypto loading x509 cert causes Segmentation fault for python26 but not for python form RHEL. Version-Release number of selected component (if applicable): I am comparing these versions. python26-m2crypto-0.21.1-3.el5 m2crypto-0.16-7.el5 How reproducible: Every time Steps to Reproduce: 0. Install both version's of m2crypto for RHEL5. # yum install python26-m2crypto m2crypto 1. Make python script #cat fred.py from M2Crypto import SMIME, X509, BIO st = X509.X509_Store() st.load_info('/etc/grid-security/certificates/bffbd7d0.0') print st 2. Run with "python" # python fred.py <M2Crypto.X509.X509_Store instance at 0xca3878> 3. Run with python2.6 # python2.6 fred.py Segmentation fault For me a 0.18 or higher version of M2Crypto in RHEL would also be fine I don't need python26, unfortunately the RHEL 5 version is m2crypto-0.16-6.el5.6 which does not support verifying X509 SMIME signed messages, here is some of my code, that I cant get to run on RHEL version of m2crypto. def validate_text(self,text_to_verify): buf = BIO.MemoryBuffer(text_to_verify) sk = X509.X509_Stack() p7, data = SMIME.smime_load_pkcs7_bio(buf) try: supplied_stack = p7.get0_signers(sk) except AttributeError, e: if str(e) == "PKCS7 instance has no attribute 'get0_signers'": self.logger.error('m2crypto version 0.18 is the minimum supported, please upgrade.') raise e I mark this as urgent, as although only in EPEL their is no way to make your code verify X509 signed SMIME messages in python without using the openssl library via the command line. (I know it all works fine in RHEL6 and its a known limitation with m2crypto 0.16 and 0.17, just google "get0_signers") Thank you for taking the time to look into this bug, I hope you get time to add the issue to your test suites. Regards Owen
Relevant part of disassembly: > 0x00002aaaaf27b7f2 <_wrap_x509_store_load_locations+130>: mov 0x20(%rsp),%rbx > 0x00002aaaaf27b7f7 <_wrap_x509_store_load_locations+135>: callq 0x2aaaaf279970 <SWIG_AsCharPtrAndSize> * arg1 == argp1 is loaded into %rbx at ...b7f2. * ...b7f7 calls SWIG_AsCharPtrAndSize * SWIG_AsCharPtrAndSize stores %rbx on the stack, and eventually calls > char *cstr; int len; > PyString_AsStringAndSize(obj, &cstr, &len); * However, the second patameter of PyString_AsStringAndSize is actually a pointer to Py_ssize_t (64bit instead of 32-bit) * Thus, the %rbx value saved on stack is overwritten by zeroes * ... and eventually X509_STORE_load_locations is called with the first parameter equal to NULL So, this all seems to be caused by the fact that the swig in RHEL does not support Python 2.6.
As for the missing get0_signers in m2crypto-0.16-7.el5, if you are a Red Hat customer with an active subscription, please report this via the Red Hat Customer Portal at http://access.redhat.com/ to allow correct prioritization of this issue.
This is a swig issue that happens when building against Python >= 2.5 on 64-bit systems. Upstream fixed this bug in its svn repo ages ago with a very small change to the code, so bug 707778 attempts to get that fix backported to RHEL 5's swig package. If that happens then this bug can be fixed with a recompile. Otherwise I can look into monkey-patching _m2crypto_wrapper.c, though that is less than ideal. For posterity's sake, here is a minimal reproducer: > yum install python26-m2crypto > python2.6 << EOF > from M2Crypto import X509 > store = X509.X509Store() > store.load_info('/etc/pki/tls/certs/ca-bundle.crt') > EOF
Dear all, Thankyou for the work on this area. Miloslav Trma\u010d, Sorry I am not a redhat customer, I am a Scientfic Linux user. Regards Owen
Possible alternate approach (though v. ugly): hack up the build of python26-m2crypto to apply the patch seen in bug 707778 to the code that SWIG generates (IIRC, the files that that patch touches are templates used by the code generator. I could be misremembering).
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora or Fedora EPEL, please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.