Created attachment 568808 [details] allow cross-compilation of fips_standalone_sha1 while preserving target hmac signatures Description of problem: When cross-compiling openssl for different (understand incompatible with the "build") arch, the source rpm has the following section in %check: %define __spec_install_post \ %{?__debug_package:%{__debug_install_post}} \ %{__arch_install_post} \ %{__os_install_post} \ crypto/fips/fips_standalone_sha1 $RPM_BUILD_ROOT/%{_lib}/libcrypto.so.%{version} >$RPM_BUILD_ROOT/%{_lib}/.libcrypto.so.%{version}.hmac \ ln -sf .libcrypto.so.%{version}.hmac $RPM_BUILD_ROOT/%{_lib}/.libcrypto.so.%{soversion}.hmac \ crypto/fips/fips_standalone_sha1 $RPM_BUILD_ROOT%{_libdir}/libssl.so.%{version} >$RPM_BUILD_ROOT%{_libdir}/.libssl.so.%{version}.hmac \ ln -sf .libssl.so.%{version}.hmac $RPM_BUILD_ROOT%{_libdir}/.libssl.so.%{soversion}.hmac \ %{nil} This calculates the appropriate hmac values for the fips files, BUT it won't work in cross-compilation mode, particularly if the "build" and "host" arches are incompatible (say, build=x86_64, host=arm), OR, if the Lib C version used on the "build" is different from the one on "host" (say glibc on the "build" and uclibc on the "host"). Version-Release number of selected component (if applicable): 1.0.0g, FC17 How reproducible: Always, provided cross-compilation is used (i.e. --cross-compile-prefix is passed on to ./Configure) Steps to Reproduce: 1. unpack the source rpm 2. initiate cross-compilation (e.g. rpmbuild --target=armv7 openssl.spec) 3. Actual results: Compilation may pass, but at the end rpmbuild will exit with an error, either stating that crypto/fips/fips_standalone_sha1 cannot be executed (due to incompatible "build" and "host" arches) or will show a similar error that Lib C link-loader for the "host" arch cannot be found. Expected results: rpmbuild to succeed Additional info: The problem won't be easily solved by just using the compiler to compile/build crypto/fips/fips_standalone_sha1 for the "build" arch instead of the "host", because I am not sure the hmac signatures will match! The problem has already been discussed here - http://rt.openssl.org/Ticket/Display.html?id=1822&user=guest&pass=guest, though it is not clear whether the solution has been applied upstream. I am attaching a patch with one *VERY UGLY* hack: it forces static build of crypto/fips/fips_standalone_sha1, thus at least eliminating the dependency on the target Lib C library used (this gets included in the binary itself). This does *NOT* eliminate the problem of differing (i.e. incompatible) "build" and "host" arches though! I have eliminated that problem for myself by using qemu and applying some binfmt magic so that my environment (mock chroot) can execute "host" binaries on the "build" (in other words, execute arm-based binaries on my x86_64 environment). That way openssl compilation succeeds, but this is not a solution which should be offered to the "general public"!
Using the build arch compiler instead of the cross-compiler would work as the tool and the HMAC-SHA256 algorithm is invariant on the host architecture. However you would have to build also the relevant part of openssl library (namely the SHA and HMAC algorithms) with the build arch compiler. Alternatively the fipshmac tool from the fipscheck library could be required for the cross-compiling builds and used instead of the fips_standalone_sha1 tool. If you want to try this, go ahead. Note that all of this should be strictly conditional for the cross compilation builds as I do not want to introduce build requirement on fipscheck for the regular builds.
(In reply to comment #1) > Using the build arch compiler instead of the cross-compiler would work as the > tool and the HMAC-SHA256 algorithm is invariant on the host architecture. Am I right in assuming that fips_standalone_sha1 will produce the same result, regardless of what arch it has been compiled for, as long as it could run on the build arch? > However you would have to build also the relevant part of openssl library > (namely the SHA and HMAC algorithms) with the build arch compiler. That is my preferred option as well. As far as I can see, fips_standalone_sha1 is not used in the final packaging, so it makes perfect sense for the Makefile to be modified, so that it builds fips_standalone_sha1 (and everything it depends on) for the "build" arch, not the "host"! Again, that would be OK provided fips_standalone_sha1 could do its work regardless of what architecture it is build for ("build" or "host") - something I wasn't completely sure of when I submitted the above bug. > Alternatively the fipshmac tool from the fipscheck library could be required > for the cross-compiling builds and used instead of the fips_standalone_sha1 > tool. No, that is wrong - why introduce another meaningless dependency, which will only be used for a one-off build of openssl? > If you want to try this, go ahead. Note that all of this should be > strictly conditional for the cross compilation builds as I do not want to > introduce build requirement on fipscheck for the regular builds. Exactly!
(In reply to comment #2) > (In reply to comment #1) > > Using the build arch compiler instead of the cross-compiler would work as the > > tool and the HMAC-SHA256 algorithm is invariant on the host architecture. > Am I right in assuming that fips_standalone_sha1 will produce the same result, > regardless of what arch it has been compiled for, as long as it could run on > the build arch? Yes. > > However you would have to build also the relevant part of openssl library > > (namely the SHA and HMAC algorithms) with the build arch compiler. > That is my preferred option as well. > > As far as I can see, fips_standalone_sha1 is not used in the final packaging, > so it makes perfect sense for the Makefile to be modified, so that it builds > fips_standalone_sha1 (and everything it depends on) for the "build" arch, not > the "host"! Yes. But note that it depends on some of the object files from the openssl build and on rawhide it links to full libcrypto.
(In reply to comment #3) > Yes. But note that it depends on some of the object files from the openssl > build and on rawhide it links to full libcrypto. Do you mean crypto as in crypt{.so.a} or crypto as in crypto{.so.a} (the openssl library)? If it is the former, this is, as far as I know, part of glibc (as well as uclibc as this is what I am using for cross-compilation), so this extra dependency won't affect anything. If it is the latter, then I guess the Makefile should be amended to build the dependent object files for the "build" arch (as well as the "host" as these are needed to be packaged later on) - the sources are already there, so that won't be very difficult. For convenience, as the "build" arch crypto objects are "temporary" they could be named differently and linked later on together when fips_standalone_sha1 is build. In either case, there won't be any need for extra new dependencies, which is always good.
(In reply to comment #4) > (In reply to comment #3) > > Yes. But note that it depends on some of the object files from the openssl > > build and on rawhide it links to full libcrypto. > Do you mean crypto as in crypt{.so.a} or crypto as in crypto{.so.a} (the > openssl library)? > > If it is the former, this is, as far as I know, part of glibc (as well as > uclibc as this is what I am using for cross-compilation), so this extra > dependency won't affect anything. > > If it is the latter, then I guess the Makefile should be amended to build the > dependent object files for the "build" arch (as well as the "host" as these are > needed to be packaged later on) - the sources are already there, so that won't > be very difficult. It is the latter. I am not quite sure I want to modify the Makefile this much though. I'd probably say that fipshmac tool from fipscheck should be pulled as buildrequires instead. This would be much less invasive change and it would not require any Makefile changes - just .spec changes. > For convenience, as the "build" arch crypto objects are "temporary" they could > be named differently and linked later on together when fips_standalone_sha1 is > build. > > In either case, there won't be any need for extra new dependencies, which is > always good. I don't share this view - these dependencies would not change anything on the target arch they would be just needed on the build arch and there they are provided by Fedora. So I rather prefer pulling some build dependency than to mangle the build process to even build the libcrypto twice on cross builds.
> So I rather prefer pulling some build dependency than to > mangle the build process to even build the libcrypto twice on cross builds. Fair enough - you are the maintainer of this, so who am I to argue? I have just discovered that there is an identical issue with openssh as well (they use fipscheck directly, though there isn't any BuildRequires for the "build" arch present in the .spec file).
If it is of any help, there is a separate package - hmaccalc - which might be useful - just adding BuildRequires for that package and remove the %post script calculation would suffice (if indeed adding build dependency is the preferred route to take).
That does not make sense to me. How would just adding hmaccalc to buildrequires remove the need to have the %post script in the openssl.spec file? It still would have to be there, it would just be possible to use the hmaccalc instead of fips_standalone_sha1. That's basically the same thing as adding fipscheck to buildrequires and using fipshmac from this package.
BTW I wonder if the best way could be just remove the post install build script and the .hmac from the filelists altogether as having the cross builds FIPS certified is not a real goal for us anyway.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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 please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.