During the final linking stage, when the shared object is built, the compiler is free to insert functions from compiled object files anywhere it sees fit in the final shared object's code segment. The object file is fundamentally transformed by this process; information which was present in the original object file may or may not end up in the resulting shared object. Although the machine code in the subroutines should be copied into the final shared object unmodified, the original object file is effectively gone and cannot be recovered. Without the original object file, we cannot calculate its cryptographic hash. "As long as politics is the shadow cast on society by big business, the attenuation of the shadow will not change the substance." Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6, page 163). Carbondale, IL: Southern Illinois University Press. On Mon, Mar 14, 2016 at 9:26 PM, Satya Das <satya at attivonetworks.com> wrote: > Hello Ethan, > > I am tweaking the centos rpmspec to use my fips object module. That seems > to be downloading source tar ball, patching etc. > > Please note that the sha1 of the so is not so interesting as the embedded > sha1 check inside so (when one calls FIPS_mode_set). Essentially if I can > get the embedded sha1in the so, I can compare that with the sha1 I have as > part of the object module I have built. I am assuming the embedded sha1 is > that of fipscanister.o. > > Hope that makes sense ? > > Thanks. > > > From: Ethan Rahn > Sent: Monday, March 14, 6:11 PM > Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with > what is embedded in libcrypto.so > To: openssl-users at openssl.org > > Is there a reason why you cannot build it from a controlled build > environment and record the hash of the final .so? > > It seems that it would be pretty non-trivial if not impossible to pull a > .o file from a .so in the exact same format that it went in, such that you > could check the hash. Being able to check if a .c file is in the same state > in the .so afterwards seems pretty much impossible given all the things > that would change in the code with compiling and linking in between the .c > state and the final .so state. > > On Mon, Mar 14, 2016 at 5:30 PM, Satya Das <satya at attivonetworks.com> > wrote: > > Hello, > > > > I have a simple problem I am trying to solve. I have built a fips capable > openssl shared object (.so). I also have the sha1 hash of the > fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1 > hash of fips_premain.c in a file called fips_premain.c.sha1. In order to > make sure the build is good, I want to make sure that the .so was indeed > built with these versions of fipscanister.o and fips_premain. > > > > Is there a way to do this ? I am on centos 6.6 x86_64 and linking to > object module 2.0.11 from openssl 1.0.1e with patches. > > > > Thanks > > -- > openssl-users mailing list > To unsubscribe: https > <https://mta.openssl.org/mailman/listinfo/openssl-users>:// > <https://mta.openssl.org/mailman/listinfo/openssl-users>mta.openssl.org > <https://mta.openssl.org/mailman/listinfo/openssl-users>/mailman/ > <https://mta.openssl.org/mailman/listinfo/openssl-users>listinfo > <https://mta.openssl.org/mailman/listinfo/openssl-users>/ > <https://mta.openssl.org/mailman/listinfo/openssl-users>openssl-users > <https://mta.openssl.org/mailman/listinfo/openssl-users> > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160314/9ee764b0/attachment.html>
