[openssl-dev] Fix use of "can_load" in run_tests.pl (was GH PR #3424)

[Rainer Jung]

The below change doesn't work, because "can_load" must be used differently.

When running on SLES 11 which contains perl 1.10.0 (and thus no 
TAP::Harness module), run_tests.pl gives:


Can't locate object method "new" via package "TAP::Harness" (perhaps you 
forgot to load "TAP::Harness"?) at .././test/run_tests.pl line 64.


Please see below for a patch.

Am 10.05.2017 um 17:05 schrieb Richard Levitte:

The branch master has been updated
   via  76e0d0b21cc4e8a879d54f4d78a392826dadb1d1 (commit)
  from  03d8e9cb43da5c524e5890a5a51e2c77f1fbd789 (commit)


- Log -
commit 76e0d0b21cc4e8a879d54f4d78a392826dadb1d1
Author: Richard Levitte 
Date:   Wed May 10 12:58:36 2017 +0200

Prefer TAP::Harness over Test::Harness

TAP:Harness came along in perl 5.10.1, and since we claim to support
perl 5.10.0 in configuration and testing, we can only load it
conditionally.

The main reason to use TAP::Harness rather than Test::Harness is its
capability to merge stdout and stderr output from the test recipes,
which Test::Harness can't.  The merge gives much more comprehensible
output when testing verbosely.

Reviewed-by: Rich Salz 
Reviewed-by: Matt Caswell 
(Merged from https://github.com/openssl/openssl/pull/3424)

---

Summary of changes:
 test/run_tests.pl | 58 ---
 1 file changed, 47 insertions(+), 11 deletions(-)

diff --git a/test/run_tests.pl b/test/run_tests.pl
index 9c5ade1..aa1dba0 100644
--- a/test/run_tests.pl
+++ b/test/run_tests.pl
@@ -17,7 +17,10 @@ BEGIN {
 use File::Spec::Functions qw/catdir catfile curdir abs2rel rel2abs/;
 use File::Basename;
 use if $^O ne "VMS", 'File::Glob' => qw/glob/;
-use Test::Harness qw/runtests $switches/;
+use Module::Load::Conditional qw(can_load);
+
+my $TAP_Harness = can_load({modules => [ 'TAP::Harness' ]})
+? 'TAP::Harness' : 'OpenSSL::TAP::Harness';


The following patch fixes the can_load use:

--- test/run_tests.pl   2017-05-25 16:21:00.0 +0200
+++ test/run_tests.pl   2017-05-25 21:07:20.066149000 +0200
@@ -19,7 +19,7 @@
 use if $^O ne "VMS", 'File::Glob' => qw/glob/;
 use Module::Load::Conditional qw(can_load);

-my $TAP_Harness = can_load({modules => [ 'TAP::Harness' ]})
+my $TAP_Harness = can_load(modules => { 'TAP::Harness' => undef })
 ? 'TAP::Harness' : 'OpenSSL::TAP::Harness';

 my $srctop = $ENV{SRCTOP} || $ENV{TOP};

It should be applied to master and the 1.1.0 branch.

Should I open a GH issue or pull request for that trivial change?

Thanks a bunch,

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

[openssl-dev] OpenSSL 1.1.0 pre 5+6: SPARCv9 assembler stack alignment problem

[Rainer Jung]

When building OpenSSL 1.1.0 pre 5 or pre 6 on Sparc I get:

/usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 4811: warning: 
stack alignment problem; second operand is not a multiple of 8
/usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5063: warning: 
stack alignment problem; second operand is not a multiple of 8
/usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5539: warning: 
stack alignment problem; second operand is not a multiple of 8


The lines in question in crypto/ec/ecp_nistz256-sparcv9.s are:

 save %sp,-(2047+192)-32*10,%sp
 save %sp,-(2047+192)-32*18-32,%sp
 save %sp,-(2047+192)-32*15-32,%sp

They probably go back to the following lines in 
crypto/ec/ecp_nistz256-sparcv9.s.S:


...
#ifdef  __arch64__
.register   %g2,#scratch
.register   %g3,#scratch
# define STACK64_FRAME  STACK_FRAME
# define LOCALS64   LOCALS
#else
# define STACK64_FRAME  (2047+192)
# define LOCALS64   STACK64_FRAME
#endif
...
save%sp,-STACK64_FRAME-32*10,%sp
...
save%sp,-STACK64_FRAME-32*18-32,%sp
...
save%sp,-STACK64_FRAME-32*15-32,%sp

I can't judge on the validity of the "stack alignment problem", but at 
least 2047 is indeed not divisible by 8 (but all other offsets added or 
subtracted from 2047 are).


Thanks and regards,

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

[openssl-dev] OpenSSL 1.1.0 pre 6: SPARCv9 capability bits problem

[Rainer Jung]

The following change introduced build problems:

Am 25.04.2016 um 11:51 schrieb Andy Polyakov:

The branch master has been updated
   via  299ccadcdb99001c618d188fb243c1c86a1c (commit)
  from  a82a9f71ad0149380a680cae4c0cc693e6324679 (commit)


- Log -
commit 299ccadcdb99001c618d188fb243c1c86a1c
Author: Andy Polyakov 
Date:   Sat Apr 23 19:10:04 2016 +0200

crypto/sparc_arch.h: reserve more SPARCv9 capability bits.

Reviewed-by: Richard Levitte 

---

Summary of changes:
 crypto/sparc_arch.h |  9 -
 crypto/sparcv9cap.c | 17 -
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/crypto/sparc_arch.h b/crypto/sparc_arch.h
index 6f8969f..5bcdd9f 100644
--- a/crypto/sparc_arch.h
+++ b/crypto/sparc_arch.h
@@ -5,12 +5,16 @@
 # define SPARCV9_PREFER_FPU  (1<<1)
 # define SPARCV9_VIS1(1<<2)
 # define SPARCV9_VIS2(1<<3)/* reserved */
-# define SPARCV9_FMADD   (1<<4)/* reserved for SPARC64 V */
+# define SPARCV9_FMADD   (1<<4)
 # define SPARCV9_BLK (1<<5)/* VIS1 block copy */
 # define SPARCV9_VIS3(1<<6)
 # define SPARCV9_RANDOM  (1<<7)
 # define SPARCV9_64BIT_STACK (1<<8)
 # define SPARCV9_FJAESX  (1<<9)/* Fujitsu SPARC64 X AES */
+# define SPARCV9_FJDESX  (1<<10)/* Fujitsu SPARC64 X DES, reserved */
+# define SPARCV9_FJHPCACE(1<<11)/* Fujitsu HPC-ACE, reserved */
+# define SPARCV9_IMA (1<<13)/* reserved */
+# define SPARCV9_VIS4(1<<14)/* reserved */

 /*
  * OPENSSL_sparcv9cap_P[1] is copy of Compatibility Feature Register,
@@ -29,6 +33,9 @@
 # define CFR_MONTMUL 0x0200/* Supports MONTMUL opcodes */
 # define CFR_MONTSQR 0x0400/* Supports MONTSQR opcodes */
 # define CFR_CRC32C  0x0800/* Supports CRC32C opcodes */
+# define CFR_XMPMUL  0x1000/* Supports XMPMUL opcodes */
+# define CFR_XMONTMUL0x2000/* Supports XMONTMUL opcodes */
+# define CFR_XMONTSQR0x4000/* Supports XMONTSQR opcodes */

 # if defined(OPENSSL_PIC) && !defined(__PIC__)
 #  define __PIC__
diff --git a/crypto/sparcv9cap.c b/crypto/sparcv9cap.c
index e1e6d73..30c384b 100644
--- a/crypto/sparcv9cap.c
+++ b/crypto/sparcv9cap.c
@@ -149,17 +149,24 @@ void OPENSSL_cpuid_setup(void)
 unsigned int vec[1];


The vec array still has size 1, but ...


 if (getisax (vec,1)) {
-if (vec[0]&0x0020)  OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS1;
-if (vec[0]&0x0040)  OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS2;
-if (vec[0]&0x0080)  OPENSSL_sparcv9cap_P[0] |= SPARCV9_BLK;
-if (vec[0]&0x0100)  OPENSSL_sparcv9cap_P[0] |= SPARCV9_FMADD;
-if (vec[0]&0x0400)  OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS3;
+if (vec[0]&0x00020) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS1;
+if (vec[0]&0x00040) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS2;
+if (vec[0]&0x00080) OPENSSL_sparcv9cap_P[0] |= SPARCV9_BLK;
+if (vec[0]&0x00100) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FMADD;
+if (vec[0]&0x00400) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS3;
+if (vec[0]&0x01000) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FJHPCACE;
+if (vec[0]&0x02000) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FJDESX;
+if (vec[0]&0x08000) OPENSSL_sparcv9cap_P[0] |= SPARCV9_IMA;
 if (vec[0]&0x1) OPENSSL_sparcv9cap_P[0] |= SPARCV9_FJAESX;
+if (vec[1]&0x8) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4;


... here we use vec[1], so the compiler warns:

crypto/sparcv9cap.c:179:20: warning: array subscript is above array 
bounds [-Warray-bounds]

 if (vec[1]&0x8) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4;
^
I also can't check whether 0x8 is correct for vec[1] (and we need 
size 2) or 0x8 should be something else. My Sparc system is too old 
for VIS4.



 /* reconstruct %cfr copy */
 OPENSSL_sparcv9cap_P[1] = (vec[0]>>17)&0x3ff;
 OPENSSL_sparcv9cap_P[1] |= 
(OPENSSL_sparcv9cap_P[1]_MONTMUL)<<1;
 if (vec[0]&0x2000) OPENSSL_sparcv9cap_P[1] |= CFR_CRC32C;
+if (vec[1]&0x0020) OPENSSL_sparcv9cap_P[1] |= CFR_XMPMUL;
+if (vec[1]&0x0040)
+OPENSSL_sparcv9cap_P[1] |= CFR_XMONTMUL|CFR_XMONTSQR;


Again vec[1] (twice).


 /* Some heuristics */
 /* all known VIS2-capable CPUs have unprivileged tick counter */



Furthermore the following changes:

The branch master has been updated
   via  6944565bd55d147bdb46c708dff06ac310457036 (commit)
   via  4400f6c61e586dde2aea8dd023c9d4573fbbc547 (commit)
   via  fb65020b37d606659f90aa62163220b72d5560f5 (commit)
  from  38c5674dda8333288aa5d57ccd046203803aa81f (commit)

- 

Re: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles

[Rainer Jung]

Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:

I understand this part. What I'm questioning is the need to set PERL to
"/usr/bin/env perl" to begin with. It's practically not different at all from
setting it to just "perl", all this does is that any time the environment
variable PERL is used to run a perl script is to have an extra process between
the shell and perl itself that will simply pass along the exact environment
that it got from the shell. In effect, any time the environment variable PERL
with your assignment is used to run a script (assuming the quoting you
suggest), i.e.:

$PERL blah.pl

it would expand to this:

/usr/bin/env perl blah.pl

If it's only assigned "perl", the command would expand to this:

perl blah.pl

perl itself literally gets the exact same environment in both cases.


I agree.


Mind you, I did read your reasoning around #! in scripts. Unfortunately, that
reasoning is flawed, that won't be affected by the environment variable PERL.


I had to rad my ticket again, and actually this is the only reason for 
the ticket: the following perl scripts are generated from .in files 
during building OpenSSL and get installed and executed later in another 
environment:


- c_rehash
- CA.pl
- tsget

All of them contain in the .in file the magic header:

#!{- $config{perl} -}

IMHO $config{perl} - detected and set during config and Configure from 
the PERL env var and as a fallback from the PATH - is used as the perl 
during build time and also put into the scripts for use on the target 
system.


But those two perl paths should be defined independently from each other.

You say the reasoning is flawed, but to me it looks like:

- config checks whether the PERL env var is set. If not it searches for 
a perl in the path and sets the PERL env var to that one.


- config calls Configure

- Configure sets $config{perl} from the PERL env var

- the scripts c_rehash, CA.pl and tsget are generated from their .in 
files and their first line


#!{- $config{perl} -}

is replaced by #!$PERL (with $PERL resolved).

I'd love if I were wrong and there would already be a way to set the 
perl for those scripts independently from the one used for the build 
process. If you think that demand is too specific, I can live with 
patching the scripts myself. But IMHO it would be nice not to enforce 
the same restrictions on the build procedure perl to the runtime perl 
for those simple scripts. For the build procedure it should be the 
required 5.10 with modules etc. For the three scripts typically the 
platform perl would suffice.


Regards,

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

Re: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles

[Rainer Jung via RT]

Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:
> I understand this part. What I'm questioning is the need to set PERL to
> "/usr/bin/env perl" to begin with. It's practically not different at all from
> setting it to just "perl", all this does is that any time the environment
> variable PERL is used to run a perl script is to have an extra process between
> the shell and perl itself that will simply pass along the exact environment
> that it got from the shell. In effect, any time the environment variable PERL
> with your assignment is used to run a script (assuming the quoting you
> suggest), i.e.:
>
> $PERL blah.pl
>
> it would expand to this:
>
> /usr/bin/env perl blah.pl
>
> If it's only assigned "perl", the command would expand to this:
>
> perl blah.pl
>
> perl itself literally gets the exact same environment in both cases.

I agree.

> Mind you, I did read your reasoning around #! in scripts. Unfortunately, that
> reasoning is flawed, that won't be affected by the environment variable PERL.

I had to rad my ticket again, and actually this is the only reason for 
the ticket: the following perl scripts are generated from .in files 
during building OpenSSL and get installed and executed later in another 
environment:

- c_rehash
- CA.pl
- tsget

All of them contain in the .in file the magic header:

#!{- $config{perl} -}

IMHO $config{perl} - detected and set during config and Configure from 
the PERL env var and as a fallback from the PATH - is used as the perl 
during build time and also put into the scripts for use on the target 
system.

But those two perl paths should be defined independently from each other.

You say the reasoning is flawed, but to me it looks like:

- config checks whether the PERL env var is set. If not it searches for 
a perl in the path and sets the PERL env var to that one.

- config calls Configure

- Configure sets $config{perl} from the PERL env var

- the scripts c_rehash, CA.pl and tsget are generated from their .in 
files and their first line

#!{- $config{perl} -}

is replaced by #!$PERL (with $PERL resolved).

I'd love if I were wrong and there would already be a way to set the 
perl for those scripts independently from the one used for the build 
process. If you think that demand is too specific, I can live with 
patching the scripts myself. But IMHO it would be nice not to enforce 
the same restrictions on the build procedure perl to the runtime perl 
for those simple scripts. For the build procedure it should be the 
required 5.10 with modules etc. For the three scripts typically the 
platform perl would suffice.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles

[Rainer Jung via RT]

Am 10.05.2016 um 15:29 schrieb Richard Levitte via RT:
> On Tue May 10 13:18:22 2016, matt wrote:
>> Makefile.in doesn't exist any more. Ping Richard Levitte - does
>> anything need
>> to be done for the new build system?
>
> The run_tests.pl line in Configurations/unix-Makefile.tmpl would still need
> that change...
>
> ... but I don't quite understand the background story. What you end up with is
> perl calls like this:
>
> /usr/bin/env perl ... blah ...
>
> and the difference between that and this is nil:
>
> perl ... blah ...

No, this is about lines which set the PERL shell variable from the 
Makefile variable and then run a command on the same line, e.g.

PERL=$(PERL) /path/to/something

Now if the Makefile variable PERL is set to

PERL=/usr/bin/env perl

without quotes the shell command resolves to:

PERL=/usr/bin/env perl /path/to/something

so we call perl with argument /path/to/something and environment 
variable PERL set to /usr/bin/env.

With quotes it is

PERL="/usr/bin/env perl" /path/to/something

so we call /path/to/something with PERL env var set to "/usr/bin/env perl".

Currently (1.1.0pre5) I patch only one file before building, the 
unix-Makefile.tmpl file:

--- ./Configurations/unix-Makefile.tmpl.orig2016-04-19 
18:51:16.0 +0200
+++ ./Configurations/unix-Makefile.tmpl 2016-04-19 19:39:11.0 +0200
@@ -231,7 +231,7 @@
 @ : {- output_on() if !$disabled{tests}; "" -}

  list-tests:
-   @TOP=$(SRCDIR) PERL=$(PERL) $(PERL) $(SRCDIR)/test/run_tests.pl list
+   @TOP=$(SRCDIR) PERL="$(PERL)" $(PERL) 
$(SRCDIR)/test/run_tests.pl list

  libclean:
 @set -e; for s in $(SHLIB_INFO); do \
@@ -939,7 +939,7 @@
  $target: $lib$libext $deps $ordinalsfile
 \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
 PLATFORM=\$(PLATFORM) \\
-   PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+   PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
 INSTALLTOP='\$(INSTALLTOP)' LIBDIR='\$(LIBDIR)' \\
 LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
 LIBNAME=$libname 
LIBVERSION=\$(SHLIB_MAJOR).\$(SHLIB_MINOR) \\
@@ -975,7 +975,7 @@
  $target: $objs $deps
 \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
 PLATFORM=\$(PLATFORM) \\
-   PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+   PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
 LIBDEPS='\$(PLIB_LDFLAGS) '"$shlibdeps"' \$(EX_LIBS)' \\
 LIBNAME=$libname LDFLAGS='\$(LDFLAGS)' \\
 CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(DSO_CFLAGS)' \\
@@ -1012,7 +1012,7 @@
  $bin$exeext: $objs $deps
 \$(RM) $bin$exeext
 \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
-   PERL=\$(PERL) SRCDIR=\$(SRCDIR) \\
+   PERL="\$(PERL)" SRCDIR=\$(SRCDIR) \\
 APPNAME=$bin$exeext OBJECTS="$objs" \\
 LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
 CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(BIN_CFLAGS)' \\

I haven't checked for other platform files though.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles

[Rainer Jung]

Am 10.05.2016 um 15:29 schrieb Richard Levitte via RT:

On Tue May 10 13:18:22 2016, matt wrote:

Makefile.in doesn't exist any more. Ping Richard Levitte - does
anything need
to be done for the new build system?


The run_tests.pl line in Configurations/unix-Makefile.tmpl would still need
that change...

... but I don't quite understand the background story. What you end up with is
perl calls like this:

/usr/bin/env perl ... blah ...

and the difference between that and this is nil:

perl ... blah ...


No, this is about lines which set the PERL shell variable from the 
Makefile variable and then run a command on the same line, e.g.


PERL=$(PERL) /path/to/something

Now if the Makefile variable PERL is set to

PERL=/usr/bin/env perl

without quotes the shell command resolves to:

PERL=/usr/bin/env perl /path/to/something

so we call perl with argument /path/to/something and environment 
variable PERL set to /usr/bin/env.


With quotes it is

PERL="/usr/bin/env perl" /path/to/something

so we call /path/to/something with PERL env var set to "/usr/bin/env perl".

Currently (1.1.0pre5) I patch only one file before building, the 
unix-Makefile.tmpl file:


--- ./Configurations/unix-Makefile.tmpl.orig2016-04-19 
18:51:16.0 +0200

+++ ./Configurations/unix-Makefile.tmpl 2016-04-19 19:39:11.0 +0200
@@ -231,7 +231,7 @@
@ : {- output_on() if !$disabled{tests}; "" -}

 list-tests:
-   @TOP=$(SRCDIR) PERL=$(PERL) $(PERL) $(SRCDIR)/test/run_tests.pl list
+   @TOP=$(SRCDIR) PERL="$(PERL)" $(PERL) 
$(SRCDIR)/test/run_tests.pl list


 libclean:
@set -e; for s in $(SHLIB_INFO); do \
@@ -939,7 +939,7 @@
 $target: $lib$libext $deps $ordinalsfile
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
PLATFORM=\$(PLATFORM) \\
-   PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+   PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
INSTALLTOP='\$(INSTALLTOP)' LIBDIR='\$(LIBDIR)' \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
LIBNAME=$libname 
LIBVERSION=\$(SHLIB_MAJOR).\$(SHLIB_MINOR) \\

@@ -975,7 +975,7 @@
 $target: $objs $deps
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
PLATFORM=\$(PLATFORM) \\
-   PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+   PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$shlibdeps"' \$(EX_LIBS)' \\
LIBNAME=$libname LDFLAGS='\$(LDFLAGS)' \\
CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(DSO_CFLAGS)' \\
@@ -1012,7 +1012,7 @@
 $bin$exeext: $objs $deps
\$(RM) $bin$exeext
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
-   PERL=\$(PERL) SRCDIR=\$(SRCDIR) \\
+   PERL="\$(PERL)" SRCDIR=\$(SRCDIR) \\
APPNAME=$bin$exeext OBJECTS="$objs" \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(BIN_CFLAGS)' \\

I haven't checked for other platform files though.

Regards,

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

[openssl-dev] [openssl.org #4520] Camellia asm build failure for 1.1.0pre5 on Solaris (typo in build.info)

[Rainer Jung via RT]

The change

https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed

introduced a typo in the last line of file crypto/camellia/build.info.

The fix is:

--- crypto/camellia/build.info2016-03-16 19:18:09.0 +0100
+++ crypto/camellia/build.info2016-04-19 19:39:11.449856000 +0200
@@ -8,4 +8,4 @@
  GENERATE[cmll-x86_64.s]=asm/cmll-x86_64.pl $(PERLASM_SCHEME)
  GENERATE[cmllt4-sparcv9.S]=asm/cmllt4-sparcv9.pl $(PERLASM_SCHEME)
  INCLUDE[cmllt4-sparcv9.o]=..
-DEPEND[cmllt4-sparcv9.S]=../perlasm/sparcv9-modes.pl
+DEPEND[cmllt4-sparcv9.S]=../perlasm/sparcv9_modes.pl

The correct Perl script name contains an underscore.

This was already reported on dev@ on 2016-04-19. I just wanted to make 
sure it doesn't get missed, therefore this RT.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4520
Please log in as guest with password guest if prompted

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

[openssl-dev] Broken links in pod file of OpenSSL 1.1.0pre5

[Rainer Jung]

Output during "make install":

Cannot find "BIO_gets" in podpath: cannot find suitable replacement 
path, cannot resolve link
Cannot find "BIO_callback_ctrl" in podpath: cannot find suitable 
replacement path, cannot resolve link
Cannot find "DSA_SIG_new3)" in podpath: cannot find suitable replacement 
path, cannot resolve link


Likely patch (it fixes the warnings, but please double check for 
correctness):


--- doc/crypto/DSA_meth_new.pod 2016-04-19 18:51:18.0 +0200
+++ doc/crypto/DSA_meth_new.pod 2016-04-19 21:06:01.785837000 +0200
@@ -174,7 +174,7 @@
 =head1 SEE ALSO

 L, L, L, 
L,
-L, L, L, 
L,
+L, L, L, 
L,

 L, L, L

 =head1 HISTORY


( "DSA_SIG_new(3)" instead of "DSA_SIG_new3)").


--- doc/crypto/BIO_meth_new.pod 2016-04-19 18:51:18.0 +0200
+++ doc/crypto/BIO_meth_new.pod 2016-04-19 21:14:10.702572000 +0200
@@ -75,7 +75,7 @@
 the function have the same meaning as for BIO_puts().

 BIO_meth_get_gets() and BIO_meth_set_gets() get and set the function 
typically
-used for reading a line of data from the BIO respectively (see the 
L
+used for reading a line of data from the BIO respectively (see the 
L
 page for more information). This function will be called in response 
to the
 application calling BIO_gets(). The parameters for the function have 
the same

 meaning as for BIO_gets().
@@ -102,7 +102,7 @@

 BIO_meth_get_callback_ctrl() and BIO_meth_set_callback_ctrl() get and 
set the
 function used for processing callback ctrl messages in the BIO 
respectively. See
-the L page for more information. This function will 
be called
+the L page for more information. This function 
will be called
 in response to the application calling BIO_callback_ctrl(). The 
parameters for

 the function have the same meaning as for BIO_callback_ctrl().


(Adding twice "(3)").

Regards,

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

[openssl-dev] Core dump OpenSSL 1.1.0-pre5 during test (likely in 70-test_sslskewith0p.t)

[Rainer Jung]

I get a core dump during test execution for 1.1.0-pre5. Test is 
test/recipes/70-test_sslskewith0p.t, platform is Solaris 10 Sparc.


The crash happens in BN_num_bits() (crypto/bn/bn_lib.c:211), because it 
is called with a NULL argument, which is then dereferenced.


The call comes from EVP_PKEY_bits() (crypto/evp/p_lib.c:78). There the 
key has pkey->ameth->pkey_bits equals to dh_bits(), so it calls 
dh_bits(pkey), which calls BN_num_bits(pkey->pkey.dh->p). Looking at 
pkey->pkey.dh we see:


(gdb) print *pkey->pkey.dh
$6 = {pad = 0, version = 0, p = 0x0, g = 0x0, length = 0, pub_key = 0x0, 
priv_key = 0x0, flags = 1025, method_mont_p = 0x0, q = 0x0, j = 0x0, 
seed = 0x0, seedlen = 0,
  counter = 0x0, references = 1, ex_data = {sk = 0x0}, meth = 0x2b45ec, 
engine = 0x0, lock = 0x2e2c68}


so p is actually NULL.

Further print stack:

#2  0x00072e54 in ssl_print_tmp_key (out=out@entry=0x2dae68, 
s=s@entry=0x2e1ab0) at apps/s_cb.c:478
#3  0x00075894 in print_stuff (bio=0x2dae68, s=s@entry=0x2e1ab0, 
full=full@entry=1) at apps/s_client.c:2625
#4  0x000784c8 in s_client_main (argc=, argv=out>) at apps/s_client.c:2521


Verbose run output:

$ HARNESS_VERBOSE=yes TESTS=test_sslskewith0p make test
( cd test; \
  SRCTOP=../. \
  BLDTOP=../. \
  EXE_EXT= \
  OPENSSL_ENGINES=.././engines \
/usr/bin/env perl .././test/run_tests.pl test_sslskewith0p )
../test/recipes/70-test_sslskewith0p.t ..
1..1
Proxy started on port 4453
engine "ossltest" set.
Using default temp DH parameters
ACCEPT
engine "ossltest" set.
Connection opened
Received client packet
Packet length = 102
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 97
  Message type: ClientHello
  Message Length: 93
Client Version:771
Session ID Len:0
Ciphersuite len:4
Compression Method Len:1
Extensions Len:48

Forwarded packet length = 102
Received server packet
Packet length = 474
Processing flight 1
 Record 1 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 61
  Message type: ServerHello
  Message Length: 57
Server Version:771
Session ID Len:0
Ciphersuite:52
Compression Method:0
Extensions Len:17
 Record 2 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 394
  Message type: ServerKeyExchange
  Message Length: 390
 Record 3 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 4
  Message type: ServerHelloDone
  Message Length: 0

Forwarded packet length = 347
1:error:1416D066:SSL routines:tls_process_key_exchange:bad dh 
value:ssl/statem/statem_clnt.c:1568:

Received client packet
Packet length = 7
Processing flight 2
 Record 1 (client -> server)
  Content type: ALERT
  Version: TLS1.2
  Length: 2

Forwarded packet length = 7
Connection closed
Waiting for server process to close: 14314
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)
CONNECTION FAILURE
1:error:1409441A:SSL 
routines:ssl3_read_bytes:reason(1050):ssl/record/rec_layer_s3.c:1467:SSL 
alert number 50

ok 1 - ServerKeyExchange with 0 p
Segmentation Fault - core dumped
ok
All tests successful.

Regards,

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

[openssl-dev] Camellia asm build failure for 1.1.0pre5 on Solaris (typo in build.info)

[Rainer Jung]

The change

https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed

introduced a typo in the last line of file crypto/camellia/build.info. 
Fix is:


--- crypto/camellia/build.info  2016-03-16 19:18:09.0 +0100
+++ crypto/camellia/build.info  2016-04-19 19:39:11.449856000 +0200
@@ -8,4 +8,4 @@
 GENERATE[cmll-x86_64.s]=asm/cmll-x86_64.pl $(PERLASM_SCHEME)
 GENERATE[cmllt4-sparcv9.S]=asm/cmllt4-sparcv9.pl $(PERLASM_SCHEME)
 INCLUDE[cmllt4-sparcv9.o]=..
-DEPEND[cmllt4-sparcv9.S]=../perlasm/sparcv9-modes.pl
+DEPEND[cmllt4-sparcv9.S]=../perlasm/sparcv9_modes.pl

The Perl script name contains an underscore.

Regards,

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

Re: [openssl-dev] [openssl.org #4459] openssl-1.1.0-pre4: make install fals on solaris64-x86_64-gcc.

[Rainer Jung]

I'm sorry and thanks for your patience: there's a bug in the patch: 
Replace the $$(ENGINE) in the line


@set -e; if [ "X$$(ENGINES)" != "X" ]; then \

by $(ENGINE) (no "$$" instead just a single "$").

The new line is

@set -e; if [ "X$(ENGINES)" != "X" ]; then \

(plus a tab and some additional whitespace in front).

The wrong "X$$(ENGINES)" is reduced by make into "X$(ENGINES)" which 
doesn't make sense in shell. The "X$$ENGINES" in your suggested echo 
line is reduced to "X$ENGINES" and since there's no shell variable named 
ENGINES set, this is reduced by the shell to "X". But I want 
"X$(ENGINES)" in my patch: make reduces this to "X", because the make 
variable ENGINES has an empty value and that's what we want to test in 
the new "if".


Regards,

Rainer

Am 21.03.2016 um 00:05 schrieb Kiyoshi KANAZAWA via RT:

Hello,

Tried your openssl-install-engines.patch, but have the same result.
% make install_engines
*** Installing engines
/bin/sh: syntax error at line 2: `;' unexpected
Makefile:251: recipe for target 'install_engines' failed
make: *** [install_engines] Error 2


I think it should work, and added, for double check,
@echo "XENGINES="X$$ENGINES
after the line

@echo "*** Installing engines".
% make install_engines
*** Installing engines
XENGINES=X
/bin/sh: syntax error at line 2: `;' unexpected
Makefile:251: recipe for target 'install_engines' failed
make: *** [install_engines] Error 2



Regards,

--- Kiyoshi <yoi_no_myou...@yahoo.co.jp>



- Original Message -

From: Rainer Jung via RT <r...@openssl.org>
To: yoi_no_myou...@yahoo.co.jp
Cc: openssl-dev@openssl.org
Date: 2016/3/21, Mon 01:16
Subject: Re: [openssl-dev] [openssl.org #4459] openssl-1.1.0-pre4: make install 
fals on solaris64-x86_64-gcc.

Am 20.03.2016 um 16:46 schrieb Kiyoshi KANAZAWA via RT:

  Hello,

  Yes, ENGINES in the top level Makefile is empty.

  22:  LIBS=libcrypto.a libssl.a
  23:  SHLIBS=
  24:  ENGINES=
  25:  PROGRAMS=apps/openssl


OK, that explains the error, because the install_engines target then
contains a shell snippet

for e in ; do

($(ENGINES) is empty, but since it is not used as a shell variable but
instead as a make variable, that is the resulting for loop). That results in

/bin/sh: syntax error at line 1: `;' unexpected

at least for /bin/sh on Solaris.

So we need to add special handling in $(ENGINES) is empty.

You could try the attached patch.

Regards,

Rainer

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4459
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4459] openssl-1.1.0-pre4: make install fals on solaris64-x86_64-gcc.

[Rainer Jung via RT]

I'm sorry and thanks for your patience: there's a bug in the patch: 
Replace the $$(ENGINE) in the line

@set -e; if [ "X$$(ENGINES)" != "X" ]; then \

by $(ENGINE) (no "$$" instead just a single "$").

The new line is

@set -e; if [ "X$(ENGINES)" != "X" ]; then \

(plus a tab and some additional whitespace in front).

The wrong "X$$(ENGINES)" is reduced by make into "X$(ENGINES)" which 
doesn't make sense in shell. The "X$$ENGINES" in your suggested echo 
line is reduced to "X$ENGINES" and since there's no shell variable named 
ENGINES set, this is reduced by the shell to "X". But I want 
"X$(ENGINES)" in my patch: make reduces this to "X", because the make 
variable ENGINES has an empty value and that's what we want to test in 
the new "if".

Regards,

Rainer

Am 21.03.2016 um 00:05 schrieb Kiyoshi KANAZAWA via RT:
> Hello,
>
> Tried your openssl-install-engines.patch, but have the same result.
> % make install_engines
> *** Installing engines
> /bin/sh: syntax error at line 2: `;' unexpected
> Makefile:251: recipe for target 'install_engines' failed
> make: *** [install_engines] Error 2
>
>
> I think it should work, and added, for double check,
> @echo "XENGINES="X$$ENGINES
> after the line
>
> @echo "*** Installing engines".
> % make install_engines
> *** Installing engines
> XENGINES=X
> /bin/sh: syntax error at line 2: `;' unexpected
> Makefile:251: recipe for target 'install_engines' failed
> make: *** [install_engines] Error 2
>
>
>
> Regards,
>
> --- Kiyoshi <yoi_no_myou...@yahoo.co.jp>
>
>
>
> - Original Message -
>> From: Rainer Jung via RT <r...@openssl.org>
>> To: yoi_no_myou...@yahoo.co.jp
>> Cc: openssl-dev@openssl.org
>> Date: 2016/3/21, Mon 01:16
>> Subject: Re: [openssl-dev] [openssl.org #4459] openssl-1.1.0-pre4: make 
>> install fals on solaris64-x86_64-gcc.
>>
>> Am 20.03.2016 um 16:46 schrieb Kiyoshi KANAZAWA via RT:
>>>   Hello,
>>>
>>>   Yes, ENGINES in the top level Makefile is empty.
>>>
>>>   22:  LIBS=libcrypto.a libssl.a
>>>   23:  SHLIBS=
>>>   24:  ENGINES=
>>>   25:  PROGRAMS=apps/openssl
>>
>> OK, that explains the error, because the install_engines target then
>> contains a shell snippet
>>
>> for e in ; do
>>
>> ($(ENGINES) is empty, but since it is not used as a shell variable but
>> instead as a make variable, that is the resulting for loop). That results in
>>
>> /bin/sh: syntax error at line 1: `;' unexpected
>>
>> at least for /bin/sh on Solaris.
>>
>> So we need to add special handling in $(ENGINES) is empty.
>>
>> You could try the attached patch.
>>
>> Regards,
>>
>> Rainer
>>
>> --
>> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4459
>> Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4459
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4459] openssl-1.1.0-pre4: make install fals on solaris64-x86_64-gcc.

[Rainer Jung via RT]

Am 20.03.2016 um 16:46 schrieb Kiyoshi KANAZAWA via RT:
> Hello,
>
> Yes, ENGINES in the top level Makefile is empty.
>
> 22:  LIBS=libcrypto.a libssl.a
> 23:  SHLIBS=
> 24:  ENGINES=
> 25:  PROGRAMS=apps/openssl

OK, that explains the error, because the install_engines target then 
contains a shell snippet

   for e in ; do

($(ENGINES) is empty, but since it is not used as a shell variable but 
instead as a make variable, that is the resulting for loop). That results in

   /bin/sh: syntax error at line 1: `;' unexpected

at least for /bin/sh on Solaris.

So we need to add special handling in $(ENGINES) is empty.

You could try the attached patch.

Regards,

Rainer

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4459
Please log in as guest with password guest if prompted

--- Makefile	2016-03-19 14:08:21.655179000 +0100
+++ Makefile	2016-03-20 17:08:48.298012000 +0100
@@ -284,7 +284,8 @@
 	@[ -n "$(INSTALLTOP)" ] || (echo INSTALLTOP should not be empty; exit 1)
 	@$(PERL) $(SRCDIR)/util/mkdir-p.pl $(DESTDIR)$(INSTALLTOP)/$(LIBDIR)/engines/
 	@echo "*** Installing engines"
-	@set -e; for e in $(ENGINES); do \
+	@set -e; if [ "X$$(ENGINES)" != "X" ]; then \
+	for e in $(ENGINES); do \
 		fn=`basename $$e`; \
 		if [ "$$fn" = 'ossltest.so' ]; then \
 			continue; \
@@ -294,7 +295,8 @@
 		chmod 755 $(DESTDIR)$(INSTALLTOP)/$(LIBDIR)/engines/$$fn.new; \
 		mv -f $(DESTDIR)$(INSTALLTOP)/$(LIBDIR)/engines/$$fn.new \
 		  $(DESTDIR)$(INSTALLTOP)/$(LIBDIR)/engines/$$fn; \
-	done
+	done; \
+	fi
 
 uninstall_engines:
 	@echo "*** Uninstalling engines"
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4459] openssl-1.1.0-pre4: make install fals on solaris64-x86_64-gcc.

[Rainer Jung]

Am 20.03.2016 um 16:46 schrieb Kiyoshi KANAZAWA via RT:

Hello,

Yes, ENGINES in the top level Makefile is empty.

22:  LIBS=libcrypto.a libssl.a
23:  SHLIBS=
24:  ENGINES=
25:  PROGRAMS=apps/openssl


OK, that explains the error, because the install_engines target then 
contains a shell snippet


  for e in ; do

($(ENGINES) is empty, but since it is not used as a shell variable but 
instead as a make variable, that is the resulting for loop). That results in


  /bin/sh: syntax error at line 1: `;' unexpected

at least for /bin/sh on Solaris.

So we need to add special handling in $(ENGINES) is empty.

You could try the attached patch.

Regards,

Rainer
--- Makefile	2016-03-19 14:08:21.655179000 +0100
+++ Makefile	2016-03-20 17:08:48.298012000 +0100
@@ -284,7 +284,8 @@
 	@[ -n "$(INSTALLTOP)" ] || (echo INSTALLTOP should not be empty; exit 1)
 	@$(PERL) $(SRCDIR)/util/mkdir-p.pl $(DESTDIR)$(INSTALLTOP)/$(LIBDIR)/engines/
 	@echo "*** Installing engines"
-	@set -e; for e in $(ENGINES); do \
+	@set -e; if [ "X$$(ENGINES)" != "X" ]; then \
+	for e in $(ENGINES); do \
 		fn=`basename $$e`; \
 		if [ "$$fn" = 'ossltest.so' ]; then \
 			continue; \
@@ -294,7 +295,8 @@
 		chmod 755 $(DESTDIR)$(INSTALLTOP)/$(LIBDIR)/engines/$$fn.new; \
 		mv -f $(DESTDIR)$(INSTALLTOP)/$(LIBDIR)/engines/$$fn.new \
 		  $(DESTDIR)$(INSTALLTOP)/$(LIBDIR)/engines/$$fn; \
-	done
+	done; \
+	fi
 
 uninstall_engines:
 	@echo "*** Uninstalling engines"
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4459] openssl-1.1.0-pre4: make install fals on solaris64-x86_64-gcc.

[Rainer Jung via RT]

Am 20.03.2016 um 15:07 schrieb Kiyoshi KANAZAWA via RT:
> With patch for #,
>
>
> % mkdir /tmp/install_check
> % ./config --prefix=/tmp/install_check
>
>  :
> Configured for solaris64-x86_64-gcc.
>
> % make
> (passed)
>
> % make test
> (passed)
>
> % make install
>  :
> install openssl.pc -> /tmp/install_check/lib/pkgconfig/openssl.pc
> *** Installing engines
> /bin/sh: syntax error at line 1: `;' unexpected
> Makefile:251: recipe for target 'install_engines' failed
> make: *** [install_engines] Error 2
>
>
>
> OS: Solaris10 x86/x64

Could it be that the ENGINES variable in the top level Makefile is 
empty? On my Solaris Sparc system it is

ENGINES=engines/capi.so engines/dasync.so engines/ossltest.so 
engines/padlock.so

(line 24)

To debug, you might look for the line starting with

install_engines:

and then change the

@set -e; ...

a few lines down into

@set -ex; ...

(add the "x") and run "make install" again.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4459
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4459] openssl-1.1.0-pre4: make install fals on solaris64-x86_64-gcc.

[Rainer Jung]

Am 20.03.2016 um 15:07 schrieb Kiyoshi KANAZAWA via RT:

With patch for #,


% mkdir /tmp/install_check
% ./config --prefix=/tmp/install_check

 :
Configured for solaris64-x86_64-gcc.

% make
(passed)

% make test
(passed)

% make install
 :
install openssl.pc -> /tmp/install_check/lib/pkgconfig/openssl.pc
*** Installing engines
/bin/sh: syntax error at line 1: `;' unexpected
Makefile:251: recipe for target 'install_engines' failed
make: *** [install_engines] Error 2



OS: Solaris10 x86/x64


Could it be that the ENGINES variable in the top level Makefile is 
empty? On my Solaris Sparc system it is


ENGINES=engines/capi.so engines/dasync.so engines/ossltest.so 
engines/padlock.so


(line 24)

To debug, you might look for the line starting with

install_engines:

and then change the

@set -e; ...

a few lines down into

@set -ex; ...

(add the "x") and run "make install" again.

Regards,

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

[openssl-dev] [openssl.org #4447] Missing generators for sparcv8plus.s, sparcv8.s and sparccpuid.s (OpenSSL 1.1.0 pre4)

[Rainer Jung via RT]

When building OpenSSL 1.1.0 pre4 on Solaris Sparc for 64 Bits I get an 
error, because before building crypto/bn/sparcv8plus.o first generates 
crypto/bn/asm/sparcv8plus.s from crypto/bn/asm/sparcv8plus.S with the 
following command

gcc -E  crypto/bn/asm/sparcv8plus.S > crypto/bn/asm/sparcv8plus.s

This command is missing CFLAGS. As a consequence, the generated .s file 
does not work for 64 bit compilation and compiling it fails with lots of 
errors of type:

/usr/ccs/bin/as: "crypto/bn/asm/sparcv8plus.s", line ...: error: detect 
global register use not covered .register pseudo-op

The pre3 version compiled crypto/bn/asm/sparcv8plus.o directly from 
crypto/bn/asm/sparcv8plus.S (upper case ".S") using "gcc -c" and all 
CFLAGS, include flags etc.

So either one does the same for pre4 or one adds a Makefile rule for 
crypto/bn/asm/sparcv8plus.s generating it from 
crypto/bn/asm/sparcv8plus.S respecting CFLAGS, include dirs etc. or 
simply copying it from the .S file.

I think the switch from .S to .s happens in src2obj() inside 
Configurations/unix-Makefile.tmpl. So if it is intentional, you need to 
define and use a generator from .S to .s.

The following patch worked for me, but I don't know whether it is how it 
should work:


--- Configurations/00-base-templates.conf   Wed Mar 16 19:18:09 2016
+++ Configurations/00-base-templates.conf   Fri Mar 18 22:31:59 2016
@@ -198,8 +198,8 @@
  },
  sparcv9_asm => {
 template=> 1,
-   cpuid_asm_src   => "sparcv9cap.c sparccpuid.S",
-   bn_asm_src  => "asm/sparcv8plus.S sparcv9-mont.S 
sparcv9a-mont.S vis3-mont.S sparct4-mont.S sparcv9-gf2m.S",
+   cpuid_asm_src   => "sparcv9cap.c sparccpuid.s",
+   bn_asm_src  => "sparcv8plus.s sparcv9-mont.S sparcv9a-mont.S 
vis3-mont.S sparct4-mont.S sparcv9-gf2m.S",
 ec_asm_src  => "ecp_nistz256.c ecp_nistz256-sparcv9.S",
 des_asm_src => "des_enc-sparc.S fcrypt_b.c dest4-sparcv9.S",
 aes_asm_src => "aes_core.c aes_cbc.c aes-sparcv9.S 
aest4-sparcv9.S",
@@ -213,7 +213,7 @@
  sparcv8_asm => {
 template=> 1,
 cpuid_asm_src   => "",
-   bn_asm_src  => "asm/sparcv8.S",
+   bn_asm_src  => "sparcv8.s",
 des_asm_src => "des_enc-sparc.S fcrypt_b.c",
 perlasm_scheme  => "void"
  },


(upper case ".S" to lower case ".s" and removal of "asm/").

and two build.info changes:


--- crypto/build.info Wed Mar 16 19:18:08 2016
+++ crypto/build.info   Fri Mar 18 22:11:43 2016
@@ -21,6 +21,8 @@

  GENERATE[x86_64cpuid.s]=x86_64cpuid.pl $(PERLASM_SCHEME)

+GENERATE[sparccpuid.s]=sparccpuid.S
+
  GENERATE[ia64cpuid.s]=ia64cpuid.S
  GENERATE[ppccpuid.s]=ppccpuid.pl $(PERLASM_SCHEME)
  GENERATE[pariscid.s]=pariscid.pl $(PERLASM_SCHEME)


--- crypto/bn/build.info  Wed Mar 16 19:18:09 2016
+++ crypto/bn/build.infoFri Mar 18 22:11:43 2016
@@ -24,6 +24,9 @@
 $(PERLASM_SCHEME) $(CFLAGS) $(LIB_CFLAGS) $(PROCESSOR)
  DEPEND[x86-gf2m.s]=../perlasm/x86asm.pl

+GENERATE[sparcv8.s]=asm/sparcv8.S
+GENERATE[sparcv8plus.s]=asm/sparcv8plus.S
+
  GENERATE[sparcv9a-mont.S]=asm/sparcv9a-mont.pl $(PERLASM_SCHEME)
  INCLUDE[sparcv9a-mont.o]=..
  GENERATE[sparcv9-mont.S]=asm/sparcv9-mont.pl $(PERLASM_SCHEME)


This seems to be consistent with how it is done for

crypto/ia64cpuid.S
crypto/aes/asm/aes-ia64.S
crypto/bn/asm/ia64.S

The same changes probably need to be done for

crypto/s390xcpuid.S
crypto/bn/asm/s390x.S

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4447
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make fails with "recipe for target 'depend' failed" on solaris64-x86_64

[Rainer Jung via RT]

I had the same problem. /bin/sh on Solaris does not understand the "-nt" 
operator used in the definition of the "depend" target in the top-level 
Makefile, e.g. in line

if [ Makefile -nt Makefile ] ...

and elsewhere.

 From "man test" on Solaris:

...
  file1 -nt file2 True if file1 exists  and  is  newer
  than file2. (Not available in sh.)
...

Also normative standards documents as 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html 
indicate, that "-nt" can't be expected. Quoting: "Some additional 
primaries newly invented or from the KornShell appeared in an early 
proposal as part of the conditional command ([[]]): s1 > s2, s1 < s2, 
str = pattern, str != pattern, f1 -nt f2, f1 -ot f2, and f1 -ef f2. They 
were not carried forward into the test utility when the conditional 
command was removed from the shell because they have not been included 
in the test utility built into historical implementations of the sh 
utility."

I added a line

SHELL=/bin/ksh

to the Makefile on Solaris, because I was afraid that more non-standard 
shell stuff might be in the Makefile now or in the future. It would be 
better though to replace the non-standard stuff, but I didn't have the 
time to work on a full patch. Using the SHELL=/bin/ksh workaround should 
allow you to proceed building on Solaris. "make" then uses the Korn 
Shell for shell constructs contained in the Makefile.

Regards,

Rainer

Am 18.03.2016 um 08:51 schrieb Kiyoshi KANAZAWA via RT:
> % ./config --prefix=/opt/openssl
> Operating system: i86pc-whatever-solaris2
> Configuring for solaris64-x86_64-gcc
> Configuring OpenSSL version 1.1.0-pre4 (0x0x1014L)
>  no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
>  no-crypto-mdebug-backtrace [forced]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE 
> (skip dir)
>  no-dynamic-engine [forced]
>  no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip 
> dir)
>  no-egd  [default]  OPENSSL_NO_EGD (skip dir)
>  no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
>  no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
>  no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
>  no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
>  no-shared   [default]
>  no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
>  no-ssl3 [default]  OPENSSL_NO_SSL3 (skip dir)
>  no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
>  no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
>  no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
>  no-zlib [default]
>  no-zlib-dynamic [default]
> Configuring for solaris64-x86_64-gcc
> IsMK1MF   =no
> CC=gcc
> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H  -Wa,--noexecstack
> SHARED_CFLAG  =-fPIC
> DEFINES   =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS 
> OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT 
> OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM 
> MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
> LFLAG =
> PLIB_LFLAG=
> EX_LIBS   =-lresolv -lsocket -lnsl -ldl
> APPS_OBJ  =
> CPUID_OBJ =x86_64cpuid.o
> UPLINK_OBJ=
> BN_ASM=asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o 
> rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
> EC_ASM=ecp_nistz256.o ecp_nistz256-x86_64.o
> DES_ENC   =des_enc.o fcrypt_b.o
> AES_ENC   =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o 
> aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
> BF_ENC=bf_enc.o
> CAST_ENC  =c_enc.o
> RC4_ENC   =rc4-x86_64.o rc4-md5-x86_64.o
> RC5_ENC   =rc5_enc.o
> MD5_OBJ_ASM   =md5-x86_64.o
> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o 
> sha256-mb-x86_64.o
> RMD160_OBJ_ASM=
> CMLL_ENC  =cmll-x86_64.o cmll_misc.o
> MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
> PADLOCK_OBJ   =e_padlock-x86_64.o
> CHACHA_ENC=chacha-x86_64.o
> POLY1305_OBJ  =poly1305-x86_64.o
> BLAKE2_OBJ=
> PROCESSOR =
> RANLIB=/usr/ccs/bin/ranlib
> ARFLAGS   =
> PERL  =/opt/perl5/bin/perl
>
> SIXTY_FOUR_BIT_LONG mode
>
> Configured for solaris64-x86_64-gcc.
>
>
> % make
>:
> make[1]: Leaving directory '/tmp/openssl-1.1.0-pre4'
> /opt/perl5/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
>  "-oMakefile" apps/CA.pl.in > "apps/CA.pl"
> chmod a+x apps/CA.pl
> /opt/perl5/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
>  "-oMakefile" tools/c_rehash.in > "tools/c_rehash"
> chmod a+x tools/c_rehash
> Makefile:170: recipe for target 'depend' failed
> make: *** [depend] Error 1
>
>
>
> Other information
> OS: Solaris10 x86/64
>
> perl version:v5.22.1
> gcc version: 4.8.5
> ld: /usr/ccs/bin/ld
>
>
> Best Regards,
>
>
> --- Kiyoshi 


-- 
Ticket 

Re: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make fails with "recipe for target 'depend' failed" on solaris64-x86_64

[Rainer Jung]

I had the same problem. /bin/sh on Solaris does not understand the "-nt" 
operator used in the definition of the "depend" target in the top-level 
Makefile, e.g. in line


if [ Makefile -nt Makefile ] ...

and elsewhere.

From "man test" on Solaris:

...
 file1 -nt file2 True if file1 exists  and  is  newer
 than file2. (Not available in sh.)
...

Also normative standards documents as 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html 
indicate, that "-nt" can't be expected. Quoting: "Some additional 
primaries newly invented or from the KornShell appeared in an early 
proposal as part of the conditional command ([[]]): s1 > s2, s1 < s2, 
str = pattern, str != pattern, f1 -nt f2, f1 -ot f2, and f1 -ef f2. They 
were not carried forward into the test utility when the conditional 
command was removed from the shell because they have not been included 
in the test utility built into historical implementations of the sh 
utility."


I added a line

SHELL=/bin/ksh

to the Makefile on Solaris, because I was afraid that more non-standard 
shell stuff might be in the Makefile now or in the future. It would be 
better though to replace the non-standard stuff, but I didn't have the 
time to work on a full patch. Using the SHELL=/bin/ksh workaround should 
allow you to proceed building on Solaris. "make" then uses the Korn 
Shell for shell constructs contained in the Makefile.


Regards,

Rainer

Am 18.03.2016 um 08:51 schrieb Kiyoshi KANAZAWA via RT:

% ./config --prefix=/opt/openssl
Operating system: i86pc-whatever-solaris2
Configuring for solaris64-x86_64-gcc
Configuring OpenSSL version 1.1.0-pre4 (0x0x1014L)
 no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
 no-crypto-mdebug-backtrace [forced]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE 
(skip dir)
 no-dynamic-engine [forced]
 no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
 no-egd  [default]  OPENSSL_NO_EGD (skip dir)
 no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
 no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
 no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
 no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
 no-shared   [default]
 no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
 no-ssl3 [default]  OPENSSL_NO_SSL3 (skip dir)
 no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
 no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
 no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
 no-zlib [default]
 no-zlib-dynamic [default]
Configuring for solaris64-x86_64-gcc
IsMK1MF   =no
CC=gcc
CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H  -Wa,--noexecstack
SHARED_CFLAG  =-fPIC
DEFINES   =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS OPENSSL_NO_DYNAMIC_ENGINE 
OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 
OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM 
BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG =
PLIB_LFLAG=
EX_LIBS   =-lresolv -lsocket -lnsl -ldl
APPS_OBJ  =
CPUID_OBJ =x86_64cpuid.o
UPLINK_OBJ=
BN_ASM=asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o 
rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM=ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o 
aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o 
sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC  =cmll-x86_64.o cmll_misc.o
MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
PADLOCK_OBJ   =e_padlock-x86_64.o
CHACHA_ENC=chacha-x86_64.o
POLY1305_OBJ  =poly1305-x86_64.o
BLAKE2_OBJ=
PROCESSOR =
RANLIB=/usr/ccs/bin/ranlib
ARFLAGS   =
PERL  =/opt/perl5/bin/perl

SIXTY_FOUR_BIT_LONG mode

Configured for solaris64-x86_64-gcc.


% make
   :
make[1]: Leaving directory '/tmp/openssl-1.1.0-pre4'
/opt/perl5/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
 "-oMakefile" apps/CA.pl.in > "apps/CA.pl"
chmod a+x apps/CA.pl
/opt/perl5/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
 "-oMakefile" tools/c_rehash.in > "tools/c_rehash"
chmod a+x tools/c_rehash
Makefile:170: recipe for target 'depend' failed
make: *** [depend] Error 1



Other information
OS: Solaris10 x86/64

perl version:v5.22.1
gcc version: 4.8.5
ld: /usr/ccs/bin/ld


Best Regards,


--- Kiyoshi 

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

Re: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make fails with "recipe for target 'depend' failed" on solaris64-x86_64

[Rainer Jung via RT]

Works here. No more "-nt" error, no warnings or other STDERR output.
Tested on Solaris 10 Sparc using GCC doing a 32 bit build and another 64 
bit build. Builds succeed, tests pass.

Am 19.03.2016 um 12:34 schrieb Richard Levitte via RT:
> Fixed in commit 243a98d4a03a411dfe6db727dbf90adbfa2e7474. Can we close this
> ticket for good now?
>
> Vid Sat, 19 Mar 2016 kl. 10.14.25, skrev levitte:
>> Right. A little 'exit 0' in the right spot should fix that.
>>
>> It's true that the dependencies that are generated depend quite a lot
>> on what
>> you've built so far, I hope that's not an enormous bother.
>>
>> Cheers,
>> Richard
>>
>> Vid Sat, 19 Mar 2016 kl. 01.31.53, skrev e...@efca.com:
>>> still not working right.
>>> Attached a longish log file extract.
>>> But root cause seems to be that we try to process test dependencies
>>> while doing depend in crypto, way before we had done any work in
>>> the test subdir. That causes the find to exit with failed status
>>> aborting
>>> the depend.
>>>
>>>
 -- Original Message --

 Fixup show in last message has now been merged with master, commit
 a6adf099cbd7c3bc5c7051ad3d334636ef5e7f90

 --
 Richard Levitte
 levi...@openssl.org

 --
 Ticket here: http://rt.openssl.org/Ticket/Display.html?id=
 Please log in as guest with password guest if prompted

 --
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-
 dev
>>>
>>
>>
>> --
>> Richard Levitte
>> levi...@openssl.org
>
>
> --
> Richard Levitte
> levi...@openssl.org


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4447] Missing generators for sparcv8plus.s, sparcv8.s and sparccpuid.s (OpenSSL 1.1.0 pre4)

[Rainer Jung via RT]

Hi Richard,

Am 19.03.2016 um 12:49 schrieb Richard Levitte via RT:
> So I'm wondering, what happens if you apply the attached patch?

Works like a charm, tested on Solaris 10 Sparc doing a 32bit build and a 
64bit build. The intermediate ".s" (lower case) file no longer gets 
generated and instead the object file gets directly compiled from the .S 
(upper case) file.

Builds succeed, tests pass.

As always: thanks a bunch!

Regards,

Rainer

> Vid Sat, 19 Mar 2016 kl. 11.02.09, skrev levitte:
>> Hmmm...
>>
>> Actually, I'm thinkg that src2obj() should check if the original file
>> exists as
>> given before changing .S to .s... That should work, since we're always
>> generating 'foo.s' from 'asm/foo.S' (or 'asm/foo.pl', but that's not
>> applicable
>> here)... The directory difference should make it safe.
>>
>> I'll experiment a little, there's also the question of the assembler
>> files in
>> crypto/, but they are a problem in other builds as well...
>>
>> So, fix coming up! But not quite your solution.
>>
>> Vid Fre, 18 Mar 2016 kl. 21.56.37, skrev rainer.j...@kippdata.de:
>>> When building OpenSSL 1.1.0 pre4 on Solaris Sparc for 64 Bits I get
>>> an
>>> error, because before building crypto/bn/sparcv8plus.o first
>>> generates
>>> crypto/bn/asm/sparcv8plus.s from crypto/bn/asm/sparcv8plus.S with the
>>> following command
>>>
>>> gcc -E crypto/bn/asm/sparcv8plus.S > crypto/bn/asm/sparcv8plus.s
>>>
>>> This command is missing CFLAGS. As a consequence, the generated .s
>>> file
>>> does not work for 64 bit compilation and compiling it fails with lots
>>> of
>>> errors of type:
>>>
>>> /usr/ccs/bin/as: "crypto/bn/asm/sparcv8plus.s", line ...: error:
>>> detect
>>> global register use not covered .register pseudo-op
>>>
>>> The pre3 version compiled crypto/bn/asm/sparcv8plus.o directly from
>>> crypto/bn/asm/sparcv8plus.S (upper case ".S") using "gcc -c" and all
>>> CFLAGS, include flags etc.
>>>
>>> So either one does the same for pre4 or one adds a Makefile rule for
>>> crypto/bn/asm/sparcv8plus.s generating it from
>>> crypto/bn/asm/sparcv8plus.S respecting CFLAGS, include dirs etc. or
>>> simply copying it from the .S file.
>>>
>>> I think the switch from .S to .s happens in src2obj() inside
>>> Configurations/unix-Makefile.tmpl. So if it is intentional, you need
>>> to
>>> define and use a generator from .S to .s.
>>>
>>> The following patch worked for me, but I don't know whether it is how
>>> it
>>> should work:
>>>
>>>
>>> --- Configurations/00-base-templates.conf Wed Mar 16 19:18:09 2016
>>> +++ Configurations/00-base-templates.conf Fri Mar 18 22:31:59 2016
>>> @@ -198,8 +198,8 @@
>>> },
>>> sparcv9_asm => {
>>> template => 1,
>>> - cpuid_asm_src => "sparcv9cap.c sparccpuid.S",
>>> - bn_asm_src => "asm/sparcv8plus.S sparcv9-mont.S
>>> sparcv9a-mont.S vis3-mont.S sparct4-mont.S sparcv9-gf2m.S",
>>> + cpuid_asm_src => "sparcv9cap.c sparccpuid.s",
>>> + bn_asm_src => "sparcv8plus.s sparcv9-mont.S sparcv9a-mont.S
>>> vis3-mont.S sparct4-mont.S sparcv9-gf2m.S",
>>> ec_asm_src => "ecp_nistz256.c ecp_nistz256-sparcv9.S",
>>> des_asm_src => "des_enc-sparc.S fcrypt_b.c dest4-sparcv9.S",
>>> aes_asm_src => "aes_core.c aes_cbc.c aes-sparcv9.S
>>> aest4-sparcv9.S",
>>> @@ -213,7 +213,7 @@
>>> sparcv8_asm => {
>>> template => 1,
>>> cpuid_asm_src => "",
>>> - bn_asm_src => "asm/sparcv8.S",
>>> + bn_asm_src => "sparcv8.s",
>>> des_asm_src => "des_enc-sparc.S fcrypt_b.c",
>>> perlasm_scheme => "void"
>>> },
>>>
>>>
>>> (upper case ".S" to lower case ".s" and removal of "asm/").
>>>
>>> and two build.info changes:
>>>
>>>
>>> --- crypto/build.info Wed Mar 16 19:18:08 2016
>>> +++ crypto/build.info Fri Mar 18 22:11:43 2016
>>> @@ -21,6 +21,8 @@
>>>
>>> GENERATE[x86_64cpuid.s]=x86_64cpuid.pl $(PERLASM_SCHEME)
>>>
>>> +GENERATE[sparccpuid.s]=sparccpuid.S
>>> +
>>> GENERATE[ia64cpuid.s]=ia64cpuid.S
>>> GENERATE[ppccpuid.s]=ppccpuid.pl $(PERLASM_SCHEME)
>>> GENERATE[pariscid.s]=pariscid.pl $(PERLASM_SCHEME)
>>>
>>>
>>> --- crypto/bn/build.info Wed Mar 16 19:18:09 2016
>>> +++ crypto/bn/build.info Fri Mar 18 22:11:43 2016
>>> @@ -24,6 +24,9 @@
>>> $(PERLASM_SCHEME) $(CFLAGS) $(LIB_CFLAGS) $(PROCESSOR)
>>> DEPEND[x86-gf2m.s]=../perlasm/x86asm.pl
>>>
>>> +GENERATE[sparcv8.s]=asm/sparcv8.S
>>> +GENERATE[sparcv8plus.s]=asm/sparcv8plus.S
>>> +
>>> GENERATE[sparcv9a-mont.S]=asm/sparcv9a-mont.pl $(PERLASM_SCHEME)
>>> INCLUDE[sparcv9a-mont.o]=..
>>> GENERATE[sparcv9-mont.S]=asm/sparcv9-mont.pl $(PERLASM_SCHEME)
>>>
>>>
>>> This seems to be consistent with how it is done for
>>>
>>> crypto/ia64cpuid.S
>>> crypto/aes/asm/aes-ia64.S
>>> crypto/bn/asm/ia64.S
>>>
>>> The same changes probably need to be done for
>>>
>>> crypto/s390xcpuid.S
>>> crypto/bn/asm/s390x.S
>>>
>>> Regards,
>>>
>>> Rainer
>>>
>>
>>
>> --
>> Richard Levitte
>> levi...@openssl.org
>
>
> --
> Richard Levitte
> levi...@openssl.org


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4447
Please log in as guest with password guest if prompted

-- 

Re: [openssl-dev] [openssl.org #4447] Missing generators for sparcv8plus.s, sparcv8.s and sparccpuid.s (OpenSSL 1.1.0 pre4)

[Rainer Jung]

Hi Richard,

Am 19.03.2016 um 12:49 schrieb Richard Levitte via RT:

So I'm wondering, what happens if you apply the attached patch?


Works like a charm, tested on Solaris 10 Sparc doing a 32bit build and a 
64bit build. The intermediate ".s" (lower case) file no longer gets 
generated and instead the object file gets directly compiled from the .S 
(upper case) file.


Builds succeed, tests pass.

As always: thanks a bunch!

Regards,

Rainer


Vid Sat, 19 Mar 2016 kl. 11.02.09, skrev levitte:

Hmmm...

Actually, I'm thinkg that src2obj() should check if the original file
exists as
given before changing .S to .s... That should work, since we're always
generating 'foo.s' from 'asm/foo.S' (or 'asm/foo.pl', but that's not
applicable
here)... The directory difference should make it safe.

I'll experiment a little, there's also the question of the assembler
files in
crypto/, but they are a problem in other builds as well...

So, fix coming up! But not quite your solution.

Vid Fre, 18 Mar 2016 kl. 21.56.37, skrev rainer.j...@kippdata.de:

When building OpenSSL 1.1.0 pre4 on Solaris Sparc for 64 Bits I get
an
error, because before building crypto/bn/sparcv8plus.o first
generates
crypto/bn/asm/sparcv8plus.s from crypto/bn/asm/sparcv8plus.S with the
following command

gcc -E crypto/bn/asm/sparcv8plus.S > crypto/bn/asm/sparcv8plus.s

This command is missing CFLAGS. As a consequence, the generated .s
file
does not work for 64 bit compilation and compiling it fails with lots
of
errors of type:

/usr/ccs/bin/as: "crypto/bn/asm/sparcv8plus.s", line ...: error:
detect
global register use not covered .register pseudo-op

The pre3 version compiled crypto/bn/asm/sparcv8plus.o directly from
crypto/bn/asm/sparcv8plus.S (upper case ".S") using "gcc -c" and all
CFLAGS, include flags etc.

So either one does the same for pre4 or one adds a Makefile rule for
crypto/bn/asm/sparcv8plus.s generating it from
crypto/bn/asm/sparcv8plus.S respecting CFLAGS, include dirs etc. or
simply copying it from the .S file.

I think the switch from .S to .s happens in src2obj() inside
Configurations/unix-Makefile.tmpl. So if it is intentional, you need
to
define and use a generator from .S to .s.

The following patch worked for me, but I don't know whether it is how
it
should work:


--- Configurations/00-base-templates.conf Wed Mar 16 19:18:09 2016
+++ Configurations/00-base-templates.conf Fri Mar 18 22:31:59 2016
@@ -198,8 +198,8 @@
},
sparcv9_asm => {
template => 1,
- cpuid_asm_src => "sparcv9cap.c sparccpuid.S",
- bn_asm_src => "asm/sparcv8plus.S sparcv9-mont.S
sparcv9a-mont.S vis3-mont.S sparct4-mont.S sparcv9-gf2m.S",
+ cpuid_asm_src => "sparcv9cap.c sparccpuid.s",
+ bn_asm_src => "sparcv8plus.s sparcv9-mont.S sparcv9a-mont.S
vis3-mont.S sparct4-mont.S sparcv9-gf2m.S",
ec_asm_src => "ecp_nistz256.c ecp_nistz256-sparcv9.S",
des_asm_src => "des_enc-sparc.S fcrypt_b.c dest4-sparcv9.S",
aes_asm_src => "aes_core.c aes_cbc.c aes-sparcv9.S
aest4-sparcv9.S",
@@ -213,7 +213,7 @@
sparcv8_asm => {
template => 1,
cpuid_asm_src => "",
- bn_asm_src => "asm/sparcv8.S",
+ bn_asm_src => "sparcv8.s",
des_asm_src => "des_enc-sparc.S fcrypt_b.c",
perlasm_scheme => "void"
},


(upper case ".S" to lower case ".s" and removal of "asm/").

and two build.info changes:


--- crypto/build.info Wed Mar 16 19:18:08 2016
+++ crypto/build.info Fri Mar 18 22:11:43 2016
@@ -21,6 +21,8 @@

GENERATE[x86_64cpuid.s]=x86_64cpuid.pl $(PERLASM_SCHEME)

+GENERATE[sparccpuid.s]=sparccpuid.S
+
GENERATE[ia64cpuid.s]=ia64cpuid.S
GENERATE[ppccpuid.s]=ppccpuid.pl $(PERLASM_SCHEME)
GENERATE[pariscid.s]=pariscid.pl $(PERLASM_SCHEME)


--- crypto/bn/build.info Wed Mar 16 19:18:09 2016
+++ crypto/bn/build.info Fri Mar 18 22:11:43 2016
@@ -24,6 +24,9 @@
$(PERLASM_SCHEME) $(CFLAGS) $(LIB_CFLAGS) $(PROCESSOR)
DEPEND[x86-gf2m.s]=../perlasm/x86asm.pl

+GENERATE[sparcv8.s]=asm/sparcv8.S
+GENERATE[sparcv8plus.s]=asm/sparcv8plus.S
+
GENERATE[sparcv9a-mont.S]=asm/sparcv9a-mont.pl $(PERLASM_SCHEME)
INCLUDE[sparcv9a-mont.o]=..
GENERATE[sparcv9-mont.S]=asm/sparcv9-mont.pl $(PERLASM_SCHEME)


This seems to be consistent with how it is done for

crypto/ia64cpuid.S
crypto/aes/asm/aes-ia64.S
crypto/bn/asm/ia64.S

The same changes probably need to be done for

crypto/s390xcpuid.S
crypto/bn/asm/s390x.S

Regards,

Rainer




--
Richard Levitte
levi...@openssl.org



--
Richard Levitte
levi...@openssl.org

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

Re: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make fails with "recipe for target 'depend' failed" on solaris64-x86_64

[Rainer Jung via RT]

Am 18.03.2016 um 19:33 schrieb Richard Levitte via RT:
> Vid Fre, 18 Mar 2016 kl. 18.07.31, skrev rainer.j...@kippdata.de:
>> Am 18.03.2016 um 17:49 schrieb Richard Levitte via RT:
>>> Vid Fre, 18 Mar 2016 kl. 16.34.05, skrev rainer.j...@kippdata.de:
 I had the same problem. /bin/sh on Solaris does not understand the
 "-
 nt"
 operator used in the definition of the "depend" target in the top-
 level
 Makefile, e.g. in line

 if [ Makefile -nt Makefile ] ...
>>>
>>> That can't be the cause, because whatever the exit code from the test
>>> is, it's
>>> "swallowed" by 'if'. A little like this is:
>>
>> If it were syntactically correct, but it isn't.
>
> You'll have to explain that to me. I just had a look here:
> https://docs.oracle.com/cd/E26502_01/html/E29030/sh-1.html:
>
>
 if list ; then list elif list ; then list ; ] . . . [ else list ; ] fi
>
 The list following if is executed and, if it returns a zero exit status,
> the list following the first then is executed. Otherwise, the list following
> elif is executed and, if its value is zero, the list following the next then 
> is
> executed. Failing that, the else list is executed. If no else list or then 
> list
> is executed, then the if command returns a zero exit status.
>
>> I added the "set -ex" and:
>>
>> % make depend
>> catdepends=false
>> + [ Makefile -nt Makefile ]
>> Makefile:172: recipe for target 'depend' failed
>> make: *** [depend] Error 1
>
> Would the following make a difference?
>
> if ( [ Makefile -nt Makefile ] 2>/dev/null || [ $$? = 1 ] ); then

Yes, that works. Works means: it correctly detects, that Solaris doesn't 
support "-nt" and adds all dependencies to the end of the Makefile.

> or perhaps using 'test' instead of '[' (and removing the ']' in that case, of
> course)?

Also works.

>> or - since there's no more real need for the catdepends variable
>
> That's an incorrect assumption. 'depend' is run as part of the larger targets,
> and on some slower systems, having the same file copying happening every time
> is quite time consuming. Checking if there's a need for all the data copying 
> at
> all first takes down the time for the cases when the .d files haven't been
> updated since last time.

I think the variant I suggested still does that, at least in my tests. 
If there's no newer dependency, then it will not add anything to the 
Makefile, since the result of the "find" command is empty.

depend:
 @:
 @( sed -e '/^# DO NOT DELETE THIS LINE.*/,$$d' < Makefile; \
   echo '# DO NOT DELETE THIS LINE -- make depend depends on it.'; \
   echo; \
   for d in `find $(DEPS) -newer Makefile`; do \
 if [ -f $$d ]; then cat $$d; fi; \
   done ) > Makefile.new; \
 if cmp Makefile.new Makefile >/dev/null 2>&1; then \
   rm -f Makefile.new; \
 else \
  mv -f Makefile.new Makefile; \
 fi
 @:

With "no need for catdepends" I only wanted to say there's no need any 
more for first checking, then remembering the check result in the 
variable and then executing on the check result. Instead one can move 
the dependency change detection directly into the latter part as shown 
in my previous mail. It has also the benefit of only adding the 
dependency snippets that are newer than the Makefile, not all of them. 
Is that a logically correct aim, or do we need to add all dependencies 
even if only some of the files are newer than Makefile?

Your suggested fix would mean on platforms without "-nt" we would always 
rebuild and that's in fact what I observed (make test rebuilds a lot of 
object files) whereas the "find" variant should work on all platforms 
and only adds the dependencies that are newer than the Makefile. If you 
want to add all dependencies even if only one is newer than the 
Makefile, a "find" based solution would be:

depend:
 @:
 @if [ "X`find $(DEPS) -newer Makefile`" != "X" ]; then \
   ( sed -e '/^# DO NOT DELETE THIS LINE.*/,$$d' < Makefile; \
 echo '# DO NOT DELETE THIS LINE -- make depend depends on 
it.'; \
 echo; \
 for d in $(DEPS); do \
   if [ -f $$d ]; then cat $$d; fi; \
 done ) > Makefile.new; \
   if cmp Makefile.new Makefile >/dev/null 2>&1; then \
 rm -f Makefile.new; \
   else \
 mv -f Makefile.new Makefile; \
   fi; \
 fi
 @:

One final suggestion: if the final solution will still contain a "for d 
in ..." loop, you might want to rename the loop variable from d to 
something else, like e.g. "f". Why? It took me quite some time to 
understand why

sed -e '/^# DO NOT DELETE THIS LINE.*/,$$d' < Makefile;

works although the variable "d" was only defined below that line. Only 
later I noticed, that here the "$$d" has a totally different meaning 
than $$d in the loop (",$$" resolves to ",$" meaning until end of file 
and "d" is 

Re: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make fails with "recipe for target 'depend' failed" on solaris64-x86_64

[Rainer Jung via RT]

Am 18.03.2016 um 17:49 schrieb Richard Levitte via RT:
> Vid Fre, 18 Mar 2016 kl. 16.34.05, skrev rainer.j...@kippdata.de:
>> I had the same problem. /bin/sh on Solaris does not understand the "-
>> nt"
>> operator used in the definition of the "depend" target in the top-
>> level
>> Makefile, e.g. in line
>>
>> if [ Makefile -nt Makefile ] ...
>
> That can't be the cause, because whatever the exit code from the test is, it's
> "swallowed" by 'if'. A little like this is:

If it were syntactically correct, but it isn't. I added the "set -ex" and:

% make depend
catdepends=false
+ [ Makefile -nt Makefile ]
Makefile:172: recipe for target 'depend' failed
make: *** [depend] Error 1

Line numbers are:

 167 # To check if test has the file age comparison operator, we
 168 # simply try, and rely test to exit with 0 if the comparison
 169 # was true, 1 if false, and most importantly, 2 if it doesn't
 170 # recognise the operator.
 171 depend:
 172 @:
 173 @set -ex; catdepends=false; \
 174 if [ Makefile -nt Makefile ] 2>/dev/null || [ $$? = 1 
]; then \
...

> $ if (exit 1); then :; fi; echo $? 0 I cannot tell you what's going wrong, and
> the only suggestion I currently have is to apply the attached patch and then
> reconfigure and make and see what the output is. Can I assume you know what
> 'set -ex' does?

You can and "man sh" would tell me otherwise ;)

I tried a couple of other approaches. One could simulate the "-nt" using 
perl and stat() but my current favorite is using "find" with "-newer":

 171 depend:
 172 @:
 173 @catdepends=false; \
 174 if [ "X`find $(DEPS) -newer Makefile`" != "X" ]; then \
 175   catdepends=true; \
 176 fi; \
 177 if [ $$catdepends = true ]; then \
... rest unchanged

or - since there's no more real need for the catdepends variable shorter 
and more direct:

 171 depend:
 172 @:
 173 @( sed -e '/^# DO NOT DELETE THIS LINE.*/,$$d' < 
Makefile; \
 174   echo '# DO NOT DELETE THIS LINE -- make depend 
depends on it.'; \
 175   echo; \
 176   for d in `find $(DEPS) -newer Makefile`; do \
 177 if [ -f $$d ]; then cat $$d; fi; \
 178   done ) > Makefile.new; \
 179 if cmp Makefile.new Makefile >/dev/null 2>&1; then \
 180   rm -f Makefile.new; \
 181 else \
 182  mv -f Makefile.new Makefile; \
 183 fi
 184 @:

I don't know which length restrictions for $(DEPS) as find arguments we 
have, but at least for current OpenSSL 1.1.0 pre 4 on Solaris - which is 
typically more limited than Linux - it works. One could also iterate 
over "find" using one DEPS file for each iteration, but that would be 
much slower due to the overhead of forking "find" lots of times (on my 
slow system the above takes less than one second, but 6 seconds after 
switching to a loop over $(DEPS) with find inside the loop.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make fails with "recipe for target 'depend' failed" on solaris64-x86_64

[Rainer Jung]

Am 18.03.2016 um 17:49 schrieb Richard Levitte via RT:

Vid Fre, 18 Mar 2016 kl. 16.34.05, skrev rainer.j...@kippdata.de:

I had the same problem. /bin/sh on Solaris does not understand the "-
nt"
operator used in the definition of the "depend" target in the top-
level
Makefile, e.g. in line

if [ Makefile -nt Makefile ] ...


That can't be the cause, because whatever the exit code from the test is, it's
"swallowed" by 'if'. A little like this is:


If it were syntactically correct, but it isn't. I added the "set -ex" and:

% make depend
catdepends=false
+ [ Makefile -nt Makefile ]
Makefile:172: recipe for target 'depend' failed
make: *** [depend] Error 1

Line numbers are:

167 # To check if test has the file age comparison operator, we
168 # simply try, and rely test to exit with 0 if the comparison
169 # was true, 1 if false, and most importantly, 2 if it doesn't
170 # recognise the operator.
171 depend:
172 @:
173 @set -ex; catdepends=false; \
174 if [ Makefile -nt Makefile ] 2>/dev/null || [ $$? = 1 
]; then \

...


$ if (exit 1); then :; fi; echo $? 0 I cannot tell you what's going wrong, and
the only suggestion I currently have is to apply the attached patch and then
reconfigure and make and see what the output is. Can I assume you know what
'set -ex' does?


You can and "man sh" would tell me otherwise ;)

I tried a couple of other approaches. One could simulate the "-nt" using 
perl and stat() but my current favorite is using "find" with "-newer":


171 depend:
172 @:
173 @catdepends=false; \
174 if [ "X`find $(DEPS) -newer Makefile`" != "X" ]; then \
175   catdepends=true; \
176 fi; \
177 if [ $$catdepends = true ]; then \
... rest unchanged

or - since there's no more real need for the catdepends variable shorter 
and more direct:


171 depend:
172 @:
173 @( sed -e '/^# DO NOT DELETE THIS LINE.*/,$$d' < 
Makefile; \
174   echo '# DO NOT DELETE THIS LINE -- make depend 
depends on it.'; \

175   echo; \
176   for d in `find $(DEPS) -newer Makefile`; do \
177 if [ -f $$d ]; then cat $$d; fi; \
178   done ) > Makefile.new; \
179 if cmp Makefile.new Makefile >/dev/null 2>&1; then \
180   rm -f Makefile.new; \
181 else \
182  mv -f Makefile.new Makefile; \
183 fi
184 @:

I don't know which length restrictions for $(DEPS) as find arguments we 
have, but at least for current OpenSSL 1.1.0 pre 4 on Solaris - which is 
typically more limited than Linux - it works. One could also iterate 
over "find" using one DEPS file for each iteration, but that would be 
much slower due to the overhead of forking "find" lots of times (on my 
slow system the above takes less than one second, but 6 seconds after 
switching to a loop over $(DEPS) with find inside the loop.


Regards,

Rainer

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

Re: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make fails with "recipe for target 'depend' failed" on solaris64-x86_64

[Rainer Jung]

Am 18.03.2016 um 19:33 schrieb Richard Levitte via RT:

Vid Fre, 18 Mar 2016 kl. 18.07.31, skrev rainer.j...@kippdata.de:

Am 18.03.2016 um 17:49 schrieb Richard Levitte via RT:

Vid Fre, 18 Mar 2016 kl. 16.34.05, skrev rainer.j...@kippdata.de:

I had the same problem. /bin/sh on Solaris does not understand the
"-
nt"
operator used in the definition of the "depend" target in the top-
level
Makefile, e.g. in line

if [ Makefile -nt Makefile ] ...


That can't be the cause, because whatever the exit code from the test
is, it's
"swallowed" by 'if'. A little like this is:


If it were syntactically correct, but it isn't.


You'll have to explain that to me. I just had a look here:
https://docs.oracle.com/cd/E26502_01/html/E29030/sh-1.html:



if list ; then list elif list ; then list ; ] . . . [ else list ; ] fi



The list following if is executed and, if it returns a zero exit status,

the list following the first then is executed. Otherwise, the list following
elif is executed and, if its value is zero, the list following the next then is
executed. Failing that, the else list is executed. If no else list or then list
is executed, then the if command returns a zero exit status.


I added the "set -ex" and:

% make depend
catdepends=false
+ [ Makefile -nt Makefile ]
Makefile:172: recipe for target 'depend' failed
make: *** [depend] Error 1


Would the following make a difference?

if ( [ Makefile -nt Makefile ] 2>/dev/null || [ $$? = 1 ] ); then


Yes, that works. Works means: it correctly detects, that Solaris doesn't 
support "-nt" and adds all dependencies to the end of the Makefile.



or perhaps using 'test' instead of '[' (and removing the ']' in that case, of
course)?


Also works.


or - since there's no more real need for the catdepends variable


That's an incorrect assumption. 'depend' is run as part of the larger targets,
and on some slower systems, having the same file copying happening every time
is quite time consuming. Checking if there's a need for all the data copying at
all first takes down the time for the cases when the .d files haven't been
updated since last time.


I think the variant I suggested still does that, at least in my tests. 
If there's no newer dependency, then it will not add anything to the 
Makefile, since the result of the "find" command is empty.


depend:
@:
@( sed -e '/^# DO NOT DELETE THIS LINE.*/,$$d' < Makefile; \
  echo '# DO NOT DELETE THIS LINE -- make depend depends on it.'; \
  echo; \
  for d in `find $(DEPS) -newer Makefile`; do \
if [ -f $$d ]; then cat $$d; fi; \
  done ) > Makefile.new; \
if cmp Makefile.new Makefile >/dev/null 2>&1; then \
  rm -f Makefile.new; \
else \
 mv -f Makefile.new Makefile; \
fi
@:

With "no need for catdepends" I only wanted to say there's no need any 
more for first checking, then remembering the check result in the 
variable and then executing on the check result. Instead one can move 
the dependency change detection directly into the latter part as shown 
in my previous mail. It has also the benefit of only adding the 
dependency snippets that are newer than the Makefile, not all of them. 
Is that a logically correct aim, or do we need to add all dependencies 
even if only some of the files are newer than Makefile?


Your suggested fix would mean on platforms without "-nt" we would always 
rebuild and that's in fact what I observed (make test rebuilds a lot of 
object files) whereas the "find" variant should work on all platforms 
and only adds the dependencies that are newer than the Makefile. If you 
want to add all dependencies even if only one is newer than the 
Makefile, a "find" based solution would be:


depend:
@:
@if [ "X`find $(DEPS) -newer Makefile`" != "X" ]; then \
  ( sed -e '/^# DO NOT DELETE THIS LINE.*/,$$d' < Makefile; \
echo '# DO NOT DELETE THIS LINE -- make depend depends on 
it.'; \

echo; \
for d in $(DEPS); do \
  if [ -f $$d ]; then cat $$d; fi; \
done ) > Makefile.new; \
  if cmp Makefile.new Makefile >/dev/null 2>&1; then \
rm -f Makefile.new; \
  else \
mv -f Makefile.new Makefile; \
  fi; \
fi
@:

One final suggestion: if the final solution will still contain a "for d 
in ..." loop, you might want to rename the loop variable from d to 
something else, like e.g. "f". Why? It took me quite some time to 
understand why


sed -e '/^# DO NOT DELETE THIS LINE.*/,$$d' < Makefile;

works although the variable "d" was only defined below that line. Only 
later I noticed, that here the "$$d" has a totally different meaning 
than $$d in the loop (",$$" resolves to ",$" meaning until end of file 
and "d" is the sed delete command). So my confusion was triggered by 
seeing "$$d" in two places close to each other but having totally 
different meaning. If 

[openssl-dev] [openssl.org #4448] Solaris pod install "sed" problem for OpenSSL 1.1.0 pre4

[Rainer Jung via RT]

The following line in Configurations/unix-Makefile.tmpl is non 
standards-conforming and breaks using Solaris sed:

...
   sed -e ':a;{N;s/\n/ /;ba}' | \
...

The man page tells me, Solaris sed mandatory needs a newline before the 
closing "}". The above construct throws errors when executing 
PROCESS_PODS during the make target install_man_docs:

   Label too long: :a;{N;s/\n/ /;ba}

Since I didn't find a way to include a verbatim newline in 
Configurations/unix-Makefile.tmpl that survives to the generated 
Makefile, I instead applied the following patch:

--- unix-Makefile.tmpl Wed Mar 16 19:18:09 2016
+++ unix-Makefile.tmpl  Fri Mar 18 22:23:57 2016
@@ -512,7 +512,7 @@
  # The third sed removes the description and turns all commas into spaces
  # Voilà, you have a space separated list of names!
  EXTRACT_NAMES=sed -e '1,/^=head1  *NAME *$$/d;/^=head1/,$$d' | \
-  sed -e ':a;{N;s/\n/ /;ba}' | \
+  $(PERL) -p -0 -e 's/\n/ /g; END {print "\n"}' | \
sed -e 's/ - .*$$//;s/,/ /g'
  PROCESS_PODS=\
 set -e; \

The perl based solution should work everywhere.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4448
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4450] OpenSSL 1.1.0 pre4 podpath: cannot find suitable replacement path, cannot resolve link

[Rainer Jung via RT]

Errors during make install:

Cannot find "EXAMPLES" in podpath: cannot find suitable replacement 
path, cannot resolve link
Cannot find "X509_STORE_set_default_paths" in podpath: cannot find 
suitable replacement path, cannot resolve link
Cannot find "SSL_pending()" in podpath: cannot find suitable replacement 
path, cannot resolve link
Cannot find "EVP_MAX_IV_LENGTH" in podpath: cannot find suitable 
replacement path, cannot resolve link
Cannot find "EVP_EncryptInit_ex" in podpath: cannot find suitable 
replacement path, cannot resolve link
Cannot find "HMAC_Init_ex" in podpath: cannot find suitable replacement 
path, cannot resolve link
Cannot find "EVP_DecryptInit_ex" in podpath: cannot find suitable 
replacement path, cannot resolve link
Cannot find "HMAC_Init_ex" in podpath: cannot find suitable replacement 
path, cannot resolve link

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4450
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] API Problems in current master

[Rainer Jung]

Am 13.03.2016 um 23:42 schrieb Richard Moore:

By the way, the serial number accessors are missing from the docs too or
is that just a problem with the website?


Fixed by Steve today as 
https://github.com/openssl/openssl/commit/bae26b582e6cbff4bce5edc46907e6f331bc19e5.


Regards,

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

Re: [openssl-dev] API Problems in current master

[Rainer Jung]

Am 13.03.2016 um 14:34 schrieb Richard Moore:

I'm currently testing the new release by trying to port Qt to use it
(with the compatibility stuff disabled). Here are the first problems
I've hit:

How do we get the certificate serial number? We were doing
x509->cert_info->serialNumber to get it as an ASN1_INTEGER.


ASN1_INTEGER *X509_get_serialNumber(X509 *x);

implemented in crypto/x509/x509_cmp.c:

ASN1_INTEGER *X509_get_serialNumber(X509 *a)
{
return >cert_info.serialNumber;
}


https://www.openssl.org/docs/manmaster/crypto/EVP_PKEY_type.html says:
"EVP_PKEY_type() returns the type of key corresponding to the value
type. The type of a key can be obtained with EVP_PKEY_type(pkey->type)."
except it can't
because the structure is now opaque.


The docs should be fixed, but there's:

int EVP_PKEY_id(const EVP_PKEY *pkey);
int EVP_PKEY_base_id(const EVP_PKEY *pkey);

implemented in crypto/evp/p_lib.c:

int EVP_PKEY_id(const EVP_PKEY *pkey)
{
return pkey->type;
}

int EVP_PKEY_base_id(const EVP_PKEY *pkey)
{
return EVP_PKEY_type(pkey->type);
}

HTH

Regards,

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

Re: [openssl-dev] [openssl-commits] [openssl] master update

[Rainer Jung]

Am 09.03.2016 um 22:53 schrieb Richard Levitte:

The branch master has been updated
via  64b9d84bfd0da0305a1df9b97ffbdc3898f59e62 (commit)
   from  2b8fa1d56cd3a41d666994a1b2ed9df0f5e5d1ec (commit)


- Log -
commit 64b9d84bfd0da0305a1df9b97ffbdc3898f59e62
Author: Richard Levitte 
Date:   Wed Mar 9 22:34:27 2016 +0100

 When grepping something starting with a dash, remember to use -e


Strictly speaking "grep -e" has another meaning. If a leading dash is 
the only problem to fix, one can use "grep --", so the below would become


if echo "$CONFIG_OPTS" | grep -- "--classic" >/dev/null; then

Regards,

Rainer


 Reviewed-by: Viktor Dukhovni 

---

Summary of changes:
  .travis.yml | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index ce7e208..0865817 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -60,7 +60,7 @@ matrix:
  before_script:
  - sh .travis-create-release.sh $TRAVIS_OS_NAME
  - tar -xvzf _srcdist.tar.gz
-- if echo "$CONFIG_OPTS" | grep "--classic" >/dev/null; then
+- if echo "$CONFIG_OPTS" | grep -e "--classic" >/dev/null; then
srcdir=.;
cd _srcdist;
else
@@ -83,7 +83,7 @@ before_script:
  - cd ..

  script:
-- if echo "$CONFIG_OPTS" | grep "--classic" >/dev/null; then
+- if echo "$CONFIG_OPTS" | grep -e "--classic" >/dev/null; then
cd _srcdist;
else
cd _build;

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

[openssl-dev] Solaris Sparc: Text relocation remains against symbol ecp_nistz256_point_add_vis3

[Rainer Jung]

OpenSSl 1.1.0 pre 3 on Solaris 10 Sparc using GCC 4.9.3 but Solaris 
linker and assembler


% /usr/ccs/bin/as -V
/usr/ccs/bin/as: SunOS 5.10 118683-08 Patch 07/05/2012

% /usr/ccs/bin/ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.497

When linking other software against libcrypto.a (static lib) I get:

Text relocation remains referenced
against symbol  offset  in file
ecp_nistz256_point_add_vis3 0x25f0c 
/shared/build/autobuild/install/openssl-1.1.0pre3sp1-1.solaris10.sparc/lib/libcrypto.a(ecp_nistz256-sparcv9.o)

ld: fatal: relocations remain against allocatable but non-writable sections

I know that I can work around this using -Bsymbolic for the linker, but 
since over the years the need for -Bsymbolic in the stable branches has 
gone away, I thought I let you know that there's now a new symbol 
(ecp_nistz256_point_add_vis3) with that problem.


elfdump show the symbol as:

[Index]   Value  SizeType  Bind  Other Shndx   Name
[19]|161184|1720|NOTY |GLOB |0|2 
|ecp_nistz256_point_add_vis3


I will happily test any suggested changes.

Regards,

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

Re: [openssl-dev] Solaris 10 80-test_ca failure

[Rainer Jung]

Am 03.03.2016 um 18:51 schrieb Erik Forsberg:


I have been having 32-bit only test failures from test_ca
for quite a while now on Solaris 10 (1.1.pre), Finally figured
out what is wrong.

I build both 32-bit and 64-bit libraries.
My /usr/local/bin/perl is always 64-bit,
used to be required for assembler support.

LD_PRELOAD is used to force newly built libs into the test process
using util/shlib_wrap.sh

So, when building 32-bit libs, shlib_wrap tries to preload a 32-bit
libcrypto/libssl into the 64-bit perl process when CA.pl is invoked.
This causes failure on Solaris 10, but seems to be ignored on Solaris 11.

There was specific support to handle 64-bit builds in shlib_wrap, this
method also needs to be used for 32-bit builds.

This patch makes it work in all cases for me.
Someone using SPARC should review what /usr/bin/file
reports for an old 32-bit SPARC library (if such still exists)
I have no access to SPARC hardware.


% /usr/bin/file /lib/libc.so.1

/lib/libc.so.1: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ 
Required, dynamically linked, not stripped, no debugging information 
available


% /usr/bin/file /lib/sparcv9/libc.so

/lib/sparcv9/libc.so:   ELF 64-bit MSB dynamic lib SPARCV9 Version 1, 
dynamically linked, not stripped, no debugging information available


This was on Solaris 10 Sparc.

Regards,

Rainer


*** shlib_wrap.sh   Tue Feb 16 23:55:51 2016
--- /usr/local/src/openssl-1.1//shlib_wrap.sh   Tue Mar  1 23:21:23 2016
***
*** 27,32 
--- 27,37 
 LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
 preload_var=LD_PRELOAD_64
 ;;
+   *ELF\ 32*SPARC*|*ELF\ 32*80386*)
+   [ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
+   LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
+   preload_var=LD_PRELOAD_32
+   ;;
 # Why are newly built .so's preloaded anyway? Because run-time
 # .so lookup path embedded into application takes precedence
 # over LD_LIBRARY_PATH and as result application ends up linking



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

[openssl-dev] [openssl.org #4329] OpenSSL 1.1.0 pre3: internal error in tls_post_process_client_key_exchange during reneg

[Rainer Jung via RT]

Running the Apache test suite for Apache 2.4 with OpenSSL 1.1.0 
adjustments, I get

error:14180044:SSL 
routines:tls_post_process_client_key_exchange:internal error

The error is triggered in tls_post_process_client_key_exchange() file 
ssl/statem/statem_srvr.c which checks s->s3->handshake_buffer against NULL:

2631 if (!s->s3->handshake_buffer) {
2632 SSLerr(SSL_F_TLS_POST_PROCESS_CLIENT_KEY_EXCHANGE,
2633ERR_R_INTERNAL_ERROR);
2634 ossl_statem_set_error(s);
2635 return WORK_ERROR;
2636 }

Running the test, the handshake_buffer gets set in 
ssl3_init_finished_mac(), then cleared in 
tls_post_process_client_hello() which calls ssl3_digest_cached_records() 
with "keep" equals 0. This resets the handshake_buffer to NULL.

Then later tls1_generate_master_secret() again calls 
ssl3_digest_cached_records() with keep set to 1 (but the 
handshake_buffer is already NULL and stays like that) and finally 
tls_post_process_client_key_exchange() throws the error because the 
handshake_buffer is NULL.

The message sequence was:

server Loop: SSLv3/TLS write hello request
client Loop: SSLv3/TLS write client hello
server Loop: SSLv3/TLS read client hello
server Loop: SSLv3/TLS write server hello
server Loop: SSLv3/TLS write certificate
server Loop: SSLv3/TLS write key exchange
server Loop: SSLv3/TLS write server done
client Loop: SSLv3/TLS write client hello
client Loop: SSLv3/TLS read server hello
client Loop: SSLv3/TLS read server certificate
client Loop: SSLv3/TLS read server key exchange
client Loop: SSLv3/TLS read server done
client Loop: SSLv3/TLS write client certificate
client Loop: SSLv3/TLS write client key exchange
client Loop: SSLv3/TLS write certificate verify
client Loop: SSLv3/TLS write change cipher spec
client Loop: SSLv3/TLS write finished
server Loop: SSLv3/TLS write server done
server Loop: SSLv3/TLS read client certificate
server error:14180044:SSL 
routines:tls_post_process_client_key_exchange:internal error

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4329
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Rainer Jung via RT]

Am 17.02.2016 um 19:51 schrieb Salz, Rich:
>
>>*header = c;
>> +header++;
>
> Header isn't used after that assignment.  How does this line change anything?

The call to load_iv() that occurs next, has as its first argument 
header_pp which is a pointer to header:

char **header_pp = 

Inside load_iv() this pointer is named fromp and is immediately being 
dereferenced:

from = *fromp;

so "from" is an alias to "header", it contains the same address as 
"header". When being dereferenced, "from" will return the same char, 
that "header" points to.

Now in load_iv() "from" is used to iterate over the IV hex chars:

 for (i = 0; i < num; i++) {
 if ((*from >= '0') && (*from <= '9'))
 v = *from - '0';
 else if ((*from >= 'A') && (*from <= 'F'))
 v = *from - 'A' + 10;
 else if ((*from >= 'a') && (*from <= 'f'))
 v = *from - 'a' + 10;
 else {
 PEMerr(PEM_F_LOAD_IV, PEM_R_BAD_IV_CHARS);
 return (0);
 }
 from++;
 to[i / 2] |= v << (long)((!(i & 1)) * 4);
 }

Since *from == *header == ',' at the beginning of the loop, this bombs. 
"header" needs to be incremented to actually point to the beginning of 
the IV.

I hope this is understandable. It took me a moment as well to 
understand, how "from" in load_iv() relates to "header" in 
PEM_get_EVP_CIPHER_INFO().

I checked the patch with the reproduction case before posting and also 
added some debug logging to the "from" loop to double check.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Rainer Jung]

Am 17.02.2016 um 19:51 schrieb Salz, Rich:



   *header = c;
+header++;


Header isn't used after that assignment.  How does this line change anything?


The call to load_iv() that occurs next, has as its first argument 
header_pp which is a pointer to header:


char **header_pp = 

Inside load_iv() this pointer is named fromp and is immediately being 
dereferenced:


from = *fromp;

so "from" is an alias to "header", it contains the same address as 
"header". When being dereferenced, "from" will return the same char, 
that "header" points to.


Now in load_iv() "from" is used to iterate over the IV hex chars:

for (i = 0; i < num; i++) {
if ((*from >= '0') && (*from <= '9'))
v = *from - '0';
else if ((*from >= 'A') && (*from <= 'F'))
v = *from - 'A' + 10;
else if ((*from >= 'a') && (*from <= 'f'))
v = *from - 'a' + 10;
else {
PEMerr(PEM_F_LOAD_IV, PEM_R_BAD_IV_CHARS);
return (0);
}
from++;
to[i / 2] |= v << (long)((!(i & 1)) * 4);
}

Since *from == *header == ',' at the beginning of the loop, this bombs. 
"header" needs to be incremented to actually point to the beginning of 
the IV.


I hope this is understandable. It took me a moment as well to 
understand, how "from" in load_iv() relates to "header" in 
PEM_get_EVP_CIPHER_INFO().


I checked the patch with the reproduction case before posting and also 
added some debug logging to the "from" loop to double check.


Regards,

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

[openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Rainer Jung via RT]

Change

https://github.com/openssl/openssl/commit/33a6d5a0e565e08758bcb6af456ec657c3a7a76a

introduced a bug in crypto/pem/pem_lib.c function 
PEM_get_EVP_CIPHER_INFO(). One line was removed that is actually needed.

The following patch fixes it:

--- crypto/pem/pem_lib.c 2016-02-15 19:08:07.0 +0100
+++ crypto/pem/pem_lib.c  2016-02-17 18:45:14.092815000 +0100
@@ -537,6 +537,7 @@
  *header = '\0';
  cipher->cipher = enc = EVP_get_cipherbyname(dekinfostart);
  *header = c;
+header++;

  if (enc == NULL) {
  PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, 
PEM_R_UNSUPPORTED_ENCRYPTION);


While you are at it, the following is a small improvement which is used 
in similar ways close to this place:

--- crypto/pem/pem_lib.c.orig 2016-02-17 18:45:14.092815000 +0100
+++ crypto/pem/pem_lib.c  2016-02-17 19:15:19.901402000 +0100
@@ -509,6 +509,7 @@
  PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, PEM_R_NOT_ENCRYPTED);
  return (0);
  }
+header += 9;
  for (; (*header != '\n') && (*header != '\0'); header++) ;
  if (*header == '\0') {
  PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, PEM_R_SHORT_HEADER);



How to reproduce the bug:

OpenSSL> dsaparam -out dsa-test 2048
Generating DSA parameters, 2048 bit long prime
This could take some time
...

OpenSSL> gendsa -out dsa-test.pem -aes128 dsa-test
Generating DSA key, 2048 bits
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

OpenSSL> dsa -in dsa-test.pem -text
read DSA key
unable to load Private Key
4280523828:error:09065067:PEM routines:load_iv:bad iv chars:pem_lib.c:568:
unable to load Key
error in dsa

The same happens e.g. when using -des or -des3 instead of -aes128.

Without incrementing the header pointer, the parsing of the line

DEK-Info: AES-128-CBC,CBFAADAF91039DF800391FB382CAC3B9

proceeds at the comma, instead of the hex string and bombs out.

Thanks and Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles

[Rainer Jung via RT]

Hi there,

I built OpenSSL 1.1.0-pre3 with

PERL="/usr/bin/env perl"

This has the nice effect, that any generated perl artefact that itself 
uses perl via the "#!" notation contains

   #!/usr/bin/env perl

and not the perl path to which "/usr/bin/env perl" resolves during build 
time on the build machine.

The only tweak I had to apply to make this work, was quoting a few lines 
that use PERL=$(PERL) in Makefile.in:


--- Makefile.in   2016-02-15 20:51:46.0 +0100
+++ Makefile.in 2016-02-16 00:28:16.51073 +0100
@@ -512,8 +512,8 @@
  errors:
 $(PERL) util/ck_errf.pl -strict */*.c */*/*.c
 $(PERL) util/mkerr.pl -recurse -write
-   (cd engines; $(MAKE) PERL=$(PERL) errors)
-   (cd crypto/ct; $(MAKE) PERL=$(PERL) errors)
+   (cd engines; $(MAKE) PERL="$(PERL)" errors)
+   (cd crypto/ct; $(MAKE) PERL="$(PERL)" errors)

  ordinals: util/libeay.num util/ssleay.num test_ordinals TABLE
  util/libeay.num::
@@ -521,7 +521,7 @@
  util/ssleay.num::
 $(PERL) util/mkdef.pl ssl update
  test_ordinals:
-   TOP=$(TOP) PERL=$(PERL) $(PERL) test/run_tests.pl test_ordinals
+   TOP=$(TOP) PERL="$(PERL)" $(PERL) test/run_tests.pl test_ordinals

  TABLE: Configure Configurations/*.conf
 (echo 'Output of `Configure TABLE'"':"; \


--- test/Makefile.in  2016-02-15 20:51:48.0 +0100
+++ test/Makefile.in2016-02-16 00:28:16.545897000 +0100
@@ -155,12 +155,12 @@
 @sh $(TOP)/util/point.sh dummytest.c $@

  tests: exe apps
-   TOP=$(TOP) PERL=$(PERL) $(PERL) run_tests.pl $(TESTS)
+   TOP=$(TOP) PERL="$(PERL)" $(PERL) run_tests.pl $(TESTS)

  errors:

  list-tests:
-   @TOP=$(TOP) PERL=$(PERL) $(PERL) run_tests.pl list
+   @TOP=$(TOP) PERL="$(PERL)" $(PERL) run_tests.pl list

  apps:
 @(cd ..; $(MAKE) DIRS=apps all)


You might want to consider this change.

Looking through all assignments in Makefile.in files and ignoring the 
possible use of paths with spaces (people shouldn't use them), i see one 
other line which might benefit from quoting. It is in test/Makefile.in:

top:
(cd ..; $(MAKE) DIRS=$(DIR) TESTS=$(TESTS) all)

Here the TESTS=$(TESTS) by default assigns "alltests" which is just one 
token, but the plural form of the variable suggests one could also set 
it to contain multiple test names and then the above line might fail.

Regards and thanks,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] How to do reneg with client certs in 1.1.0 API

[Rainer Jung]

Am 08.02.2016 um 15:26 schrieb Matt Caswell:

On 08/02/16 13:45, Tomas Mraz wrote:

On Po, 2016-02-08 at 12:34 +, Matt Caswell wrote:


On 08/02/16 12:11, Rainer Jung wrote:



Renegotiation isn't entirely within the control of the server. A
server
can request that a renegotiation takes place. It is up to the client
whether it honours that request immediately; or perhaps its finishes
off
sending some application data before it gets around to honouring it;
or
perhaps it doesn't honour it at all.


   SSL_renegotiate(ssl);
   SSL_do_handshake(ssl);


This sequence makes the server send the HelloVerifyRequest. It is
then
back in a state where it can continue to receive application data
from
the client. At some later point the client may or may not initiate a
reneg.


   SSL_set_state(ssl, SSL_ST_ACCEPT);
   SSL_do_handshake(ssl);


This is really not a good idea, and I suspect is a hack that was
originally copied from s_server :-). Doing this will make the
connection
fail if the client sends application data next (which it is allowed
to do).

We don't know what we're going to get next from the client it could
be
more application data. It could be an immediate start of a new
handshake. The correct thing for the server to do is to attempt to
read
application data. If we happen to get a handshake instead then it
will
be automatically handled.


What if the server wants to discard all the application data that was
sent before the renegotiation completed? Or how the server can
recognize which part of data was received before renegotiation
completed and which after it?



You never get app data from two different epochs returned in a single
API call. In certain situations you can get a handshake finish occur
followed by a read of application data all within a single API call.
It's also valid that the attempt to read application data handled the
handshake but doesn't actually return any app data because the client
didn't send any yet (it *just* did the reneg).

So if you want to discard all application data until the client has
initiated a reneg and supplied a certificate then you'll want to do
something like:

SSL_renegotiate(ssl);
SSL_do_handshake(ssl);
do {
 read_some_app_data();
 if(no_client_cert_yet()) {
 discard_app_data();
 }
} while(no_client_cert_yet());


After doing some experiments I ended up calling SSL_peek() with a length 
of 0 bytes. That seems to reliably trigger the renegotiation handshake. 
Using this approach was easier, since we (Apache) have to handle various 
reneg scenarios:


- waiting for client certs
- doing a reneg because cipher requirements changed but no client certs 
involved

- sometimes no application data is expected after the renegotiation

I hope that effect of SSL_peek(ssl, buf, 0) is not just an 
implementation artefact and we can actually rely on it.


Regards,

Rainer

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

[openssl-dev] [openssl.org #4303] OpenSSL 1.1.0 renegotiation problem (s_server/s_client)

[Rainer Jung via RT]

Using OpenSSL 1.1.0pre2 I see renegotiation problems between s_client 
and s_server (but also in Apache mod_ssl).

First starting:

   s_server -cert server.crt -key server.pem -accept 8443 -debug -state

Using default temp DH parameters
ACCEPT

Now starting

   s_client -connect localhost:8443 -debug -state

I see on the server side:

SSL_accept:before SSL initialization
...
SSL_accept:SSLv3/TLS write finished
-BEGIN SSL SESSION PARAMETERS-
MFoCAQECAgMDBALAMAQABDBWP93rPtTOpEyh6rNq87IB7+8JHLQ3Kgg3dDxFrxhH
6gdH1LM33nePKWE8je2ezmKhBgIEVr4d6aIEAgIcIKQGBAQBrQMCAQE=
-END SSL SESSION PARAMETERS-
Shared 
ciphers:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-CAMELLIA256-SHA384:ECDHE-ECDSA-CAMELLIA256-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:ECDH-RSA-CAMELLIA256-SHA384:ECDH-ECDSA-CAMELLIA256-SHA384:AES256-CCM8:AES256-CCM:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA256:CAMELLIA256-SHA:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:ECDHE-RSA-A!
 ES128-GC
M-SHA256
Signature Algorithms: 
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Signature Algorithms: 
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Supported Elliptic Curve Point Formats: 
uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Supported Elliptic Curves: 
P-256:P-521:brainpoolP512r1:brainpoolP384r1:P-384:brainpoolP256r1:secp256k1:B-571:K-571:K-409:B-409:K-283:B-283
Shared Elliptic curves: 
P-256:P-521:brainpoolP512r1:brainpoolP384r1:P-384:brainpoolP256r1:secp256k1:B-571:K-571:K-409:B-409:K-283:B-283
CIPHER is ECDHE-RSA-AES256-GCM-SHA384
Secure Renegotiation IS supported


and on the client side:


CONNECTED(0003)
SSL_connect:before SSL initialization
...
-END CERTIFICATE-
subject=/C=US/ST=California/L=San 
Francisco/O=ASF/OU=httpd-test/rsa-test/CN=localhost/emailAddress=test-...@httpd.apache.org
issuer=/C=US/ST=California/L=San 
Francisco/O=ASF/OU=httpd-test/CN=ca/emailAddress=test-...@httpd.apache.org
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1672 bytes and written 447 bytes
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
 Protocol  : TLSv1.2
 Cipher: ECDHE-RSA-AES256-GCM-SHA384
 Session-ID: 
B57844A325DB8E6781073CD615128A88342E850B5A11B9966A2B7C2F475B1727
 Session-ID-ctx:
 Master-Key: 
563FDDEB3ED4CEA44CA1EAB36AF3B201EFEF091CB4372A0837743C45AF1847EA0747D4B337DE778F29613C8DED9ECE62
 PSK identity: None
 PSK identity hint: None
 SRP username: None
 TLS session ticket lifetime hint: 7200 (seconds)
 TLS session ticket:
...

 Start Time: 1455300073
 Timeout   : 7200 (sec)
 Verify return code: 21 (unable to verify the first certificate)
 Extended master secret: yes
---


Now pressing R and return on the client side results on the server side in:


read from 0x2c9978 [0x2d7abb] (5 bytes => 5 (0x5))
 - 16 03 03 01 63c
read from 0x2c9978 [0x2d7ac0] (355 bytes => 355 (0x163))
SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write certificate
SSL_accept:error in error
ERROR
4280523828:error:14179044:SSL 
routines:tls_construct_server_key_exchange:internal 
error:statem/statem_srvr.c:1778:
shutting down SSL
CONNECTION CLOSED
ACCEPT


and on the client side


R
RENEGOTIATING
SSL_connect:SSL negotiation finished successfully
write to 0x2cf680 [0x2dbc13] (360 bytes => 360 (0x168))
...
SSL_connect:SSLv3/TLS write client hello
read from 0x2cf680 [0x2d76c3] (5 bytes => 0 (0x0))
SSL_connect:error in SSLv3/TLS write client hello
write:errno=0
error in s_client


I ran into the same problem when trying to use OpenSSL 1.1.0pre2 in 
Apache for mod_ssl. The code in question is in 
tls_construct_server_key_exchange().

The following conditions triggers the jump to err:

1773 if (type & 

[openssl-dev] [openssl.org #4304] [Patch] Support HTTP-on-HTTPS-Error for OpenSSL 1.1.0

[Rainer Jung via RT]

Hi there,

please find attached a patch proposal to reintroduce the HTTP-on-HTTPS 
detection for OpenSSL 1.1.0. The feature is present until 1.0.2, but 
although the error codes are still in the 1.1.0 header files, the 
detection is gone.

Comments welcome!

Regards,

Rainer

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4304
Please log in as guest with password guest if prompted

--- ssl/record/ssl3_record.c	2016-01-14 10:51:33.0 +0100
+++ ssl/record/ssl3_record.c	2016-02-12 22:41:06.59751 +0100
@@ -275,6 +275,20 @@
 }
 
 if ((version >> 8) != SSL3_VERSION_MAJOR) {
+if (s->first_packet) {
+/* Go back to start of packet */
+p -= 5;
+if ((strncmp("GET ", (char *)p, 4) == 0) ||
+(strncmp("POST ", (char *)p, 5) == 0) ||
+(strncmp("HEAD ", (char *)p, 5) == 0) ||
+(strncmp("PUT ", (char *)p, 4) == 0)) {
+SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_HTTP_REQUEST);
+goto err;
+} else if (strncmp("CONNECT", (char *)p, 7) == 0) {
+SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_HTTPS_PROXY_REQUEST);
+goto err;
+}
+}
 SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_WRONG_VERSION_NUMBER);
 goto err;
 }
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] How to do reneg with client certs in 1.1.0 API

[Rainer Jung]

Am 08.02.2016 um 13:34 schrieb Matt Caswell:

On 08/02/16 12:11, Rainer Jung wrote:

I'm adding support for OpenSSL 1.1.0 to the Apache web server.

I struggle to migrate the renegotiation code in the case wehere we want
the client to send a client cert. The current code works like explained in

   http://www.linuxjournal.com/node/5487/print

After using SSL_set_verify() it calls

   SSL_renegotiate(ssl);
   SSL_do_handshake(ssl);
   SSL_set_state(ssl, SSL_ST_ACCEPT);
   SSL_do_handshake(ssl);

for reasons given in the article.

The new 1.1.0 API no longer allows to set the state using
SSL_set_state(). The old article states, that calling
SSL_set_accept_state() is not the right thing to do. Looking at
s_server.c doesn't give a hint what to do instead, because it looks like
it reads the client certs just raw from the socket.

Any hint what would replace the above sequence or at least the
SSL_set_state(ssl, SSL_ST_ACCEPT)?

Thanks a bunch and regards,


Renegotiation isn't entirely within the control of the server. A server
can request that a renegotiation takes place. It is up to the client
whether it honours that request immediately; or perhaps its finishes off
sending some application data before it gets around to honouring it; or
perhaps it doesn't honour it at all.


   SSL_renegotiate(ssl);
   SSL_do_handshake(ssl);


This sequence makes the server send the HelloVerifyRequest. It is then
back in a state where it can continue to receive application data from
the client. At some later point the client may or may not initiate a reneg.


   SSL_set_state(ssl, SSL_ST_ACCEPT);
   SSL_do_handshake(ssl);


This is really not a good idea, and I suspect is a hack that was
originally copied from s_server :-). Doing this will make the connection
fail if the client sends application data next (which it is allowed to do).

We don't know what we're going to get next from the client it could be
more application data. It could be an immediate start of a new
handshake. The correct thing for the server to do is to attempt to read
application data. If we happen to get a handshake instead then it will
be automatically handled.


OK, tried it and it partially works. More precisely: when the cipher is 
AES128-SHA it works, bur for ECDHE-RSA-AES128-SHA256 I run into an error 
in tls_construct_server_key_exchange() (file statem/statem_srvr.c).


The following conditions triggers the jump to err:

   1773 if (type & (SSL_kECDHE | SSL_kECDHEPSK)) {
   1774 int nid;
   1775
   1776 if (s->s3->tmp.pkey != NULL) {
   1777 SSLerr(SSL_F_TLS_CONSTRUCT_SERVER_KEY_EXCHANGE,
   1778ERR_R_INTERNAL_ERROR);
   1779 goto err;
   1780 }

By comparing the communication for the two ciphers I see the following flow:

write 69/69 bytes
SSLv3/TLS write hello request
- try to read app data -> I/O error, 5 bytes expected to read
read 5/5 bytes
read 576/576
Handshake: start
before SSL initialization
before SSL initialization
SSLv3/TLS read client hello
write 149/149
SSLv3/TLS write server hello
write 2021/2021
SSLv3/TLS write certificate

And here for the ECDHE case the error triggered by the above check.

In the AES case we proceed

write 1173/1173
SSLv3/TLS write certificate request
write 69/69 bytes
write 3412/3412 bytes
SSLv3/TLS write server done
error in SSLv3/TLS write server done
read 5/5 bytes
read 1952/1952
SSLv3/TLS write server done
Successful client certificate verification

Any idea how to clear s->s3->tmp.pkey so that the check doesn't trigger?

I see SSL_clear() but from its description I doubt that is should be 
used here.


Regards,

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

[openssl-dev] How to do reneg with client certs in 1.1.0 API

[Rainer Jung]

I'm adding support for OpenSSL 1.1.0 to the Apache web server.

I struggle to migrate the renegotiation code in the case wehere we want 
the client to send a client cert. The current code works like explained in


  http://www.linuxjournal.com/node/5487/print

After using SSL_set_verify() it calls

  SSL_renegotiate(ssl);
  SSL_do_handshake(ssl);
  SSL_set_state(ssl, SSL_ST_ACCEPT);
  SSL_do_handshake(ssl);

for reasons given in the article.

The new 1.1.0 API no longer allows to set the state using 
SSL_set_state(). The old article states, that calling 
SSL_set_accept_state() is not the right thing to do. Looking at 
s_server.c doesn't give a hint what to do instead, because it looks like 
it reads the client certs just raw from the socket.


Any hint what would replace the above sequence or at least the 
SSL_set_state(ssl, SSL_ST_ACCEPT)?


Thanks a bunch and regards,

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

[openssl-dev] SSL_R_HTTP_REQUEST no longer supported in 1.1.0

[Rainer Jung]

The constant SSL_R_HTTP_REQUEST is still defined, but I can't find code 
that sets it and practical experiments indicate it is no longer set.


In Apache land we use it to detect "HTTP spoken on HTTPS port". OpenSSL 
1.0.2 has code in ssl23_get_client_hello() that checks read bytes 
against "HEAD", "GET", "POST" etc. to detect this situation.


Was this feature removed intentionally or will it come back until the 
final 1.1.0 release?


Regards,

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

[openssl-dev] [openssl.org #4292] SSL_CTX_set_mode.pod:101: Unknown command paragraph "======"

[Rainer Jung via RT]

OpenSSL 1.1.0 produces the error

   SSL_CTX_set_mode.pod:101: Unknown command paragraph "=="

during "make install".

It looks like line 101 is indeed an unintended addition introduced by

 
https://github.com/openssl/openssl/commit/bc8857bf70f5428bc2f0d26162ed59e3abb11fb1

The error does only show up when using old tools, e.g. no error for 
"Pod::Man 2.16 (Pod::Simple 3.05)" but error for "Pod::Man v1.37, 
Pod::Parser v1.14". But in this case I think the right solution is to 
simply remove the offending line from the pod. It looks like it 
shouldn't be there.

Thanks and regards,

Rainer



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4292
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] OpenSSL Security Advisory

[Rainer Jung]

Hi there,

reading the last advisory again, I noticed, that there's one logical 
inconsistency.


First:

OpenSSL before 1.0.2f will reuse the key if:
...
- Static DH ciphersuites are used. The key is part of the certificate 
and so it will always reuse it. This is only supported in 1.0.2.



and then:

It will not reuse the key for DHE ciphers suites if:
- SSL_OP_SINGLE_DH_USE is set
...

So what's the situation if both situations apply, static DH ciphersuites 
are used and SSL_OP_SINGLE_DH_USE is set is set. Which of these is 
stronger? Will the key be reused? Or is that combination impossible? It 
doesn't seem to be clear to me from the wording in the advisory.


Thanks for any clarification.

Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Rainer Jung]

Am 03.02.2016 um 00:30 schrieb Kurt Roeckx:

On Tue, Feb 02, 2016 at 10:34:32PM +0100, Rainer Jung wrote:

Hi there,

reading the last advisory again, I noticed, that there's one logical
inconsistency.

First:

OpenSSL before 1.0.2f will reuse the key if:
...
- Static DH ciphersuites are used. The key is part of the certificate and so
it will always reuse it. This is only supported in 1.0.2.


and then:

It will not reuse the key for DHE ciphers suites if:
- SSL_OP_SINGLE_DH_USE is set
...

So what's the situation if both situations apply, static DH ciphersuites are
used and SSL_OP_SINGLE_DH_USE is set is set.


Note that it says DHE ciphers, excluding the DH ciphers.


Thanks Matt and Kurt for enlightening me.

Regards,

Rainer

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

[openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

[Rainer Jung]

Hi,

the list of downloadable files on http://openssl.org/source/ contains 
pre1 *and* pre2 files for 1.1. Furthermore pre1 is listed above pre2. 
IMHO pre2 is what people should test and pre1 is no longer entitled to 
be listed on that page. So I suggest to remove pre1 from the list.


I don't know how this list is maintained, if auto-generated or manually. 
It seems the web git is not public.


In addition one could wish to put the preferred major version (1.0.2?) 
first in the list. Despite the version explanations in front of the 
list, it would help people to choose the right one. But of course what 
is preferred might change over time and is harder to automate with 
scripting.


Thanks and regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4247] 1.1.0-pre2 on Sparc: incomplete adjustments for EVP_CIPHER_CTX opaqueness

[Rainer Jung via RT]

Building 1.1.0-pre2 on Solaris Sparc I get compilation errors, e.g.

e_des.c: In function 'des_init_key':
e_des.c:250:23: error: dereferencing pointer to incomplete type
  int mode = ctx->cipher->flags & EVP_CIPH_MODE;


The following patch fixes them:

Index: crypto/evp/e_camellia.c
--- crypto/evp/e_camellia.c 2016-01-14 10:51:32.0 +0100
+++ crypto/evp/e_camellia.c 2016-01-16 04:01:44.443269000 +0100
@@ -119,10 +119,10 @@
  const unsigned char *iv, int enc)
  {
  int ret, mode, bits;
-EVP_CAMELLIA_KEY *dat = (EVP_CAMELLIA_KEY *) ctx->cipher_data;
+EVP_CAMELLIA_KEY *dat = (EVP_CAMELLIA_KEY *) 
EVP_CIPHER_CTX_cipher_data(ctx);

-mode = ctx->cipher->flags & EVP_CIPH_MODE;
-bits = ctx->key_len * 8;
+mode = EVP_CIPHER_CTX_mode(ctx);
+bits = EVP_CIPHER_CTX_key_length(ctx) * 8;

  cmll_t4_set_key(key, bits, >ks);

Index: crypto/evp/e_des.c
--- crypto/evp/e_des.c  2016-01-14 10:51:32.0 +0100
+++ crypto/evp/e_des.c  2016-01-16 03:56:50.834081000 +0100
@@ -247,7 +247,7 @@
  dat->stream.cbc = NULL;
  # if defined(SPARC_DES_CAPABLE)
  if (SPARC_DES_CAPABLE) {
-int mode = ctx->cipher->flags & EVP_CIPH_MODE;
+int mode = EVP_CIPHER_CTX_mode(ctx);

  if (mode == EVP_CIPH_CBC_MODE) {
  des_t4_key_expand(key, >ks.ks);
Index: crypto/evp/e_des3.c
--- crypto/evp/e_des3.c 2016-01-14 10:51:32.0 +0100
+++ crypto/evp/e_des3.c 2016-01-16 03:57:51.607381000 +0100
@@ -270,7 +270,7 @@
  dat->stream.cbc = NULL;
  # if defined(SPARC_DES_CAPABLE)
  if (SPARC_DES_CAPABLE) {
-int mode = ctx->cipher->flags & EVP_CIPH_MODE;
+int mode = EVP_CIPHER_CTX_mode(ctx);

  if (mode == EVP_CIPH_CBC_MODE) {
  des_t4_key_expand([0], >ks1);
@@ -297,7 +297,7 @@
  dat->stream.cbc = NULL;
  # if defined(SPARC_DES_CAPABLE)
  if (SPARC_DES_CAPABLE) {
-int mode = ctx->cipher->flags & EVP_CIPH_MODE;
+int mode = EVP_CIPHER_CTX_mode(ctx);

  if (mode == EVP_CIPH_CBC_MODE) {
  des_t4_key_expand([0], >ks1);


Thanks and regards,

Rainer


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

[openssl-dev] [openssl.org #4211] Document Perl requirements for OpenSSL 1.1.0

[Rainer Jung via RT]

Trying to build OpenSSL 1.1.0-pre1 on Solaris 10 Sparc I got the 
opportunity to get some insight in the perl requirements especially for 
running the new OpenSSL test suite. Solaris 10 Sparc comes with perl 
5.8.4 which suffices to build OpenSSL, but not for running the test suite.

Current Docs Situation
==

Currently the OpenSSL distribution contains the info:

- NEWS
o Reworked test suite, now based on perl, Test::Harness and Test::More

Maybe one should point to the main INSTALL "Note on Perl" section here?


- INSTALL
  To install OpenSSL, you will need:
...
   * Perl 5 with core modules (see 'Note on Perl' further down)
...

and further down:

  Note on Perl
  

  For our scripts, we rely quite a bit on Perl, and increasingly on
  some core Perl modules.  These Perl modules are part of the Perl
  source, so if you build Perl on your own, you should be set.

  However, if you install Perl as binary packages, the outcome might
  differ, and you may have to check that you do get the core modules
  installed properly.  We do not claim to know them all, but experience
  has told us the following:

  - on Linux distributions based on Debian, the package 'perl' will
install the core Perl modules as well, so you will be fine.
  - on Linux distributions based on RPMs, you will need to install
'perl-core' rather than just 'perl'.

  It is highly recommended that you have at least Perl version 5.12
  installed.


Here I wonder why version 5.12 is recommended. See below for some 
argument to actually require minimum version 5.10.1 instead of 
recommending 5.12.


- CHANGES
   *) New testing framework
  The testing framework has been largely rewritten and is now using
  perl and the perl modules Test::Harness and an extended variant of
  Test::More called OpenSSL::Test to do its work.  All test scripts in
  test/ have been rewritten into test recipes, and all direct calls to
  executables in test/Makefile have become individual recipes using the
  simplified testing OpenSSL::Test::Simple.

  For documentation on our testing modules, do:

 perldoc test/testlib/OpenSSL/Test/Simple.pm
 perldoc test/testlib/OpenSSL/Test.pm

  [Richard Levitte]

Maybe one should point to the main INSTALL "Note on Perl" section here?


- test/README

no info. Maybe one should point to the main INSTALL "Note on Perl" 
section here?


Minimum useful Perl Version
===

Minimum useful version for building and testing OpenSSL 1.1.0 IMHO is 
5.10, better 5.10.1. Reasons:

- several test suite files contain regexps with "\R" which has only been 
introduced in 5.10.0.
- the module File::Path is need in version >= 2 which was first bundled 
in 5.10.0
- the module parent.pm is needed, which was first bundled in 5.10.1

The only other requirement, Test::More in version >= 0.96 was first 
bundled much later in perl 5.13.4. It is probably a bit too new to 
require that perl version in general. Fortunately adding a newer 
Test::More to an existing perl is quite trivial, even using a private 
lib directory when not having write permissions for the perl 
installation. Since Test::More has no other dependencies and doesn't 
compile native stuff etc. during its installation, it suffices to add 
the directory lib/Test from the extracted Test::More download (ie. the 
following files):

Test/Builder/IO/Scalar.pm
Test/Builder/Tester/Color.pm
Test/Builder/Module.pm
Test/Builder/Tester.pm
Test/Tester/Capture.pm
Test/Tester/CaptureRunner.pm
Test/Tester/Delegate.pm
Test/use/ok.pm
Test/Tutorial.pod
Test/Simple.pm
Test/Builder.pm
Test/Tester.pm
Test/More.pm

into some directory and add that directory to the PERL5LIB env var 
before running make test. That is a bit dirty though (doesn't run the 
module test suite etc.).

Using cpan, it typically works to install a module like Test::More to a 
private directory /my/perl/dir by setting the following env vars before 
running cpan:

   PERL_LOCAL_LIB_ROOT=/my/perl/dir
   PERL_MB_OPT="--install_base /my/perl/dir"
   PERL_MM_OPT="INSTALL_BASE=/my/perl/dir"
   PERL5LIB=/my/perl/dir/lib/perl5

then running cpan and "install Test::More" and the setting the env var

   PERL5LIB=/my/perl/dir/lib/perl5

before building and especially testing OpenSSL.

So I wonder why the INSTALL file recommends 5.12? I'd require 5.10.1 and 
add some info about adding a sufficiently new (0.96) version of 
Test::More to an existing installation.

One can check which module was bundled with which perl version using the 
"corelist" command, that itself was first bundled a bit before 5.10.

Regards,

Rainer

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

[openssl-dev] [openssl.org #4210] Compiler warning for Sparc T4 DES opcodes

[Rainer Jung via RT]

OpenSSL 1.1.0 Pre 1
Platform: Sparc Solaris 10
Compiler: GCC 4.9.3

Warnings:

e_des.c: In function 'des_init_key':
e_des.c:239:29: warning: assignment from incompatible pointer type
  dat->stream.cbc = enc ? des_t4_cbc_encrypt : 
des_t4_cbc_decrypt;
  ^
e_des3.c: In function 'des_ede_init_key':
e_des3.c:266:29: warning: assignment from incompatible pointer type
  dat->stream.cbc = enc ? des_t4_ede3_cbc_encrypt :
  ^
e_des3.c: In function 'des_ede3_init_key':
e_des3.c:293:29: warning: assignment from incompatible pointer type
  dat->stream.cbc = enc ? des_t4_ede3_cbc_encrypt :
  ^

Definition of stream.cbc is

void (*cbc) (const void *, void *, size_t, const void *, void *);

and the functions whose pointers are assigned have declarations:

void des_t4_cbc_encrypt(const void *inp, void *out, size_t len,
 DES_key_schedule *ks, unsigned char iv[8]);
void des_t4_cbc_decrypt(const void *inp, void *out, size_t len,
 DES_key_schedule *ks, unsigned char iv[8]);

void des_t4_ede3_cbc_encrypt(const void *inp, void *out, size_t len,
  DES_key_schedule *ks, unsigned char iv[8]);
void des_t4_ede3_cbc_decrypt(const void *inp, void *out, size_t len,
  DES_key_schedule *ks, unsigned char iv[8]);

Problem likely introduced with 
https://github.com/openssl/openssl/commit/c5d975a74313268a36b6a6103cd37221724137c2
 
in 2013.

Regards,

Rainer

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

Re: [openssl-dev] [openssl.org #4138] Detection of assembler version

[Rainer Jung via RT]

Am 12.11.2015 um 22:20 schrieb Andy Polyakov via RT:
> Hi,
>
>> I just found out that building with at least with the French
>> locale the AVX code is missing.  The problem is this code in
>> crypto/sha/asm/sha1-x86_64.pl:
>> if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1`
>>  =~ /GNU assembler version ([2-9]\.[0-9]+)/) {
>>  $avx = ($1>=2.19) + ($1>=2.22);
>> }
>>
>> In English it returns:
>> GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU 
>> Binutils for Debian) 2.25.1
>>
>> But in French it returns:
>> Version de l'assembleur GNU 2.25.1 (x86_64-linux-gnu) utilisant la version 
>> BFD (GNU Binutils for Debian) 2.25.1
>>
>> A quick grep at least shows 17 affected files.
>>
>> The fix should be easy setting the locale to C when doing that
>> check.
>
> Oh! Though I'd like to suggest taking it even further. Namely setting
> LANG to C in top-most Makefile. This way we would also ensure that even
> compiler error messages are readable when reported. What do you think?
>
> (I wish one could do something like that even with Microsouple
> l'compilateur ;-)

Just a small addition: LANG gets overwritten by LC_* and LC_* gets 
overwritten by LC_ALL. So it would be strongest to set LC_ALL, not LANG.

Regards,

Rainer


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

Re: [openssl-dev] [openssl.org #4138] Detection of assembler version

[Rainer Jung]

Am 12.11.2015 um 22:20 schrieb Andy Polyakov via RT:

Hi,


I just found out that building with at least with the French
locale the AVX code is missing.  The problem is this code in
crypto/sha/asm/sha1-x86_64.pl:
if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1`
 =~ /GNU assembler version ([2-9]\.[0-9]+)/) {
 $avx = ($1>=2.19) + ($1>=2.22);
}

In English it returns:
GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU Binutils 
for Debian) 2.25.1

But in French it returns:
Version de l'assembleur GNU 2.25.1 (x86_64-linux-gnu) utilisant la version BFD 
(GNU Binutils for Debian) 2.25.1

A quick grep at least shows 17 affected files.

The fix should be easy setting the locale to C when doing that
check.


Oh! Though I'd like to suggest taking it even further. Namely setting
LANG to C in top-most Makefile. This way we would also ensure that even
compiler error messages are readable when reported. What do you think?

(I wish one could do something like that even with Microsouple
l'compilateur ;-)


Just a small addition: LANG gets overwritten by LC_* and LC_* gets 
overwritten by LC_ALL. So it would be strongest to set LC_ALL, not LANG.


Regards,

Rainer

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

Re: [openssl-dev] [openssl-commits] [openssl] master update

[Rainer Jung]

Am 22.06.2015 um 21:49 schrieb Rich Salz:

The branch master has been updated
via  75ba5c58c6b3b3326a6c3198100830afa120e7c3 (commit)
   from  389ebcecae2575188a4ff9566389ce694352be43 (commit)


- Log -
commit 75ba5c58c6b3b3326a6c3198100830afa120e7c3
Author: Rich Salz rs...@akamai.com
Date:   Sat Jun 13 17:18:47 2015 -0400

 RT3907: avoid local in testssl script

 Reviewed-by: Richard Levitte levi...@openssl.org

---

Summary of changes:
  test/testssl | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/test/testssl b/test/testssl
index 7e834a7..cb8e56a 100644
--- a/test/testssl
+++ b/test/testssl
@@ -118,11 +118,10 @@ echo test sslv2/sslv3 with both client and server 
authentication via BIO pair an
  $ssltest -bio_pair -server_auth -client_auth -app_verify $CA $extra || exit 1

  test_cipher() {
-  local cipher=$1
-  local protocol=$2
+_cipher=$1


It seems _cipher is never used and instead the function still uses 
cipher (which is the variable which is set elsewhere before calling 
the function test_cipher).



  echo Testing $cipher
  prot=
-if [ $protocol = SSLv3 ] ; then
+if [ $2 = SSLv3 ] ; then
prot=-ssl3
  fi
  $ssltest -cipher $cipher $prot


Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3907] Script testssl uses bash feature (non-POSIX)

[Rainer Jung via RT]

The script test/testssl uses the local keywork in test_cipher() since 
commit 
https://github.com/openssl/openssl/commit/e8356e32aed70d139eae2d05aeaeb160509262aa
 
(master, merged at least to 1.0.1 and 1.0.2).

This keyword is non-POSIX but the script is supposed to be run with 
/bin/sh. E.g. on Solaris systems this will produce an error

./testssl: local: not found

because the shell does not understand local as a keyword and tries to 
find an executable local in the path.

Currently this error is not fatal, because the keyword is used to mark 
the variables cipher and protocol as local. They are set from the 
first and second arguments of the function, which is simply ignored when 
the error happens. Fortunately all calls to the function pass global 
variables cipher and protocol as first and second arguments, so the 
failure is transparent since the global variables of the same name 
already have the correct values. $cipher and $protocol will still 
provide the correct contents in the function.

Possible fixes are:

- demand running the script using bash. Not all systems might provide 
bash though.

- simply removing the local keyword. Currently the script would 
overwrite the global variables cipher and protocol in test_cipher(), but 
those are only used to actually pass arguments to this function, so 
overwriting has no side effect

- removing the local keyword and renaming the local variables cipher and 
protocol so something like localCipher and localProtocol to remind about 
their scope. I suggest using this workaround.

I think there's no POSIX compliant way to scope variables in shell, at 
least not without playing difficult to read eval games.

Thanks,

Rainer

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

Re: [openssl-dev] OpenSSL version 1.0.2b released

[Rainer Jung]

The release notes mentioned and linked in all of the four release 
announcements still contain stale text:


https://www.openssl.org/news/openssl-1.0.2-notes.html
https://www.openssl.org/news/openssl-1.0.1-notes.html
https://www.openssl.org/news/openssl-1.0.0-notes.html
https://www.openssl.org/news/openssl-0.9.8-notes.html

The current release simply looks like

 Major changes between OpenSSL 1.0.2a and OpenSSL 1.0.2b [under 
development]


-

Major changes between OpenSSL 1.0.2 and OpenSSL 1.0.2a [19 Mar 2015]
...

So all entries for todays releases are still missing.

Maybe it is on its way, but since the announcement was 2 hours ago and 
the pages are linked in them I thought I'd better let you know.


Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

[Rainer Jung]

Am 09.06.2015 um 18:43 schrieb Bill Cox:

On Tue, Jun 9, 2015 at 9:38 AM, Salz, Rich rs...@akamai.com
mailto:rs...@akamai.com wrote:


 Zooko only asked for supporting Blake2 as an MD5 replacement, but he's 
being too modest.  I can't stress enough how important the speed of Blake2

The problem is that when you say Blake2 everyone (yes, everyone in
the entire world:) thinks it's one digest.  What's really meant is a
family of four.

That's not insurmountable, but it is confusing.


I agree.  How about Blake256 and Blake512, and leave out the parallel
versions?  That's not confusing.


Not an expert here, but according to

https://131002.net/blake/

and

http://en.wikipedia.org/wiki/BLAKE_%28hash_function%29

the terms BLAKE-256 and BLAKE-512 were already used by BLAKE, the 
predecessor of BLAKE2.


Regards,

Rainer

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

[openssl-dev] [openssl.org #3860] Some Sparc build configurations for gcc use deprecated -mv8

[Rainer Jung via RT]

Some build configurations for gcc on Sparc use the outdated gcc switch -mv8.

The switch was deprecated at least back for gcc 2.95.2 in October 1999 
([1][2]). GCC 4 does no longer support the -mv8 switch but instead now 
you have to use the switch that was already preferred for version 
2.95.2: -mcpu=v8 ([3]).

Please replace all occurrences of -mv8 in Configure (Release branches) 
resp. Configurations/10-main.conf (master) with -mcpu=v8.

Thanks,

Rainer

[1] https://gcc.gnu.org/onlinedocs/gcc-2.95.2/gcc_2.html#SEC19
[2] http://www.gnu.org/software/gcc/releases.html
[3] https://gcc.gnu.org/gcc-4.0/changes.html


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

Re: [openssl-dev] What key length is used for DHE by default ?

[Rainer Jung]

Am 22.05.2015 um 18:32 schrieb Nayna Jain:

Ok, I think this is what I didn't know. I was using openssl 1.0.1g client.

I still didn't have openssl 1.0.2 .


If it were trivial I think showing the temp key size would be a welcome 
backport to 1.0.1 before the next release. It is very useful in light of 
logjam but many people are not yet at 1.0.2. Of course they wont get the 
latest 1.0.1 immediately, but distros have a chance to backport.


Regards,

Rainer

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

Re: [openssl-dev] [openssl-commits] [openssl] master update

[Rainer Jung]

Am 10.04.2015 um 18:28 schrieb Viktor Dukhovni:

The branch master has been updated
via  34b0a927ab5c9232bcf864d524a9bf2558411700 (commit)
   from  e71cecd551f1d8beca20681184d94f7000a5e333 (commit)


- Log -
commit 34b0a927ab5c9232bcf864d524a9bf2558411700
Author: Viktor Dukhovni openssl-us...@dukhovni.org
Date:   Fri Apr 10 12:25:30 2015 -0400

 Polish shell script to avoid needless complexity.

 No need for here documents, just use yes or /dev/null.
 No need for || exit 1 clauses, just use set -e.

 Reviewed-by: Rich Salz rs...@openssl.org
 Reviewed-by: Richard Levitte levi...@openssl.org

---

Summary of changes:
  test/testca | 32 +---
  1 file changed, 9 insertions(+), 23 deletions(-)

diff --git a/test/testca b/test/testca
index d4d0159..4bcb1fd 100644
--- a/test/testca
+++ b/test/testca
@@ -1,5 +1,7 @@
  #!/bin/sh


So this is a /bin/sh script, not necessarily bash or ksh, and thus ...


@@ -9,35 +11,19 @@ else
  fi
  export PATH

-SSLEAY_CONFIG=-config CAss.cnf
-export SSLEAY_CONFIG
-
-OPENSSL=`pwd`/../util/opensslwrap.sh
-export OPENSSL
+export SSLEAY_CONFIG=-config CAss.cnf
+export OPENSSL=`pwd`/../util/opensslwrap.sh


...


-SSLEAY_CONFIG=-config Uss.cnf
-export SSLEAY_CONFIG
-$PERL ../apps/CA.pl -newreq || exit 1
+export SSLEAY_CONFIG=-config Uss.cnf
+$PERL ../apps/CA.pl -newreq

  SSLEAY_CONFIG=-config ../apps/openssl.cnf
-export SSLEAY_CONFIG
-


Combining

  X=Y
  export X

into

  export X=Y

does not work for all plain Shells. E.g. /bin/sh on Solaris is a Bourne 
Shell, which does not support this shortcut:


  $ export X=Y
  X=Y: is not an identifier

Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3771] bug: s_client loop at 100% cpu

[Rainer Jung]

Am 30.03.2015 um 09:51 schrieb John Denker via RT:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Contrast the following two examples:

#1:
time : | openssl s_client -connect www.openssl.org:443   /dev/null

real0m0.545s
user0m0.000s
sys 0m0.000s

#2:
time : | openssl s_client -quiet -connect www.openssl.org:443   /dev/null

real0m21.255s
user0m9.500s
sys 0m11.180s

- ---

Note the numerology:   21.225 - 9.5 - 11.18 =  0.545
That means that if you discount the half second it takes to actually
fetch the certificate, s_client was using 100% of the cpu the whole
time ... for more than 20 seconds.

I cannot imagine why it loops when -quiet is specified and not
otherwise.  I cannot imagine why it loops for 20.5 seconds instead
of 20.5 minutes or 20.5 hours.

This is 100% reproducible chez moi, although the timings naturally
vary by a little bit.


(gdb) where
#0  0x77903653 in __select_nocancel () at 
../sysdeps/unix/syscall-template.S:81
#1  0x00434d73 in s_client_main (argc=0, argv=0x7fffe680) at 
s_client.c:1794
#2  0x004039a8 in do_cmd (prog=0x990540, argc=4, argv=0x7fffe660) 
at openssl.c:470
#3  0x004035b8 in main (Argc=4, Argv=0x7fffe660) at openssl.c:366


That's maybe due to your chosen pipe shell construct. I can see the same 
behavior, if I choose to let s_client read from /dev/null and set 
-quiet. It then loops trying to read from /dev/null, getting 0 bytes 
but not EOF back. Without -quiet this does not happen. More precisely it 
seems to happen with -ign_eof, which is set as a side effect of -quiet.


Reading from /dev/null without -ign_eof lets s_client end immediately 
after the connect, with -ign_eof it hangs for 20 seconds (web server 
timeout?) and eats 1 CPU during that time doing a lot of reads from 
/dev/null.


The behavior is probably due to the following code snippet in s_client:

...
i = raw_read_stdin(cbuf, BUFSIZZ);

if ((!c_ign_eof)  ((i = 0) || (cbuf[0] == 'Q'))) {
BIO_printf(bio_err, DONE\n);
ret = 0;
goto shut;
}

Here I expect i==0, so without -ign_eof the code breaks the loop and 
goes to shut.


So this probably works as designed and when just running

openssl s_client -connect www.openssl.org:443

you shouldn't notice CPU hogging. Why -ign_eof is set as a side effect 
of -quiet I do not know.


Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3771] bug: s_client loop at 100% cpu

[Rainer Jung]

Am 30.03.2015 um 10:27 schrieb Rainer Jung:


So this probably works as designed and when just running

openssl s_client -connect www.openssl.org:443


Oups, I meant:

openssl s_client -quiet -connect www.openssl.org:443


you shouldn't notice CPU hogging. Why -ign_eof is set as a side effect
of -quiet I do not know.

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

Re: [openssl-dev] [openssl.org #3771] bug: s_client loop at 100% cpu

[Rainer Jung via RT]

Am 30.03.2015 um 09:51 schrieb John Denker via RT:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Contrast the following two examples:

 #1:
 time : | openssl s_client -connect www.openssl.org:443   /dev/null

 real0m0.545s
 user0m0.000s
 sys 0m0.000s

 #2:
 time : | openssl s_client -quiet -connect www.openssl.org:443   /dev/null

 real0m21.255s
 user0m9.500s
 sys 0m11.180s

 - ---

 Note the numerology:   21.225 - 9.5 - 11.18 =  0.545
 That means that if you discount the half second it takes to actually
 fetch the certificate, s_client was using 100% of the cpu the whole
 time ... for more than 20 seconds.

 I cannot imagine why it loops when -quiet is specified and not
 otherwise.  I cannot imagine why it loops for 20.5 seconds instead
 of 20.5 minutes or 20.5 hours.

 This is 100% reproducible chez moi, although the timings naturally
 vary by a little bit.


 (gdb) where
 #0  0x77903653 in __select_nocancel () at 
 ../sysdeps/unix/syscall-template.S:81
 #1  0x00434d73 in s_client_main (argc=0, argv=0x7fffe680) at 
 s_client.c:1794
 #2  0x004039a8 in do_cmd (prog=0x990540, argc=4, argv=0x7fffe660) 
 at openssl.c:470
 #3  0x004035b8 in main (Argc=4, Argv=0x7fffe660) at openssl.c:366

That's maybe due to your chosen pipe shell construct. I can see the same 
behavior, if I choose to let s_client read from /dev/null and set 
-quiet. It then loops trying to read from /dev/null, getting 0 bytes 
but not EOF back. Without -quiet this does not happen. More precisely it 
seems to happen with -ign_eof, which is set as a side effect of -quiet.

Reading from /dev/null without -ign_eof lets s_client end immediately 
after the connect, with -ign_eof it hangs for 20 seconds (web server 
timeout?) and eats 1 CPU during that time doing a lot of reads from 
/dev/null.

The behavior is probably due to the following code snippet in s_client:

...
 i = raw_read_stdin(cbuf, BUFSIZZ);

 if ((!c_ign_eof)  ((i = 0) || (cbuf[0] == 'Q'))) {
 BIO_printf(bio_err, DONE\n);
 ret = 0;
 goto shut;
 }

Here I expect i==0, so without -ign_eof the code breaks the loop and 
goes to shut.

So this probably works as designed and when just running

openssl s_client -connect www.openssl.org:443

you shouldn't notice CPU hogging. Why -ign_eof is set as a side effect 
of -quiet I do not know.

Regards,

Rainer


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

[openssl-dev] [openssl.org #3718] Broken NAME header in doc/crypto/d2i_ECPKParameters.pod (master and 1.0.2)

[Rainer Jung via RT]

File doc/crypto/d2i_ECPKParameters.pod starts with

=pod

=head1 NAME

d2i_ECPKParameters, i2d_ECPKParameters, d2i_ECPKParameters_bio, 
i2d_ECPKParameters_bio, d2i_ECPKParameters_fp, 
i2d_ECPKParameters_fp(fp,x), ECPKParameters_print, 
ECPKParameters_print_fp - Functions for decoding and encoding ASN1 
representations of elliptic curve entities

=head1 SYNOPSIS


The argument syntax (fp,x) breaks util/extract-names.pl which is used in 
the Makefile to determine which symlinks to create in the man pages 
directory:

% perl util/extract-names.pl  doc/crypto/d2i_ECPKParameters.pod
d2i_ECPKParameters
i2d_ECPKParameters
d2i_ECPKParameters_bio
i2d_ECPKParameters_bio
d2i_ECPKParameters_fp
i2d_ECPKParameters_fp(fp
x)
ECPKParameters_print
ECPKParameters_print_fp

After installation there are broken symlinks:

lrwxrwxrwx   ... i2d_ECPKParameters_fp(fp.3 - d2i_ECPKParameters.3
lrwxrwxrwx   ... x).3 - d2i_ECPKParameters.3

The script util/extract-names.pl is unchanged since 11 years (master and 
1.0.2 branch), the pod file doc/crypto/d2i_ECPKParameters.pod is new in 
1.0.2 and contains the broken syntax in 1.0.2 and master.

Solution: drop (fp,x) in the NAME header:

--- doc/crypto/d2i_ECPKParameters.pod  2014-08-07 06:28:31.0 
+0200
+++ doc/crypto/d2i_ECPKParameters.pod   2015-02-23 23:02:57.481128000 +0100
@@ -2,7 +2,7 @@

  =head1 NAME

-d2i_ECPKParameters, i2d_ECPKParameters, d2i_ECPKParameters_bio, 
i2d_ECPKParameters_bio, d2i_ECPKParameters_fp, 
i2d_ECPKParameters_fp(fp,x), ECPKParameters_print, 
ECPKParameters_print_fp - Functions for decoding and encoding ASN1 
representations of elliptic curve entities
+d2i_ECPKParameters, i2d_ECPKParameters, d2i_ECPKParameters_bio, 
i2d_ECPKParameters_bio, d2i_ECPKParameters_fp, i2d_ECPKParameters_fp, 
ECPKParameters_print, ECPKParameters_print_fp - Functions for decoding 
and encoding ASN1 representations of elliptic curve entities

  =head1 SYNOPSIS


Thanks!

Rainer


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

Re: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 make test bus error in evp_test (Solaris 10 Sparc, sun4u)

[Rainer Jung]

Am 24.02.2015 um 22:14 schrieb Andy Polyakov:

Basically I just want to say good analysis and confirm that yes,
everything points at compiler bug. I also don't sent this to rt, but to
openssl-dev, in order to prevent case reopen.


Looking at disassembly around CRYPTO_ccm128_decrypt+532 (decimal 532 =
0x214):

  CRYPTO_ccm128_decrypt+0x214: f4 1f 00 00  ldd   [%i4], %i2
  CRYPTO_ccm128_decrypt+0x218: b8 07 20 10  add   %i4, 0x10, %i4


I want to point out instruction that follows the ldd. If %i4 was temp,
then why would compiler have to increment it? Actually, if it was temp,
which can only be stack-based, then compiler would address it through
%fp, just like it addresses scratch in next instruction below. Also note
that %i4 value is the same as inp in your stack backtrace presented in
original message. Bottom line here is that compiler optimized away
memcpy by assuming that input is aligned, despite the fact that it's
declared char. That's compiler bug.


  CRYPTO_ccm128_decrypt+0x21c: c4 1f bf f0  ldd   [%fp - 0x10], %g2
  CRYPTO_ccm128_decrypt+0x220: d8 1f 3f f8  ldd   [%i4 - 0x8], %o4
  CRYPTO_ccm128_decrypt+0x224: b0 1e 80 02  xor   %i2, %g2, %i0
  CRYPTO_ccm128_decrypt+0x228: b2 1e c0 03  xor   %i3, %g3, %i1


If you still have 4.9.1 lying around, I wonder if it would help to
declare temp as volatile? It's really just a wonder, so don't feel
obligated to answer if you don't have time or energy.


Thanks for looking into it. I have everything in place for experiments.

Adding volatile first results in new compiler warnings:

ccm128.c: In function 'CRYPTO_ccm128_decrypt':
ccm128.c:300:9: warning: passing argument 1 of 'memcpy' discards 
'volatile' qualifier from pointer target type

 memcpy(temp.c, inp, 16);
 ^
In file included from /usr/include/string.h:18:0,
 from ccm128.c:53:
/usr/include/iso/string_iso.h:60:14: note: expected 'void *' but 
argument is of type 'volatile u8 *'
 extern void *memcpy(void *_RESTRICT_KYWD, const void *_RESTRICT_KYWD, 
size_t);

  ^


And then it also changes the resulting code:

-   ldd [%i4], %i2
+   callmemcpy, 0
^^^ that's probably the memcpy() that was optimized away before
+nop
+   ldd [%fp-16], %i2
+   ldd [%fp-32], %g2
+   add %l6, %i4, %o0
+   mov %l0, %o1
+   ldd [%fp-8], %i0
+   mov 16, %o2
add %i4, 16, %i4
-   ldd [%fp-16], %g2
-   ldd [%i4-8], %o4
-   xor %i2, %g2, %i0
-   xor %i3, %g3, %i1
-   ldd [%fp-8], %g2
-   std %i0, [%fp-16]
-   xor %o4, %g2, %g2
-   xor %o5, %g3, %g3
ldd [%i5+16], %o4
-   std %g2, [%fp-8]
-   xor %o4, %i0, %i2
-   xor %o5, %i1, %i3
+   xor %i2, %g2, %i2
+   xor %i3, %g3, %i3
+   ldd [%fp-24], %g2
+   std %i2, [%fp-32]
+   xor %i0, %g2, %g2
+   xor %i1, %g3, %g3
+   std %g2, [%fp-24]
+   xor %o4, %i2, %i0
+   xor %o5, %i3, %i1
ldd [%i5+24], %o4
-   std %i2, [%i5+16]
-   xor %o4, %g2, %i2
-   xor %o5, %g3, %i3
+   std %i0, [%i5+16]
+   xor %o4, %g2, %i0
+   xor %o5, %g3, %i1
callmemcpy, 0
-std%i2, [%i5+24]
-   mov %l5, %o0
-   mov %l5, %o1
+std%i0, [%i5+24]
+   mov %l3, %o0
+   mov %l3, %o1
call%l1, 0
 mov%l2, %o2

And yes, with volatile the test no longer crashes even when compiled 
with the broken gcc 4.9.1 and -O3.


Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Submitting new bugs to rt via mail broken?

[Rainer Jung]

Am 10.02.2015 um 21:30 schrieb Matt Caswell:


On 10/02/15 19:23, Rainer Jung wrote:

Hello everyone,

I sent a mail to r...@openssl.org 3 days ago, subject OpenSSL 1.0.2 make
test bus error in evp_test (Solaris 10 Sparc, sun4u).

The mail didn't create a new ticket in RT, nor was it forwarded to the
dev list.

Should I resend or simply be more patient?


Email to rt is manually moderated by Lutz. Sometimes it can take a few
days to come through. Very occasionally a genuine email gets lost within
the swamp of spam. I would be a little more patient, but if it doesn't
arrive in a couple more days then try again.


I tried again on Feb 14, about a week ago. Still nothing shows up in RT 
or on mailing lists. Other mails on the dev list also indicate problems 
with stalled RT communication.


If it helps, I can send the original mail via PM or to this list here.

Regards,

Rainer

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

[openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 make test bus error in evp_test (Solaris 10 Sparc, sun4u)

[Rainer Jung via RT]

2nd attempt. First sent on Feb 7th.

I get a failure for 1.0.2 running make test on Solaris 10.

It might be related to #3688, but I don't think so.

Mine is a sun4u machine, so neither T2 nor T4.
Compilation done with gcc 4.9.1 with v9 target.

Failure is a bus error in evp_test.

gdb shows the following details:

(gdb) bt full
#0  CRYPTO_ccm128_decrypt (ctx=0x6cbd0, inp=0xffbfd091 
\232_...230dxgf042382d949b43b7d6bb2b9864786726,
 out=0xffbfdfe8 ..., len=32) at ccm128.c:300
 temp = optimized out
 n = 32
 i = optimized out
 L = 1
 flags0 = 121 'y'
 block = 0xff1ee3c0 AES_encrypt
 key = 0x6cac0
 scratch = {u = {14547399086359111669, 7716584104704463675}, c = 
...}
#1  0xff26d774 in aes_ccm_cipher (ctx=0xffbfcf5c, out=0xffbfdfe8 ...,
 in=0xffbfd091 ..., len=32) at e_aes.c:1893
 rv = -1
 cctx = 0x6cac0
 ccm = 0x6cbd0
#2  0xff267f6c in EVP_DecryptUpdate (ctx=ctx@entry=0xffbfcf5c, 
out=out@entry=0xffbfdfe8 ..., outl=outl@entry=0xffbfcf40,
 in=in@entry=0xffbfd091 ..., inl=inl@entry=32) at evp_enc.c:437
 fix_len = optimized out
 b = optimized out
#3  0x0001301c in test1 (encdec=optimized out, tn=16, tag=optimized 
out, an=optimized out, aad=optimized out, cn=32,
 ciphertext=0xffbfd091 ..., pn=32,
 plaintext=0xffbfd050 ..., in=optimized out,
 iv=0xffbfd035 ..., kn=optimized out, key=optimized out, 
c=0xff342150) at evp_test.c:346
 ctx = {cipher = 0xff342150, engine = 0x0, encrypt = 0, buf_len 
= 0, oiv = '\000' repeats 15 times, iv = ...,
   buf = ..., '\000' repeats 15 times, num = 0, app_data = 
0x0, key_len = 32, flags = 257, cipher_data = 0x6cac0, final_used = 0,
   block_mask = 0, final = '\000' repeats 31 times}
 outl = 32
 out = ..
 outl2 = 0
 mode = optimized out
#4  test_cipher (encdec=optimized out, tn=16, tag=optimized out, 
an=optimized out, aad=optimized out, cn=32,
 ciphertext=0xffbfd091 ..., pn=32,
 plaintext=0xffbfd050 ..., in=optimized out,
 iv=0xffbfd035 ..., kn=optimized out, key=optimized out, 
cipher=optimized out) at evp_test.c:390
 c = 0x13920
#5  main (argc=optimized out, argv=optimized out) at evp_test.c:546
 line = aes-256-ccm..
 encdec = optimized out
 tag = optimized out
 an = optimized out
 tn = 16
 p = optimized out
 aad = optimized out
 szTestFile = optimized out
 f = optimized out


Funny is, that a bus error on Sparc often is due to an alignment 
problem, and line 300 where it crashes is:

289  while (len = 16) {
290  #if defined(STRICT_ALIGNMENT)
291  union {
292  u64 u[2];
293  u8 c[16];
294  } temp;
295  #endif
296  (*block) (ctx-nonce.c, scratch.c, key);
297  ctr64_inc(ctx-nonce.c);
298  #if defined(STRICT_ALIGNMENT)
299  memcpy(temp.c, inp, 16);
300  ctx-cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
301  ctx-cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
302  memcpy(out, scratch.c, 16);
303  #else
304  ctx-cmac.u[0] ^= (((u64 *)out)[0] = scratch.u[0] ^ 
((u64 *)inp)[0]);
305  ctx-cmac.u[1] ^= (((u64 *)out)[1] = scratch.u[1] ^ 
((u64 *)inp)[1]);
306  #endif
307  (*block) (ctx-cmac.c, ctx-cmac.c, key);
308
309  inp += 16;
310  out += 16;
311  len -= 16;
312  }

so inside a STRICT_ALIGNMENT block ...

Now ctx-cmac.u[0] and scratch.u[0] seem to be aligned correct to me:

(gdb) print ctx-cmac.u[0]
$10 = (u64 *) 0x6cbe0
(gdb) print scratch.u[0]
$12 = (u64 *) 0xffbfcdd0

but temp is not available in gdb:

(gdb) print temp.u[0]
value has been optimized out

It is defined as

290  #if defined(STRICT_ALIGNMENT)
291  union {
292  u64 u[2];
293  u8 c[16];
294  } temp;
295  #endif


gdb command info registers says:

g0 0x0  0
g1 0x2  2
g2 0x6c 108
g3 0x4d 5046272
g4 0xb0009600   -1342138880
g5 0x3b 59
g6 0x0  0
g7 0xff392a00   -13030912
o0 0xffbfdfe8   -4202520
o1 0xffbfcdd0   -4207152
o2 0x10 16
o3 0x41 65
o4 0x0  0
o5 0x4  4
sp 0xffbfcd60   0xffbfcd60
o7 0xff208064   -14647196
l0 0xffbfcdd0   -4207152
l1 0xff1ee3c0   -14752832
l2 0x6cac0  445120
l3 0x10 16
l4 0xffbfdff8   -4202504
l5 0x6cbe0  445408
l6 0x1  1
l7 0xff338dd8   -13398568
i0 0x   -1
i1 0xffbfd091   -4206447
i2 0xffbfdfe8   -4202520

Re: [openssl-dev] [openssl-commits] [openssl] master update (Add Camellia CTR mode, dda8199922f9d52087d2c41b22a61eb4f9671385)

[Rainer Jung]

Am 11.02.2015 um 20:30 schrieb Andy Polyakov:

The branch master has been updated
via  dda8199922f9d52087d2c41b22a61eb4f9671385 (commit)
via  c79e17731f462d6d42b917027a7085c0f59a2214 (commit)
   from  b7c9187b32a14b5b4a850161aed5c044d2130d5a (commit)


- Log -
commit dda8199922f9d52087d2c41b22a61eb4f9671385
Author: Andy Polyakov ap...@openssl.org
Date:   Wed Feb 11 20:30:13 2015 +0100

 Add Camellia CTR mode.

 Reviewed-by: Rich Salz rs...@openssl.org



...


---

Summary of changes:
  crypto/evp/c_allc.c|3 ++
  crypto/evp/e_camellia.c|9 ++---
  crypto/evp/evptests.txt|   64 ++
  crypto/objects/obj_dat.h   |   82 +---
  crypto/objects/obj_mac.h   |   60 
  crypto/objects/obj_mac.num |   12 +++
  crypto/objects/objects.txt |   12 +++
  7 files changed, 231 insertions(+), 11 deletions(-)

diff --git a/crypto/evp/c_allc.c b/crypto/evp/c_allc.c
index 174a419..7ae36d7 100644
--- a/crypto/evp/c_allc.c
+++ b/crypto/evp/c_allc.c
@@ -245,5 +245,8 @@ void OpenSSL_add_all_ciphers(void)
  EVP_add_cipher(EVP_camellia_256_ofb());
  EVP_add_cipher_alias(SN_camellia_256_cbc, CAMELLIA256);
  EVP_add_cipher_alias(SN_camellia_256_cbc, camellia256);
+EVP_add_cipher(EVP_camellia_128_ctr());
+EVP_add_cipher(EVP_camellia_192_ctr());
+EVP_add_cipher(EVP_camellia_256_ctr());
  #endif
  }


We get build warnings and crashes during run in EVP_add_cipher(). It 
seems EVP_camellia_128_ctr(), EVP_camellia_192_ctr() and 
EVP_camellia_256_ctr() are missing from crypto/evp/evp.h:


c_allc.c:248:5: warning: implicit declaration of function 
EVP_camellia_128_ctr [-Wimplicit-function-declaration]

 EVP_add_cipher(EVP_camellia_128_ctr());
etc.

Thanks,

Rainer

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

Re: [openssl-dev] [openssl-commits] [openssl] master update (Add Camellia CTR mode, dda8199922f9d52087d2c41b22a61eb4f9671385)

[Rainer Jung]

Am 12.02.2015 um 12:00 schrieb Andy Polyakov:

diff --git a/crypto/evp/c_allc.c b/crypto/evp/c_allc.c
index 174a419..7ae36d7 100644
--- a/crypto/evp/c_allc.c
+++ b/crypto/evp/c_allc.c
@@ -245,5 +245,8 @@ void OpenSSL_add_all_ciphers(void)
   EVP_add_cipher(EVP_camellia_256_ofb());
   EVP_add_cipher_alias(SN_camellia_256_cbc, CAMELLIA256);
   EVP_add_cipher_alias(SN_camellia_256_cbc, camellia256);
+EVP_add_cipher(EVP_camellia_128_ctr());
+EVP_add_cipher(EVP_camellia_192_ctr());
+EVP_add_cipher(EVP_camellia_256_ctr());
   #endif
   }


We get build warnings and crashes during run in EVP_add_cipher().


Thanks. I'm on it. Out of curiosity, with which config do you get
crashes? I don't mean that this doesn't need fixing, I only want to have
a reference.


Thanks to you.

The crash occurred while using it during a CI build for Tomcat plus 
Tomcat native connector (tcnative) which in turn uses OpenSSL.


OpenSSL was build with config --prefix=... shared enable-deprecated.

I don't have a full stack available. The Java HS-Error file says:

[junit] #
[junit] # A fatal error has been detected by the Java Runtime 
Environment:

[junit] #
[junit] #  SIGSEGV (0xb) at pc=0x7fb882f66ef9, pid=32437, 
tid=140431064893184

[junit] #
[junit] # JRE version: Java(TM) SE Runtime Environment (8.0_25-b17) 
(build 1.8.0_25-b17)
[junit] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 
mixed mode linux-amd64 compressed oops)

[junit] # Problematic frame:
[junit] # C  [libcrypto.so.1.1.0+0x14fef9]  EVP_add_cipher+0x9
[junit] #

Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Submitting new bugs to rt via mail broken?

[Rainer Jung]

Hello everyone,

I sent a mail to r...@openssl.org 3 days ago, subject OpenSSL 1.0.2 make 
test bus error in evp_test (Solaris 10 Sparc, sun4u).


The mail didn't create a new ticket in RT, nor was it forwarded to the 
dev list.


Should I resend or simply be more patient?

Thanks and regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-web] OpenSSL Web Pages branch master updated. e138d289a5639f166c2d1b62c421cbd9cb7b35f2

[Rainer Jung]

Am 20.11.2014 um 23:35 schrieb Kurt Roeckx:


- Log -
commit e138d289a5639f166c2d1b62c421cbd9cb7b35f2
Author: Kurt Roeckx k...@roeckx.be
Date:   Thu Nov 20 23:34:52 2014 +0100

 Add a RewriteCond for each rule

 As far as I can tell you can only multiple conditions but they apply to 
only 1 rule.

---

Summary of changes:
  source/.htaccess |8 
  1 file changed, 8 insertions(+)

diff --git a/source/.htaccess b/source/.htaccess
index 3b3077c..9fe909e 100644
--- a/source/.htaccess
+++ b/source/.htaccess
@@ -7,9 +7,17 @@ RewriteEngine on
  # Old distro's are in subdirs.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule (openssl-0.9.8.*) old/0.9.x/$1 [L]
+
+RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule openssl-(1.0.0.*) old/1.0.0/openssl-$1 [L]
+
+RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule openssl-(1.0.1.*) old/1.0.1/openssl-$1 [L]
+
+RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule openssl-(1.0.2.*) old/1.0.1/openssl-$1 [L]


CopyPaste: 1.0.2 on the right side?


+RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule openssl-(fips.*)  old/fips/openssl-$1 [L]


You could combine the last 4 (not the 0.9.x one):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule openssl-(1\.\d\.\d|fips).*) old/$2/openssl-$1 [L]

Shorter but maybe less readable.

Regards,

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

Re: [openssl-web] OpenSSL Web Pages branch master updated. e138d289a5639f166c2d1b62c421cbd9cb7b35f2

[Rainer Jung]

Am 21.11.2014 um 18:21 schrieb Rainer Jung:


RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule openssl-(1\.\d\.\d|fips).*) old/$2/openssl-$1 [L]


Ahem, I forgot one opening (:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule openssl-((1\.\d\.\d|fips).*) old/$2/openssl-$1 [L]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3535] TS high-precision time malformation - demo

[Rainer Jung]

Am 19.09.2014 um 11:25 schrieb Rainer Jung:

Am 18.09.2014 um 20:03 schrieb Salz, Rich:

The default time comes from the gettimeofday() system call (see
def_time_cb in ts_rsp_sign.c).
I don't see any openssl bug here.


It does, but I agree with the OP: the *textual formatting* of the
fractional second in ./crypto/ts/ts_rsp_sign.c is wrong. It must include
leading zeroes:

BIO_snprintf(p, 2 + precision, .%06ld, usec);

instead of the current

BIO_snprintf(p, 2 + precision, .%ld, usec);

There's a dot . before the %ld, so any usec below 10 would be
incorrectly formatted.

Example:

usec=5

Expected: .05
Real: .5


Any chance to get this simple change in?

Thanks and regards,

Rainer

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

Re: [openssl.org #3535] TS high-precision time malformation - demo

[Rainer Jung]

Am 18.09.2014 um 20:03 schrieb Salz, Rich:

The default time comes from the gettimeofday() system call (see def_time_cb in 
ts_rsp_sign.c).
I don't see any openssl bug here.


It does, but I agree with the OP: the *textual formatting* of the 
fractional second in ./crypto/ts/ts_rsp_sign.c is wrong. It must include 
leading zeroes:


BIO_snprintf(p, 2 + precision, .%06ld, usec);

instead of the current

BIO_snprintf(p, 2 + precision, .%ld, usec);

There's a dot . before the %ld, so any usec below 10 would be 
incorrectly formatted.


Example:

usec=5

Expected: .05
Real: .5

Regards,

Rainer


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

Re: [openssl.org #3271] OpenSSL 1.0.2 Beta 1 Solaris 10 Sparc Shell error during make install

[Rainer Jung]

Anyone? I created a pull request to make fixing easier:

https://github.com/openssl/openssl/pull/171

Thanks,

Rainer

Am 20.08.2014 um 20:46 schrieb Rainer Jung:

When trying to build 1.0.2 beta 2 on Solaris I noticed, that the fix for
#3271 was incomplete. The same problem happened in 3 Makefiles for beta1
but only one was fixed for beta2.

The two files still broken are engines/Makefile and
engines/ccgost/Makefile. The solution applied to the top Makefile
(flipping the if and else parts) applies here as well.

Am 28.02.2014 um 22:57 schrieb Andy Polyakov via RT:

Change
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b3ef742cbbc1c8bf0e33dca60f08c65031647b07

broke make install on Solaris. Error message:

/bin/sh: !: not found

The new syntax

-  if [ $(PLATFORM) != Cygwin ]; then \
+  if ! expr $(PLATFORM) : Cygwin /dev/null; then \

introduced to the Makefile doesn't work for /bin/sh on Solaris.


flipped condition in
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=cd077dab08769091ebff3c2a5cbb27ffdb8043a7.

thanks for report.


Regards,

Rainer

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

Re: [openssl.org #3271] OpenSSL 1.0.2 Beta 1 Solaris 10 Sparc Shell error during make install

[Rainer Jung]

When trying to build 1.0.2 beta 2 on Solaris I noticed, that the fix for 
#3271 was incomplete. The same problem happened in 3 Makefiles for beta1 
but only one was fixed for beta2.


The two files still broken are engines/Makefile and 
engines/ccgost/Makefile. The solution applied to the top Makefile 
(flipping the if and else parts) applies here as well.


Am 28.02.2014 um 22:57 schrieb Andy Polyakov via RT:

Change
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b3ef742cbbc1c8bf0e33dca60f08c65031647b07
broke make install on Solaris. Error message:

/bin/sh: !: not found

The new syntax

-  if [ $(PLATFORM) != Cygwin ]; then \
+  if ! expr $(PLATFORM) : Cygwin /dev/null; then \

introduced to the Makefile doesn't work for /bin/sh on Solaris.


flipped condition in
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=cd077dab08769091ebff3c2a5cbb27ffdb8043a7.
thanks for report.


Regards,

Rainer

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

[openssl.org #3376] 0.9.8za/1.0.0m/1.0.1h build failure in ssl/s3_pkt.c - missing include for limits.h

[Rainer Jung via RT]

File ssl/s3_pkt.c uses INT_MAX since May 19th. This macro is defined in
limits.h which is not included in s3_pkt.c.

Some platforms have INT_MAX defined even without the include - like
Linux - others not - like Solaris.

Similar files like e.g. ssl/s3_both.c already include limits.h.

The problem was introduced with commits

989d87cb1a174a951efd829ff6b2f68a322f9df8 (1.0.1)
c01a838d623a156f1ec912382d63bd219a049dba (1.0.0)
8e928aab02a4ebb491b6950d2829edad90e73245 (0.9.8)

in addition: It looks to me as if that change was not (!) ported to
1.0.2 and trunk/master. I don't know whether it is necessary there or not.

Patch (1.0.1):

--- ssl/s3_pkt.c2014-06-05 11:44:33.0 +0200
+++ ssl/s3_pkt.c2014-06-05 18:23:37.606588000 +0200
@@ -109,6 +109,7 @@
  *
  */

+#include limits.h
 #include stdio.h
 #include limits.h
 #include errno.h


Regards,

Rainer

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

[openssl.org #3377] 0.9.8za/1.0.0m incomplete backport from 1.0.1h in ssl/s3_pkt.c

[Rainer Jung via RT]

Commit 989d87cb1a174a951efd829ff6b2f68a322f9df8  for 1.0.1 was shortly
after improved by commit dac3654e2d89d43807e7b8e4b9da86ae1d33fe2b. It
changed s-s3-wnum  INT_MAX to s-s3-wnum = INT_MAX (lower or
equals instead of lower than).

The backports to 1.0.0 and 0.9.8 only contained the first commit, not
the second, so 1.0.1 allow lower or equals INT_MAX, but 0.9.8 and 1.0.0
only allow lower than INT_MAX.

Patch (1.0.0):

--- ssl/s3_pkt.c2014-06-05 11:41:31.0 +0200
+++ ssl/s3_pkt.c2014-06-05 18:31:57.659093000 +0200
@@ -583,7 +583,7 @@
int i,tot;

s-rwstate=SSL_NOTHING;
-   OPENSSL_assert(s-s3-wnum  INT_MAX);
+   OPENSSL_assert(s-s3-wnum = INT_MAX);
tot=s-s3-wnum;
s-s3-wnum=0;


The patches seem to be completely missing from 1.0.2 and trunk/master.

Regards,

Rainer

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

Re: [openssl.org #3376] 0.9.8za/1.0.0m/1.0.1h build failure in ssl/s3_pkt.c - missing include for limits.h

[Rainer Jung]

One correction to self: no problem for 1.0.1, which had been fixed in
commit 8ca7d124304502158fba780eed293c4e3c5c1c71 Fixed Windows
compilation failure.

But 1.0.0 and 0.9.8 lack tha addition.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3271] OpenSSL 1.0.2 Beta 1 Solaris 10 Sparc Shell error during make install

[Rainer Jung via RT]

Change
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b3ef742cbbc1c8bf0e33dca60f08c65031647b07
broke make install on Solaris. Error message:

/bin/sh: !: not found

The new syntax

-  if [ $(PLATFORM) != Cygwin ]; then \
+  if ! expr $(PLATFORM) : Cygwin /dev/null; then \

introduced to the Makefile doesn't work for /bin/sh on Solaris.

Regards,

Rainer

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

[openssl.org #3216] Invalid shell syntax == in test/testssl (only 0.9.8 and 1.0.0)

[Rainer Jung via RT]

File test/testssl in branches 0.9.8 and 1.0.0 contains the line

if [ $protocol == SSLv3 ] ; then

for 1.0.1, 1.0.2 and master it is:

if [ $protocol = SSLv3 ] ; then

The script is executed by /bin/sh and the == syntax is not supported
for all basic shells, e.g. not on Solaris. Other parts of the script use
the = syntax for all versions, so please adjust == to = in
test/testssl for 0.9.8 and 1.0.0:

Patch for 0.9.8:

diff -u test/testssl test/testssl
--- test/testssl2014-01-06 23:24:16.465594000 +0100
+++ test/testssl2014-01-06 23:26:52.817292000 +0100
@@ -125,7 +125,7 @@
   for cipher in `../util/shlib_wrap.sh ../apps/openssl ciphers
RSA+$protocol | tr ':' ' '`; do
 echo Testing $cipher
 prot=
-if [ $protocol == SSLv3 ] ; then
+if [ $protocol = SSLv3 ] ; then
   prot=-ssl3
 fi
 $ssltest -cipher $cipher $prot

Patch for 1.0.0:

diff -u test/testssl test/testssl
--- test/testssl2014-01-06 23:24:39.614747000 +0100
+++ test/testssl2014-01-06 23:26:55.834853000 +0100
@@ -125,7 +125,7 @@
   for cipher in `../util/shlib_wrap.sh ../apps/openssl ciphers
RSA+$protocol | tr ':' ' '`; do
 echo Testing $cipher
 prot=
-if [ $protocol == SSLv3 ] ; then
+if [ $protocol = SSLv3 ] ; then
   prot=-ssl3
 fi
 $ssltest -cipher $cipher $prot


Thanks,

Rainer

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

Re: [openssl.org #2279] Bug Report

[Rainer Jung]

This bug about an incompatibility of cms-test.pl with old Perl versions
has been fixed in 2011 for trunk by Andy (thanks!), but not been
backported to any release branch. I verified it today for 1.0.1 on
Solaris 8. It would be nice if the simple change could be applied to at
least some of the release branches.

http://rt.openssl.org/Ticket/Display.html?id=2279

Thanks!

Rainer

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

Re: [CVS] OpenSSL: openssl/ Configure PROBLEMS TABLE

[Rainer Jung]

On 13.08.2012 18:10, Andy Polyakov wrote:

   OpenSSL CVS Repository
   http://cvs.openssl.org/
   

   Server: cvs.openssl.org  Name:   Andy Polyakov
   Root:   /v/openssl/cvs   Email:  ap...@openssl.org
   Module: openssl  Date:   13-Aug-2012 18:10:09
   Branch: HEAD Handle: 2012081316100800

   Modified files:
 openssl Configure PROBLEMS TABLE

   Log:
 ./Configure: libcrypto.a can grow to many GB because of ar bug.

 PR: 2838

   Summary:
 RevisionChanges Path
 1.749   +1  -1  openssl/Configure
 1.22+14 -0  openssl/PROBLEMS
 1.305   +2  -2  openssl/TABLE
   


...


   patch -p0 '@@ .'
   Index: openssl/TABLE
   
   $ cvs diff -u -r1.304 -r1.305 TABLE
   --- openssl/TABLE18 Apr 2012 13:01:32 -  1.304
   +++ openssl/TABLE13 Aug 2012 16:10:08 -  1.305
   @@ -1718,7 +1718,7 @@

*** debug-ben-debug
$cc   = gcc
   -$cflags   = -Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare 
-Wmissing-prototypes -Wshadow -Wformat -Werror -DCRYPTO_MDEBUG_ALL 
-DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED -DBN_DEBUG 
-DCONF_DEBUG -DDEBUG_SAFESTACK -g3 -O2 -pipe
   +$cflags   = -Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare 
-Wmissing-prototypes -Wshadow -Wformat -Werror -DCRYPTO_MDEBUG_ALL 
-DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED -DBN_DEBUG 
-DCONF_DEBUG -DDEBUG_SAFESTACK -DOPENSSL_NO_HW_PADLOCK -g3 -O2 -pipe
$unistd   =
$thread_cflag = (unknown)
$sys_id   =


Was this part (adding -DOPENSSL_NO_HW_PADLOCK) intentional? It doesn't 
seem related to the ar fix and is not part of the backports to the 
other branches.



   @@ -5441,7 +5441,7 @@
$shared_cflag = -KPIC
$shared_ldflag = -xarch=v9 -G -dy -z text
$shared_extension = .so.$(SHLIB_MAJOR).$(SHLIB_MINOR)
   -$ranlib   = /usr/ccs/bin/ar rs
   +$ranlib   =
$arflags  =
$multilib = /64

   @@ .


Regards,

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

Re: [openssl.org #1306] apps/apps.c does not define strcasecmp

[Rainer Jung via RT]

Fixed today for trunk and 1.0.1, still open for 1.0.0.

See

http://cvs.openssl.org/chngview?cn=22117

and

http://cvs.openssl.org/chngview?cn=22118

Also tracked as PR 2717:

http://rt.openssl.org/Ticket/Display.html?id=2717

Not yet backported to 1.0.0.

Regards,

Rainer


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

Re: [openssl.org #1306] apps/apps.c does not define strcasecmp

[Rainer Jung via RT]

Verified, still open: explicitely checked for 1.0.1-beta2 and 1.0.0g, 
code in trunk is the same. 0.9.8 doesn't contain the problematic parts.

The define _POSIX_C_SOURCE 2 was added in

http://cvs.openssl.org/chngview?cn=14636

and slightly improved in

http://cvs.openssl.org/chngview?cn=18152

Not sure about VMS, but in other places things are shielded by

#ifdef OPENSSL_SYS_VMS

for the other OSes.

Regards,

Rainer


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

[openssl.org #2689] Sparc Assembler warning: backport cn=22016 to 1.0.1.

[Rainer Jung via RT]

Sparc assembler warning

/usr/ccs/bin/as: sha512-sparcv9.s, line 676: warning: v8+ ABI 
violation: illegal use of %i or %l register as rs1 in brnz,a instruction

on Solaris.

Fixed in trunk, please backport

http://cvs.openssl.org/chngview?cn=22016

to 1.0.1 and 1.0.0.

Regards,

Rainer

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

[openssl.org #2690] Use of uninitialized value $output in asm/md5-x86_64.pl line 115.

[Rainer Jung via RT]

Warning when building 1.0.1-beta2:

Use of uninitialized value $output in pattern match (m//) at 
asm/md5-x86_64.pl line 115.

Code looks like:

111 my $flavour = shift;
112 my $output  = shift;
113 if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
114
115 my $win64=0; $win64=1 if ($flavour =~ /[nm]asm|mingw64/ || $output 
=~ /\.asm$/);

Code in trunk seems to be the same.

Regards,

Rainer

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

Re: Release of OpenSSL 1.0.1 approaching...

[Rainer Jung]

On 13.01.2012 10:23, Andy Polyakov wrote:

I'll see how to work around the warning...


Great, thank's a lot. Happy to retest.


http://cvs.openssl.org/chngview?cn=22016.


I applied the change to the current 1.0.1 snapshot. The warning is gone 
now, make test doesn't show any regression.


Thanks!

Regards,

Rainer

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

Re: Release of OpenSSL 1.0.1 approaching...

[Rainer Jung]

On 12.01.2012 15:54, Andy Polyakov wrote:

In addition one assembler warning (Solaris Sparc):

/usr/ccs/bin/as: sha512-sparcv9.s, line 676: warning: v8+ ABI
violation: illegal use of %i or %l register as rs1 in brnz,a instruction


What version is it? Solaris and assembler (as -V)?


% as -V
as: Sun Compiler Common 10 Patch 09/04/2007

% uname -a
SunOS 5.10 Generic_142900-07 sun4u sparc SUNW,Sun-Fire-V240

% cat /etc/release
  Solaris 10 10/08 s10s_u6wos_07b SPARC
   Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
Use is subject to license terms.
Assembled 27 October 2008

gcc was a self-compiled 4.6.2.


For reference, instruction in question performs conditional branch
depending on content of 64-bit %i4 register. Thing about v8+ ABI is that
upper halves of %i and %l registers can be zeroed at any time. While it
would be plain wrong to rely on upper half having non-zero value, the
warning is safe to ignore in *this* case, because %i4 is used to keep a
5-bit value, so it doesn't matter if system zeros upper half or not.


Thanks for the explanation.


I'll see how to work around the warning...


Great, thank's a lot. Happy to retest.

Regards,

Rainer

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

Re: _POSIX_C_SOURCE

[Rainer Jung]

On 04.01.2012 03:16, Tim Rice wrote:


Some things came up attempting to build on OpenServer 5
.
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -O3 
-fomit-frame-pointer -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c ui_openssl.c
In file included from /usr/include/posix/signal.h:35,
  from /usr/include/signal.h:11,
  from ui_openssl.c:128:
/usr/include/sys/signal.h:175: parse error before `siginfo_t'
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
.

Same problem with apps/apps.c
It comes from
#ifndef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE 2
#endif

The comments in apps/apps.c indicate it is needed for VMS and the comments
in crypto/ui/ui_openssl.c say it is needed for gcc -ansi.
Was it VMS users using gcc -ansi?
Can we restrict the _POSIX_C_SOURCE define to VMS?


Yes, please. See also my remarks from 3 weeks ago at

http://www.mail-archive.com/openssl-dev@openssl.org/msg29964.html

Regards,

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

Re: Release of OpenSSL 1.0.1 approaching...

[Rainer Jung]

the config script contains

   414  # Only set CC if not supplied already
   415  if [ -z $CROSS_COMPILE$CC ]; then
   416GCCVER=`sh -c gcc -dumpversion 2/dev/null`

In our case we do set CC, but we do not cross compile. Since CC is 
set, the -z test fails and consequently the GCCVER variable is not 
set. Later down, for Solaris it compares GCCVER to 28 and due to the 
variable being 0 it falls back to old gcc compiler mode despite we are 
using gcc 4.


I don't know enough about cross compilation, but the following is a 
proposed fix assuming that non-gcc compilers set in CC will only write 
an error when called with -dumpversion:


--- config  Sat Dec 10 11:57:36 2011
+++ config  Sat Dec 10 12:56:36 2011
@@ -411,9 +411,9 @@
 # this is where the translation occurs into SSLeay terms
 # 
---


-# Only set CC if not supplied already
-if [ -z $CROSS_COMPILE$CC ]; then
-  GCCVER=`sh -c gcc -dumpversion 2/dev/null`
+# Only set if not cross compiling
+if [ -z $CROSS_COMPILE ]; then
+  GCCVER=`sh -c ${CC:-gcc} -dumpversion 2/dev/null`
   if [ $GCCVER !=  ]; then
 # then strip off whatever prefix egcs prepends the number with...
 # Hopefully, this will work for any future prefixes as well.
@@ -423,9 +423,9 @@
 # major and minor version numbers.
 # peak single digit before and after first dot, e.g. 2.95.1 gives 29
 GCCVER=`echo $GCCVER | sed 's/\([0-9]\)\.\([0-9]\).*/\1\2/'`
-CC=gcc
+CC=${CC:-gcc}
   else
-CC=cc
+CC=${CC:-cc}
   fi
 fi
 GCCVER=${GCCVER:-0}



Alternatively one could only try to use -dumpversion if C is not set 
or e.g. the first token in CC has a basename gcc. But this would not 
work, e.g. for CC=/my/path/bin/gcc-4.1.2 or similar.


Regards,

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

Re: Release of OpenSSL 1.0.1 approaching...

[Rainer Jung]

Two compiler warnings (gcc 4.1.2) during compilation:

sparcv9cap.c: In function 'OPENSSL_cpuid_setup':
sparcv9cap.c:173: warning: unused variable 'sig'

It seems the line

173 int sig;

could simply be dropped.


apps.c: In function 'set_ext_copy':
apps.c:1306: warning: implicit declaration of function 'strcasecmp'

The file defined _POSIX_C_SOURCE 2, which results in strcasecmp no 
longer being defined. Adding -D__EXTENSIONS__ activates all compatible 
extensions (on Solaris) and resolves this. The Configure entry for 
Solaris debug already contains -D__EXTENSIONS__. Alternatively one might 
only set _POSIX_C_SOURCE 2 for the platform that needs it. In apps.c 
it says:


/* On VMS, you need to define this to get
   the declaration of fileno().  The value
   2 is to make sure no function defined
   in POSIX-2 is left undefined. */

but then sets it unconditionally for all platforms :(


In addition one assembler warning (Solaris Sparc):

/usr/ccs/bin/as: sha512-sparcv9.s, line 676: warning: v8+ ABI 
violation: illegal use of %i or %l register as rs1 in brnz,a instruction


All of these also occur in 1.0.0e.

Regards,

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

Re: [openssl.org #2596] report possible bug in 1.0.0e install.

[Rainer Jung]

On 14.09.2011 17:27, Ladar Levison wrote:
 On 9/13/2011 10:57 AM, Zaccone, Warren wrote:
 There is also appears to be a critical issue. the config command
 removed /dev/null.   ON next reboot this causes Solaris 10 to be
 unable to boot up.

 # pwd

 # ls -l /dev/null
 lrwxrwxrwx   1 root root  27 Sep 13 10:46 /dev/null - 
 ../devices/pseudo/mm@0:null

...

Note this is only an issue if you build it using the root user - which
you should *never* do. As non-root /dev/null can not be removed.

Regards,

Rainer

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

Re: [CVS] OpenSSL: openssl/doc/ssl/ SSL_CTX_set_options.pod

[Rainer Jung]

Resend, because it's not fixed yet.

Regards,

Rainer

On 09.12.2009 19:16, 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:   09-Dec-2009 19:16:50
   Branch: HEAD Handle: 2009120918165000

   Modified files:
 openssl/doc/ssl SSL_CTX_set_options.pod

   Log:
 clarify docs

   Summary:
 RevisionChanges Path
 1.17+10 -9  openssl/doc/ssl/SSL_CTX_set_options.pod
   

   patch -p0'@@ .'
   Index: openssl/doc/ssl/SSL_CTX_set_options.pod
   
   $ cvs diff -u -r1.16 -r1.17 SSL_CTX_set_options.pod
   --- openssl/doc/ssl/SSL_CTX_set_options.pod  9 Dec 2009 17:59:29 -   
1.16
   +++ openssl/doc/ssl/SSL_CTX_set_options.pod  9 Dec 2009 18:16:50 -   
1.17

...

   @@ -254,13 +254,14 @@
whether an attack is taking place.

If the option BSSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION  is set then the
   -renegotiation between unpatched clients and patched servers is permitted as
   -well as initial connections and renegotiation between patched clients and
   -unpatched servers. This option should be used with caution because it leaves
   -both clients and servers vulnerable. However unpatched servers and clients 
are
   -likely to be around for some time and simply refusing to connect to 
unpatched
   -servers may well be considered unacceptable. So applications may be forced 
to
   -use this option for the immediate future.
   +above restrictions are relaxed. Renegotiation is permissible and initial
   +initial connections to unpatched servers will succeed.


permissible and initial initial connections
 ^^^

See also revision 1.15.2.2 in 1_0_0 and 1.13.2.5 in 0_9_8.

Regards,

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

Re: [CVS] OpenSSL: openssl/doc/ssl/ SSL_CTX_set_options.pod

[Rainer Jung]

On 09.12.2009 19:16, 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:   09-Dec-2009 19:16:50
   Branch: HEAD Handle: 2009120918165000

   Modified files:
 openssl/doc/ssl SSL_CTX_set_options.pod

   Log:
 clarify docs

   Summary:
 RevisionChanges Path
 1.17+10 -9  openssl/doc/ssl/SSL_CTX_set_options.pod
   

   patch -p0'@@ .'
   Index: openssl/doc/ssl/SSL_CTX_set_options.pod
   
   $ cvs diff -u -r1.16 -r1.17 SSL_CTX_set_options.pod
   --- openssl/doc/ssl/SSL_CTX_set_options.pod  9 Dec 2009 17:59:29 -   
1.16
   +++ openssl/doc/ssl/SSL_CTX_set_options.pod  9 Dec 2009 18:16:50 -   
1.17

...

   @@ -254,13 +254,14 @@
whether an attack is taking place.

If the option BSSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION  is set then the
   -renegotiation between unpatched clients and patched servers is permitted as
   -well as initial connections and renegotiation between patched clients and
   -unpatched servers. This option should be used with caution because it leaves
   -both clients and servers vulnerable. However unpatched servers and clients 
are
   -likely to be around for some time and simply refusing to connect to 
unpatched
   -servers may well be considered unacceptable. So applications may be forced 
to
   -use this option for the immediate future.
   +above restrictions are relaxed. Renegotiation is permissible and initial
   +initial connections to unpatched servers will succeed.


permissible and initial initial connections
 ^^^

See also revision 1.15.2.2 in 1_0_0 and 1.13.2.5 in 0_9_8.

Regards,

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