[openssl.org #1822] Issues w/ fips Makefile

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
> [[hidden email] - Mon Jan 26 12:04:23 2009]:
>
> The target:
>
> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
>         $(CC) $(CFLAGS) -DFIPSCANISTER_O -o $@
> sha/fips_standalone_sha1.c $(FIPSLIBDIR)fipscanister.o
>
> is built, but the extension is dropped when it's actually invoked:
>
> fipscanister.o: fips_start.o $(LIBOBJ) $(FIPS_OBJ_LISTS) fips_end.o
> ...
>         ./fips_standalone_sha1 fipscanister.o > fipscanister.o.sha1
>
>
> should be "./fips_standalone_sha1$(EXE_EXT) ..." of course.
>

OK, I can fix the missing $(EXE_EXT) but this is part of the validated
tarball so wont be usable for FIPS.

> Also, in a cross-compiling environment, "CC" tends to default to the
> target machine.
>
> If you're building intermediate binaries to be run as part of the
> build
> itself, these need to be indicated separately.
>
> A common practice is:
>
> HOSTCC?=$(CC)
> ...
>
> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
> $(HOSTCC) $(CFLAGS) -DFIPSCANISTER_O -o $@ sha/fips_standalone_sha1.c
> $(FIPSLIBDIR)fipscanister.o
>

The FIPS builds currently don't support cross compilation so this be of
much use in practice: they have to run a generate binary in order to
extract the signature during the linking process.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #1822] Issues w/ fips Makefile

Green, Paul
Stephen Henson via RT wrote:

> > [[hidden email] wrote:
> >
> > The target:
> >
> > fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
> >         $(CC) $(CFLAGS) -DFIPSCANISTER_O -o $@
> > sha/fips_standalone_sha1.c $(FIPSLIBDIR)fipscanister.o
> >
> > is built, but the extension is dropped when it's actually invoked:
> >
> > fipscanister.o: fips_start.o $(LIBOBJ) $(FIPS_OBJ_LISTS) fips_end.o
> > ...
> >         ./fips_standalone_sha1 fipscanister.o > fipscanister.o.sha1
> >
> >
> > should be "./fips_standalone_sha1$(EXE_EXT) ..." of course.
> >
>
> OK, I can fix the missing $(EXE_EXT) but this is part of the validated
> tarball so wont be usable for FIPS.

Philip, what operating system are you using or refering to?  I know of
at least two operating systems that require executable extensions on the
*files* but neither of them requires the shell to specify the extension
on the command line.  The Stratus VOS environment is the one I'm most
familiar with (note my email address); I'm pretty sure that MS-DOS also
works as I describe.  I've ported a *lot* of open-source software that
doesn't bother appending the $(EXE_EXT) when it invokes a command.  I'm
really curious to know which OS works the way you describe.

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;
AIM: PaulGreen
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
Stephen Henson via RT wrote:

> > [[hidden email] wrote:
> >
> > The target:
> >
> > fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
> >         $(CC) $(CFLAGS) -DFIPSCANISTER_O -o $@
> > sha/fips_standalone_sha1.c $(FIPSLIBDIR)fipscanister.o
> >
> > is built, but the extension is dropped when it's actually invoked:
> >
> > fipscanister.o: fips_start.o $(LIBOBJ) $(FIPS_OBJ_LISTS) fips_end.o
> > ...
> >         ./fips_standalone_sha1 fipscanister.o > fipscanister.o.sha1
> >
> >
> > should be "./fips_standalone_sha1$(EXE_EXT) ..." of course.
> >
>
> OK, I can fix the missing $(EXE_EXT) but this is part of the validated
> tarball so wont be usable for FIPS.

Philip, what operating system are you using or refering to?  I know of
at least two operating systems that require executable extensions on the
*files* but neither of them requires the shell to specify the extension
on the command line.  The Stratus VOS environment is the one I'm most
familiar with (note my email address); I'm pretty sure that MS-DOS also
works as I describe.  I've ported a *lot* of open-source software that
doesn't bother appending the $(EXE_EXT) when it invokes a command.  I'm
really curious to know which OS works the way you describe.

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;
AIM: PaulGreen


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Philip Prindeville
In reply to this post by Green, Paul
Green, Paul wrote:

> Stephen Henson via RT wrote:
>>> [[hidden email] wrote:
>>>
>>> The target:
>>>
>>> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
>>>         $(CC) $(CFLAGS) -DFIPSCANISTER_O -o $@
>>> sha/fips_standalone_sha1.c $(FIPSLIBDIR)fipscanister.o
>>>
>>> is built, but the extension is dropped when it's actually invoked:
>>>
>>> fipscanister.o: fips_start.o $(LIBOBJ) $(FIPS_OBJ_LISTS) fips_end.o
>>> ...
>>>         ./fips_standalone_sha1 fipscanister.o > fipscanister.o.sha1
>>>
>>>
>>> should be "./fips_standalone_sha1$(EXE_EXT) ..." of course.
>>>
>> OK, I can fix the missing $(EXE_EXT) but this is part of the validated
>> tarball so wont be usable for FIPS.
>
> Philip, what operating system are you using or refering to?  I know of
> at least two operating systems that require executable extensions on the
> *files* but neither of them requires the shell to specify the extension
> on the command line.  The Stratus VOS environment is the one I'm most
> familiar with (note my email address); I'm pretty sure that MS-DOS also
> works as I describe.  I've ported a *lot* of open-source software that
> doesn't bother appending the $(EXE_EXT) when it invokes a command.  I'm
> really curious to know which OS works the way you describe.
>
> Thanks
> PG

Yes, on DOS (or in a CMD.EXE shell in Windows) you don't need the extension... if your PATHEXT variable hasn't been tampered with.

In a robust build system, you can't always count on the build environment not having been messed with.

I spent 40 minutes once tracking down an issue....  A make script wasn't picking up the correct SVN version (it was using the construct:

svn info | awk '/^Last Changed Rev:/ { print $2 }'

and failing)... because the user had set LANG=de (he was German).

Bulletproofing the build system to not rely on the user's settings is usually not a bad thing... unless it becomes so annotated as to be too difficult to read.

-Philip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
Green, Paul wrote:

> Stephen Henson via RT wrote:
>>> [[hidden email] wrote:
>>>
>>> The target:
>>>
>>> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
>>>         $(CC) $(CFLAGS) -DFIPSCANISTER_O -o $@
>>> sha/fips_standalone_sha1.c $(FIPSLIBDIR)fipscanister.o
>>>
>>> is built, but the extension is dropped when it's actually invoked:
>>>
>>> fipscanister.o: fips_start.o $(LIBOBJ) $(FIPS_OBJ_LISTS) fips_end.o
>>> ...
>>>         ./fips_standalone_sha1 fipscanister.o > fipscanister.o.sha1
>>>
>>>
>>> should be "./fips_standalone_sha1$(EXE_EXT) ..." of course.
>>>
>> OK, I can fix the missing $(EXE_EXT) but this is part of the validated
>> tarball so wont be usable for FIPS.
>
> Philip, what operating system are you using or refering to?  I know of
> at least two operating systems that require executable extensions on the
> *files* but neither of them requires the shell to specify the extension
> on the command line.  The Stratus VOS environment is the one I'm most
> familiar with (note my email address); I'm pretty sure that MS-DOS also
> works as I describe.  I've ported a *lot* of open-source software that
> doesn't bother appending the $(EXE_EXT) when it invokes a command.  I'm
> really curious to know which OS works the way you describe.
>
> Thanks
> PG

Yes, on DOS (or in a CMD.EXE shell in Windows) you don't need the extension... if your PATHEXT variable hasn't been tampered with.

In a robust build system, you can't always count on the build environment not having been messed with.

I spent 40 minutes once tracking down an issue....  A make script wasn't picking up the correct SVN version (it was using the construct:

svn info | awk '/^Last Changed Rev:/ { print $2 }'

and failing)... because the user had set LANG=de (he was German).

Bulletproofing the build system to not rely on the user's settings is usually not a bad thing... unless it becomes so annotated as to be too difficult to read.

-Philip


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Philip Prindeville
In reply to this post by Rich Salz via RT
On 6/29/09 3:26 PM, Stephen Henson via RT wrote:

>
>> Also, in a cross-compiling environment, "CC" tends to default to the
>> target machine.
>>
>> If you're building intermediate binaries to be run as part of the
>> build
>> itself, these need to be indicated separately.
>>
>> A common practice is:
>>
>> HOSTCC?=$(CC)
>> ...
>>
>> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
>> $(HOSTCC) $(CFLAGS) -DFIPSCANISTER_O -o $@ sha/fips_standalone_sha1.c
>> $(FIPSLIBDIR)fipscanister.o
>>
>>      
> The FIPS builds currently don't support cross compilation so this be of
> much use in practice: they have to run a generate binary in order to
> extract the signature during the linking process.
>
>
>    

I'm sorry, I guess I'm not understanding what you're saying here.

If this step is run as part of the build process, then the binaries need
to be for the build host (and not the target host).

If on the other hand you're saying that this step isn't mandatory, then
can we add an additional target (like "make build-no-fips") that skips
this step altogether?

Thanks.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
On 6/29/09 3:26 PM, Stephen Henson via RT wrote:

>
>> Also, in a cross-compiling environment, "CC" tends to default to the
>> target machine.
>>
>> If you're building intermediate binaries to be run as part of the
>> build
>> itself, these need to be indicated separately.
>>
>> A common practice is:
>>
>> HOSTCC?=$(CC)
>> ...
>>
>> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
>> $(HOSTCC) $(CFLAGS) -DFIPSCANISTER_O -o $@ sha/fips_standalone_sha1.c
>> $(FIPSLIBDIR)fipscanister.o
>>
>>      
> The FIPS builds currently don't support cross compilation so this be of
> much use in practice: they have to run a generate binary in order to
> extract the signature during the linking process.
>
>
>    

I'm sorry, I guess I'm not understanding what you're saying here.

If this step is run as part of the build process, then the binaries need
to be for the build host (and not the target host).

If on the other hand you're saying that this step isn't mandatory, then
can we add an additional target (like "make build-no-fips") that skips
this step altogether?

Thanks.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

[openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
> [[hidden email] - Tue Jul 06 23:40:15 2010]:
>
> On 6/29/09 3:26 PM, Stephen Henson via RT wrote:
> >
> >> Also, in a cross-compiling environment, "CC" tends to default to the
> >> target machine.
> >>
> >> If you're building intermediate binaries to be run as part of the
> >> build
> >> itself, these need to be indicated separately.
> >>
> >> A common practice is:
> >>
> >> HOSTCC?=$(CC)
> >> ...
> >>
> >> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
> >> $(HOSTCC) $(CFLAGS) -DFIPSCANISTER_O -o $@ sha/fips_standalone_sha1.c
> >> $(FIPSLIBDIR)fipscanister.o
> >>
> >>      
> > The FIPS builds currently don't support cross compilation so this be of
> > much use in practice: they have to run a generate binary in order to
> > extract the signature during the linking process.
> >
> >
> >    
>
> I'm sorry, I guess I'm not understanding what you're saying here.
>
> If this step is run as part of the build process, then the binaries need
> to be for the build host (and not the target host).
>
> If on the other hand you're saying that this step isn't mandatory, then
> can we add an additional target (like "make build-no-fips") that skips
> this step altogether?
>

I'm not sure what you're trying to do here.

If you want to cross compile without FIPS 140-2 support then you should
never reach that point.

If you want FIPS 140-2 support then you can cross compile now using the
information in the revised security policy and the appropriate patch.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Philip Prindeville
  On 7/18/10 10:00 AM, Stephen Henson via RT wrote:

>> [[hidden email] - Tue Jul 06 23:40:15 2010]:
>>
>> On 6/29/09 3:26 PM, Stephen Henson via RT wrote:
>>>> Also, in a cross-compiling environment, "CC" tends to default to the
>>>> target machine.
>>>>
>>>> If you're building intermediate binaries to be run as part of the
>>>> build
>>>> itself, these need to be indicated separately.
>>>>
>>>> A common practice is:
>>>>
>>>> HOSTCC?=$(CC)
>>>> ...
>>>>
>>>> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
>>>> $(HOSTCC) $(CFLAGS) -DFIPSCANISTER_O -o $@ sha/fips_standalone_sha1.c
>>>> $(FIPSLIBDIR)fipscanister.o
>>>>
>>>>
>>> The FIPS builds currently don't support cross compilation so this be of
>>> much use in practice: they have to run a generate binary in order to
>>> extract the signature during the linking process.
>>>
>>>
>>>
>> I'm sorry, I guess I'm not understanding what you're saying here.
>>
>> If this step is run as part of the build process, then the binaries need
>> to be for the build host (and not the target host).
>>
>> If on the other hand you're saying that this step isn't mandatory, then
>> can we add an additional target (like "make build-no-fips") that skips
>> this step altogether?
>>
> I'm not sure what you're trying to do here.
>
> If you want to cross compile without FIPS 140-2 support then you should
> never reach that point.
>
> If you want FIPS 140-2 support then you can cross compile now using the
> information in the revised security policy and the appropriate patch.
>
> Steve.

What I'm trying to do is simple: in the case of cross-compilation, you have two types of binaries.

You have target binaries that will get installed on the target system which you're building for, and you have one-off intermediate binaries that are compiled and executed in the course of the build.

The problem here is that the intermediate binaries like ./fips_standalone_sha1 are being built with the target compiler, not the host compiler.

I had submitted a patch a year and a half ago to fix this issue, but for whatever reason it's been languishing.

Which "appropriate patch" are you talking about?

And what's been the objection to applying the patch I furnished?


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
  On 7/18/10 10:00 AM, Stephen Henson via RT wrote:

>> [[hidden email] - Tue Jul 06 23:40:15 2010]:
>>
>> On 6/29/09 3:26 PM, Stephen Henson via RT wrote:
>>>> Also, in a cross-compiling environment, "CC" tends to default to the
>>>> target machine.
>>>>
>>>> If you're building intermediate binaries to be run as part of the
>>>> build
>>>> itself, these need to be indicated separately.
>>>>
>>>> A common practice is:
>>>>
>>>> HOSTCC?=$(CC)
>>>> ...
>>>>
>>>> fips_standalone_sha1$(EXE_EXT): sha/fips_standalone_sha1.c
>>>> $(HOSTCC) $(CFLAGS) -DFIPSCANISTER_O -o $@ sha/fips_standalone_sha1.c
>>>> $(FIPSLIBDIR)fipscanister.o
>>>>
>>>>
>>> The FIPS builds currently don't support cross compilation so this be of
>>> much use in practice: they have to run a generate binary in order to
>>> extract the signature during the linking process.
>>>
>>>
>>>
>> I'm sorry, I guess I'm not understanding what you're saying here.
>>
>> If this step is run as part of the build process, then the binaries need
>> to be for the build host (and not the target host).
>>
>> If on the other hand you're saying that this step isn't mandatory, then
>> can we add an additional target (like "make build-no-fips") that skips
>> this step altogether?
>>
> I'm not sure what you're trying to do here.
>
> If you want to cross compile without FIPS 140-2 support then you should
> never reach that point.
>
> If you want FIPS 140-2 support then you can cross compile now using the
> information in the revised security policy and the appropriate patch.
>
> Steve.

What I'm trying to do is simple: in the case of cross-compilation, you have two types of binaries.

You have target binaries that will get installed on the target system which you're building for, and you have one-off intermediate binaries that are compiled and executed in the course of the build.

The problem here is that the intermediate binaries like ./fips_standalone_sha1 are being built with the target compiler, not the host compiler.

I had submitted a patch a year and a half ago to fix this issue, but for whatever reason it's been languishing.

Which "appropriate patch" are you talking about?

And what's been the objection to applying the patch I furnished?



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

[openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
> [[hidden email] - Sun Jul 18 19:02:04 2010]:
>
> The problem here is that the intermediate binaries like
> ./fips_standalone_sha1 are being built with the target compiler, not
> the host compiler.
>
> I had submitted a patch a year and a half ago to fix this issue, but
> for whatever reason it's been languishing.
>

That was addressed some time ago as part of the cross compilation
support for FIPS builds. Let me know of any problems.

> Which "appropriate patch" are you talking about?
>

Historically the problem with FIPS builds was that you needed to execute
target binaries in order to embed the appropriate signature (the fipsld
script did that). That was fine if the host and target were compatible
but choked if they weren't.

We couldn't change that without modifying the validated module source
and that is not allowed without permission.

An update to the validation (a change letter) now means cross
compilation is supported for FIPS builds. The "appropriate patch" is
something that adds cross compilation functionality to the validated
module. It is at:

http://www.openssl.org/source/openssl-fips-1.2.crossbuild.diff.gz

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Philip Prindeville
  On 7/18/10 12:27 PM, Stephen Henson via RT wrote:

>> [[hidden email] - Sun Jul 18 19:02:04 2010]:
>>
>> The problem here is that the intermediate binaries like
>> ./fips_standalone_sha1 are being built with the target compiler, not
>> the host compiler.
>>
>> I had submitted a patch a year and a half ago to fix this issue, but
>> for whatever reason it's been languishing.
>>
> That was addressed some time ago as part of the cross compilation
> support for FIPS builds. Let me know of any problems.
When did this patch get applied?  I see it's in 0.9.8n

>> Which "appropriate patch" are you talking about?
>>
> Historically the problem with FIPS builds was that you needed to execute
> target binaries in order to embed the appropriate signature (the fipsld
> script did that). That was fine if the host and target were compatible
> but choked if they weren't.
>
> We couldn't change that without modifying the validated module source
> and that is not allowed without permission.
>
> An update to the validation (a change letter) now means cross
> compilation is supported for FIPS builds. The "appropriate patch" is
> something that adds cross compilation functionality to the validated
> module. It is at:
>
> http://www.openssl.org/source/openssl-fips-1.2.crossbuild.diff.gz
>
> Steve.
Did a bump to 0.9.8n and ran into a separate issue: we need to explicitly pass various flags to CC and LD, but there's no easy way to do that.  So added the following patch.



openssl-configure.patch (534 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
  On 7/18/10 12:27 PM, Stephen Henson via RT wrote:

>> [[hidden email] - Sun Jul 18 19:02:04 2010]:
>>
>> The problem here is that the intermediate binaries like
>> ./fips_standalone_sha1 are being built with the target compiler, not
>> the host compiler.
>>
>> I had submitted a patch a year and a half ago to fix this issue, but
>> for whatever reason it's been languishing.
>>
> That was addressed some time ago as part of the cross compilation
> support for FIPS builds. Let me know of any problems.
When did this patch get applied?  I see it's in 0.9.8n

>> Which "appropriate patch" are you talking about?
>>
> Historically the problem with FIPS builds was that you needed to execute
> target binaries in order to embed the appropriate signature (the fipsld
> script did that). That was fine if the host and target were compatible
> but choked if they weren't.
>
> We couldn't change that without modifying the validated module source
> and that is not allowed without permission.
>
> An update to the validation (a change letter) now means cross
> compilation is supported for FIPS builds. The "appropriate patch" is
> something that adds cross compilation functionality to the validated
> module. It is at:
>
> http://www.openssl.org/source/openssl-fips-1.2.crossbuild.diff.gz
>
> Steve.
Did a bump to 0.9.8n and ran into a separate issue: we need to explicitly pass various flags to CC and LD, but there's no easy way to do that.  So added the following patch.




--- openssl-0.9.8n/Configure.orig2 2010-07-18 11:57:13.000000000 -0600
+++ openssl-0.9.8n/Configure 2010-07-18 12:25:57.000000000 -0600
@@ -841,6 +841,14 @@ PROCESS_ARGS:
  {
  $flags.=$_." ";
  }
+ elsif (/^--cflags=(.*)$/)
+ {
+ $flags=$1." ";
+ }
+ elsif (/^--ldflags=(.*)$/)
+ {
+ $lflags=$1." ";
+ }
  elsif (/^--prefix=(.*)$/)
  {
  $prefix=$1;
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Philip Prindeville
  On 7/19/10 9:25 AM, Philip Prindeville via RT wrote:

>    On 7/18/10 12:27 PM, Stephen Henson via RT wrote:
>>> [[hidden email] - Sun Jul 18 19:02:04 2010]:
>>>
>>> The problem here is that the intermediate binaries like
>>> ./fips_standalone_sha1 are being built with the target compiler, not
>>> the host compiler.
>>>
>>> I had submitted a patch a year and a half ago to fix this issue, but
>>> for whatever reason it's been languishing.
>>>
>> That was addressed some time ago as part of the cross compilation
>> support for FIPS builds. Let me know of any problems.
> When did this patch get applied?  I see it's in 0.9.8n
>
>>> Which "appropriate patch" are you talking about?
>>>
>> Historically the problem with FIPS builds was that you needed to execute
>> target binaries in order to embed the appropriate signature (the fipsld
>> script did that). That was fine if the host and target were compatible
>> but choked if they weren't.
>>
>> We couldn't change that without modifying the validated module source
>> and that is not allowed without permission.
>>
>> An update to the validation (a change letter) now means cross
>> compilation is supported for FIPS builds. The "appropriate patch" is
>> something that adds cross compilation functionality to the validated
>> module. It is at:
>>
>> http://www.openssl.org/source/openssl-fips-1.2.crossbuild.diff.gz
>>
>> Steve.
> Did a bump to 0.9.8n and ran into a separate issue: we need to explicitly pass various flags to CC and LD, but there's no easy way to do that.  So added the following patch.

Anything?  Up/down vote?

Is it acceptable, or if not, what do I need to do to make it acceptable?

Thanks.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1822] Issues w/ fips Makefile

Rich Salz via RT
  On 7/19/10 9:25 AM, Philip Prindeville via RT wrote:

>    On 7/18/10 12:27 PM, Stephen Henson via RT wrote:
>>> [[hidden email] - Sun Jul 18 19:02:04 2010]:
>>>
>>> The problem here is that the intermediate binaries like
>>> ./fips_standalone_sha1 are being built with the target compiler, not
>>> the host compiler.
>>>
>>> I had submitted a patch a year and a half ago to fix this issue, but
>>> for whatever reason it's been languishing.
>>>
>> That was addressed some time ago as part of the cross compilation
>> support for FIPS builds. Let me know of any problems.
> When did this patch get applied?  I see it's in 0.9.8n
>
>>> Which "appropriate patch" are you talking about?
>>>
>> Historically the problem with FIPS builds was that you needed to execute
>> target binaries in order to embed the appropriate signature (the fipsld
>> script did that). That was fine if the host and target were compatible
>> but choked if they weren't.
>>
>> We couldn't change that without modifying the validated module source
>> and that is not allowed without permission.
>>
>> An update to the validation (a change letter) now means cross
>> compilation is supported for FIPS builds. The "appropriate patch" is
>> something that adds cross compilation functionality to the validated
>> module. It is at:
>>
>> http://www.openssl.org/source/openssl-fips-1.2.crossbuild.diff.gz
>>
>> Steve.
> Did a bump to 0.9.8n and ran into a separate issue: we need to explicitly pass various flags to CC and LD, but there's no easy way to do that.  So added the following patch.

Anything?  Up/down vote?

Is it acceptable, or if not, what do I need to do to make it acceptable?

Thanks.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]