Bug 1094365
| Summary: | suspicious library linking of python-hashlib | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Ondrej Moriš <omoris> |
| Component: | beah | Assignee: | beaker-dev-list |
| Status: | CLOSED WONTFIX | QA Contact: | tools-bugs <tools-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 0.16 | CC: | aigao, asaha, bkabrda, bpeck, dcallagh, hkario, katzj, ksrot, mcsontos, omoris, rmancy |
| Target Milestone: | --- | Keywords: | TestBlocker |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-05-27 02:26:37 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux. There used to be MD5 checksum on files content sent from RHTS Harness to Server. This checksum was originally implemented by server but was later turned off to allow working in FIPS mode. The DIGEST option in beah_beaker.conf should be set to `no` (which is the default) and md5 should not be used at all. Is this just suspicious (CLOSE NOTABUG then please) or is there anything broken? // (In case of trouble) I suggest dropping the (now unused) hashes altogether. It is really broken. As mentioned, the problem is in importing hashlib by beah* - even though md5 might not be used at all, hashlib is imported anyway (see reproducer). Suspicious is that "requires" difference between x86_64 and the other architectures (which, btw, causes the problem). Doh, I see... It used to be md5 module which was an issue and hashlib was considered safe. Likely a mistake in a build script. This could work: http://gerrit.beaker-project.org/#/c/3079/ Marian, thanks for the patch. It looks like it is a solution for bug 707623 (getting rid of hashlib entirely). Ray made an attempt at that a few years back but got stuck and then it dropped off our radar. We would want to remove the Requires: python-hashlib as well. Then we could drop python-hashlib from the harness repos and this bug would no longer be an issue. I am going to verify that the patch doesn't break anything (see: https://bugzilla.redhat.com/show_bug.cgi?id=707623#c15) Closing this as WONTFIX because we won't fix the issues with the custom python-hashlib package. Instead, beah will no longer require python-hashlib at all (bug 707623). |
Description of problem: Package pythons-hashlib links different libraries on different architectures, on x86_64 it looks as follows: # rpm -q --requires python-hashliblibc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libpthread.so.0()(64bit) python(abi) = 2.4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) on the other hand on i386: ]# rpm -q --requires python-hashliblibc.so.6 libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.4) libcrypto.so.6 libpthread.so.0 libssl.so.6 python(abi) = 2.4 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) The similar result can be seen on ppc64, ia64 and s390x. The important different is that on non-x86_64_64 architectures the following is linked: libcrypto.so.6 libssl.so.6 These are openssl libraries. Unfortunately this implies that on x86_64 (only) python-hashlib is not using openssl crypto library and on the other architectures is is. Normally one might not notice it but in FIPS mode some of openssl algoritms are forbidden (md5 in particular) and in practice it is not even possible to import hashlib on a non x86_64 architecture (on x86_64 it works fine since non-openssl crypto code does not care about FIPS mode): i386 ==== # python -c 'import hashlib' Traceback (most recent call last): File "<string>", line 1, in ? File "/usr/lib/python2.4/site-packages/hashlib.py", line 136, in ? md5 = __get_builtin_constructor('md5') File "/usr/lib/python2.4/site-packages/hashlib.py", line 63, in __get_builtin_constructor import _md5 ImportError: No module named _md5 # uname -a Linux pes-guest-72.lab.eng.brq.redhat.com 2.6.18-371.el5 #1 SMP Thu Sep 5 21:20:46 EDT 2013 i686 i686 i386 GNU/Linux x86_64 ====== # python -c 'import hashlib' # uname -a Linux hp-dl380pgen8-02-vm-12.lab.bos.redhat.com 2.6.18-371.el5 #1 SMP Thu Sep 5 21:21:44 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux Version-Release number of selected component (if applicable): python-hashlib-20081119-4.el5 How reproducible: 100% on i386, ppc64 and s390x, 0% on x86_64 Steps to Reproduce: 1. python -c 'import hashlib' Actual results: Traceback (most recent call last): File "<string>", line 1, in ? File "/usr/lib/python2.4/site-packages/hashlib.py", line 136, in ? md5 = __get_builtin_constructor('md5') File "/usr/lib/python2.4/site-packages/hashlib.py", line 63, in __get_builtin_constructor import _md5 ImportError: No module named _md5 Expected results: No traceback. Additional info: This issue is blocking all FIPS testing on i386, ppc64 and s390x because beah used by beaker is importing hashlib in /usr/bin/beah-beaker-backend which leads to traceback during its start on these architectures and all jobs are then aborted because beah-beaker-backend is not running. I am opening this bug for python component since there is no python-hashlib component in bugzilla (why???).