Re: [openssl-users] Can't compile Apache 2.4.23 with OpenSSL 1.1.0b

[Salz, Rich]

You might want to start here: 
http://apache-http-server.18135.x6.nabble.com/Support-for-OpenSSL-1-1-0-td5027694.html

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Can't compile Apache 2.4.23 with OpenSSL 1.1.0b

[Benjamin Kaduk]

The library is mostly self-initializing now, so the malloc_init call is
probably not needed.

SSLv2 support is entirely removed.

There are very drastic changes between the 1.0.x series and the 1.1.0
series, you really should read at least the NEWS file entries and maybe
the CHANGES as well.  Porting a large application such as Apache to the
new library will be a nontrivial work, but as you suspect, is probably
best discussed on the httpd mailing list.

-Ben

On 09/27/2016 12:14 PM, Paquin, Brian wrote:
> When I try to compile Apache 2.4.23 with OpenSSL 1.1.0b I get:
>
> secure:httpd-2.4.23 administrator$ sudo make
> <--many lines cut out-->
> /Users/administrator/Downloads/httpd-2.4.23/srclib/apr/libtool --silent 
> --mode=link gcc-arch x86_64 -L/usr/local/openssl/lib -lssl -lcrypto 
> -lpthread  \
>-o ab  ab.lo   
> /Users/administrator/Downloads/httpd-2.4.23/srclib/apr-util/libaprutil-1.la 
> -lexpat -liconv 
> /Users/administrator/Downloads/httpd-2.4.23/srclib/apr/libapr-1.la -lpthread 
> Undefined symbols for architecture x86_64:
>   "_CRYPTO_malloc_init", referenced from:
>   _main in ab.o
>   "_SSLv2_client_method", referenced from:
>   _main in ab.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[2]: *** [ab] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all-recursive] Error 1
>
> It compiles fine with 1.0.1j, but I am curious what I need to change to get 
> 1.1.0b working…
> (this may be for the httpd mailing list, but since it was specific to v1.1.0 
> I thought I would start here.
>
> OS is Mac OS X 10.11.6.
>
> Thank you,
>
> Brian

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Building on Windows against run-time library

[Wei Sun]

Hello,
  
 I'm new to the openssl build system and I'm sure there is some script I 
could change/add for different linking behaviors.
  
 It seems it uses /MD to build shared library and /MT to build static 
library for 1.1.0b. And I was able to edit generated makefile to change 
run-time dependency, it's not optimal solution, but it would be easiest one 
for our case for now.
  
  
  
  
  Original Message 
- From: "Michael Wojcik" 
- Sent: Tuesday, September 27, 2016 6:08 AM
- To: "openssl-users@openssl.org" 
- Subject: Re: [openssl-users] Building on Windows against run-time 
library
-
- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
Behalf
- > Of Wei Sun
- > Sent: Monday, September 26, 2016 19:06
- >
- > Just joined the list, and apologize if the following question was 
answered
- > before.
- >
- > I'm building openssl 1.1.0b on Windows. It is stated that it defaults 
to
- > /MD while building openssl, so is there a way to change the linker 
option
- > to /MT?
-
- We're still using 1.0.2, so I don't know if the 1.1.0 build system is 
significantly different; but we use a build script of our own which edits 
the Perl build scripts (using Cygwin sed) after extracting the tarball and 
before running the OpenSSL build process. One of the things it does is 
force the C RTS linker switches we want.
-
- I don't know of a cleaner way to handle this particular aspect of build 
configuration. It's been some years since I looked into it, though.
-
- It's not an issue for us because our build scripts do a bunch of other 
things (as part of our integration process) besides extracting the sources 
and building OpenSSL, so adding this step wasn't burdensome.
-
- Michael Wojcik
- Distinguished Engineer, Micro Focus
-
-
- --
- openssl-users mailing list
- To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Can't compile Apache 2.4.23 with OpenSSL 1.1.0b

[Paquin, Brian]

When I try to compile Apache 2.4.23 with OpenSSL 1.1.0b I get:

secure:httpd-2.4.23 administrator$ sudo make
<--many lines cut out-->
/Users/administrator/Downloads/httpd-2.4.23/srclib/apr/libtool --silent 
--mode=link gcc-arch x86_64 -L/usr/local/openssl/lib -lssl -lcrypto 
-lpthread  \
 -o ab  ab.lo   
/Users/administrator/Downloads/httpd-2.4.23/srclib/apr-util/libaprutil-1.la 
-lexpat -liconv 
/Users/administrator/Downloads/httpd-2.4.23/srclib/apr/libapr-1.la -lpthread 
Undefined symbols for architecture x86_64:
  "_CRYPTO_malloc_init", referenced from:
  _main in ab.o
  "_SSLv2_client_method", referenced from:
  _main in ab.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [ab] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

It compiles fine with 1.0.1j, but I am curious what I need to change to get 
1.1.0b working…
(this may be for the httpd mailing list, but since it was specific to v1.1.0 I 
thought I would start here.

OS is Mac OS X 10.11.6.

Thank you,

Brian
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Building FIPS-capable OpenSSL on Linux PPC64

[Steve Marquess]

On 09/27/2016 10:56 AM, Perrow, Graeme wrote:
> I am trying to build FIPS OpenSSL libraries for Linux PPC64 but it does
> not seem possible. This has been raised before (link below) but I didn’t
> see any resolution.
> 
>  
> 
> http://openssl.6102.n7.nabble.com/BUG-FIPS-capable-OpenSSL-fails-to-build-on-Linux-PPC64-td66890.html
> 
>  
> 
> I can build it if I run “./Configure linux-ppc64” but it is my
> understanding that you ***must*** build the FIPS libraries using
> “./config” or “./config no-asm”. Is there a workaround? Is there a fix
> coming? Given that the problem is within the FIPS module, is a fix
> possible without recertification?
> 
>  
> 
> Thanks
> 
> Graeme Perrow
> 
>  
> 
> 
> 

Well, your first and biggest problem is that no Linux on 64-bit PPC
platforms ("OEs") have been validated. So whether you can build it there
or not it moot.

We can still add platforms to the 2.0 FIPS module, but of course that
takes time and money. Typically we would introduce new architecture
targets in config/Configure as necessary to accommodate the requirement
that command line options not be used (that's where most of the revision
bumps come from).

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Building FIPS-capable OpenSSL on Linux PPC64

[Perrow, Graeme]

I am trying to build FIPS OpenSSL libraries for Linux PPC64 but it does not 
seem possible. This has been raised before (link below) but I didn't see any 
resolution.

http://openssl.6102.n7.nabble.com/BUG-FIPS-capable-OpenSSL-fails-to-build-on-Linux-PPC64-td66890.html

I can build it if I run "./Configure linux-ppc64" but it is my understanding 
that you **must** build the FIPS libraries using "./config" or "./config 
no-asm". Is there a workaround? Is there a fix coming? Given that the problem 
is within the FIPS module, is a fix possible without recertification?

Thanks
Graeme Perrow

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] new FIPS module

[Zeke Evans]

> As always, if you don't care about FIPS 140 then count yourself lucky and
> move on.
> 
> Work on the new FIPS module has so far taken a backseat to higher priority
> topics like the 1.1 release and security vulnerabilities, but we should start 
> to
> make some progress soon. I've put together a rough wiki page outlining
> some goals for the new FIPS module:
> 
>   https://wiki.openssl.org/index.php/FIPS_module_3.0
> 
> Within the very tight constraints of schedule, resources, and what is
> permitted by FIPS 140, we want this FIPS module to be as widely useful as
> possible.
> 
> If we've omitted anything of vital importance please speak up.

The fixed base address requirement causes problems for large Windows x86 
applications and there isn't a great work around.  It isn't clear to me if item 
2 " Support compilation in various forms" will address this or not.  An option 
to compile the fips module as a dll instead of a static lib would be nice or at 
least allow the fips capable module to be rebased.

Zeke Evans
Senior Software Engineer
Micro Focus
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] new FIPS module

[Jakob Bohm]

On 27/09/2016 15:41, Steve Marquess wrote:

As always, if you don't care about FIPS 140 then count yourself lucky
and move on.

Work on the new FIPS module has so far taken a backseat to higher
priority topics like the 1.1 release and security vulnerabilities, but
we should start to make some progress soon. I've put together a rough
wiki page outlining some goals for the new FIPS module:

   https://wiki.openssl.org/index.php/FIPS_module_3.0

Within the very tight constraints of schedule, resources, and what is
permitted by FIPS 140, we want this FIPS module to be as widely useful
as possible.

If we've omitted anything of vital importance please speak up.

Here's one practical thing (as a suggestion):

- To ensure compatibility with platform ASLR, build the FIPS cannister
 as completely position independent code with no relocations whenever
 platforms allow.  This probably requires that the FIPS cannister
 makes all calls to outside libraries as callbacks to function pointers
 supplied during module init, or at least via a function table that is
 outside the hashed FIPS cannister.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] new FIPS module

[Steve Marquess]

As always, if you don't care about FIPS 140 then count yourself lucky
and move on.

Work on the new FIPS module has so far taken a backseat to higher
priority topics like the 1.1 release and security vulnerabilities, but
we should start to make some progress soon. I've put together a rough
wiki page outlining some goals for the new FIPS module:

  https://wiki.openssl.org/index.php/FIPS_module_3.0

Within the very tight constraints of schedule, resources, and what is
permitted by FIPS 140, we want this FIPS module to be as widely useful
as possible.

If we've omitted anything of vital importance please speak up.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Building on Windows against run-time library

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Wei Sun
> Sent: Monday, September 26, 2016 19:06
> 
>  Just joined the list, and apologize if the following question was answered
> before.
> 
>  I'm building openssl 1.1.0b on Windows. It is stated that it defaults to
> /MD while building openssl, so is there a way to change the linker option
> to /MT?

We're still using 1.0.2, so I don't know if the 1.1.0 build system is 
significantly different; but we use a build script of our own which edits the 
Perl build scripts (using Cygwin sed) after extracting the tarball and before 
running the OpenSSL build process. One of the things it does is force the C RTS 
linker switches we want.

I don't know of a cleaner way to handle this particular aspect of build 
configuration. It's been some years since I looked into it, though.

It's not an issue for us because our build scripts do a bunch of other things 
(as part of our integration process) besides extracting the sources and 
building OpenSSL, so adding this step wasn't burdensome.

Michael Wojcik 
Distinguished Engineer, Micro Focus 


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why 1.0.1 AND 1.0.2 ?

[Salz, Rich]

(Can you change your mailer to plaintext, or at least get rid of the 
black-on-grey styling?)


> Reading the 1.0.2j CHANGES file, it appears that 1.0.2 was built from 1.0.1l.

That might be the time it was branched off from it.  At that point, the two 
releases are different.
 
>And my knowledge of OpenSSL is VERY VERY small.

Okay.  But you are going to have a hard time understanding changes, then.

>Looking at 1.0.1l, out of bug fixes, I've found some changes that do not look 
>as bugfixes:

Those are security issues.  When someone publishes a paper that shows a weak DH 
key can be cracked in an hour, then a security toolkit must "move up" to longer 
keys by default.  This article might be useful: 
https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ and 
the "SWEET32" article will talk about the DES changes.

> However, only the first one, in bold, appears in 1.0.1l and NOT in 1.0.2j .

 No.  The entry just before "28 jan" in the CHANGES file.

>Why OpenSSL still delivers 1.0.1* though 1.0.2* should provide the same 
>changes plus new features ?

Your confusion is thinking that "upgraded security parameters" are new feature, 
and not security fixes.

>Because change "dhparam: generate 2048-bit parameters by default." appears in 
>1.0.1[n-l] and not in 1.0.2* ???

It is.

> I need to know in order to decide if I still manage 1.0.1 compatibility in 
> addition to delivering 1.0.2[last version] .

You can do what you want :)  Openssl 1.0.1 becomes unsupported at the end of 
2016. If you want to tell your users that you are ending support early, nobody 
can stop you. :)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] "nmake install" attempts to write outside of prefix

[Jaroslav Imrich]

On 26 September 2016 at 22:04, Braden McDaniel  wrote:

> After configuring with a prefix (other than "C:\Program Files"), it seems
> that "nmake install" still attempts to write to "C:\Program Files\Common
> Files\SSL". Is there some other way to suppress this, or is this a bug in
> the current build system?
>

You need to use both --prefix and --openssldir arguments.

Regards, Jaroslav
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why 1.0.1 AND 1.0.2 ?

[Matt Caswell]

On 27/09/16 08:52, REIX, Tony wrote:
> Reading the 1.0.2j CHANGES file, it appears that 1.0.2 was built from
> 1.0.1l.
> And there are 1124 of description of the changes for 1.0.2 and about 500
> lines of changes from 1.0.1l to 1.0.1u .
> And my knowledge of OpenSSL is VERY VERY small.
> 
> Looking at 1.0.1l, out of bug fixes, I've found some changes that do not
> look as bugfixes:
> - *dhparam: generate 2048-bit parameters by default. (1.0.1n)*
> - Reject DH handshakes with parameters shorter than 768 bits.
> - In DSA_generate_parameters_ex, if the provided seed is too short, use
> a random seed, as already documented.
> - Reject DH handshakes with parameters shorter than 1024 bits.
> - Disable SRP fake user seed to address a server memory leak.
>   Add a new method SRP_VBASE_get1_by_user that handles the seed properly.
> - Remove LOW from the DEFAULT cipher list.  This removes singles DES
> from the default.
> 
> However, only the first one, in bold, appears in 1.0.1l and NOT in 1.0.2j .

That's just an omission. dhparam has generated 2048-bit parameters by
default in 1.0.2 since its first release.

> 
> 
> So, my question is still:
> 
> Why OpenSSL still delivers 1.0.1* though 1.0.2* should provide the same
> changes plus new features ?

1.0.1 should be binary compatible with 1.0.2 (as long as they are
compiled with the same configuration options etc). However many users
still prefer to use an exactly matching version.

> Because change "*dhparam: generate 2048-bit parameters by default."*
> appears in 1.0.1[n-l] and not in 1.0.2* ???
> 
> 
> I need to know in order to decide if I still manage 1.0.1 compatibility
> in addition to delivering 1.0.2[last version] .

1.0.1 is nearing end-of-life. From the beginning of this year it has
been receiving security fixes only. From the end of this year it will be
out of support completely. All users should be making plans to move off
of 1.0.1 if they are still using it, and transitioning to 1.0.2. This
should be a very easy move.

Matt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] "nmake install" attempts to write outside of prefix

['Braden McDaniel']

After configuring with a prefix (other than "C:\Program Files"), it seems that 
"nmake install" still attempts to write to "C:\Program Files\Common Files\SSL". 
Is there some other way to suppress this, or is this a bug in the current build 
system?

I am using OpenSSL 1.1.0b with platform VC-WIN64A.

Braden

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why 1.0.1 AND 1.0.2 ?

[REIX, Tony]

Reading the 1.0.2j CHANGES file, it appears that 1.0.2 was built from 1.0.1l.
And there are 1124 of description of the changes for 1.0.2 and about 500 lines 
of changes from 1.0.1l to 1.0.1u .
And my knowledge of OpenSSL is VERY VERY small.

Looking at 1.0.1l, out of bug fixes, I've found some changes that do not look 
as bugfixes:
- dhparam: generate 2048-bit parameters by default. (1.0.1n)
- Reject DH handshakes with parameters shorter than 768 bits.
- In DSA_generate_parameters_ex, if the provided seed is too short, use a 
random seed, as already documented.
- Reject DH handshakes with parameters shorter than 1024 bits.
- Disable SRP fake user seed to address a server memory leak.
  Add a new method SRP_VBASE_get1_by_user that handles the seed properly.
- Remove LOW from the DEFAULT cipher list.  This removes singles DES from the 
default.

However, only the first one, in bold, appears in 1.0.1l and NOT in 1.0.2j .


So, my question is still:

Why OpenSSL still delivers 1.0.1* though 1.0.2* should provide the same changes 
plus new features ?
Because change "dhparam: generate 2048-bit parameters by default." appears in 
1.0.1[n-l] and not in 1.0.2* ???


I need to know in order to decide if I still manage 1.0.1 compatibility in 
addition to delivering 1.0.2[last version] .

Help is welcome !

Tony

Le 26/09/2016 à 17:53, Salz, Rich a écrit :

However, out of more ABIs delivered by 1.0.2 compared to 1.0.1, I do not 
understand what is the exact difference between versions 1.0.1 and 1.0.2 .



Perhaps look at the CHANGES file in 1.0.2 and see what's been added?  1.0.1 
only gets bugfixes, 1.0.2 adds features, but starting with 1.0.2a only gets 
bugfixes.

Hope this help.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz




-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users