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

[Richard Levitte via RT]

Would you try the attached patch, please?

--
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

diff --git a/config b/config
index 77f730f..5213a0d 100755
--- a/config
+++ b/config
@@ -851,6 +851,7 @@ case "$GUESSOS" in
   # these are all covered by the catchall below
   # *-dgux) OUT="dgux" ;;
   mips-sony-newsos4) OUT="newsos4-gcc" ;;
+  x86_64-*-cygwin) OUT="Cygwin-x86_64" ;;
   *-*-cygwin_pre1.3) OUT="Cygwin-pre1.3" ;;
   *-*-cygwin) OUT="Cygwin" ;;
   t3e-cray-unicosmk) OUT="cray-t3e" ;;
-- 
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

[noloa...@gmail.com via RT]

> 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?

Yes, that seems to be the issue at hand for OpenSSL 1.0.2. Using the
following works:

  $ export KERNEL_BITS=64
  $ ./Configure Cygwin-x86_64 ...

KERNEL_BITS=64 may not be needed. Its old habit for OS X, where config
wants to select 32-bit builds for modern 64-bit machines.

Uname (for x86_64 installation):

  $ uname -m
  x86_64

  $ uname -a
  CYGWIN_NT-6.3 asus-windows8 2.4.1(0.293/5/3)
2016-01-24 11:26 x86_64 Cygwin

  $ uname -s
  CYGWIN_NT-6.3

You can also go to the preprocessor, if interested (for x86_64 installation):

  $ cpp -dM - 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

[Jeffrey Walton]

> 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?

Yes, that seems to be the issue at hand for OpenSSL 1.0.2. Using the
following works:

  $ export KERNEL_BITS=64
  $ ./Configure Cygwin-x86_64 ...

KERNEL_BITS=64 may not be needed. Its old habit for OS X, where config
wants to select 32-bit builds for modern 64-bit machines.

Uname (for x86_64 installation):

  $ uname -m
  x86_64

  $ uname -a
  CYGWIN_NT-6.3 asus-windows8 2.4.1(0.293/5/3)
2016-01-24 11:26 x86_64 Cygwin

  $ uname -s
  CYGWIN_NT-6.3

You can also go to the preprocessor, if interested (for x86_64 installation):

  $ cpp -dM - https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[noloa...@gmail.com via RT]

On Sun, Feb 21, 2016 at 1:27 AM, 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?

Yes, that seems to be the issue at hand for OpenSSL 1.0.2. Using the
following works:

  $ export KERNEL_BITS=64
  $ ./Configure Cygwin-x86_64 ...

KERNEL_BITS=64 may not be needed. Its old habit for OS X, where config
wants to select 32-bit builds for modern 64-bit machines.

Uname (for x86_64 installation):

  $ uname -m
  x86_64

  $ uname -a
  CYGWIN_NT-6.3 asus-windows8 2.4.1(0.293/5/3)
2016-01-24 11:26 x86_64 Cygwin

  $ uname -s
  CYGWIN_NT-6.3

You can also go to the preprocessor, if interested (for x86_64 installation):

  $ cpp -dM - 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 #4328] Cygwin, self test and "./bctest: line 35: bc: command not found"

[Richard Levitte via RT]

Truth is, the logic is a bit flawed, and it's not about those platform specific
tests (which it shouldn't try on that first run). The correct conclusion right
now is that you need to install 'bc' to be able to run the BIGNUM test

Vid Sun, 21 Feb 2016 kl. 05.25.30, skrev noloa...@gmail.com:
> Working on Windows under Cygwin-64:
>
> $ make test
> ... running bc
> ./bctest: line 35: bc: command not found
> bc does not work properly ('SunOStest' failed). Looking for another bc ...
> No working bc found. Consider installing GNU bc.
> 0 tests passed
>
> I'm reporting it because of the reference to "'SunOStest". It appears
> there's some logic involved that identifies the platform.
>


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

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

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?

Cheers,
Richard

Vid Sun, 21 Feb 2016 kl. 04.33.17, skrev noloa...@gmail.com:
> Also see Issue 3110
> (http://rt.openssl.org/Ticket/Display.html?id=3110) and "Adding
> support for x86_64 Cygwin"
> (http://openssl.6102.n7.nabble.com/openssl-org-3110-Adding-support-
> for-x86-64-Cygwin-td46131.html).
>
> The 3110 issue was closed in May 2015, but it looks like something is
> a bit amiss.
>
> > After configuring on Windows 8.1/Core i5 4th gen machine, make'ing
> > depend produces the following errors:
> >
> > $ make depend
> > making depend in crypto...
> > make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto'
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > cc1: error: CPU you selected does not support x86-64 instruction set
> > Makefile:136: recipe for target 'local_depend' failed
> > make[1]: *** [local_depend] Error 1
> > make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto'
> > Makefile:471: recipe for target 'depend' failed
> > make: *** [depend] Error 1
> >
> > ==
> >
> > $ ./config shared no-ssl2 no-ssl3 --openssldir="$HOME/ssl"
> > Operating system: x86_64-whatever-cygwin
> > Configuring for Cygwin
> > Configuring for Cygwin
> > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
> > (skip dir)
> > no-gmp [default] OPENSSL_NO_GMP (skip dir)
> > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
> > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
> > no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
> > no-md2 [default] OPENSSL_NO_MD2 (skip dir)
> > no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
> > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
> > no-sctp [default] OPENSSL_NO_SCTP (skip dir)
> > no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> > no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir)
> > no-ssl3 [option] OPENSSL_NO_SSL3 (skip dir)
> > no-store [experimental] OPENSSL_NO_STORE (skip dir)
> > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> > no-zlib [default]
> > no-zlib-dynamic [default]
> > IsMK1MF=0
> > CC =gcc
> > CFLAG =-D_WINDLL -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN
> > -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3
> > -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
> > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> > -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM
> > -DWHIRLPOOL_ASM -DGHASH_ASM
> > EX_LIBS =
> > CPUID_OBJ =x86cpuid.o
> > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o
> > EC_ASM =
> > DES_ENC =des-586.o crypt586.o
> > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o
> > BF_ENC =bf-586.o
> > CAST_ENC =c_enc.o
> > RC4_ENC =rc4-586.o
> > RC5_ENC 

[openssl-dev] [openssl.org #4328] Cygwin, self test and "./bctest: line 35: bc: command not found"

[noloa...@gmail.com via RT]

Working on Windows under Cygwin-64:

  $ make test
  ... running bc
  ./bctest: line 35: bc: command not found
  bc does not work properly ('SunOStest' failed). Looking for another bc ...
  No working bc found. Consider installing GNU bc.
  0 tests passed

I'm reporting it because of the reference to "'SunOStest". It appears
there's some logic involved that identifies the platform.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4328
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 #4327] SSL_CTX_use_serverinfo_file() causes issues for SSL_CTX with multiple certs

[TJ Saunders via RT]

When the SSL_CTX_use_serverinfo_file() function is used to configure
custom TLS extension data (e.g. for SCT data), AND the SSL_CTX in
question is configured for multiple server certificates, the SSL/TLS
handshake can fail unexpectedly, and will not return the configured TLS
extension data properly.

See:

  https://github.com/openssl/openssl/issues/719

Cheers,
TJ


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

[noloa...@gmail.com via RT]

 After configuring on Windows 8.1/Core i5 4th gen machine, make'ing
depend produces the following errors:

$ make depend
making depend in crypto...
make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto'
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
Makefile:136: recipe for target 'local_depend' failed
make[1]: *** [local_depend] Error 1
make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto'
Makefile:471: recipe for target 'depend' failed
make: *** [depend] Error 1

==

$ ./config shared no-ssl2 no-ssl3 --openssldir="$HOME/ssl"
Operating system: x86_64-whatever-cygwin
Configuring for Cygwin
Configuring for Cygwin
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
no-ssl2 [option]   OPENSSL_NO_SSL2 (skip dir)
no-ssl3 [option]   OPENSSL_NO_SSL3 (skip dir)
no-store[experimental] OPENSSL_NO_STORE (skip dir)
no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
IsMK1MF=0
CC=gcc
CFLAG =-D_WINDLL -DOPENSSL_PIC -DOPENSSL_THREADS  -DDSO_DLFCN
-DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3
-march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM
-DWHIRLPOOL_ASM -DGHASH_ASM
EX_LIBS   =
CPUID_OBJ =x86cpuid.o
BN_ASM=bn-586.o co-586.o x86-mont.o x86-gf2m.o
EC_ASM=
DES_ENC   =des-586.o crypt586.o
AES_ENC   =aes-586.o vpaes-x86.o aesni-x86.o
BF_ENC=bf-586.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4-586.o
RC5_ENC   =rc5-586.o
MD5_OBJ_ASM   =md5-586.o
SHA1_OBJ_ASM  =sha1-586.o sha256-586.o sha512-586.o
RMD160_OBJ_ASM=rmd-586.o
CMLL_ENC  =cmll-x86.o
MODES_OBJ =ghash-x86.o
ENGINES_OBJ   =
PROCESSOR =
RANLIB=/usr/bin/ranlib.exe
ARFLAGS   =
PERL  =/usr/bin/perl.exe
THIRTY_TWO_BIT mode
DES_PTR used
DES_RISC1 used
DES_UNROLL used
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined
e_os2.h => include/openssl/e_os2.h
making links in crypto...
make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto'
crypto.h => ../include/openssl/crypto.h
opensslv.h => ../include/openssl/opensslv.h
opensslconf.h => ../include/openssl/opensslconf.h
ebcdic.h => ../include/openssl/ebcdic.h
symhacks.h => 

Re: [openssl-dev] Ubsec and Chil engines

[Jaroslav Imrich]

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.

Regards, Jaroslav
-- 
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 <5b8f45ea-5867-4832-916a-6b31a323a...@temme.net> on Sat, 20 Feb 2016 
12:40:38 -0800, Sander Temme  said:

sander> 
sander> > On Feb 19, 2016, at 3:31 AM, Matt Caswell  wrote:
sander> 
sander> OK that made our support lines blow up so yes there is interest.
sander> 
sander> Disclaimer: I work for Thales but do not speak for Thales.
sander> 
sander> > So it seems that for chil there may possibly be some rare use (but 
even
sander> > the most recent evidence is 4 years old). However the OpenSSL dev team
sander> > do not have access to this hardware to maintain the engine and (as 
noted
sander> > above) this is currently not building in 1.1.0.
sander> 
sander> I think (again, personal impression) that this is one of those
sander> sleeper integrations that a lot of people use but doesn’t get
sander> on the radar a whole lot. Using openssl is by far the easiest
sander> way to get the nShield HSM to do something with protected
sander> keys… as long as those are RSA keys.  Pair that with existing
sander> application integrations like Apache, OpenSSH, etc. I know of
sander> a number of customers and partners, none of whom I am at
sander> liberty to discuss (although they might speak up for
sander> themselves), who use OpenSSL with nShield for various
sander> applications.

Oh, nShield?  Back when I was playing with e_chil.c, it was nCipher.
But, no matter really...

sander> So it’s not dead.  What it does, it does very well.  If
sander> anything, the lack of visible activity may indicate how easy
sander> CHIL is to use and support.

The trouble is that we can't verify that.  We don't have the hardware
or the expertise.  Even the few of us that got to play with a nCipher
box 15+ years ago don't have that around any more.  So there's that
pile of code that no one dares to touch because we have no idea what
the effects might be and have no way of testing that.

With all that in mind, I've a question back to you...  wouldn't it be
more productive if Thales let an OpenSSL engine, built as a DSO,
accompany the hardware?  Considering you are much closer to the
hardware and the expertise, it seems a bit more appropriate, doesn't
it?

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.  Sometimes, the border between the two
might be blurry, but...  If OpenSSL is to "obtain" a PKCS#11 engine,
it would probably be by writing one.  It would be far easier, though,
if someone would package the already existing engine_pkcs11 with
OpenSSL (that packaging doesn't have to be done by the OpenSSL team),
*or* with hardware distributions.

Cheers,
Richard

-- 
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

[Sander Temme]

> On Feb 19, 2016, at 3:31 AM, Matt Caswell  wrote:

OK that made our support lines blow up so yes there is interest.

Disclaimer: I work for Thales but do not speak for Thales.

> So it seems that for chil there may possibly be some rare use (but even
> the most recent evidence is 4 years old). However the OpenSSL dev team
> do not have access to this hardware to maintain the engine and (as noted
> above) this is currently not building in 1.1.0.

I think (again, personal impression) that this is one of those sleeper 
integrations that a lot of people use but doesn’t get on the radar a whole lot. 
Using openssl is by far the easiest way to get the nShield HSM to do something 
with protected keys… as long as those are RSA keys.  Pair that with existing 
application integrations like Apache, OpenSSH, etc. I know of a number of 
customers and partners, none of whom I am at liberty to discuss (although they 
might speak up for themselves), who use OpenSSL with nShield for various 
applications.

So it’s not dead.  What it does, it does very well.  If anything, the lack of 
visible activity may indicate how easy CHIL is to use and support.

> In both cases I would like to remove these engines from 1.1.0. I'd like
> to hear from the community if there is any active use of these. One
> option if there is found to be some small scale use is to spin out the
> engine into a separately managed repo (as has happened recently with the
> GOST engine).
> 
> If I don't hear from anyone I will remove these.

Ehm.  Let’s talk about this.  As I noted above, a lot of our valued customers 
may depend on this even thought they might not know or may have forgotten about 
it.  From your October 28 commit (29e7a56d), it seems that what broke us was 
when the bn structure went opaque… I see only two lines in e_chil.c that depend 
on the internal structure of bn so that should be addressable.  We’d like to do 
some more things to this Engine, like more key types and, yes, those dynamic 
locks should go away, which requires some surgery to the stuff underneath but 
nothing major.  All the platforms we run on now have good locking.  And, Rich, 
I indeed have had those locks on my guilty conscience for all this time but not 
found any round tuits.

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.

What I would like to see though is for such a PKCS#11 Engine to be part of 
OpenSSL proper, so that our customers and everyone else’s don’t have to go hunt 
hither and yon for bits and bobs of software in order to make their hardware 
kit work with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to include in 
its distribution?

Thanks,

S.

--
san...@temme.net  http://www.temme.net/sander/
PGP FP: BCD1 6D2C 8906 C48A 540E  253E 94D3 36A3 6D15 930A





signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4324] openssl-1.1.0-pre3 with solaris-x86-cc & solaris64-x86_64-cc make fails

[Kiyoshi KANAZAWA via RT]

Make fails with ./Configure solaris-x86-cc such as
  :
cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_PIC 
-DOPENSSLDIR=/opt/openssl/ssl -DENGINESDIR=/opt/openssl/lib/engines -KPIC 
-D_REENTRANT -xarch=generic -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 
-xregs=frameptr -xdepend -xbuiltin -G -dy -z text -h libcrypto.so.1.1 
-Wl,-Bsymbolic -o ./libcrypto.so.1.1 -z allextract,-M,crypto.map ./libcrypto.a 
-z defaultextract -lsocket -lnsl -ldl
ld: fatal: option -z has illegal argument 'allextract,-M,crypto.map'
ld: fatal: flags processing errors



./Configure solaris64-x86_64-cc fails with the same error.


Tested on Solaris10 x86/64
cc: solarisstudio12.4 cc
ld: /usr/ccs/bin/ld


Before get here, you need #4314 fix &
patch as follows, because "add_before" in 10-main.conf does not set cflags 
correctly.
(See #4319)


diff -cr ../openssl-1.1.0-pre3.orig/Configurations/10-main.conf 
./Configurations/10-main.conf
*** ../openssl-1.1.0-pre3.orig/Configurations/10-main.conf  2016-02-16 
03:08:07.0 +0900
--- ./Configurations/10-main.conf   2016-02-20 15:13:44.634129625 +0900
***
*** 35,44 
  shared_extension => ".so",
  },
  
!  Solaros configirations
  "solaris-common" => {
  template => 1,
- cflags   => "-DFILIO_H",
  ex_libs  => "-lsocket -lnsl -ldl",
  dso_scheme   => "dlfcn",
  shared_target    => "solaris-shared",
--- 35,43 
  shared_extension => ".so",
  },
  
!  Solaris configurations
  "solaris-common" => {
  template => 1,
  ex_libs  => "-lsocket -lnsl -ldl",
  dso_scheme   => "dlfcn",
  shared_target    => "solaris-shared",
***
*** 53,59 
  # with "Illegal mnemonic" error message.
  inherit_from => [ "solaris-common", asm("x86_elf_asm") ],
  cc   => "gcc",
! cflags   => add_before("-march=pentium -Wall -DL_ENDIAN 
-DOPENSSL_NO_INLINE_ASM"),
  debug_cflags => "-O0 -g",
  release_cflags   => "-O3 -fomit-frame-pointer",
  thread_cflag => "-pthread",
--- 52,58 
  # with "Illegal mnemonic" error message.
  inherit_from => [ "solaris-common", asm("x86_elf_asm") ],
  cc   => "gcc",
! cflags   => "-march=pentium -Wall -DL_ENDIAN 
-DOPENSSL_NO_INLINE_ASM -DFILIO_H",
  debug_cflags => "-O0 -g",
  release_cflags   => "-O3 -fomit-frame-pointer",
  thread_cflag => "-pthread",
***
*** 72,78 
  # 
  inherit_from => [ "solaris-common", asm("x86_64_asm") ],
  cc   => "gcc",
! cflags   => add_before("-m64 -Wall -DL_ENDIAN"),
  debug_cflags => "-O0 -g",
  release_cflags   => "-O3",
  thread_cflag => "-pthread",
--- 71,77 
  # 
  inherit_from => [ "solaris-common", asm("x86_64_asm") ],
  cc   => "gcc",
! cflags   => "-m64 -Wall -DL_ENDIAN -DFILIO_H",
  debug_cflags => "-O0 -g",
  release_cflags   => "-O3",
  thread_cflag => "-pthread",
***
*** 87,93 
  "solaris-x86-cc" => {
  inherit_from => [ "solaris-common" ],
  cc   => "cc",
! cflags   => add_before("-xarch=generic -xstrconst -Xa 
-DL_ENDIAN"),
  debug_cflags => "-g",
  release_cflags   => "-xO5 -xregs=frameptr -xdepend -xbuiltin",
  thread_cflag => "-D_REENTRANT",
--- 86,92 
  "solaris-x86-cc" => {
  inherit_from => [ "solaris-common" ],
  cc   => "cc",
! cflags   => "-xarch=generic -xstrconst -Xa -DL_ENDIAN 
-DFILIO_H",
  debug_cflags => "-g",
  release_cflags   => "-xO5 -xregs=frameptr -xdepend -xbuiltin",
  thread_cflag => "-D_REENTRANT",
***
*** 100,106 
  "solaris64-x86_64-cc" => {
  inherit_from => [ "solaris-common", asm("x86_64_asm") ],
  cc   => "cc",
! cflags   => add_before("-xarch=generic64 -xstrconst -Xa 
-DL_ENDIAN"),
  debug_cflags => "-g",
  release_cflags   => "-xO5 -xdepend -xbuiltin",
  thread_cflag => "-D_REENTRANT",
--- 99,105 
  "solaris64-x86_64-cc" => {
  inherit_from => [ "solaris-common", asm("x86_64_asm") ],
  cc   => "cc",
! cflags   => "-m64 -xstrconst -Xa -DL_ENDIAN -DFILIO_H",
  debug_cflags => "-g",
  release_cflags   => "-xO5 -xdepend -xbuiltin",
  thread_cflag => "-D_REENTRANT",
***
*** 109,115 
  bn_ops   => "SIXTY_FOUR_BIT_LONG",
  perlasm_scheme   => "elf",
  

[openssl-dev] [openssl.org #4325] Unified Builds Don't Work With ARM

[Kurt Cancemi via RT]

Hello,

There are a few problems that I am facing with unified builds with arm:

1. arm_arch.h is not in the include path.
 fatal error: arm_arch.h: No such file or directory

2. The arm assembler scripts output to stdout
(see attached output.txt)

I have a patch for aes-armv4.pl that fixes the stdout issue
(I don't know if its proper) that uses the method from the
x86_64 perl files if thats the way to go I'll make a complete patch.
(see aes-armv4.pl.patch)

--
Kurt Cancemi
https://www.x64architecture.com

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

pi@raspberrypi:/tmp/openssl $ ./config --unified
Operating system: armv7l-whatever-linux2
Configuring for linux-armv4
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-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-zlib [default] 
no-zlib-dynamic [forced]  
Configuring for linux-armv4
IsMK1MF   =no
CC=gcc
CFLAG = -pthread -Wall -O3 -march=armv7-a -Wa,--noexecstack
DEFINES   =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS OPENSSL_BN_ASM_MONT 
OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM AES_ASM BSAES_ASM GHASH_ASM 
ECP_NISTZ256_ASM POLY1305_ASM
LFLAG =
PLIB_LFLAG=
EX_LIBS   =-ldl
CPUID_OBJ =armcap.o armv4cpuid.o
BN_ASM=bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM=ecp_nistz256.o ecp_nistz256-armv4.o
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4_enc.o rc4_skey.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
RMD160_OBJ_ASM=
CMLL_ENC  =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ =ghash-armv4.o ghashv8-armx.o
PADLOCK_OBJ   =
CHACHA_ENC=chacha-armv4.o
POLY1305_OBJ  =poly1305-armv4.o
PROCESSOR =
RANLIB=/usr/bin/ranlib
ARFLAGS   =
PERL  =/usr/bin/perl

THIRTY_TWO_BIT mode
BN_LLONG mode
 
Configured for linux-armv4.
pi@raspberrypi:/tmp/openssl $ make
CC="gcc" /usr/bin/perl crypto/aes/asm/aes-armv4.pl linux32 
crypto/aes/aes-armv4.S

@ 
@ Written by Andy Polyakov  for the OpenSSL
@ project. The module is, however, dual licensed under OpenSSL and
@ CRYPTOGAMS licenses depending on where you obtain it. For further
@ details see http://www.openssl.org/~appro/cryptogams/.
@ 

@ AES for ARMv4

@ January 2007.
@
@ Code uses single 1K S-box and is >2 times faster than code generated
@ by gcc-3.4.1. This is thanks to unique feature of ARMv4 ISA, which
@ allows to merge logical or arithmetic operation with shift or rotate
@ in one instruction and emit combined result every cycle. The module
@ is endian-neutral. The performance is ~42 cycles/byte for 128-bit
@ key [on single-issue Xscale PXA250 core].

@ May 2007.
@
@ AES_set_[en|de]crypt_key is added.

@ July 2010.
@
@ Rescheduling for dual-issue pipeline resulted in 12% improvement on
@ Cortex A8 core and ~25 cycles per byte processed with 128-bit key.

@ February 2011.
@
@ Profiler-assisted and platform-specific optimization resulted in 16%
@ improvement on Cortex A8 core and ~21.5 cycles per byte.

#ifndef __KERNEL__
# include "arm_arch.h"
#else
# define __ARM_ARCH__ __LINUX_ARM_ARCH__
#endif

.text
#if defined(__thumb2__) && !defined(__APPLE__)
.syntax unified
.thumb
#else
.code   32
#undef __thumb2__
#endif

.type   AES_Te,%object
.align  5
AES_Te:
.word   0xc66363a5, 0xf87c7c84, 0xee99, 0xf67b7b8d
.word   0xfff2f20d, 0xd66b6bbd, 0xde6f6fb1, 0x91c5c554
.word   0x60303050, 0x02010103, 0xce6767a9, 0x562b2b7d
.word   0xe7fefe19, 0xb5d7d762, 0x4dababe6, 0xec76769a
.word   0x8fcaca45, 0x1f82829d, 0x89c9c940, 0xfa7d7d87
.word   0xeffafa15, 0xb25959eb, 0x8e4747c9, 0xfbf0f00b
.word   0x41adadec, 0xb3d4d467, 0x5fa2a2fd, 0x45afafea
.word   0x239c9cbf, 0x53a4a4f7, 0xe4727296, 0x9bc0c05b
.word   0x75b7b7c2, 0xe1fdfd1c, 0x3d9393ae, 0x4c26266a
.word   0x6c36365a, 0x7e3f3f41, 0xf5f7f702, 0x834f
.word   0x6834345c, 0x51a5a5f4, 0xd1e5e534, 0xf9f1f108
.word   0xe2717193, 0xabd8d873, 0x62313153, 0x2a15153f
.word   0x0804040c, 0x95c7c752, 0x46232365, 0x9dc3c35e
.word   0x30181828, 

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

[Salz, Rich via RT]

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

[openssl-dev] Openssl SNAP 20160220 issues

[The Doctor]

Major shop stopper

../test/recipes/30-test_pbelu.t ...
1..1
./pbelutest: can't load library 'ssl.so.1.1'
not ok 1 - running pbelutest

#   Failed test 'running pbelutest'
#   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/40-test_rehash.t .. ../apps/openssl: can't load library 
'ssl.so.1.1'

1..0 # SKIP test_rehash is not available on this platform
skipped: test_rehash is not available on this platform
../test/recipes/70-test_clienthello.t .
1..1
./clienthellotest: can't load library 'ssl.so.1.1'
not ok 1 - running clienthellotest

#   Failed test 'running clienthellotest'
#   at ../test/recipes/70-test_clienthello.t line 13.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/70-test_packet.t ..
1..1
./packettest: can't load library 'ssl.so.1.1'
not ok 1 - running packettest

#   Failed test 'running packettest'
#   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/70-test_sslcertstatus.t ...
1..1
Proxy started on port 4453
../apps/openssl: can't load library 'ssl.so.1.1'
../apps/openssl: can't load library 'ssl.so.1.1'

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Broadcasting the truth for 25 years
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 20160220 repository

[The Doctor]

On Sat, Feb 20, 2016 at 01:57:53PM +0100, Richard Levitte wrote:
> Yes. Sorry about that, the disk space had filled out. It has been dealt with, 
> and the next snapshots will be whole. 
> 
> Cheers 
> Richard 
> 
> The Doctor  skrev: (20 februari 2016 13:38:59 CET)
> >Only Openssl 1.1 SNAP showed up.
> >
> >The other 2 choked off.
>

You haveto watch that disc space ;-)
 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Broadcasting the truth for 25 years
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 20160220 repository

[Richard Levitte]

Yes. Sorry about that, the disk space had filled out. It has been dealt with, 
and the next snapshots will be whole. 

Cheers 
Richard 

The Doctor  skrev: (20 februari 2016 13:38:59 CET)
>Only Openssl 1.1 SNAP showed up.
>
>The other 2 choked off.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] 20160220 repository

[The Doctor]

Only Openssl 1.1 SNAP showed up.

The other 2 choked off.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Broadcasting the truth for 25 years
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev