On Tue, Feb 21, 2012 at 3:51 PM, Andy Polyakov wrote:
>> Another option (but shoot it down if its bogus :-): I noticed that if I
>> compile
>> fipscanister.o without "-fPIC", then the const variables do get placed in
>> the (really readonly) .rodata section as desired. I thought maybe if I did
>>
Dr. Stephen Henson wrote:
[SNIP]
Should be fixed now, see:
http://cvs.openssl.org/chngview?cn=22124
to make OpenSSL understand both formats when verifying and:
http://cvs.openssl.org/chngview?cn=22126
to use the same format as older versions of OpenSSL when creating signatures.
10x . I confirm t
> Another option (but shoot it down if its bogus :-): I noticed that if I
> compile
> fipscanister.o without "-fPIC", then the const variables do get placed in
> the (really readonly) .rodata section as desired. I thought maybe if I did
> that and went the static route - build libcrypto with no-sh
On Tue, Feb 21, 2012 at 1:11 PM, Andy Polyakov wrote:
>> Though in FIPS 2.0 there is new option that might work in this case.
>> Besides switching to another compiler that is. Introduced to rectify
>> situation with rodata segments not being position-independent on Win64,
>> defini
On Tue, Feb 21, 2012, Kurt Roeckx wrote:
> On Sat, Jan 14, 2012 at 08:11:30PM +0100, Andy Polyakov wrote:
> > It's unfortunate and should have been taken care of at 1.0.0 release. I
> > mean it should have been 1.0 or 10 or something.
> >
> > > I'd just like verification that this is intentional
On Tue, Feb 21, 2012, Bruce Stephens wrote:
> This is when built with fips enabled. The issue seems to be some
> difference in gcc behaviour:
>
> make[3]: Entering directory `/releng/nightly/trunk/build/openssl/crypto/bn'
> ../../util/domd ../.. -MD gcc -- -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
This is when built with fips enabled. The issue seems to be some
difference in gcc behaviour:
make[3]: Entering directory `/releng/nightly/trunk/build/openssl/crypto/bn'
../../util/domd ../.. -MD gcc -- -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLF
On Sat, Jan 14, 2012 at 08:11:30PM +0100, Andy Polyakov wrote:
> It's unfortunate and should have been taken care of at 1.0.0 release. I
> mean it should have been 1.0 or 10 or something.
>
> > I'd just like verification that this is intentional and we can expect
> > binaries built against the 1.0
> Though in FIPS 2.0 there is new option that might work in this case.
> Besides switching to another compiler that is. Introduced to rectify
> situation with rodata segments not being position-independent on Win64,
> defining __fips_constseg might prove useful even in this situatio
