Re: [CVS] OpenSSL: OpenSSL_1_0_1-stable: openssl/ Configure

2012-03-14 Thread William A. Rowe Jr.
+1, I had applied this locally [sorry for delays]

On 3/14/2012 5:20 PM, Dr. Stephen Henson wrote:
>   OpenSSL CVS Repository
>   http://cvs.openssl.org/
>   
> 
>   Server: cvs.openssl.org  Name:   Dr. Stephen Henson
>   Root:   /v/openssl/cvs   Email:  st...@openssl.org
>   Module: openssl  Date:   14-Mar-2012 23:20:40
>   Branch: OpenSSL_1_0_1-stable Handle: 2012031422204000
> 
>   Modified files:   (Branch: OpenSSL_1_0_1-stable)
> openssl Configure
> 
>   Log:
> remove trailing slash
> 
>   Summary:
> RevisionChanges Path
> 1.621.2.37.2.32+2  -2  openssl/Configure
>   
> 
>   patch -p0 <<'@@ .'
>   Index: openssl/Configure
>   
>   $ cvs diff -u -r1.621.2.37.2.31 -r1.621.2.37.2.32 Configure
>   --- openssl/Configure   3 Mar 2012 13:18:06 -   1.621.2.37.2.31
>   +++ openssl/Configure   14 Mar 2012 22:20:40 -  1.621.2.37.2.32
>   @@ -904,11 +904,11 @@
>   }
>   elsif (/^--with-fipsdir=(.*)$/)
>   {
>   -   $fipsdir="$1/";
>   +   $fipsdir="$1";
>   }
>   elsif (/^--with-fipslibdir=(.*)$/)
>   {
>   -   $fipslibdir="$1/";
>   +   $fipslibdir="$1";
>   }
>   elsif (/^--with-baseaddr=(.*)$/)
>   {
>   @@ .
> __
> OpenSSL Project http://www.openssl.org
> CVS Repository Commit List openssl-...@openssl.org
> Automated List Manager   majord...@openssl.org
> 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread William A. Rowe Jr.
On 3/14/2012 12:27 PM, Bruce Stephens wrote:
> open...@master.openssl.org (OpenSSL) writes:
> 
> [...]
> 
>>   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
> 
> I note that #2741 appears not to be resolved, so if you build on Windows
> and use --with-fipsdir=... then that probably won't work.

Recall, you can patch around the OpenSSL project compilation.

You cannot patch around the OpenSSL/FIPS 2.0[future] package compilation.
So this issue probably isn't fatal.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Mike Frysinger
On Wednesday 14 March 2012 19:23:14 Dr. Stephen Henson wrote:
> On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > i'm not looking for downstream workarounds here but rather the right
> > answer. is openssl-1.0.1 expected to be ABI compatible with
> > openssl-1.0.0 ?
> 
> Yes. In brief the versioning scheme introduced with 1.0.0 is:
> 
> Changes to last letter: security and bugfix only, no new features.
> E.g.  1.0.0->1.0.0a
> Changes to last number: new ABI compatible features.
> E.g. 1.0.0->1.0.1
> Changes to middle number: major release, ABI compatibility not guaranteed.
> E.g. 1.0.0->1.1.0
> 
> This is the first "feature release" that has been done since he versioning
> scheme changed so there may be some issues to iron out...

thanks.  i've posted a report for the openssh guys.
https://bugzilla.mindrot.org/show_bug.cgi?id=1991
-mike


signature.asc
Description: This is a digitally signed message part.


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Richard Levitte
I've looked at that, and the modes part is quite integral to a number
of other algorithms.  Supporting it being turned off is likely to be a
maintainance nightmare (especially since it will seldom blow up
considering most platforms today have a C compiler that supports long
long).

My conclusion is that we should stop trying to support compilers that
don't support long long.  Unfortunately for VAX, it means that we have
to stop supporting that, unless you know of a compiler that supports
long long on that platform.

Cheers,
Richard

In message  on Wed, 14 Mar 
2012 17:14:52 +0100, Arpadffy Zoltan  said:

Zoltan.Arpadffy> Hello,
Zoltan.Arpadffy> 
Zoltan.Arpadffy> Thank you very much for 1.0.1 release.
Zoltan.Arpadffy> 
Zoltan.Arpadffy> It builds and works perfect on OpenVMS Alpha and IA64 
architectures - as long I could test it.
Zoltan.Arpadffy> 
Zoltan.Arpadffy> Unfortunately, it is still not possible to build on VAX 
architecture, because the "[openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS 
issues on VAX" is sill not solved.
Zoltan.Arpadffy> 
Zoltan.Arpadffy> Thank you.
Zoltan.Arpadffy> 
Zoltan.Arpadffy> Regards,
Zoltan.Arpadffy> Z
Zoltan.Arpadffy> 
Zoltan.Arpadffy> -Original Message-
Zoltan.Arpadffy> From: OpenSSL [mailto:open...@master.openssl.org]
Zoltan.Arpadffy> Sent: den 14 mars 2012 16:09
Zoltan.Arpadffy> To: openssl-annou...@master.openssl.org; 
openssl-...@master.openssl.org; openssl-us...@master.openssl.org
Zoltan.Arpadffy> Subject: OpenSSL 1.0.1 released
Zoltan.Arpadffy> 
Zoltan.Arpadffy> -BEGIN PGP SIGNED MESSAGE-
Zoltan.Arpadffy> Hash: SHA1
Zoltan.Arpadffy> 
Zoltan.Arpadffy> 
Zoltan.Arpadffy>OpenSSL version 1.0.1 released
Zoltan.Arpadffy>===
Zoltan.Arpadffy> 
Zoltan.Arpadffy>OpenSSL - The Open Source toolkit for SSL/TLS
Zoltan.Arpadffy>http://www.openssl.org/
Zoltan.Arpadffy> 
Zoltan.Arpadffy>The OpenSSL project team is pleased to announce the release 
of
Zoltan.Arpadffy>version 1.0.1 of our open source toolkit for SSL/TLS. This 
new
Zoltan.Arpadffy>OpenSSL version is a new feature release. For a complete
Zoltan.Arpadffy>list of changes, please see
Zoltan.Arpadffy> 
Zoltan.Arpadffy>http://www.openssl.org/source/exp/CHANGES.
Zoltan.Arpadffy> 
Zoltan.Arpadffy>The most significant changes are:
Zoltan.Arpadffy> 
Zoltan.Arpadffy>   o TLS/DTLS heartbeat support.
Zoltan.Arpadffy>   o SCTP support.
Zoltan.Arpadffy>   o RFC 5705 TLS key material exporter.
Zoltan.Arpadffy>   o RFC 5764 DTLS-SRTP negotiation.
Zoltan.Arpadffy>   o Next Protocol Negotiation.
Zoltan.Arpadffy>   o PSS signatures in certificates, requests and CRLs.
Zoltan.Arpadffy>   o Support for password based recipient info for CMS.
Zoltan.Arpadffy>   o Support TLS v1.2 and TLS v1.1.
Zoltan.Arpadffy>   o Preliminary FIPS capability for unvalidated 2.0 FIPS 
module.
Zoltan.Arpadffy>   o SRP support.
Zoltan.Arpadffy> 
Zoltan.Arpadffy>We consider OpenSSL 1.0.1 to be the best version of OpenSSL
Zoltan.Arpadffy>available and we strongly recommend that users of older 
versions
Zoltan.Arpadffy>upgrade as soon as possible. OpenSSL 1.0.1 is available for
Zoltan.Arpadffy>download via HTTP and FTP from the following master 
locations (you
Zoltan.Arpadffy>can find the various FTP mirrors under
Zoltan.Arpadffy>http://www.openssl.org/source/mirror.html):
Zoltan.Arpadffy> 
Zoltan.Arpadffy>  * http://www.openssl.org/source/
Zoltan.Arpadffy>  * ftp://ftp.openssl.org/source/
Zoltan.Arpadffy> 
Zoltan.Arpadffy>The distribution file name is:
Zoltan.Arpadffy> 
Zoltan.Arpadffy> o openssl-1.0.1.tar.gz
Zoltan.Arpadffy>   Size: 4453920
Zoltan.Arpadffy>   MD5 checksum: 134f168bc2a8333f19f81d684841710b
Zoltan.Arpadffy>   SHA1 checksum: a6476d33fd38c2e7dfb438d1e3be178cc242c907
Zoltan.Arpadffy> 
Zoltan.Arpadffy>The checksums were calculated using the following commands:
Zoltan.Arpadffy> 
Zoltan.Arpadffy> openssl md5 openssl-1.0.1.tar.gz
Zoltan.Arpadffy> openssl sha1 openssl-1.0.1.tar.gz
Zoltan.Arpadffy> 
Zoltan.Arpadffy>Yours,
Zoltan.Arpadffy> 
Zoltan.Arpadffy>The OpenSSL Project Team.
Zoltan.Arpadffy> 
Zoltan.Arpadffy> -BEGIN PGP SIGNATURE-
Zoltan.Arpadffy> Version: GnuPG v1.4.11 (GNU/Linux)
Zoltan.Arpadffy> 
Zoltan.Arpadffy> 
iQEVAwUBT2CkBKLSm3vylcdZAQJv6wgAmrvhkXBB0rOI2Yt5YkgShq7BqqogFJk7
Zoltan.Arpadffy> 
TBCHP6gR133L08e+WibwLc3HZS8eU2oAyyOYjBiTjO2Dyg5jkkslku2pyX9R8iZd
Zoltan.Arpadffy> 
vb0k/ZTuzmNO/6dDYwejbYdLjrPmTKWrcofa9GooWhiFBOzi3fbY0pAIWjHBoY07
Zoltan.Arpadffy> 
LK8HxVzqQ+v/fg3ingqNpD5qJ6y13i4S8wzMPRL/4ox3evRSsEZ2ZTRqCfxwIbQk
Zoltan.Arpadffy> 
hZHfNL2sCZ+i/BoPKYxezhRweftDKQJtAm17femzymbQ0NVZfKi2i4kcd0GXS4Ow
Zoltan.Arpadffy> eaeMwpXdAGDGcj/HzaqxH1lEkKDQB+H9fo9MT2gqawjntiRt6K/oyQ==
Zoltan.Arpadffy> =yHMc
Zoltan.Arpadffy> -END PGP SIGNATURE-
Zoltan.Arpadffy> 
__
Zoltan.Arpadffy> O

Re: OpenSSL 1.0.1 released

2012-03-14 Thread Dr. Stephen Henson
On Wed, Mar 14, 2012, Iain Morgan wrote:

> On Wed, Mar 14, 2012 at 10:09:22 -0500, OpenSSL wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > 
> >We consider OpenSSL 1.0.1 to be the best version of OpenSSL
> >available and we strongly recommend that users of older versions
> >upgrade as soon as possible. OpenSSL 1.0.1 is available for
> >download via HTTP and FTP from the following master locations (you
> >can find the various FTP mirrors under
> >http://www.openssl.org/source/mirror.html):
> > 
> >  * http://www.openssl.org/source/
> >  * ftp://ftp.openssl.org/source/
> > 
> 
> It seems to be missing from the FTP site.
> 

Ooops, fixed now.

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Iain Morgan
On Wed, Mar 14, 2012 at 10:09:22 -0500, OpenSSL wrote:
> -BEGIN PGP SIGNED MESSAGE-
> 
>We consider OpenSSL 1.0.1 to be the best version of OpenSSL
>available and we strongly recommend that users of older versions
>upgrade as soon as possible. OpenSSL 1.0.1 is available for
>download via HTTP and FTP from the following master locations (you
>can find the various FTP mirrors under
>http://www.openssl.org/source/mirror.html):
> 
>  * http://www.openssl.org/source/
>  * ftp://ftp.openssl.org/source/
> 

It seems to be missing from the FTP site.

-- 
Iain Morgan

PS: Contrats (and thanks) on releasing 1.0.1!
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Dr. Stephen Henson
On Wed, Mar 14, 2012, Mike Frysinger wrote:

> 
> i'm not looking for downstream workarounds here but rather the right answer.  
> is openssl-1.0.1 expected to be ABI compatible with openssl-1.0.0 ?
>

Yes. In brief the versioning scheme introduced with 1.0.0 is:

Changes to last letter: security and bugfix only, no new features.
E.g.  1.0.0->1.0.0a
Changes to last number: new ABI compatible features.
E.g. 1.0.0->1.0.1
Changes to middle number: major release, ABI compatibility not guaranteed.
E.g. 1.0.0->1.1.0

This is the first "feature release" that has been done since he versioning
scheme changed so there may be some issues to iron out...

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Mike Frysinger
On Wednesday 14 March 2012 17:18:19 Kurt Roeckx wrote:
> On Wed, Mar 14, 2012 at 02:30:29PM -0400, Mike Frysinger wrote:
> > On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> > > On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > > > On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
> > > > >OpenSSL version 1.0.1 released
> > > > >===
> > > > >
> > > > >http://www.openssl.org/source/exp/CHANGES.
> > > > >
> > > > >The most significant changes are:
> > > > >   o TLS/DTLS heartbeat support.
> > > > >   o SCTP support.
> > > > >   o RFC 5705 TLS key material exporter.
> > > > >   o RFC 5764 DTLS-SRTP negotiation.
> > > > >   o Next Protocol Negotiation.
> > > > >   o PSS signatures in certificates, requests and CRLs.
> > > > >   o Support for password based recipient info for CMS.
> > > > >   o Support TLS v1.2 and TLS v1.1.
> > > > >   o Preliminary FIPS capability for unvalidated 2.0 FIPS
> > > > >   module. o SRP support.
> > > > 
> > > > i don't see mention of ABI compat changes, and it seems to not be
> > > > compatible. did someone forget to update the version string in
> > > > crypto/opensslv.h ?  it still says "1.0.0" ...
> > > 
> > > Can you be more specific about "seems to not be compatible".
> > 
> > if the versions were compatible, there should be no warning when running
> > apps
> > 
> > with openssl-1.0.1 that were built against openssl-1.0.0*.  but there is:
> > OpenSSL version mismatch. Built against 105f, you have 1000100f
> 
> As far as I know, we disabled most such checks in Debian because
> they're not really useful.  I can change the ABI without changing
> the version, or have the same ABI with a different version.  If
> it's not compatible the soname should have changed.  The
> appliation shouldn't go and second guess that it's really
> compatible or not.
> 
> And if the soname stays the same but the ABI is not compatible, we
> also have ways to deal with that.

i'm not looking for downstream workarounds here but rather the right answer.  
is openssl-1.0.1 expected to be ABI compatible with openssl-1.0.0 ?  there was 
nothing in the notes that i saw, and this is a significant change in behavior 
from how openssl has loong operated.  and it wouldn't be the first time 
that a new openssl release had bugs in it including forgetting to update the 
version number (which i've reported before) or can't even compile for some 
targets due to files missing from the release tarball.

if, indeed, openssl has started down the enlightened ABI compatible path, then 
i can work on fixing relevant packages that do runtime version sanity checks 
such as openssh.  but i haven't heard an answer in either direction as to the 
openssl behavior: "it's a bug" or "it's correct behavior".
-mike


signature.asc
Description: This is a digitally signed message part.


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Dr. Stephen Henson
On Wed, Mar 14, 2012, Bruce Stephens wrote:

> open...@master.openssl.org (OpenSSL) writes:
> 
> [...]
> 
> >   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
> 
> I note that #2741 appears not to be resolved, so if you build on Windows
> and use --with-fipsdir=... then that probably won't work.
> 
> [...]

Opps, that's something for 1.0.1a anyway...

The alternative of using the FIPSDIR environment variable (you have to use
that with the FIPS module anyway) should be OK though.

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Bruce Stephens
open...@master.openssl.org (OpenSSL) writes:

[...]

>   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.

I note that #2741 appears not to be resolved, so if you build on Windows
and use --with-fipsdir=... then that probably won't work.

[...]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Kurt Roeckx
On Wed, Mar 14, 2012 at 02:30:29PM -0400, Mike Frysinger wrote:
> On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> > On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > > On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
> > > >OpenSSL version 1.0.1 released
> > > >===
> > > >
> > > >http://www.openssl.org/source/exp/CHANGES.
> > > >
> > > >The most significant changes are:
> > > >   o TLS/DTLS heartbeat support.
> > > >   o SCTP support.
> > > >   o RFC 5705 TLS key material exporter.
> > > >   o RFC 5764 DTLS-SRTP negotiation.
> > > >   o Next Protocol Negotiation.
> > > >   o PSS signatures in certificates, requests and CRLs.
> > > >   o Support for password based recipient info for CMS.
> > > >   o Support TLS v1.2 and TLS v1.1.
> > > >   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
> > > >   o SRP support.
> > > 
> > > i don't see mention of ABI compat changes, and it seems to not be
> > > compatible. did someone forget to update the version string in
> > > crypto/opensslv.h ?  it still says "1.0.0" ...
> > 
> > Can you be more specific about "seems to not be compatible".
> 
> if the versions were compatible, there should be no warning when running apps 
> with openssl-1.0.1 that were built against openssl-1.0.0*.  but there is:
>   OpenSSL version mismatch. Built against 105f, you have 1000100f

As far as I know, we disabled most such checks in Debian because
they're not really useful.  I can change the ABI without changing
the version, or have the same ABI with a different version.  If
it's not compatible the soname should have changed.  The
appliation shouldn't go and second guess that it's really
compatible or not.

And if the soname stays the same but the ABI is not compatible, we
also have ways to deal with that.


Kurt

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Mike Frysinger
On Wednesday 14 March 2012 14:36:09 Dr. Stephen Henson wrote:
> On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> > > On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > > > On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
> > > > >OpenSSL version 1.0.1 released
> > > > >===
> > > > >
> > > > >http://www.openssl.org/source/exp/CHANGES.
> > > > >
> > > > >The most significant changes are:
> > > > >   o TLS/DTLS heartbeat support.
> > > > >   o SCTP support.
> > > > >   o RFC 5705 TLS key material exporter.
> > > > >   o RFC 5764 DTLS-SRTP negotiation.
> > > > >   o Next Protocol Negotiation.
> > > > >   o PSS signatures in certificates, requests and CRLs.
> > > > >   o Support for password based recipient info for CMS.
> > > > >   o Support TLS v1.2 and TLS v1.1.
> > > > >   o Preliminary FIPS capability for unvalidated 2.0 FIPS
> > > > >   module. o SRP support.
> > > > 
> > > > i don't see mention of ABI compat changes, and it seems to not be
> > > > compatible. did someone forget to update the version string in
> > > > crypto/opensslv.h ?  it still says "1.0.0" ...
> > > 
> > > Can you be more specific about "seems to not be compatible".
> > 
> > if the versions were compatible, there should be no warning when running
> > apps
> > 
> > with openssl-1.0.1 that were built against openssl-1.0.0*.  but there is:
> > OpenSSL version mismatch. Built against 105f, you have 1000100f
> 
> What is producing that warning?

$ ssh-keygen -l
OpenSSL version mismatch. Built against 105f, you have 1000100f
-mike


signature.asc
Description: This is a digitally signed message part.


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Tomas Mraz
On Wed, 2012-03-14 at 19:36 +0100, Dr. Stephen Henson wrote: 
> On Wed, Mar 14, 2012, Mike Frysinger wrote:
> 
> > On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> > > On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > > > On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
> > > > >OpenSSL version 1.0.1 released
> > > > >===
> > > > >
> > > > >http://www.openssl.org/source/exp/CHANGES.
> > > > >
> > > > >The most significant changes are:
> > > > >   o TLS/DTLS heartbeat support.
> > > > >   o SCTP support.
> > > > >   o RFC 5705 TLS key material exporter.
> > > > >   o RFC 5764 DTLS-SRTP negotiation.
> > > > >   o Next Protocol Negotiation.
> > > > >   o PSS signatures in certificates, requests and CRLs.
> > > > >   o Support for password based recipient info for CMS.
> > > > >   o Support TLS v1.2 and TLS v1.1.
> > > > >   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
> > > > >   o SRP support.
> > > > 
> > > > i don't see mention of ABI compat changes, and it seems to not be
> > > > compatible. did someone forget to update the version string in
> > > > crypto/opensslv.h ?  it still says "1.0.0" ...
> > > 
> > > Can you be more specific about "seems to not be compatible".
> > 
> > if the versions were compatible, there should be no warning when running 
> > apps 
> > with openssl-1.0.1 that were built against openssl-1.0.0*.  but there is:
> > OpenSSL version mismatch. Built against 105f, you have 1000100f
> 
> What is producing that warning?

This is a problem of the applications (OpenSSH, postgresql,) that do
not expect different versions of openssl to be ABI compatible. They
compare the version that they were compiled against to the version
reported by the library. They usually ignore only the patch level number
(abcde...). We had to patch the version number in the library to stay
constant. I suppose these applications should have the version check
removed as it is not guaranteed to work anyway as the ABI of openssl
depends also on the compiled-in ciphers and other compile time options.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Dr. Stephen Henson
On Wed, Mar 14, 2012, Mike Frysinger wrote:

> On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> > On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > > On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
> > > >OpenSSL version 1.0.1 released
> > > >===
> > > >
> > > >http://www.openssl.org/source/exp/CHANGES.
> > > >
> > > >The most significant changes are:
> > > >   o TLS/DTLS heartbeat support.
> > > >   o SCTP support.
> > > >   o RFC 5705 TLS key material exporter.
> > > >   o RFC 5764 DTLS-SRTP negotiation.
> > > >   o Next Protocol Negotiation.
> > > >   o PSS signatures in certificates, requests and CRLs.
> > > >   o Support for password based recipient info for CMS.
> > > >   o Support TLS v1.2 and TLS v1.1.
> > > >   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
> > > >   o SRP support.
> > > 
> > > i don't see mention of ABI compat changes, and it seems to not be
> > > compatible. did someone forget to update the version string in
> > > crypto/opensslv.h ?  it still says "1.0.0" ...
> > 
> > Can you be more specific about "seems to not be compatible".
> 
> if the versions were compatible, there should be no warning when running apps 
> with openssl-1.0.1 that were built against openssl-1.0.0*.  but there is:
>   OpenSSL version mismatch. Built against 105f, you have 1000100f

What is producing that warning?

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Mike Frysinger
On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
> > >OpenSSL version 1.0.1 released
> > >===
> > >
> > >http://www.openssl.org/source/exp/CHANGES.
> > >
> > >The most significant changes are:
> > >   o TLS/DTLS heartbeat support.
> > >   o SCTP support.
> > >   o RFC 5705 TLS key material exporter.
> > >   o RFC 5764 DTLS-SRTP negotiation.
> > >   o Next Protocol Negotiation.
> > >   o PSS signatures in certificates, requests and CRLs.
> > >   o Support for password based recipient info for CMS.
> > >   o Support TLS v1.2 and TLS v1.1.
> > >   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
> > >   o SRP support.
> > 
> > i don't see mention of ABI compat changes, and it seems to not be
> > compatible. did someone forget to update the version string in
> > crypto/opensslv.h ?  it still says "1.0.0" ...
> 
> Can you be more specific about "seems to not be compatible".

if the versions were compatible, there should be no warning when running apps 
with openssl-1.0.1 that were built against openssl-1.0.0*.  but there is:
OpenSSL version mismatch. Built against 105f, you have 1000100f
-mike


signature.asc
Description: This is a digitally signed message part.


Re: 1.0.0h apps/s_client.c mystery

2012-03-14 Thread Steven M. Schweda
From: Richard Levitte 

> sms>I was thinking more like:
> [...]
> sms>  if (cipher)
> sms>  {
> sms>  if (strcmp( cipher, "PSK"))
> sms>  {
> sms>  BIO_printf(bio_err,
> sms>   "JPAKE sets cipher to PSK\n");
> sms>  goto end;
> sms>  }
> sms>  }
> sms>  else
> sms>  {
> sms>  cipher = "PSK";
> sms>  }
> sms>  }
> sms> #endif
> 
> That's functionally the same, isn't it?

   Not if "cipher" was already set to "PSK" before arriving here. 
As-was, if "cipher" was non-NULL, you got the fatal error.  My way is
intended to allow "cipher" to be previously set to "PSK", not only unset
to anything (NULL).

> ... and writing an internal application library that takes care of the
> diversity, yeah I'm with you there.

   With a lot of work, someone could make a regular program out of this
thing.

> s_client is basically supposed to work like telnet (minus the telnet
> features plus the ssl features), so it's not much of a surprise that
> it gives you as much a prompt as telnet does.

   Does Telnet do local echoing of victim input?

> I find it weird that the particular \n there would fail...  isn't that
> something that C library is supposed to deal with properly?  Of
> course, s_client uses BIO_printf(), but that one in turn uses the
> usual C library...  so it's to wonder why \n wouldn't work in that
> particular spot.  I'll have to see if I can reproduce it.

   There's a lot of fine print.  As usual, everything's complicated.



   Steven M. Schweda   sms@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Dr. Stephen Henson
On Wed, Mar 14, 2012, Mike Frysinger wrote:

> On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
> >OpenSSL version 1.0.1 released
> >===
> > 
> >http://www.openssl.org/source/exp/CHANGES.
> > 
> >The most significant changes are:
> > 
> >   o TLS/DTLS heartbeat support.
> >   o SCTP support.
> >   o RFC 5705 TLS key material exporter.
> >   o RFC 5764 DTLS-SRTP negotiation.
> >   o Next Protocol Negotiation.
> >   o PSS signatures in certificates, requests and CRLs.
> >   o Support for password based recipient info for CMS.
> >   o Support TLS v1.2 and TLS v1.1.
> >   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
> >   o SRP support.
> 
> i don't see mention of ABI compat changes, and it seems to not be compatible. 
>  
> did someone forget to update the version string in crypto/opensslv.h ?  it 
> still says "1.0.0" ...

Can you be more specific about "seems to not be compatible".

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Mike Frysinger
On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
>OpenSSL version 1.0.1 released
>===
> 
>http://www.openssl.org/source/exp/CHANGES.
> 
>The most significant changes are:
> 
>   o TLS/DTLS heartbeat support.
>   o SCTP support.
>   o RFC 5705 TLS key material exporter.
>   o RFC 5764 DTLS-SRTP negotiation.
>   o Next Protocol Negotiation.
>   o PSS signatures in certificates, requests and CRLs.
>   o Support for password based recipient info for CMS.
>   o Support TLS v1.2 and TLS v1.1.
>   o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
>   o SRP support.

i don't see mention of ABI compat changes, and it seems to not be compatible.  
did someone forget to update the version string in crypto/opensslv.h ?  it 
still says "1.0.0" ...
-mike


signature.asc
Description: This is a digitally signed message part.


Re: OpenSSL 1.0.1 released

2012-03-14 Thread Andy Polyakov
> Unfortunately, it is still not possible to build on VAX architecture,
> because the "[openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS issues
> on VAX" is sill not solved.

http://www.mail-archive.com/openssl-dev@openssl.org/msg29956.html
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


RE: OpenSSL 1.0.1 released

2012-03-14 Thread Arpadffy Zoltan
Hello,

Thank you very much for 1.0.1 release.

It builds and works perfect on OpenVMS Alpha and IA64 architectures - as long I 
could test it.

Unfortunately, it is still not possible to build on VAX architecture, because 
the "[openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS issues on VAX" is sill not 
solved.

Thank you.

Regards,
Z

-Original Message-
From: OpenSSL [mailto:open...@master.openssl.org]
Sent: den 14 mars 2012 16:09
To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; 
openssl-us...@master.openssl.org
Subject: OpenSSL 1.0.1 released

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 1.0.1 released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.1 of our open source toolkit for SSL/TLS. This new
   OpenSSL version is a new feature release. For a complete
   list of changes, please see

   http://www.openssl.org/source/exp/CHANGES.

   The most significant changes are:

  o TLS/DTLS heartbeat support.
  o SCTP support.
  o RFC 5705 TLS key material exporter.
  o RFC 5764 DTLS-SRTP negotiation.
  o Next Protocol Negotiation.
  o PSS signatures in certificates, requests and CRLs.
  o Support for password based recipient info for CMS.
  o Support TLS v1.2 and TLS v1.1.
  o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
  o SRP support.

   We consider OpenSSL 1.0.1 to be the best version of OpenSSL
   available and we strongly recommend that users of older versions
   upgrade as soon as possible. OpenSSL 1.0.1 is available for
   download via HTTP and FTP from the following master locations (you
   can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

 * http://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.0.1.tar.gz
  Size: 4453920
  MD5 checksum: 134f168bc2a8333f19f81d684841710b
  SHA1 checksum: a6476d33fd38c2e7dfb438d1e3be178cc242c907

   The checksums were calculated using the following commands:

openssl md5 openssl-1.0.1.tar.gz
openssl sha1 openssl-1.0.1.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBT2CkBKLSm3vylcdZAQJv6wgAmrvhkXBB0rOI2Yt5YkgShq7BqqogFJk7
TBCHP6gR133L08e+WibwLc3HZS8eU2oAyyOYjBiTjO2Dyg5jkkslku2pyX9R8iZd
vb0k/ZTuzmNO/6dDYwejbYdLjrPmTKWrcofa9GooWhiFBOzi3fbY0pAIWjHBoY07
LK8HxVzqQ+v/fg3ingqNpD5qJ6y13i4S8wzMPRL/4ox3evRSsEZ2ZTRqCfxwIbQk
hZHfNL2sCZ+i/BoPKYxezhRweftDKQJtAm17femzymbQ0NVZfKi2i4kcd0GXS4Ow
eaeMwpXdAGDGcj/HzaqxH1lEkKDQB+H9fo9MT2gqawjntiRt6K/oyQ==
=yHMc
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: 1.0.0h apps/s_client.c mystery

2012-03-14 Thread Richard Levitte
In message <12031409093019_20200...@antinode.info> on Wed, 14 Mar 2012 09:09:30 
-0500 (CDT), "Steven M. Schweda"  said:

sms> From: Richard Levitte 
sms> 
sms> > Of course not...  it should be as you mentioned...
sms> > [...]
sms> 
sms>I was thinking more like:
sms> 
sms> #if !defined(OPENSSL_NO_JPAKE) && !defined(OPENSSL_NO_PSK)
sms>if (jpake_secret)
sms>{
sms>if (psk_key)
sms>{
sms>BIO_printf(bio_err,
sms>   "Can't use JPAKE and PSK together\n");
sms>goto end;
sms>}
sms>psk_identity = "JPAKE";
sms> 
sms>if (cipher)
sms>{
sms>if (strcmp( cipher, "PSK"))
sms>{
sms>BIO_printf(bio_err,
sms> "JPAKE sets cipher to PSK\n");
sms>goto end;
sms>}
sms>}
sms>else
sms>{
sms>cipher = "PSK";
sms>}
sms>}
sms> #endif

That's functionally the same, isn't it?

sms>But, if I had a fatal message like that, I'd probably want to tell the
sms> victim what the bad "cipher" value was, and that JPAKE demands that it
sms> be "PSK".  Saying "JPAKE sets cipher to PSK", and then dying without
sms> actually setting "cipher" to anything seems misleading to me.

I agree.  However, JPAKE is considered experimental and should not be
enabled by default (that's a mistake in the VMS build, I'm working on
that right now (*)).

sms> > There's a fix in newer OpenSSL versions, with a variant for BeOS R5
sms> > that tries reading stdin in non-blocking mode to see if there's
sms> > anything there...  I'm just now seeing if that can be hijacked for VMS
sms> > as well, in that case I think we're good to go for a back port.
sms> 
sms>There are VMS-specific terminal things which can be done, but, with
sms> the existing lack of descriptive comments in this code, it's not obvious
sms> (to a non-Windows/non-BEOS programmer) what the desired behavior is in
sms> some of these places.  For that matter, simply defining _functional_
sms> macros, like, say, SELECT_WORKS_ON_FILES, and then defining _those_
sms> based on system type, might help someone who's trying to support a new
sms> system type.

... and writing an internal application library that takes care of the
diversity, yeah I'm with you there.

sms> > The first change (an extra \n) seem to be cosmetic only, or does it
sms> > actually change the function in a crutial way?  Considering you have
sms> > marked it optional, I'll guess that it doesn't?
sms> 
sms>I know nothing, but in my playing around, the last line I got before
sms> the program got stuck was "---", with the cursor resting over the
sms> left-most "-".  I suspect that the extra "\n" was intended to get the
sms> cursor onto its own line, below the "---" line.  Considering how
sms> differently VMS handles terminal I/O (CR, LF, et c.), I would not bet
sms> that any of this stuff would actually look right (without some extra
sms> effort, anyway).  Of course, I'm not overly fond of programs which wait
sms> for user input without putting out an obvious prompt first, so what's my
sms> opinion worth?

s_client is basically supposed to work like telnet (minus the telnet
features plus the ssl features), so it's not much of a surprise that
it gives you as much a prompt as telnet does.

I find it weird that the particular \n there would fail...  isn't that
something that C library is supposed to deal with properly?  Of
course, s_client uses BIO_printf(), but that one in turn uses the
usual C library...  so it's to wonder why \n wouldn't work in that
particular spot.  I'll have to see if I can reproduce it.

-- 
Richard Levitte rich...@levitte.org
http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


OpenSSL 1.0.1 released

2012-03-14 Thread OpenSSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 1.0.1 released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.1 of our open source toolkit for SSL/TLS. This new
   OpenSSL version is a new feature release. For a complete
   list of changes, please see

   http://www.openssl.org/source/exp/CHANGES.

   The most significant changes are:

  o TLS/DTLS heartbeat support.
  o SCTP support.
  o RFC 5705 TLS key material exporter.
  o RFC 5764 DTLS-SRTP negotiation.
  o Next Protocol Negotiation.
  o PSS signatures in certificates, requests and CRLs.
  o Support for password based recipient info for CMS.
  o Support TLS v1.2 and TLS v1.1.
  o Preliminary FIPS capability for unvalidated 2.0 FIPS module.
  o SRP support.

   We consider OpenSSL 1.0.1 to be the best version of OpenSSL
   available and we strongly recommend that users of older versions
   upgrade as soon as possible. OpenSSL 1.0.1 is available for
   download via HTTP and FTP from the following master locations (you
   can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

 * http://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.0.1.tar.gz
  Size: 4453920
  MD5 checksum: 134f168bc2a8333f19f81d684841710b
  SHA1 checksum: a6476d33fd38c2e7dfb438d1e3be178cc242c907

   The checksums were calculated using the following commands:

openssl md5 openssl-1.0.1.tar.gz
openssl sha1 openssl-1.0.1.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBT2CkBKLSm3vylcdZAQJv6wgAmrvhkXBB0rOI2Yt5YkgShq7BqqogFJk7
TBCHP6gR133L08e+WibwLc3HZS8eU2oAyyOYjBiTjO2Dyg5jkkslku2pyX9R8iZd
vb0k/ZTuzmNO/6dDYwejbYdLjrPmTKWrcofa9GooWhiFBOzi3fbY0pAIWjHBoY07
LK8HxVzqQ+v/fg3ingqNpD5qJ6y13i4S8wzMPRL/4ox3evRSsEZ2ZTRqCfxwIbQk
hZHfNL2sCZ+i/BoPKYxezhRweftDKQJtAm17femzymbQ0NVZfKi2i4kcd0GXS4Ow
eaeMwpXdAGDGcj/HzaqxH1lEkKDQB+H9fo9MT2gqawjntiRt6K/oyQ==
=yHMc
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: 1.0.0h apps/s_client.c mystery

2012-03-14 Thread Steven M. Schweda
From: Richard Levitte 

> Of course not...  it should be as you mentioned...
> [...]

   I was thinking more like:

#if !defined(OPENSSL_NO_JPAKE) && !defined(OPENSSL_NO_PSK)
if (jpake_secret)
{
if (psk_key)
{
BIO_printf(bio_err,
   "Can't use JPAKE and PSK together\n");
goto end;
}
psk_identity = "JPAKE";

if (cipher)
{
if (strcmp( cipher, "PSK"))
{
BIO_printf(bio_err,
 "JPAKE sets cipher to PSK\n");
goto end;
}
}
else
{
cipher = "PSK";
}
}
#endif

   But, if I had a fatal message like that, I'd probably want to tell the
victim what the bad "cipher" value was, and that JPAKE demands that it
be "PSK".  Saying "JPAKE sets cipher to PSK", and then dying without
actually setting "cipher" to anything seems misleading to me.

> There's a fix in newer OpenSSL versions, with a variant for BeOS R5
> that tries reading stdin in non-blocking mode to see if there's
> anything there...  I'm just now seeing if that can be hijacked for VMS
> as well, in that case I think we're good to go for a back port.

   There are VMS-specific terminal things which can be done, but, with
the existing lack of descriptive comments in this code, it's not obvious
(to a non-Windows/non-BEOS programmer) what the desired behavior is in
some of these places.  For that matter, simply defining _functional_
macros, like, say, SELECT_WORKS_ON_FILES, and then defining _those_
based on system type, might help someone who's trying to support a new
system type.

> The first change (an extra \n) seem to be cosmetic only, or does it
> actually change the function in a crutial way?  Considering you have
> marked it optional, I'll guess that it doesn't?

   I know nothing, but in my playing around, the last line I got before
the program got stuck was "---", with the cursor resting over the
left-most "-".  I suspect that the extra "\n" was intended to get the
cursor onto its own line, below the "---" line.  Considering how
differently VMS handles terminal I/O (CR, LF, et c.), I would not bet
that any of this stuff would actually look right (without some extra
effort, anyway).  Of course, I'm not overly fond of programs which wait
for user input without putting out an obvious prompt first, so what's my
opinion worth?



   Steven M. Schweda   sms@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: 1.0.0h apps/s_client.c mystery

2012-03-14 Thread Richard Levitte
In message <20120314.114607.402413137.rich...@levitte.org> on Wed, 14 Mar 2012 
11:46:07 +0100 (CET), Richard Levitte  said:

richard> You're right, that code looks quite odd, the following should do
richard> better, wouldn't you say?

Of course not...  it should be as you mentioned...

#if !defined(OPENSSL_NO_JPAKE) &&  !defined(OPENSSL_NO_PSK)
if (jpake_secret)
{
if (psk_key)
{
BIO_printf(bio_err,
   "Can't use JPAKE and PSK together\n");
goto end;
}
psk_identity = "JPAKE";
if (cipher)
{
BIO_printf(bio_err, "JPAKE sets cipher to PSK\n");
goto end;
}
cipher = "PSK";
}
#endif

-- 
Richard Levitte rich...@levitte.org
http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Fixes to the VMS version(s) of OpenSSL

2012-03-14 Thread Richard Levitte
In message  on Mon, 12 Mar 2012 
07:02:10 -0400, Neil Rieck  said:

n.rieck> Team,
n.rieck> 
n.rieck>   * A few weeks back, I discovered a problem with the command “OpenSSL 
s_client” which (I think)
n.rieck> has been broken in VMS since 2006.
n.rieck>   * While I was only working with HP-specific OpenSSL source code kits 
available from the HP,  the
n.rieck> problem still exists in the public sources available from your 
site.
n.rieck>   * I have posted my changes to file “s_client.c” here:
n.rieck> 
http://www3.sympatico.ca/n.rieck/docs/openvms_notes_ssl.html#s_client-fix

Glaring things, that (miss)handling of select() on VMS, isn't it (or
well, VMS really misshandles select(), but that's another story)?
Your fixes really don't catch it all, there's this piece of code that
really is an issue:

#if defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_MSDOS)
#if defined(OPENSSL_SYS_WINCE) || defined(OPENSSL_SYS_MSDOS)
else if (_kbhit())
#else
else if ((_kbhit()) || (WAIT_OBJECT_0 == 
WaitForSingleObject(GetStdHandle(STD_INPUT_HANDLE), 0)))
#endif
#elif defined (OPENSSL_SYS_NETWARE)
else if (_kbhit())
#else
else if (FD_ISSET(fileno(stdin),&readfds))
#endif

There's a fix in newer OpenSSL versions, with a variant for BeOS R5
that tries reading stdin in non-blocking mode to see if there's
anything there...  I'm just now seeing if that can be hijacked for VMS
as well, in that case I think we're good to go for a back port.

The first change (an extra \n) seem to be cosmetic only, or does it
actually change the function in a crutial way?  Considering you have
marked it optional, I'll guess that it doesn't?

Cheers,
Richard

-- 
Richard Levitte rich...@levitte.org
http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: 1.0.0h apps/s_client.c mystery

2012-03-14 Thread Richard Levitte
In message <12031323361474_20200...@antinode.info> on Tue, 13 Mar 2012 23:36:14 
-0500 (CDT), "Steven M. Schweda"  said:

sms>Recent discussions on comp.os.vms of problems with apps/s_client.c on
sms> VMS systems led me to poke around a little.  Bearing in mind that I
sms> know approximately nothing about how apps/s_client.c should work, I seem
sms> to get the following complaint for no apparently good reason, whenever I
sms> try to specify a cipher:
sms> 
sms> JPAKE sets cipher to PSK
sms> 
sms>The relevant code in apps/s_client.c seems to be the following:
sms> 
sms> #if !defined(OPENSSL_NO_JPAKE) && !defined(OPENSSL_NO_PSK)
sms>if (jpake_secret)
sms>{
sms>if (psk_key)
sms>{
sms>BIO_printf(bio_err,
sms>   "Can't use JPAKE and PSK together\n");
sms>goto end;
sms>}
sms>psk_identity = "JPAKE";
sms>}
sms> 
sms>if (cipher)
sms>{
sms>BIO_printf(bio_err, "JPAKE sets cipher to PSK\n");
sms>goto end;
sms>}
sms>cipher = "PSK";
sms> #endif

You're right, that code looks quite odd, the following should do
better, wouldn't you say?

#if !defined(OPENSSL_NO_JPAKE)
if (jpake_secret)
{
# if !defined(OPENSSL_NO_PSK)
if (psk_key)
{
BIO_printf(bio_err,
   "Can't use JPAKE and PSK together\n");
goto end;
}
psk_identity = "JPAKE";
# endif
if (cipher)
{
BIO_printf(bio_err, "JPAKE sets cipher to PSK\n");
goto end;
}
cipher = "PSK";
}
#endif

sms>Note that the VMS builders currently enable JPAKE unconditionally,

Try this before building, should make a difference:

$ define OPENSSL_NO_JPAKE yes

sms>VMS is, by the way, another one of those systems where select() is
sms> good only on sockets, not on files, so a bunch of the
sms> Windows/MSDOS/et-al. conditionality in this and nearby modules probably
sms> needs to be extended to include VMS.

Good point.

Cheers,
Richard

-- 
Richard Levitte rich...@levitte.org
http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


[openssl.org #2760] possible bug report: DSA_verify() doesn't correctly account for len

2012-03-14 Thread Yusheng Yang via RT
/* crypto/dsa/dsatest.c */
/* Copyright (C) 1995-1998 Eric Young (e...@cryptsoft.com)
 * All rights reserved.
 *
 * This package is an SSL implementation written
 * by Eric Young (e...@cryptsoft.com).
 * The implementation was written so as to conform with Netscapes SSL.
 * 
 * This library is free for commercial and non-commercial use as long as
 * the following conditions are aheared to.  The following conditions
 * apply to all code found in this distribution, be it the RC4, RSA,
 * lhash, DES, etc., code; not just the SSL code.  The SSL documentation
 * included with this distribution is covered by the same copyright terms
 * except that the holder is Tim Hudson (t...@cryptsoft.com).
 * 
 * Copyright remains Eric Young's, and as such any Copyright notices in
 * the code are not to be removed.
 * If this package is used in a product, Eric Young should be given attribution
 * as the author of the parts of the library used.
 * This can be in the form of a textual message at program startup or
 * in documentation (online or textual) provided with the package.
 * 
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *must display the following acknowledgement:
 *"This product includes cryptographic software written by
 * Eric Young (e...@cryptsoft.com)"
 *The word 'cryptographic' can be left out if the rouines from the library
 *being used are not cryptographic related :-).
 * 4. If you include any Windows specific code (or a derivative thereof) from 
 *the apps directory (application code) you must include an acknowledgement:
 *"This product includes software written by Tim Hudson 
(t...@cryptsoft.com)"
 * 
 * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 * The licence and distribution terms for any publically available version or
 * derivative of this code cannot be changed.  i.e. this code cannot simply be
 * copied and put under another distribution licence
 * [including the GNU Public Licence.]
 */

/* Until the key-gen callbacks are modified to use newer prototypes, we allow
 * deprecated functions for openssl-internal code */
#ifdef OPENSSL_NO_DEPRECATED
#undef OPENSSL_NO_DEPRECATED
#endif

#include 
#include 
#include 
#include 
#include 

#include "../e_os.h"

#include 
#include 
#include 
#include 
#include 

#ifdef OPENSSL_NO_DSA
int main(int argc, char *argv[])
{
printf("No DSA support\n");
return(0);
}
#else
#include 
#include 

#ifdef OPENSSL_SYS_WIN16
#define MS_CALLBACK _far _loadds
#else
#define MS_CALLBACK
#endif

static int MS_CALLBACK dsa_cb(int p, int n, BN_GENCB *arg);

/* seed, out_p, out_q, out_g are taken from the updated Appendix 5 to
 * FIPS PUB 186 and also appear in Appendix 5 to FIPS PIB 186-1 */
static unsigned char seed[20]={
0xd5,0x01,0x4e,0x4b,0x60,0xef,0x2b,0xa8,0xb6,0x21,0x1b,0x40,
0x62,0xba,0x32,0x24,0xe0,0x42,0x7d,0xd3,
};

static unsigned char out_p[]={
0x8d,0xf2,0xa4,0x94,0x49,0x22,0x76,0xaa,
0x3d,0x25,0x75,0x9b,0xb0,0x68,0x69,0xcb,
0xea,0xc0,0xd8,0x3a,0xfb,0x8d,0x0c,0xf7,
0xcb,0xb8,0x32,0x4f,0x0d,0x78,0x82,0xe5,
0xd0,0x76,0x2f,0xc5,0xb7,0x21,0x0e,0xaf,
0xc2,0xe9,0xad,0xac,0x32,0xab,0x7a,0xac,
0x49,0x69,0x3d,0xfb,0xf8,0x37,0x24,0xc2,
0xec,0x07,0x36,0xee,0x31,0xc8,0x02,0x91,
};

static unsigned char out_q[]={
0xc7,0x73,0x21,0x8c,0x73,0x7e,0xc8,0xee,
0x99,0x3b,0x4f,0x2d,0xed,0x30,0xf4,0x8e,
0xda,0xce,0x91,0x5f,
};

static unsigned char out_g[]={
0x62,0x6d,0x02,0x78,0x39,0xea,0x0a,0x13,
0x41,0x31,0x63,0xa5,0x5b,0x4c,0xb5,0x00,
0x29,0x9d,0x55,0x22,0x95,0x6c,0xef,0xcb,
0x3b,0xff,0x10,0xf3,0x99,0xce,0x2c,0x2e,
0x71,0xcb,0x9d,0xe5,0xfa,0x24,0xba,0xbf,
 

[openssl.org #2759] SSL_read / SSL_ERROR_WANT_READ / ENOTCONN infinite loop

2012-03-14 Thread Steven Parkes via RT
Type: bug report
OS: iOS (but may affect other platforms, mobile in particular)
OpenSSL versions: confirmed in 1.0.0.h and 1.0.1 Beta 3

Bug:

int BIO_sock_non_fatal_error(int err) in crypto/bio/bss_sock.c returns 1 for 
ENOTCONN which causes SSL_read to return SSL_ERROR_WANT_READ.  In at least some 
cases, ENOTCONN is fatal. In those cases, the SSL_read caller (in my case, 
libcurl), ends up calling SSL_read infinitely.

This occurs repeatably on iOS and possibly other mobile platforms which tend to 
tear down socket connections if an app becomes inactive.

My workaround has been simply not to include ENOTCONN in the non-fatal codes. 
This doesn't have any negative side effects in my testing but I'm not sure if 
it might in general. I don't know enough whether ENOTCONN might be validly 
returned before TCP handshaking has finished and if, in that case, if the flow 
of SSL connection creation might go through this function. If that were the 
case, it seems like it's going to take more significant refactoring to be able 
to tell from connection context whether ENOTCONN is fatal or not.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org