Re: [openssl-dev] MSVC 2015 internal compiler error

[Viktor Dukhovni]

On Mon, Feb 22, 2016 at 03:55:12PM -1000, Bill Bierman wrote:

> The Microsoft compiler team has suggested removing the include of ssl.h
> from srtp.h as it creates a circular reference which is likely confusing
> the compiler.

Could you test the patch below.  It tries to avoid incompatible
loss of the implicit inclusion, by making it conditional:

-- 
Viktor.

diff --git a/include/openssl/ssl.h b/include/openssl/ssl.h
index 9709103..ee61451 100644
--- a/include/openssl/ssl.h
+++ b/include/openssl/ssl.h
@@ -901,7 +901,9 @@ __owur int SSL_extension_supported(unsigned int ext_type);
 # include 
 # include   /* This is mostly sslv3 with a few tweaks */
 # include  /* Datagram TLS */
-# include   /* Support for the use_srtp extension */
+# ifndef HEADER_D1_SRTP_H
+#  include  /* Support for the use_srtp extension */
+# endif
 
 #ifdef  __cplusplus
 extern "C" {
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MSVC 2015 internal compiler error

[Bill Bierman]

The Microsoft compiler team has suggested removing the include of ssl.h
from srtp.h as it creates a circular reference which is likely confusing
the compiler.

On Mon, Feb 22, 2016 at 2:19 PM, Bill Bierman  wrote:

> Hello.  I'm sorry I cannot reply to the thread.  I only just now have
> subscribed to the list.
>
> I can confirm that this problem exists with Visual Studio 2015 on HEAD.
>
> I spoke to a friend of mine who works at MS who relayed this to the
> compiler team.  A senior dev there is aware of the issue and they are
> working on a fix.
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] MSVC 2015 internal compiler error

[Bill Bierman]

Hello.  I'm sorry I cannot reply to the thread.  I only just now have
subscribed to the list.

I can confirm that this problem exists with Visual Studio 2015 on HEAD.

I spoke to a friend of mine who works at MS who relayed this to the
compiler team.  A senior dev there is aware of the issue and they are
working on a fix.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs

[Andy Polyakov via RT]

> The fix seems to work.

On related note, a problem was reported with poly1305-armv4 module,
which was traced down to assembler (different versions disagree about
how to treat #-1 as argument to vmov.i64). If you run into problem,
don't panic, fix is upcoming...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4323
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 #4323] chacha-armv4.pl bugs

[David Benjamin via RT]

On Sun, Feb 21, 2016 at 3:27 PM Andy Polyakov via RT  wrote:

> Hi,
>
> > The partial-block tail code in chacha-armv4.pl also seems to have
> problems.
> > My colleague Steven and I made an attempt to debug it, but we're not
> > familiar enough with ARM to fix it.
> >
> > From playing with it in a debugger, it doesn't look like @t[3] contains
> the
> > length. We suspect something is going wrong with the condition flags on
> > loading or updating length.
> >
> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/chacha/asm/chacha-armv4.pl;h=55ebc9e586475a35e313b74483eb4b8d5b6f2b03;hb=HEAD#l585
>
> Attached is patch for chacha-armv4.pl (please verify) and a test snippet
> I've put together.
>

The fix seems to work. And it's a decent bit faster than our current NEON
code too. :-) Thanks!


> > It may be worth going back and testing these cases on all of the
> > implementations as well.
>
> Besides armv4 only s390x module was failing.
>

Can confirm that the armv8 code is fine.

David

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4323
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 #4335] ix 'assignment from incompatible type' warning in OBJ_NAME_new_index()

[Kaduk, Ben via RT]

On 02/22/2016 11:04 AM, David Woodhouse via RT wrote:
> We are using OPENSSL_strcmp() as the cmp_func, where cmp_func takes
> a pair of (void *) pointers, not (char *). Which is fine; we know we're
> going to pass it strings in this case. So explicitly cast it to avoid
> the resulting compiler warning.
> ---
>  crypto/objects/o_names.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/objects/o_names.c b/crypto/objects/o_names.c
> index 0a07379..1f9f10a 100644
> --- a/crypto/objects/o_names.c
> +++ b/crypto/objects/o_names.c
> @@ -83,7 +83,7 @@ int OBJ_NAME_new_index(unsigned long (*hash_func) (const 
> char *),
>  return (0);
>  }
>  name_funcs->hash_func = lh_strhash;
> -name_funcs->cmp_func = OPENSSL_strcmp;
> +name_funcs->cmp_func = (void *)OPENSSL_strcmp;
>  CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE);
>  sk_NAME_FUNCS_push(name_funcs_stack, name_funcs);
>  CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ENABLE);
>

Er, where is the cmp_func that is supposed to take void* pointers?  In
master:crypto/objects/o_names.c I see the name_funcs_st with a member
"int (*cmp_func) (const char *a, const char *b);"

(Also, strict C forbids inter-casting between function pointers and
void*, so a cast of (int (*)(void *,void *)) would seem more appropriate
for the stated goal.)

-Ben


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4335
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 1.1.0 and FIPS

[Jaroslav Imrich]

On 22 February 2016 at 20:18, Richard Levitte  wrote:

>
> This is where I go dreamy eyed with a desire to make all our built in
> algorithm into an engine, loadable like any other engine.


I have never tried such setup but this sounds like SoftHSM2 [0] with
OpenSSL crypto backend loaded by OpenSSL via engine_pkcs11 [1].

[0] https://github.com/opendnssec/SoftHSMv2
[1] https://github.com/OpenSC/engine_pkcs11

Regards, Jaroslav
-- 
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()

[Roumen Petrov via RT]

Hi Rich,

Rich Salz via RT wrote:
> fixed in commit 985c3146967633707f7c165df82bb0fd8f279758 thanks for the 
> report!
 From initial patch is missing line with header += 9.
Please could you review parsing with ENCRYPTED

Roumen

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

>From b359b5caf689583b247d825892ccd6dd42474de1 Mon Sep 17 00:00:00 2001
From: Roumen Petrov 
Date: Thu, 18 Feb 2016 23:26:43 +0200
Subject: [PATCH 4/4] #4320 OpenSSL 1.1.0-pre3: "unable to load Key" error in
 PEM_get_EVP_CIPHER_INFO()

---
 crypto/pem/pem_lib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/pem/pem_lib.c b/crypto/pem/pem_lib.c
index a75d9ac..5e8077e 100644
--- a/crypto/pem/pem_lib.c
+++ b/crypto/pem/pem_lib.c
@@ -509,6 +509,7 @@ int PEM_get_EVP_CIPHER_INFO(char *header, EVP_CIPHER_INFO *cipher)
 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);
@@ -536,7 +537,7 @@ int PEM_get_EVP_CIPHER_INFO(char *header, EVP_CIPHER_INFO *cipher)
 }
 *header = '\0';
 cipher->cipher = enc = EVP_get_cipherbyname(dekinfostart);
-*header = c;
+*header++ = c;
 
 if (enc == NULL) {
 PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, PEM_R_UNSUPPORTED_ENCRYPTION);
-- 
1.8.4

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

Re: [openssl-dev] OpenSSL 1.1.0 and FIPS

[Steve Marquess]

On 02/22/2016 01:58 PM, Dr. Stephen Henson wrote:
> On Mon, Feb 22, 2016, Wall, Stephen wrote:
> 
>> I wonder if I could get the thoughts of some of you developers on how
>> difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of
>> the current (2.0.11?) fipscanister.o.  Also, opinions on if this would be a
>> legitimate way to get FIPS in 1.1.0.
>>
> 
> Just to add a few thoughts to this.
> 
> It would be very tricky and rather messy. The 2.0.x module uses various
> shortcuts (which were pretty much essential given the time pressure on its
> development) such as keeping structure compatible with OpenSSL. For 1.1.0 many
> structures have changed considerably and many are opaque so this wont work.
> 
> Add to that that it isn't just a case of having an external ENGINE. There
> needs to be some extensive glue code in OpenSSL itself to (for example) ensure
> that the correct imeplementation is used and to block unapproved APIs and
> algorithms. 
> ...

This last point is worth emphasizing. While the formal FIPS validation
is more or less done in a vacuum (or perhaps I should say "reality
independent context"), it has to be used in a real world setting with
application code (probably legacy code developed to use stock OpenSSL).
That means a) using it with OpenSSL, because the FIPS module alone is
too impoverished an API for direct use, and b) making sure your
application does only FIPS allowed cryptography while FIPS mode is
enabled. That latter step is a lot harder than it looks. While some
vendors won't care as long as they have some minimal level of buzzword
compliance, some do.

With the "FIPS enabled" OpenSSL converting your existing application for
FIPS 140-2 can be as simple as throwing in a FIPS_mode_set() call. With
a stock OpenSSL and hand-jammed FIPS module you'd need to manually vet
all application code; the stock OpenSSL won't let you know when your
application uses non-allowed cryptography.

-Steve M.

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

[openssl-dev] RT4265 no-srtp still broken

[Short, Todd]

Configuring the master branch with no-srtp is still broken.

This PR: https://github.com/openssl/openssl/pull/582 fixes it. Its a bit out of 
date, but there shouldn’t be any conflicts.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

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

Re: [openssl-dev] OpenSSL 1.1.0 and FIPS

[Richard Levitte]

In message <20160222185829.ga19...@openssl.org> on Mon, 22 Feb 2016 18:58:29 
+, "Dr. Stephen Henson"  said:

steve> On Mon, Feb 22, 2016, Wall, Stephen wrote:
steve> 
steve> > I wonder if I could get the thoughts of some of you developers on how
steve> > difficult it would be to build an engine for OpenSSL 1.1.0 that makes 
use of
steve> > the current (2.0.11?) fipscanister.o.  Also, opinions on if this would 
be a
steve> > legitimate way to get FIPS in 1.1.0.
steve> > 
steve> 
steve> Just to add a few thoughts to this.
steve> 
steve> It would be very tricky and rather messy. The 2.0.x module uses various
steve> shortcuts (which were pretty much essential given the time pressure on 
its
steve> development) such as keeping structure compatible with OpenSSL. For 
1.1.0 many
steve> structures have changed considerably and many are opaque so this wont 
work.
steve> 
steve> Add to that that it isn't just a case of having an external ENGINE. There
steve> needs to be some extensive glue code in OpenSSL itself to (for example) 
ensure
steve> that the correct imeplementation is used and to block unapproved APIs and
steve> algorithms. 
steve> 
steve> So while I think it is theoretically possible I think handling this as 
part of
steve> a new validation effort would be the best approach. We could then 
incorporate
steve> some of the new FIPS 140-2 requirements and add some new algorithms.

This is where I go dreamy eyed with a desire to make all our built in
algorithm into an engine, loadable like any other engine.  The current
retrofit we do because we want to support having the low level
functions as dispatchers into a loaded engine still gives me the heeby
jeebies.

With that kind of setup, wouldn't it be incredibly easy to have the
approved FIPS 140-2 engine?

(if this ever happens, it's in the far future, folks)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL 1.1.0 and FIPS

[Dr. Stephen Henson]

On Mon, Feb 22, 2016, Wall, Stephen wrote:

> I wonder if I could get the thoughts of some of you developers on how
> difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of
> the current (2.0.11?) fipscanister.o.  Also, opinions on if this would be a
> legitimate way to get FIPS in 1.1.0.
> 

Just to add a few thoughts to this.

It would be very tricky and rather messy. The 2.0.x module uses various
shortcuts (which were pretty much essential given the time pressure on its
development) such as keeping structure compatible with OpenSSL. For 1.1.0 many
structures have changed considerably and many are opaque so this wont work.

Add to that that it isn't just a case of having an external ENGINE. There
needs to be some extensive glue code in OpenSSL itself to (for example) ensure
that the correct imeplementation is used and to block unapproved APIs and
algorithms. 

So while I think it is theoretically possible I think handling this as part of
a new validation effort would be the best approach. We could then incorporate
some of the new FIPS 140-2 requirements and add some new algorithms.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

[Richard Levitte]

In message <20160222180008.ga31...@calimero.vinschen.de> on Mon, 22 Feb 2016 
19:00:08 +0100, Corinna Vinschen  said:

vinschen> OTOH, is it much of a problem to apply the patches used for the Cygwin
vinschen> distro into the 1.0.2 branch so we can get rid of them entirely?  That
vinschen> would be extremly cool.  I attached them for your review.

I can at least look at them and make a judgement.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

[Corinna Vinschen]

On Feb 22 18:43, Richard Levitte wrote:
> In message <20160222173404.gb11...@calimero.vinschen.de> on Mon, 22 Feb 2016 
> 18:34:04 +0100, Corinna Vinschen  said:
> 
> vinschen> On Feb 21 06:27, Richard Levitte via RT wrote:
> vinschen> > I believe that the auto-detecting script, ./config, is lacking 
> detection of
> vinschen> > architecture for Cygwin. Does one preferably recognise a x86_64 
> Cygwin from
> vinschen> > `uname -m` or is there something in `uname -s` that should be 
> used as an
> vinschen> > indicator?
> vinschen> 
> vinschen> Uh oh, is there a chance that the configury for 1.0.2 is NOT changed
> vinschen> anymore?  We have a set of local patches in the Cygwin distro which
> vinschen> works around the missing pieces in 1.0.2 in a certain way, and 
> changing
> vinschen> the 1.0.2 branch now would break the build scripts for the Cygwin 
> distro.
> 
> A patch that fixes ./config was merged to the 1.0.2 branch earlier
> today.  Commit 5c57fbb8ca991e8db7ce23174613898a27ca3fcb.  It's a
> backport of the corresponding patch in master.  It's a very small
> change, I'd be surprised if you can't edit that particular one from
> your scripts.

This one's no problem since the build script runs ./Configure directly.

> 1.0.2 is on long term support, see
> http://openssl.org/policies/releasestrat.html.  That means that
> reasonable fixes might very well go in.  Sorry if that becomes a
> bother.

It's not a bother per se, only changes in the build system are
potentially disruptive, that's why I really dread them for the branch.

OTOH, is it much of a problem to apply the patches used for the Cygwin
distro into the 1.0.2 branch so we can get rid of them entirely?  That
would be extremly cool.  I attached them for your review.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
--- origsrc/openssl-1.0.2a/Configure2015-03-19 16:08:33.952761607 +0100
+++ src/openssl-1.0.2a/Configure2015-03-19 16:14:46.061816093 +0100
@@ -588,8 +588,8 @@ my %table=(
 "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:${no_asm}:win32",
 
 # Cygwin
-"Cygwin", "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 
-Wall:::CYGWIN::BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:${x86_asm}:coff:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a",
-"Cygwin-x86_64", "gcc:-DTERMIOS -DL_ENDIAN -O3 
-Wall:::CYGWIN::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT 
DES_UNROLL:${x86_64_asm}:mingw64:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a",
+"Cygwin", "gcc:\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 
-march=i686 -Wall:::CYGWIN::BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:${x86_asm}:coff:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a",
+"Cygwin-x86_64", "gcc:\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -O3 
-Wall:::CYGWIN::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT 
DES_UNROLL:${x86_64_asm}:mingw64:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a",
 
 # NetWare from David Ward (dsw...@novell.com)
 # requires either MetroWerks NLM development tools, or gcc / nlmconv
--- origsrc/openssl-1.0.2a/Makefile.shared  2015-03-19 16:14:57.245727560 
+0100
+++ src/openssl-1.0.2a/Makefile.shared  2015-03-19 16:15:45.514345456 +0100
@@ -272,7 +272,7 @@ link_o.cygwin:
SHLIB_SOVER=${LIBVERSION:+"-$(LIBVERSION)"}; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
-   SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base $$deffile 
-Wl,-s,-Bsymbolic"; \
+   SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base $$deffile 
-Wl,-Bsymbolic"; \
$(LINK_SO_O)
 #for mingw target if def-file is in use dll-name should match library-name
 link_a.cygwin:
@@ -297,7 +297,7 @@ link_a.cygwin:
extras="$$extras rc.o"; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
-   SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base 
-Wl,-s,-Bsymbolic -Wl,--out-implib,lib$(LIBNAME).dll.a $$extras"; \
+   SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base -Wl,-Bsymbolic 
-Wl,--out-implib,lib$(LIBNAME).dll.a $$extras"; \
[ -f apps/$$dll_name ] && rm apps/$$dll_name; \
[ -f test/$$dll_name ] && rm test/$$dll_name; \
$(LINK_SO_A) || exit 1; \
diff -up openssl-1.0.2a/Configure.enginesdir openssl-1.0.2a/Configure
--- openssl-1.0.2a/Configure.enginesdir 2015-04-20 14:37:58.13739 +0200
+++ openssl-1.0.2a/Configure2015-04-20 14:37:58.140392292 +0200
@@ -702,6 +702,7 @@ my $idx_multilib = $idx++;
 my $prefix="";
 my $libdir="";
 my $openssldir="";
+my $enginesdir="";
 my $exe_ext="";
 my $install_prefix= "$ENV{'INSTALL_PREFIX'}";
 my $cross_compile_prefix="";
@@ -929,6 +930,10 @@ PROCESS_ARGS:
{
$openssldir=$1;
}
+   elsif (/^--enginesdir=(.*)$/)
+   {
+   $enginesdir=$1;

Re: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

[Richard Levitte]

In message <20160222173404.gb11...@calimero.vinschen.de> on Mon, 22 Feb 2016 
18:34:04 +0100, Corinna Vinschen  said:

vinschen> On Feb 21 06:27, Richard Levitte via RT wrote:
vinschen> > I believe that the auto-detecting script, ./config, is lacking 
detection of
vinschen> > architecture for Cygwin. Does one preferably recognise a x86_64 
Cygwin from
vinschen> > `uname -m` or is there something in `uname -s` that should be used 
as an
vinschen> > indicator?
vinschen> 
vinschen> Uh oh, is there a chance that the configury for 1.0.2 is NOT changed
vinschen> anymore?  We have a set of local patches in the Cygwin distro which
vinschen> works around the missing pieces in 1.0.2 in a certain way, and 
changing
vinschen> the 1.0.2 branch now would break the build scripts for the Cygwin 
distro.

A patch that fixes ./config was merged to the 1.0.2 branch earlier
today.  Commit 5c57fbb8ca991e8db7ce23174613898a27ca3fcb.  It's a
backport of the corresponding patch in master.  It's a very small
change, I'd be surprised if you can't edit that particular one from
your scripts.

1.0.2 is on long term support, see
http://openssl.org/policies/releasestrat.html.  That means that
reasonable fixes might very well go in.  Sorry if that becomes a
bother.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

[Corinna Vinschen]

On Feb 21 06:27, Richard Levitte via RT wrote:
> I believe that the auto-detecting script, ./config, is lacking detection of
> architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from
> `uname -m` or is there something in `uname -s` that should be used as an
> indicator?

Uh oh, is there a chance that the configury for 1.0.2 is NOT changed
anymore?  We have a set of local patches in the Cygwin distro which
works around the missing pieces in 1.0.2 in a certain way, and changing
the 1.0.2 branch now would break the build scripts for the Cygwin distro.

I would very much prefer if people interested in OpenSSL 1.0.2 for Cygwin
would use the openssl-1.0.2 source archive, which cotains all patches
required for Cygwin, as well as the cygport build script to build openssl
exactly the same way as in the Cygwin distro.

Please let's not break that and stick to the master branch for the
build system changes.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4334] Check for UEFI before __STDC_VERSION__ for

[Rich Salz via RT]

fixed in commit a2d0baa thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4334
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 #4334] Check for UEFI before __STDC_VERSION__ for

[David Woodhouse via RT]

Adding -nostdinc to the EDK2 showed that we were including 
for some UEFI builds, because the check for __STDC_VERSION__ happens
before the check for OPENSSL_SYS_UEFI. Fix that.
---
 include/openssl/e_os2.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h
index b66b1cc..ba3345a 100644
--- a/include/openssl/e_os2.h
+++ b/include/openssl/e_os2.h
@@ -286,11 +286,7 @@ extern "C" {
 # endif
 
 /* Standard integer types */
-# if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
- defined(__osf__) || defined(__sgi) || defined(__hpux) || \
- defined(OPENSSL_SYS_VMS)
-#  include 
-# elif defined(OPENSSL_SYS_UEFI)
+# if defined(OPENSSL_SYS_UEFI)
 typedef INT8 int8_t;
 typedef UINT8 uint8_t;
 typedef INT16 int16_t;
@@ -299,7 +295,11 @@ typedef INT32 int32_t;
 typedef UINT32 uint32_t;
 typedef INT64 int64_t;
 typedef UINT64 uint64_t;
-#define PRIu64 "%Lu"
+#  define PRIu64 "%Lu"
+# elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+ defined(__osf__) || defined(__sgi) || defined(__hpux) || \
+ defined(OPENSSL_SYS_VMS)
+#  include 
 # elif defined(_MSC_VER) && _MSC_VER<=1500
 /*
  * minimally required typdefs for systems not supporting inttypes.h or
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL 1.1.0 and FIPS

[Steve Marquess]

On 02/22/2016 11:01 AM, Wall, Stephen wrote:
> I wonder if I could get the thoughts of some of you developers on how
> difficult it would be to build an engine for OpenSSL 1.1.0 that makes
> use of the current (2.0.11?) fipscanister.o.  Also, opinions on if
> this would be a legitimate way to get FIPS in 1.1.0.
> 
> Thanks, spw
> 

Re-use of the current 2.0 module was debated in detail, with the
conclusion that too many distortions to the new OpenSSL code would be
required. We're trying hard to get away from messy, ugly, fragile code
and reluctantly concluded that only a new FIPS module designed for a
clean interface with OpenSSL 1.1 was feasible.

We are not happy with the loss of FIPS support for 1.1; we know many
users require it. But, we're not willing to compromise sound software
engineering judgment to kludge together an abomination (and frankly the
current FIPS module with OpenSSL 1.0.N is pretty ugly already).

What we need is a new FIPS module, which we're willing to develop given
the opportunity. The main problem there is the formal validation
process. A FIPS 140-2 validation is challenging enough for conventional
proprietary close-source binary code; open source based validations are
enormously more difficult. Those have only been done five times, and my
assessment of the current regulatory environment is that it would be far
too risky for us to attempt a sixth such attempt (at least not without
sponsor(s) willing to absorb most of that risk).

If and when a new FIPS module for 1.1 is developed, it almost certainly
will take the form of a new "engine" style modular component.

-Steve M.

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

Re: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug

[Blumenthal, Uri - 0553 - MITLL]

If somebody (Mik, Felipe, you hear? :) cares to send me a *simple* *short*
code that exposes this problem, I’ll be willing to test it on Linux and
Mac OS X, with OpenSSL-1.0.2f, OpenSSL-1.0.2-stable, and 1.1-pre.
-- 
Regards,
Uri Blumenthal





On 2/20/16, 9:10 , "openssl-dev on behalf of Salz, Rich via RT"
 wrote:

>Still waiting to see from anyone else if it's a non-mac issue.
>
>
>-- 
>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290
>Please log in as guest with password guest if prompted
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL 1.1.0 and FIPS

[John Foley]

One of the challenges with this will be symbol collision (in a Linux 
environment).  I would think that doing this as a static engine would 
not be possible.  The reason is your new engine that's using the 2.0.11 
canister would contain symbols that exist in OpenSSL. But maybe the 
fipssyms.h trickery could be used to get past this.


Doing this as a dynamic engine may be a challenge as well.  Your dynamic 
engine, implemented as a .so, would have symbol overlap as well.  But 
these would be resolved by the loader.  Depending on whether 
libcrypto.so or your .so was loaded first by the loader, the wrong 
implementation for a symbol could be used.



On 02/22/2016 11:01 AM, Wall, Stephen wrote:

I wonder if I could get the thoughts of some of you developers on how difficult 
it would be to build an engine for OpenSSL 1.1.0 that makes use of the current 
(2.0.11?) fipscanister.o.  Also, opinions on if this would be a legitimate way 
to get FIPS in 1.1.0.

Thanks,
spw



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

[openssl-dev] [openssl.org #4309] [PATCH] Fix UEFI/EDK2 build error by defining PRIu64

[Rich Salz via RT]

pushed in commit d99d0d9 thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4309
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 #4326] Failed to configure for Cygwin-x64

[Lee, Ju via RT]

9e04edf2f309e7edc3f4c9a09d444b2fd23a1e46 fixed

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Lee, Ju 
via RT
Sent: Monday, February 22, 2016 9:57 AM
To: noloa...@gmail.com
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4326] Failed to configure for 
Cygwin-x64

It failed to 'make test' at d784bcffa3dcd7ac4a0c77bfac4e686dcb771bd9 this 
morning.

Test Summary Report
---
../../openssl/test/recipes/70-test_sslcertstatus.t (Wstat: 28416 Tests: 0 
Failed: 0)
  Non-zero exit status: 111
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=68, Tests=386, 23 wallclock secs ( 0.41 usr  0.07 sys + 14.88 cusr  0.66 
csys = 16.02 CPU)
Result: FAIL
Failed 1/68 test programs. 0/386 subtests failed.
Makefile:118: recipe for target 'test' failed
make: *** [test] Error 255
user@washinro1:~/_openssl-build_linux-x86_64$

BTW, 'make test' passed like below. Somehow the make rule in test fails.

user@washinro1:~/openssl$ cat testlog
OpenSSL self-test report:

OpenSSL version:  1.1.0-pre4-dev
Last change:  Configuration change; it's now possible to build dynami...
Options:  -Wa,--noexecstack no-crypto-mdebug no-crypto-mdebug-backtrace 
no-ec_nistp_64_gcc_128 no-egd no-heartbeats no-md2 no-rc5 no-sctp no-shared 
no-ssl-trace no-static-engine no-unit-test no-zlib no-zlib-dynamic
OS (uname):   Linux washinro1 3.16.0-4-amd64 #1 SMP Debian 
3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
OS (config):  x86_64-whatever-linux2
Target (default): linux-x86_64
Target:   linux-x86_64
Compiler: Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
  --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 
4.9.2-10)

Test passed.
user@washinro1:~/openssl$

Ju


-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard 
Levitte via RT
Sent: Monday, February 22, 2016 8:49 AM
To: noloa...@gmail.com
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

Sorry, wrong commit cited here, the correct one is 
5c57fbb8ca991e8db7ce23174613898a27ca3fcb

Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte:
> Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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


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

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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326
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 #4326] Failed to configure for Cygwin-x64

[Lee, Ju (Converged Systems)]

9e04edf2f309e7edc3f4c9a09d444b2fd23a1e46 fixed

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Lee, Ju 
via RT
Sent: Monday, February 22, 2016 9:57 AM
To: noloa...@gmail.com
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4326] Failed to configure for 
Cygwin-x64

It failed to 'make test' at d784bcffa3dcd7ac4a0c77bfac4e686dcb771bd9 this 
morning.

Test Summary Report
---
../../openssl/test/recipes/70-test_sslcertstatus.t (Wstat: 28416 Tests: 0 
Failed: 0)
  Non-zero exit status: 111
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=68, Tests=386, 23 wallclock secs ( 0.41 usr  0.07 sys + 14.88 cusr  0.66 
csys = 16.02 CPU)
Result: FAIL
Failed 1/68 test programs. 0/386 subtests failed.
Makefile:118: recipe for target 'test' failed
make: *** [test] Error 255
user@washinro1:~/_openssl-build_linux-x86_64$

BTW, 'make test' passed like below. Somehow the make rule in test fails.

user@washinro1:~/openssl$ cat testlog
OpenSSL self-test report:

OpenSSL version:  1.1.0-pre4-dev
Last change:  Configuration change; it's now possible to build dynami...
Options:  -Wa,--noexecstack no-crypto-mdebug no-crypto-mdebug-backtrace 
no-ec_nistp_64_gcc_128 no-egd no-heartbeats no-md2 no-rc5 no-sctp no-shared 
no-ssl-trace no-static-engine no-unit-test no-zlib no-zlib-dynamic
OS (uname):   Linux washinro1 3.16.0-4-amd64 #1 SMP Debian 
3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
OS (config):  x86_64-whatever-linux2
Target (default): linux-x86_64
Target:   linux-x86_64
Compiler: Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
  --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 
4.9.2-10)

Test passed.
user@washinro1:~/openssl$

Ju


-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard 
Levitte via RT
Sent: Monday, February 22, 2016 8:49 AM
To: noloa...@gmail.com
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

Sorry, wrong commit cited here, the correct one is 
5c57fbb8ca991e8db7ce23174613898a27ca3fcb

Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte:
> Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326
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 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()

[Rich Salz via RT]

fixed in commit 985c3146967633707f7c165df82bb0fd8f279758 thanks for the report!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
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 1.1.0 and FIPS

[Wall, Stephen]

I wonder if I could get the thoughts of some of you developers on how difficult 
it would be to build an engine for OpenSSL 1.1.0 that makes use of the current 
(2.0.11?) fipscanister.o.  Also, opinions on if this would be a legitimate way 
to get FIPS in 1.1.0.

Thanks,
spw

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

Re: [openssl-dev] Ubsec and Chil engines

[Blumenthal, Uri - 0553 - MITLL]

On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse"
 wrote:

>>It may even be better, instead of pushing for different engines for
>> different hardware, to make PKCS#11 the only API used to talk to
>> hardware. There is a quite functional (and active as project) pkcs11
>> engine for openssl [0].
>
>Agreed. With the caveat that I *really* want libp11 and engine_pkcs11
>to die, and be replaced by native code in openssl/crypto/pkcs11/

Would you mind explaining what you mean by “native code” that presumably
could replace the current libp11, and who in your opinion would support it?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

[Lee, Ju via RT]

It failed to 'make test' at d784bcffa3dcd7ac4a0c77bfac4e686dcb771bd9 this 
morning.

Test Summary Report
---
../../openssl/test/recipes/70-test_sslcertstatus.t (Wstat: 28416 Tests: 0 
Failed: 0)
  Non-zero exit status: 111
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=68, Tests=386, 23 wallclock secs ( 0.41 usr  0.07 sys + 14.88 cusr  0.66 
csys = 16.02 CPU)
Result: FAIL
Failed 1/68 test programs. 0/386 subtests failed.
Makefile:118: recipe for target 'test' failed
make: *** [test] Error 255
user@washinro1:~/_openssl-build_linux-x86_64$

BTW, 'make test' passed like below. Somehow the make rule in test fails.

user@washinro1:~/openssl$ cat testlog
OpenSSL self-test report:

OpenSSL version:  1.1.0-pre4-dev
Last change:  Configuration change; it's now possible to build dynami...
Options:  -Wa,--noexecstack no-crypto-mdebug no-crypto-mdebug-backtrace 
no-ec_nistp_64_gcc_128 no-egd no-heartbeats no-md2 no-rc5 no-sctp no-shared 
no-ssl-trace no-static-engine no-unit-test no-zlib no-zlib-dynamic
OS (uname):   Linux washinro1 3.16.0-4-amd64 #1 SMP Debian 
3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
OS (config):  x86_64-whatever-linux2
Target (default): linux-x86_64
Target:   linux-x86_64
Compiler: Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
  --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

Test passed.
user@washinro1:~/openssl$

Ju


-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard 
Levitte via RT
Sent: Monday, February 22, 2016 8:49 AM
To: noloa...@gmail.com
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

Sorry, wrong commit cited here, the correct one is 
5c57fbb8ca991e8db7ce23174613898a27ca3fcb

Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte:
> Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326
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 #4326] Failed to configure for Cygwin-x64

[Lee, Ju (Converged Systems)]

It failed to 'make test' at d784bcffa3dcd7ac4a0c77bfac4e686dcb771bd9 this 
morning.

Test Summary Report
---
../../openssl/test/recipes/70-test_sslcertstatus.t (Wstat: 28416 Tests: 0 
Failed: 0)
  Non-zero exit status: 111
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=68, Tests=386, 23 wallclock secs ( 0.41 usr  0.07 sys + 14.88 cusr  0.66 
csys = 16.02 CPU)
Result: FAIL
Failed 1/68 test programs. 0/386 subtests failed.
Makefile:118: recipe for target 'test' failed
make: *** [test] Error 255
user@washinro1:~/_openssl-build_linux-x86_64$

BTW, 'make test' passed like below. Somehow the make rule in test fails.

user@washinro1:~/openssl$ cat testlog
OpenSSL self-test report:

OpenSSL version:  1.1.0-pre4-dev
Last change:  Configuration change; it's now possible to build dynami...
Options:  -Wa,--noexecstack no-crypto-mdebug no-crypto-mdebug-backtrace 
no-ec_nistp_64_gcc_128 no-egd no-heartbeats no-md2 no-rc5 no-sctp no-shared 
no-ssl-trace no-static-engine no-unit-test no-zlib no-zlib-dynamic
OS (uname):   Linux washinro1 3.16.0-4-amd64 #1 SMP Debian 
3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
OS (config):  x86_64-whatever-linux2
Target (default): linux-x86_64
Target:   linux-x86_64
Compiler: Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
  --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

Test passed.
user@washinro1:~/openssl$

Ju


-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard 
Levitte via RT
Sent: Monday, February 22, 2016 8:49 AM
To: noloa...@gmail.com
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

Sorry, wrong commit cited here, the correct one is 
5c57fbb8ca991e8db7ce23174613898a27ca3fcb

Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte:
> Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882
>
> --
> Richard Levitte
> levi...@openssl.org


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

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326
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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] openssl-1.1 started looking for engines using wrong names

[Blumenthal, Uri - 0553 - MITLL]

In short, after commits done in the last few days, openssl-1.1 stopped
looking for lib.so, and started looking for .so. I think
it’s an introduced bug that needs to be fixed:

$ ~/src/openssl-1.1/bin/openssl engine pkcs11 -t

140735268914000:error:25066067:DSO support routines:dlfcn_load:could not
load the shared 
library:crypto/dso/dso_dlfcn.c:172:filename(/Users/ur20980/src/openssl-1.1/l
ib/engines/pkcs11.dylib):
dlopen(/Users/ur20980/src/openssl-1.1/lib/engines/pkcs11.dylib, 2): image
not found

140735268914000:error:25070067:DSO support routines:DSO_load:could not load
the shared library:crypto/dso/dso_lib.c:220:

140735268914000:error:260B6084:engine routines:dynamic_load:dso not
found:crypto/engine/eng_dyn.c:456:

140735268914000:error:2606A074:engine routines:ENGINE_by_id:no such
engine:crypto/engine/eng_list.c:372:id=pkcs11

$ ln -s /Users/ur20980/src/openssl-1.1/lib/engines/libpkcs11.dylib
/Users/ur20980/src/openssl-1.1/lib/engines/pkcs11.dylib

$ ~/src/openssl-1.1/bin/openssl engine pkcs11 -t

(pkcs11) pkcs11 engine

 [ available ]

$


This issue has been reported on Github:
https://github.com/openssl/openssl/issues/727
-- 
Regards,
Uri Blumenthal




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[Richard Levitte]

In message 
<347004c001fd430aadadceac908e6...@ustx2ex-dag1mb1.msg.corp.akamai.com> on Mon, 
22 Feb 2016 14:46:28 +, "Salz, Rich"  said:

rsalz> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs 
(see
rsalz> > RFC7512) can be first-class citizens throughout the crypto and SSL 
APIs. Any
rsalz> > function which takes a filename for a cert or key should also accept¹ a
rsalz> > PKCS#11 URI.
rsalz> 
rsalz> It'd be great to see a crypto/pkcs11 directory with full native support 
(as much as possible).
rsalz> 
rsalz> But really doubtful to happen in 1.1 as the API freeze is in a month.

Yeah, 1.1 is unrealistic, I'm sorry to say.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

[Richard Levitte via RT]

Sorry, wrong commit cited here, the correct one is
5c57fbb8ca991e8db7ce23174613898a27ca3fcb

Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte:
> Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882
>
> --
> Richard Levitte
> levi...@openssl.org


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

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326
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 #4330] Unsupported options: no-ssl2

[Richard Levitte via RT]

Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882

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

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4330
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 #4326] Failed to configure for Cygwin-x64

[Richard Levitte via RT]

Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882

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

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326
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] Ubsec and Chil engines

[Salz, Rich]

> If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> function which takes a filename for a cert or key should also accept¹ a
> PKCS#11 URI.

It'd be great to see a crypto/pkcs11 directory with full native support (as 
much as possible).

But really doubtful to happen in 1.1 as the API freeze is in a month.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[Jaroslav Imrich]

On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos 
wrote:

> That's an implementation detail. As far as I know engine_pkcs11 does
> not require re-authentication after fork. It handles the pkcs11
> peculiarities internally.
>

AFAIK this works by caching the PIN in engine_pkcs11 internally and is OK
for most of the use cases with smartcards. However HSMs usually use more
complex authentication schemes where this approach does not work i.e. in
order to login there must be N of M physical tokens/cards with passwords
presented in a sequence (requires vendor specific extensions when used via
PKCS#11). CHIL engine already handles such schemes very well and does not
need to reauthenticate after fork.

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

Re: [openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Mon, 2016-02-22 at 12:52 +0100, Richard Levitte wrote:
> 
> That takes me back to crypto/store, which is currently removed in
> master but which I have a rework of in a branch, which is meant to
> solve this exact problem, but without being exclusively tied to
> PKCS#11.  The design is to have it work with engine backends, and a
> PKCS#11 engine that's part of OpenSSL would fit that bill, so to say.

That seems ideal. The TPM ENGINE could benefit from it too.

I'd really like to look at this from the *application* developer's
point of view.

Please clear your mind of any internal OpenSSL knowledge and context,
and take a look at the OpenConnect VPN client, and the various hoops it
has to jump through to load a certificate:
http://git.infradead.org/users/dwmw2/openconnect.git/blob/v7.06:/openssl.c#l261
through to the main load_certificate() function which ends at line
916. 

(You can ignore the entire contents of openssl-pkcs11.c for now.)

Even if you discount the TPM and PKCS#11 parts, it's bad enough for
just loading certificates from a file. We force the *application* to
inspect the file that the user asked it to use, and work out what kind
of file it is. And then even the handling of the *passphrase* is
different according to what kind of file it is — PKCS#12 functions need
the password handed in, while PEM functions are given a callback
function instead.

And don't even *talk* to me about the horridness with the TPM's UI
having no way to pass through any opaque data to the callback, and the
need for that 'static struct openconnect_info *ui_vpninfo' at line 276.
Actually, do talk to me about that. Let's fix it before 1.1?

We desperately need to provide applications with a function that
silently Does The Right Thing, when given a filename or a PKCS#11 URI
or whatever other string a user might put reasonably put into a config
file to specify a certificate/key.

> Shall we talk?

Absolutely :)

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[Richard Levitte]

In message <1456140741.4735.272.ca...@infradead.org> on Mon, 22 Feb 2016 
11:32:21 +, David Woodhouse  said:

dwmw2> On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > sander> What I would like to see though is for such a PKCS#11 Engine
dwmw2> > sander> to be part of OpenSSL proper, so that our customers and
dwmw2> > sander> everyone else’s don’t have to go hunt hither and yon for bits
dwmw2> > sander> and bobs of software in order to make their hardware kit work
dwmw2> > sander> with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to
dwmw2> > sander> include in its distribution?
dwmw2> > 
dwmw2> > I'm not sure if this is a problem specifically for OpenSSL to solve,
dwmw2> > or if it is a packager problem. 
dwmw2> 
dwmw2> I touched on this in a message a few minutes ago, but I *definitely*
dwmw2> think it's the former.
dwmw2> 
dwmw2> If we integrate the support natively into OpenSSL, then PKCS#11 URIs
dwmw2> (see RFC7512) can be first-class citizens throughout the crypto and SSL
dwmw2> APIs. Any function which takes a filename for a cert or key should also
dwmw2> accept¹ a PKCS#11 URI.
dwmw2> 
dwmw2> Then we can also use PKCS#11 for the trust database, which allows us to
dwmw2> properly handle the trusted *purposes* in ways that a flat file
dwmw2> doesn't. And that flat file is now *exported* from the p11-kit-trust
dwmw2> token purely for the benefit of OpenSSL, which it would be nice to stop
dwmw2> doing.
dwmw2> 
dwmw2> I am happy to work on this.

That takes me back to crypto/store, which is currently removed in
master but which I have a rework of in a branch, which is meant to
solve this exact problem, but without being exclusively tied to
PKCS#11.  The design is to have it work with engine backends, and a
PKCS#11 engine that's part of OpenSSL would fit that bill, so to say.

Shall we talk?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:
> 
> sander> What I would like to see though is for such a PKCS#11 Engine
> sander> to be part of OpenSSL proper, so that our customers and
> sander> everyone else’s don’t have to go hunt hither and yon for bits
> sander> and bobs of software in order to make their hardware kit work
> sander> with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to
> sander> include in its distribution?
> 
> I'm not sure if this is a problem specifically for OpenSSL to solve,
> or if it is a packager problem. 

I touched on this in a message a few minutes ago, but I *definitely*
think it's the former.

If we integrate the support natively into OpenSSL, then PKCS#11 URIs
(see RFC7512) can be first-class citizens throughout the crypto and SSL
APIs. Any function which takes a filename for a cert or key should also
accept¹ a PKCS#11 URI.

Then we can also use PKCS#11 for the trust database, which allows us to
properly handle the trusted *purposes* in ways that a flat file
doesn't. And that flat file is now *exported* from the p11-kit-trust
token purely for the benefit of OpenSSL, which it would be nice to stop
doing.

I am happy to work on this.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


¹ Or "have a parallel function which takes"... but seriously, how often is
  a string which starts "pkcs11:" going to have been intended as a an
  actual *filename*? :)


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Fri, 2016-02-19 at 15:53 +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, 2016-02-19 at 13:12 +, Matt Caswell wrote:
> 
> > As far as I know there are some customers using the Chil engine
> > > with
> > > RHEL (openssl-1.0.1). 
> > 
> > How do you feel about the engine being spun out into a separate
> > repo?
> > That of course assumes that a volunteer can be found to maintain it
> > (I
> > don't believe anyone on the dev team wishes to do so).
> > 
> > If no such volunteer can be found how big a deal is it to remove it
> > from
> > 1.1.0 without a replacement? Obviously it won't be taken out of
> > 1.0.1/1.0.2. Of course there's no reason, even if we take it out
> > now,
> > that if someone needs it badly enough in the future that they
> > couldn't forward port the 1.0.2 version to 1.1.0 and maintain it
> > themselves at that point.
> 
> It may even be better, instead of pushing for different engines for
> different hardware, to make PKCS#11 the only API used to talk to
> hardware. There is a quite functional (and active as project) pkcs11
> engine for openssl [0].

Agreed. With the caveat that I *really* want libp11 and engine_pkcs11
to die, and be replaced by native code in openssl/crypto/pkcs11/

That way we can integrate it *properly*, with various SSL certificate
handling functions just naturally taking PKCS#11 URIs alongside
filenames.

Integrating libp11 itself would require relicensing it, which might be
non-trivial but perhaps still achievable. Or maybe we should
reimplement it, basing the new version around p11-kit.

It would be an *optional* thing, of course. Windows builds might
default to no-pkcs11. But p11-kit ought to exist fairly much everywhere
*else*.

Apart from UEFI :)

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[Nikos Mavrogiannopoulos]

On Sat, 2016-02-20 at 23:34 +0100, Jaroslav Imrich wrote:
> On 20 February 2016 at 21:40, Sander Temme  wrote:
> >  However, I’m intrigued by the notion of a PKCS#11 Engine in
> > OpenSSL: it’s a standard (an OASIS standard now); it’s fairly fully
> > featured; everyone in the industry supports it including Thales;
> > and you can build a program that calls it without needing a vendor
> > SDK, because there are standard headers and a well defined way to
> > get to the entry points.  If we can come up with a way to pick a
> > PKCS#11 slot and log into it that makes sense (e.g. not by poking
> > PINs into a system wide config file etc.) then I think we’d have a
> > winner.
> Let's not forget that CHIL provides one very unique feature - forked
> process keeps the authentication state of its parent and can access
> HSM keys if its parent was authenticated. PKCS#11 specification
> prohibits such behavior (PKCS#11 v2.20 chapter 6.6.1) and because of
> that PKCS#11 based engine couldn't fully replace CHIL engine.

That's an implementation detail. As far as I know engine_pkcs11 does
not require re-authentication after fork. It handles the pkcs11
peculiarities internally.

regards,
Nikos

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

[openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64

[Richard Levitte via RT]

Actually, master already had a patch, which is even better. I'll apply one
reminding of that.

Vid Sun, 21 Feb 2016 kl. 08.22.02, skrev noloa...@gmail.com:
> On Sun, Feb 21, 2016 at 2:50 AM, Richard Levitte via RT
>  wrote:
> > Would you try the attached patch, please?
> >
>
> Looks good for both 1.0.2 and Master.
>
> Its also nice to see CHACHA_ENC and POLY1305_OBJ in the list below.
>
> =
>
> openssl-git $ ./config
> Operating system: x86_64-pc-cygwin
> Configuring for Cygwin-x86_64
> Configuring OpenSSL version 1.1.0-pre4-dev (0x0x1014L)
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [forced]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> 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-static-engine [default]
> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> no-zlib [default]
> no-zlib-dynamic [forced]
> Configuring for Cygwin-x86_64
> IsMK1MF =no
> CC =gcc
> CFLAG = -DTERMIOS -DL_ENDIAN -Wall -O3
> DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
> OPENSSL_NO_STATIC_ENGINE 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 =
> CPUID_OBJ =x86_64cpuid.o
> 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
> PROCESSOR =
> RANLIB =/usr/bin/ranlib.exe
> ARFLAGS =
> PERL =/usr/bin/perl.exe
> SIXTY_FOUR_BIT_LONG mode
> Configured for Cygwin-x86_64.


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

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326
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 #4330] Unsupported options: no-ssl2

[Richard Levitte via RT]

Does the attached patch work for you?

Vid Sun, 21 Feb 2016 kl. 17.06.58, skrev noloa...@gmail.com:
> I think its great that SSLv2 is disabled by default or removed.
> However, this might cause some UI pain:
>
> $ ./config shared no-ssl2 no-ssl3
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre4-dev (0x0x1014L)
> * Unsupported options: no-ssl2
>
> For years we have been pounding into people's heads: "configure with
> no-ssl2 no-ssl3". SSLv2 and SSLv3 are insecure. See, for example,
> http://www.owasp.org/index.php/C-Based_Toolchain_Hardening#Integration.
>
> Changing the behavior now such that 'no-ssl2' is an error creates
> additional rules that users should not have to worry about. User might
> accidentally omit 'no-ssl2' on OpenSSL 1.0.1 and below due to the new
> conditioning.
>
> I think it would be good for users to (1) disable or omit SSLv2 (as
> the library is doing), and (2) honor or ignore 'no-ssl2' (both achieve
> the same goal).
>


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

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

commit 7ada660bede2b82bd26cca9cd6cb856abf2d7e9b
Author: Richard Levitte 
Date:   Mon Feb 22 10:42:53 2016 +0100

Get back "ssl2" as a deprecated disablable option

Preserved for now for those who have scripts with the option
"no-ssl2".  We warn that it's deprecated, and ignore it otherwise.

In response to RT#4330

diff --git a/Configure b/Configure
index 1cb5ace..7a5b8bc 100755
--- a/Configure
+++ b/Configure
@@ -325,6 +325,10 @@ foreach my $proto ((@tls, @dtls))
 	push(@disablables, "$proto-method");
 	}
 
+my @deprecated_disablables = (
+"ssl2",
+);
+
 # All of the following is disabled by default (RC5 was enabled before 0.9.8):
 
 my %disabled = ( # "what" => "comment"
@@ -490,6 +494,7 @@ if (grep /^reconf(igure)?$/, @argvcopy) {
 $config{perlargv} = [ @argvcopy ];
 
 my %unsupported_options = ();
+my %deprecated_options = ();
 foreach (@argvcopy)
 	{
 	# VMS is a case insensitive environment, and depending on settings
@@ -511,7 +516,12 @@ foreach (@argvcopy)
 if (/^(no|disable|enable)-(.+)$/)
 		{
 		my $word = $2;
-		if (!grep { $word =~ /^${_}$/ } @disablables)
+		if (grep { $word =~ /^${_}$/ } @deprecated_disablables)
+			{
+			$deprecated_options{$_} = 1;
+			next;
+			}
+		elsif (!grep { $word =~ /^${_}$/ } @disablables)
 			{
 			$unsupported_options{$_} = 1;
 			next;
@@ -694,6 +704,11 @@ foreach (@argvcopy)
 		die "* Unsupported api compatibility level: $config{api}\n",
 }
 
+	if (keys %deprecated_options)
+		{
+		warn "* Deprecated options: ",
+			join(", ", keys %deprecated_options), "\n";
+		}
 	if (keys %unsupported_options)
 		{
 		die "* Unsupported options: ",
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev