Re: Own HW Supported RSA provider

[Richard Levitte]

You can give your implementation the property "provider=myname" and for
fetching, you can use the conditional property query string
"?provider=myname".  That will ensure that, for whatever the app is
fetching, it will pick what your provider offers first, and fall back to
using stuff from any other provider (including the default provider).

"myname" can be anything you like

On Thu, Jul 18, 2024 at 3:25 PM tomasz bartczak  wrote:

> Hi,
> I want to implement my own provider that enables RSA encryption using a HW
> chip. OpenSSL already comes with default provider that provides RSA
> implementation. Could you please explain to me how to add my own provider
> and make sure it is selected over the one from default provider and still
> have access to other algorithms that come with the default provider.
> Thanks
> Tom
>

Re: Macro definitions

[Richard Levitte]

They are generated, using providers/common/der/oids_to_c.pm, and
template files like providers/common/der/der_ec_gen.c.in, where you can
see the .asn1 files that are used as sources.

Cheers,
Richard

Damodhar Boddukuri via openssl-users  writes:

> Hi OpenSSL,
>
>  
>
> I am compiling OpenSSL 3.1.3 for ARM A9. It’s unable get the following macro 
> definitions. They are used in
> der_ec_sig.c
>
>  
>
> ossl_der_oid_ecdsa_with_SHA1
>
> ossl_der_oid_ecdsa_with_SHA224
>
> ossl_der_oid_ecdsa_with_SHA256
>
> ossl_der_oid_ecdsa_with_SHA384
>
> ossl_der_oid_ecdsa_with_SHA512
>
> ossl_der_oid_id_ecdsa_with_sha3_224
>
> ossl_der_oid_id_ecdsa_with_sha3_256
>
> ossl_der_oid_id_ecdsa_with_sha3_384
>
> ossl_der_oid_id_ecdsa_with_sha3_512
>
>  
>
> +++ Compiling
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c
>
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:
> In function 'ossl_DER_w_algorithmIdentifier_ECDSA_with_MD':
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
> error: 'ossl_der_oid_ecdsa_with_SHA1' undeclared (first use in this function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
> error: (Each undeclared identifier is reported only once
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
> error: for each function it appears in.)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:35:
> error: 'ossl_der_oid_ecdsa_with_SHA224' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:36:
> error: 'ossl_der_oid_ecdsa_with_SHA256' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:37:
> error: 'ossl_der_oid_ecdsa_with_SHA384' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:38:
> error: 'ossl_der_oid_ecdsa_with_SHA512' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:39:
> error: 'ossl_der_oid_id_ecdsa_with_sha3_224' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:40:
> error: 'ossl_der_oid_id_ecdsa_with_sha3_256' undeclared (first use in this 
> function)
>
> declared (first use in this function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:41:
> error: 'ossl_der_oid_id_ecdsa_with_sha3_384' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:42:
> error: 'ossl_der_oid_id_ecdsa_with_sha3_512' undeclared (first use in this 
> function)
>
>  
>
>  
>
> Thanks & Regards,
>
> Damodhar.
>
> +91-7702191212
>
>  
>
> General
>

-- 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 20240619 snapshots

[Richard Levitte]

The Doctor via openssl-users  writes:

> On Wed, Jun 19, 2024 at 09:53:19AM +0200, Tomas Mraz wrote:
>> They are there. Maybe you've looked too soon before the CDN caches were
>> synchronized.
>> 
>> 
>> On Tue, 2024-06-18 at 21:12 -0600, The Doctor via openssl-users wrote:
>> > Where are they?
>> 
>> -- 
>> Tom Mr??z, OpenSSL
>> 
>
> I use lynx

That's absolutely fine and makes no difference.  The snapshots got in
place, but probably became visible after you looked.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Snapshots

[Richard Levitte]

I believe you mean 2022-10-29.

Correct, our automation machinery went belly up during the 29th,
alongside our web server.  It's up and running now.

Cheers,
Richard

On Mon, 31 Oct 2022 12:17:49 +0100,
The Doctor via openssl-users wrote:
> 
> No snapshots since 2022-10-19.
> 
> -- 
> Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca
> Yahweh, King & country!Never Satan President Republic!Beware AntiChrist 
> rising!
> Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
> How can one be prejudiced and remain objective? -unknown Beware 
> https://mindspring.com
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: webpages not available

[Richard Levitte]

Thanks for the notification, it seems our web server went belly up
over the weekend.  We'll investigate.

Cheers,
Richard

On Sun, 30 Oct 2022 19:41:02 +0100,
James Muir wrote:
> 
> https://www.openssl.org/docs/manmaster/man7/provider.html  ("service
> unavailable")
> https://wiki.openssl.org/index.php/OpenSSL_3.0  ("unable to connect")
> 
> The urls above do not seem to work.  Is this a consequence with the
> recent release withdrawal?
> 
> The main web page, www.openssl.org, seems to work as normal.
> 
> -James M
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenSSL 1.1.1 Windows dependencies

[Richard Levitte]

Hi David,

I just did a check to see what Windows libraries the openssl.exe app
depends on, going back to look in 1.0.2, and looking at the current
development branch (master).

1.0.2:

  ws2_32.lib(cond: no-sock)
  gdi32.lib advapi32.lib crypt32.lib user32.lib
  bufferoverflowu.lib   (cond: cl version 14+)
  unicows.lib   (cond: win32 && -DUNICODE)

master:

  ws2_32.lib(cond: no-sock)
  gdi32.lib advapi32.lib crypt32.lib user32.lib
  bufferoverflowu.lib   (cond: cl version 14+)

As you can see, it hasn't changed much (the unicows.lib dependency was
there for Win9x compatibility, according to comments).

But, it's quite possible that those libraries have dependencies of
their own that have changed in newer Windows versions.

Let me ask you this: on what Windows version was your application
built?  Common wisdom would be to build on the oldest version...

Cheers,
Richard

On Thu, 20 Oct 2022 02:54:19 +0200,
David Harris wrote:
> 
> Up front, I'd like to apologize if this is an FAQ or has been answered 
> elsewhere 
> on this list: my workload means that I simply can't keep as up-to-date as I 
> would 
> like.
> 
> I have a situation where my application fails to accept an incoming SSL 
> handshake on Windows Server 2012, but the identical software running on 
> Server 2019 accepts the same connection from the same remote client without 
> a problem. Other types of client software (such as Thunderbird) connect to 
> either system without any problems. The connecting client is a Windows Cash 
> Register using Window's built-in crypto facilities. If I downgrade my app to 
> OpenSSL 1.1.1g or earlier, the problem doesn't happen. With 1.1.1k or 1.1.1q, 
> I 
> get the error (I haven't built any versions of OpenSSL between k and q). In 
> case 
> it helps, the connection is an incoming SMTP connection on port 587, and 
> STARTTLS is used to begin SSL negotiation.
> 
> SSL_accept returns -1, with an extended error of "SSL_ERROR_SYSCALL" (5), 
> which I understand to be largely what it returns when it doesn't have a clear 
> idea 
> of what's gone wrong. The error queue is completely empty in this situation. 
> The 
> cert is a LetsEncrypt cert that loads without errors and works fine with 
> other 
> clients.
> 
> Do recent versions of OpenSSL 1.1.1 have dependencies on some Windows 
> facility (winsock and wincrypt seem likely candidates) that might work on 
> Server 
> 2019 but fail on Server 2012?
> 
> The version of my application that is in public release uses 1.1.1g, so isn't 
> affected by this issue, but I'm slightly worried that I'm going to see an 
> uptick in 
> this type of problem if I release builds based on later versions of 1.1.1.
> 
> Does this ring any bells with anyone? Again, apologies if this is answered 
> elsewhere - I *did* spend some time in Google but couldn't find anything that 
> seemed relevant.
> 
> Thanks in advance for any advice.
> 
> Cheers!
> 
> -- David --
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: I am experimenting

[Richard Levitte]

You're trying to run directly in your build tree, and haven't told the
system that /home/bullseye/test0818/openssl/3.1.0/plain/openssl-master
is a viable directory to find your newly built shared libraries in.

Fortunately, OpenSSL has a script that can be used for such cases,
util/wrap.pl.  It takes the command you want to run as arguments, sets
the appropriate environment variables for your system, then runs the
command you gave.

Example run for your example:

$ /home/bullseye/test0818/openssl/3.1.0/plain/openssl-master/util/wrap.pl \
  /home/bullseye/test0818/openssl/3.1.0/plain/openssl-master/apps/openssl 
version

Behind the scenes, on most Unix systems, the variable LD_LIBRARY_PATH
is set to the directory where the libraries are expected to be found.
You could do this manually if you want, like this:

$ LD_LIBRARY_PATH=/home/bullseye/test0818/openssl/3.1.0/plain/openssl-master
$ export LD_LIBRARY_PATH
$ /home/bullseye/test0818/openssl/3.1.0/plain/openssl-master/apps/openssl 
version

Do note, though, that setting an environment variable is permanent for
your logged in session, so it affects all commands following it, until
you change that variable again, or log out.  With util/wrap.pl, it's
only being set temporarly, just for the command to be run.

Disclaimer: util/wrap.pl is fairly new, and isn't supported out of the
build folder it's used in.  It's also not claimed to be stable across
OpenSSL versions, even though it has shown to be stable for some time
now.  That is to say, it may change in the future...  or not.

Happy experimenting!

Cheers,
Richard

On Sat, 20 Aug 2022 08:17:56 +0200,
b1...@b1bb2.com wrote:
> 
> To: openssl-users@openssl.org
> I am experimenting with
> https://github.com/openssl/openssl/archive/refs/heads/master.zip
> openssl 3.1.0 Source Distribution archive, I built it into a local
> virtual machine environment (folder). System is debian 11.3
> (Bullseye), Local Personal Computer.
> 
> This code works:
> ls
> /home/bullseye/test0818/openssl/3.1.0/plain/openssl-master/libssl.so.3
> ls
> /home/bullseye/test0818/openssl/3.1.0/plain/openssl-master/apps/openssl
> 
> This code gives error:
> /home/bullseye/test0818/openssl/3.1.0/plain/openssl-master/apps/openssl
> version
> error while loading shared libraries: libssl.so.3: cannot open shared
> object file: No such file or directory
> 
> I am trying to learn (or more precisley just trying to get it working
> without errors) so please excuse my ignorance that may be apparent in
> this paragraph. My research on internet shows that error is common and
> is caused by diffrent systems having diffrent libraries or paths to
> library. So a solution is to define the correct library and correct
> path to it. But this is suposed to be a local virtual machine
> environment, Can I put the correct library into the local virtual
> machine (folder) so the software will not search for it throughout the
> global system? Or is there a general (all system) fix for this?
> Another problem is Python 3.10.6 requires a OpenSSL 1.1.1 or
> newer. Can I link my Python virtual machine to the openssl virtual
> machine? Your comments are appreciated.
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Question about OpenSSL 3.0 and static linking

[Richard Levitte]

'no-module' will do what you want.  I noticed, though, that the
documentation in INSTALL.md isn't entirely clear on what that does.

./config --prefix=$HOME/local/openssl-3.0.1 no-shared no-module

Cheers,
Richard

On Tue, 22 Feb 2022 07:37:03 +0100,
Shunichi Shinohara wrote:
> 
> Hi List,
> 
> I have a question about OpenSSL 3.0 and static linking.
> 
> Short version: Is it possible to include the legacy provider in libcrypt.a?
> 
> Somewhat long version below.
> As a background of the question I'm using OpenSSL with Erlang/OTP [1] on Linux
> and want to static link OpenSSL library.  With OpenSSL 1.1.1, it works nice,
> but I couldn't make it work well with OpenSSL 3.0.1.
> 
> Build steps:
> 
>  curl -LO https://www.openssl.org/source/openssl-3.0.1.tar.gz
>  tar xvfz openssl-3.0.1.tar.gz
>  cd openssl-3.0.1
>  ./config --prefix=$HOME/local/openssl-3.0.1 no-shared
>  make -j && make install_sw
> 
> After Building Erlang/OTP with it and moving $HOME/local/openssl-3.0.1/lib64 
> to
> $HOME/tmp, my (Erlang) code fails at OSSL_PROVIDER_load(NULL, "legacy"):
> https://github.com/erlang/otp/blob/OTP-25.0-rc1/lib/crypto/c_src/crypto.c#L224
> 
> What I found are:
> - there are two library files under $HOME/local/openssl-3.0.1/lib64, 
> libcrypt.a
>   and ossl-modules/legacy.so, and
> - if I pass the environment variable OPENSSL_MODULES=$HOME/tmp in
> launching Erlang,
>   all work well.
>   
> https://github.com/openssl/openssl/blob/b19fcc66d382357617744690dc3363947de2cb6f/doc/man3/OSSL_PROVIDER.pod
> 
> So, copying legacy.so and adding an environment variable can be an option.
> Before going with the option, I want to confirm whether including legacy in
> libcrypt.a in possible or not.
> 
> [1] https://www.erlang.org/
> 
> Thanks in advance!
> Shino
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 3.0.0. IMPLEMENT_ASN1_FUNCTIONS missing _it prototypes

[Richard Levitte]

Not sure why it's 3.0.0 only...  however, this looks like the usual
"you define, so you must declare it first".  There are a number of
declaration macros for our ASN.1 templates, in this case, I believe
that this is what you're looking for:

DECLARE_ASN1_ITEM(TPM_PARTIAL_CERT_VALIDITY)

Cheers,
Richard

On Mon, 23 Aug 2021 21:42:00 +0200,
Ken Goldman wrote:
> 
> I get warnings on all my ASN1_SEQUENCE_END, a missing prototype for the _it 
> functions.
> The code is working, but I'd like a clean compile.
> 
> 3.0.0 only, 1.0.2 and 1.1.1 are OK.
> 
> Example:
> 
> #include 
> #include 
> #include 
> #include 
> 
> typedef struct {
> ASN1_TIME *notBefore;
> ASN1_TIME *notAfter;
> } TPM_PARTIAL_CERT_VALIDITY;
> 
> ASN1_SEQUENCE(TPM_PARTIAL_CERT_VALIDITY) = {
> ASN1_SIMPLE(TPM_PARTIAL_CERT_VALIDITY, notBefore, ASN1_TIME),
> ASN1_SIMPLE(TPM_PARTIAL_CERT_VALIDITY, notAfter, ASN1_TIME),
> } ASN1_SEQUENCE_END(TPM_PARTIAL_CERT_VALIDITY)<<<< line 97 is here
> 
> certifyx509.c:97: warning: no previous prototype for 
> 'TPM_PARTIAL_CERT_VALIDITY_it'
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Misunderstanding openssl verify

[Richard Levitte]

On Mon, 16 Aug 2021 16:30:05 +0200,
Ken Goldman wrote:
> 
> On 8/16/2021 10:04 AM, Viktor Dukhovni wrote:
> >> It seems as though the 'verify' command checks the issuer,
> >> but not the signature of the certificate - the last parameter.
> >
> > As documented.
> 
> Then I am not understanding the documentation.
> 
> https://www.openssl.org/docs/man1.1.1/man1/verify.html
> 
> says
> 
> "The final operation is to check the validity of the certificate chain.
> ...
>  The certificate signature is checked as well "
> 
> However. my experience is that the certificate signature is not
> checked.  I can hand modify the validity, public key, or
> signature, but the command still returns "OK".

The documentation on '-check_ss_sig' finishes with this:

"... This verification is disabled by default because it doesn't add
any security."

I'm sure this can be debated, but that's at least an explanation.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: CNG engine on GitHub

[Richard Levitte]

This is cool!

I had some kind of skeleton of a start to make something similar, but
time was never on my side.  I'm really glad to see this got picked up!

This also answered a question I never got the answer for, what scheme
to use for the STORE.  I know next to nothing about PowerShell, so
hadn't discovered the 'cert:' "scheme".  That answers quite a lot :-)

Time for me to throw away my skeleton then ;-)

Cheers,
Richard

On Thu, 01 Jul 2021 19:49:00 +0200,
Reinier Torenbeek wrote:
> 
> Hi,
> 
> For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you may 
> want to check out this
> new OpenSSL CNG Engine project on GitHub: 
> https://github.com/rticommunity/openssl-cng-engine . The
> associated User's Manual is on ReadTheDocs: 
> https://openssl-cng-engine.readthedocs.io/en/latest/index.html .
> 
> The project implements the majority of the EVP interface, to leverage the 
> BCrypt crypto
> implementations, as well as a subset of the STORE interface, for integration 
> with the
> Windows Certificate and Keystore(s), via the NCrypt and Cert APIs. It has 
> been tested with 1.1.1k
> on Windows 10, with Visual Studio 2017 and 2019. It is released under the 
> Apache-2.0 license.
> 
> Any feedback is welcome, please send it to me or open an issue on GitHub.
> 
> Best regards,
> Reinier
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: GNU Make erroring on makefile

[Richard Levitte]

How did you configure, and on what platform?

On Thu, 01 Jul 2021 15:22:46 +0200,
Joe Carroll wrote:
> 
> Has anyone successfully used GNU Make as part of the install process for 
> version 1.1.1k or later? 
> I’m getting a “missing separator” error on line 56.  I do not have access to 
> nmake.exe.
>  
> !IF "$(DESTDIR)" != ""
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

email notice [was: Not getting some macros for FIPS]

[Richard Levitte]

On Wed, 23 Jun 2021 10:51:05 +0200,
Tomas Mraz wrote:
> 
> On Wed, 2021-06-23 at 08:12 +, Kumar Mishra, Sanjeev wrote:
> 
> > Notice: This e-mail together with any attachments may contain
> > information of Ribbon Communications Inc. and its Affiliates that is
> > confidential and/or proprietary for the sole use of the intended
> > recipient. Any review, disclosure, reliance or distribution by others
> > or forwarding without express permission is strictly prohibited. If
> > you are not the intended recipient, please notify the sender
> > immediately and then delete all copies, including any attachments.
> 
> It's a little bit strange to send e-mails with such notices to public
> mailing lists where the intented recipient is _anyone_.

Those notices are a bit amusing, yeah.  Of course, Sanjeev can't be
blamed for this, as we can probably assume that it's a corporate
filter that automagically adds those.

And oh boy!  openssl-users having almost 3000 subscribers, that's
quite a lot of people to chase down and ensure they have destroyed all
copies, I tell ya!  "Good luck" is probably an appropriate response
;-)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 3.0 beta1 feedback about (shared) library names

[Richard Levitte]

On Tue, 22 Jun 2021 21:58:30 +0200,
Michael Richardson wrote:
> 
> Richard Levitte  wrote:
> >> But, having both "libssl-dev" and "libssl3-dev" installed at the same
> >> time is going to be a problem.
> 
> > Not really.  Programs that are built against OpenSSL's libraries will
> > use the files from libssl-dev, and programs that are built against
> > Mozilla's NSS libraries will use the files from libssl3-dev.
> 
> If both can be installed at the same time, great.

As far as I can tell, the Mozilla NSS Debian packages and the OpenSSL
Debian packages do not trample on each other, so they can be installed
at the same time.  Debian is generally pretty good at ensuring this.

> > It's not at all pragmatic, let alone not at all cool, seeing that
> > libssl3 isn't ours.  I hope you understand this at this point.
> 
> a) I think that Mozilla/Debian should plan to rename libssl3.so.
>Obviously, that name comes from the era of "SSL 3.0" vs "TLS1.3".

I'm actually more ready to assume that the '3' is due to NSS being at
version 3.x as well.  They ship other libraries as well, with that
same number:

grep '\.so' /var/lib/dpkg/info/libnss3\:amd64.list 
/usr/lib/x86_64-linux-gnu/libnss3.so
/usr/lib/x86_64-linux-gnu/libnssutil3.so
/usr/lib/x86_64-linux-gnu/libsmime3.so
/usr/lib/x86_64-linux-gnu/libssl3.so
/usr/lib/x86_64-linux-gnu/nss/libfreebl3.so
/usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.so
/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
/usr/lib/x86_64-linux-gnu/nss/libnssdbm3.so
/usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so

However, if you want Debian to change how they package libnss, then
you should talk with them.  I would be surprised if they did, though,
because that would mean that libnss libraries would be named
differently on different platforms, and that's quite a can of worms.

> b) what I meant was uncool was that the next version of "libssl.so.1"
>would be "libssl3.so.3" rather than "libssl.so.3"
>Actually, at that point, you could consider "libopenssl.so.3".

Our library isn't named in a way that you deem uncool, so I guess
we're fine ;-)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 3.0 beta1 feedback about (shared) library names

[Richard Levitte]

On Tue, 22 Jun 2021 04:23:06 +0200,
Michael Richardson wrote:
> 
> WTF is libssl3.so?  I still don't know, but:
> 
> %dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
> libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
> something up there that should be concerning, because maybe it will cause 
> confusion.

Here's how to take a closer look at Debian packages:

$ apt show libnss3
Package: libnss3
Version: 2:3.67-1
Priority: optional
Section: libs
Source: nss
Maintainer: Maintainers of Mozilla-related packages 

Installed-Size: 4,173 kB
Depends: libc6 (>= 2.14), libnspr4 (>= 2:4.12), libsqlite3-0 (>= 3.5.9)
Conflicts: libnss3-1d (<< 2:3.13.4-2)
Homepage: http://www.mozilla.org/projects/security/pki/nss/
Tag: role::shared-lib
Download-Size: 1,316 kB
APT-Manual-Installed: no
APT-Sources: http://ftp.se.debian.org/debian unstable/main amd64 Packages
Description: Network Security Service libraries
 This is a set of libraries designed to support cross-platform development
 of security-enabled client and server applications. It can support SSLv2
 and  v4, TLS, PKCS #5, #7, #11, #12, S/MIME, X.509 v3 certificates and
 other security standards.

As you can see, libnss3 packages Mozilla's NSS project, not OpenSSL.

I just had a look at the source of that package, and it makes it clear
that libnss3.so is actually the NSS project's own name for their SSL
library, so this isn't even a packaging problem.

> But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
> going to be a problem.

Not really.  Programs that are built against OpenSSL's libraries will
use the files from libssl-dev, and programs that are built against
Mozilla's NSS libraries will use the files from libssl3-dev.

Yes, I agree that it's unfortunate that the library names are so
similar, because confusion.  I understand that.

> I think that the differences in ABI may be significant enough that you should
> consider calling it "libssl3" and "libcrypto3".  Yeah, maybe that's uncool,
> but it may be pragmatic.

It's not at all pragmatic, let alone not at all cool, seeing that
libssl3 isn't ours.  I hope you understand this at this point.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Macro to support 3.0 and 1.0

[Richard Levitte]

Before using OPENSSL_VERSION_NUMBER, you should have this line:

#include 

So something like this should make it possible:

#include 

#if (OPENSSL_VERSION_NUMBER >= 0x3000L)

  /**higher version code/

 #include 

#else

  /***lower version code */

 #include 

#endif

If that's not the case, you may have found a bug.  A short example
program that demonstrates this flaw would be nice in that case.

Cheers,
Richard

On Thu, 06 May 2021 12:38:30 +0200,
Shivakumar Poojari wrote:
> 
> 
> Hi All,
> 
>  We are upgrading our code to openssl 3.0. But we need to keep the 
> older
>  version of code also which is 1.0. So, we tried by keeping the newer 
> version 
>  of the code as below but when we compiled the code for 3.0, evp.h is 
> not
>  getting included. Please suggest f our approach is correct
> 
> #if (OPENSSL_VERSION_NUMBER >= 0x3000L)
> 
>   /**higher version code/
> 
>  #include 
> 
> #else
> 
>   /***lower version code */
> 
>  #include 
> 
> #endif
> 
>Also, we found that OPENSSL_VERSION_NUMBER is deprecated, so thought 
> of using
>the below macros but we think since this macro is defined in newer 
> version this might
>not work when we compile it for older versions. Please suggest how to 
> handle this.
> 
> if (OPENSSL_VERSION_MAJOR >= 3)
>   #include 
> else if (OPENSSL_VERSION_MAJOR < 3)
>   #include 
> 
> thanks, 
> shiva kumar 
> 
> Notice: This e-mail together with any attachments may contain information of 
> Ribbon Communications
> Inc. and its Affiliates that is confidential and/or proprietary for the sole 
> use of the intended
> recipient. Any review, disclosure, reliance or distribution by others or 
> forwarding without
> express permission is strictly prohibited. If you are not the intended 
> recipient, please notify
> the sender immediately and then delete all copies, including any attachments.
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: PEM_read_bio_RSAPublicKey equivalent API which returns EVP_PKEY

[Richard Levitte]

On Mon, 12 Apr 2021 06:24:32 +0200,
Paramashivaiah, Sunil wrote:
> 
> But, I couldn't find equivallent API to replace "PEM_read_bio_RSAPublicKey" 
> to get EVP_PKEY for 
> creating EVP ctx(EVP_PKEY_CTX_new) to use in "EVP_PKEY_encrypt" and 
> "EVP_PKEY_decrypt".

I believe that one of these functions would help you:

EVP_PKEY_CTX *EVP_PKEY_CTX_new(EVP_PKEY *pkey, ENGINE *e);

EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_pkey(OSSL_LIB_CTX *libctx,
 EVP_PKEY *pkey, const char *propquery);

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenSSL 3.0 daily snapshot

[Richard Levitte]

Hmmm, I have never seen that (apart from in one of my own development branches, 
but that never reached the main source).

If you want anyone to look into it, it would be a good idea to show us what 
your configuration is. The output from this command is recommended:

perl configdata.pm -d

Cheers
Richard


The Doctor  skrev: (14 februari 2021 13:33:51 CET)
>Anyome running tests running into an infinite loop 
>on 04-test_encoder_decoder_legacy.t ?

-- 
Richard by mobile

Re: Encoding of AlgorithmIdentifier with NULL parameters

[Richard Levitte]

This was a good find, thank you all.

It's clearly a bug.  Fix on GitHub, in PR #14030
(https://github.com/openssl/openssl/pull/14030)

Cheers,
Richard

On Thu, 28 Jan 2021 21:04:17 +0100,
Russ Housley wrote:
> 
> [1  ]
> [2  ]
> RFC 4055 says:
> 
>The object identifier used to identify the PKCS #1 version 1.5
>signature algorithm with SHA-224 is:
> 
>   sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }
> 
>The object identifier used to identify the PKCS #1 version 1.5
>signature algorithm with SHA-256 is:
> 
>   sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 }
> 
>The object identifier used to identify the PKCS #1 version 1.5
>signature algorithm with SHA-384 is:
> 
>   sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 }
> 
>The object identifier used to identify the PKCS #1 version 1.5
>signature algorithm with SHA-512 is:
> 
>   sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 }
> 
>When any of these four object identifiers appears within an
>AlgorithmIdentifier, the parameters MUST be NULL.  Implementations
>MUST accept the parameters being absent as well as present.
> 
> So, when generating the certificate, the NULL ought to be there.
> 
> Also, when validating, the code should be forgiving about it not being there.
> 
> Russ
> 
> On Jan 28, 2021, at 2:07 PM, Thulasi Goriparthi 
>  wrote:
>
> I am trying to provide a test certificate generated by 
> openssl-3.0.0-alpha10 to a third party
> certificate parser/manager. This software expects AlgorithmIdentifier to 
> either have
> parameters or to have null encoded (05 00) parameters which seems to be 
> missing in the
> certificate.
>
> Certificate generated by openssl-3.0.0-alpha10
>
> 0:d=0  hl=4 l=1030 cons: SEQUENCE  
> 4:d=1  hl=4 l= 752 cons: SEQUENCE  
> 8:d=2  hl=2 l=   3 cons: cont [ 0 ]
>10:d=3  hl=2 l=   1 prim: INTEGER   :02
>13:d=2  hl=2 l=   1 prim: INTEGER   :01
>16:d=2  hl=2 l=  11 cons: SEQUENCE  
>18:d=3  hl=2 l=   9 prim: OBJECT:sha256WithRSAEncryption
>29:d=2  hl=3 l= 143 cons: SEQUENCE  
>32:d=3  hl=2 l=  11 cons: SET   
>34:d=4  hl=2 l=   9 cons: SEQUENCE  
>36:d=5  hl=2 l=   3 prim: OBJECT:countryName
>
> Certificate generated by openssl-1.1.1g
>
> 0:d=0  hl=4 l= 988 cons: SEQUENCE  
> 4:d=1  hl=4 l= 708 cons: SEQUENCE  
> 8:d=2  hl=2 l=   3 cons: cont [ 0 ]
>10:d=3  hl=2 l=   1 prim: INTEGER   :02
>13:d=2  hl=2 l=   1 prim: INTEGER   :01
>16:d=2  hl=2 l=  13 cons: SEQUENCE  
>18:d=3  hl=2 l=   9 prim: OBJECT:sha256WithRSAEncryption
>29:d=3  hl=2 l=   0 prim: NULL  
>31:d=2  hl=3 l= 143 cons: SEQUENCE  
>34:d=3  hl=2 l=  11 cons: SET   
>36:d=4  hl=2 l=   9 cons: SEQUENCE  
>38:d=5  hl=2 l=   3 prim: OBJECT:countryName
>
> From https://tools.ietf.org/html/rfc5280#section-4.1.1.2, It isn't clear 
> if NULL parameters
> can be completely omitted or if it should still have NULL encoding.
>
> Is this a too stringent check in the third-party s/w or a miss in 
> openss-3.0.0-alpha10?
>
> Thanks,
> Thulasi.
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OPenssl 3.0 issues

[Richard Levitte]

That should be fixed, I merged a fixup commit yesterday.

Cheers,
Richard

On Mon, 25 Jan 2021 15:56:28 +0100,
The Doctor wrote:
> 
> Anyone using BSD running into basename issues?
> 
> -- 
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> doctor@@nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist 
> rising!
> Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
>  
> Born 29 Jan 1969 Redhill, Surrey, UK 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: RSA-OAEP Certificate

[Richard Levitte]

On Wed, 20 Jan 2021 02:24:24 +0100,
Viktor Dukhovni wrote:
> 
> On Tue, Jan 19, 2021 at 06:26:23PM -0500, Russ Housley wrote:
> 
> > I am looking a test certificate that contains an RSA-OAEP subject
> > public key (OID = id-RSAES-OAEP from RFC 4055) and is signed with
> > RSA-PSS (OID = id-RSASSA-PSS also from RFC 4055).  I have not ben able
> > to find a way to generate such a certificate with OpenSSL.  If you
> > have a pointer to such a certificate or a recipe for generating one, I
> > would appreciate the pointer.
> 
> While RSA-PSS keys are supported by genpkey(1), I don't see any support
> for generating RSAES-OAEP keys in any of the command-line utilities.
> 
> It does not look like RSAES-OAEP SPKI are supported even at the API
> level.  Perhaps I did not look hard enough...

You are entirely correct.  I was surprised when I discovered this, but
there you go.  I suppose that the early implementation was "on demand", 
i.e. RSA-PSS keys were seen out in the wild, prompting us ("someone")
to add support for them.  RSA-OAEP keys haven't had the same demand,
so no one implemented support for them as such.

We do have support for RSA-OAEP, but only on an operational level,
i.e. encryption and decryption with a "normal" RSA key and additional
OAEP parameters for the operation.  On a command level, it means that
it's possible to have OAEP padding mode with 'openssl pkeyutl'.

A few of us in the team are keenly aware of the lack of RSA-OAEP key
support, and we have discussed internally whether we should add that
with OpenSSL 3.0...  I don't quite recall if we came to an actual "yay
or nay" decision, it's just not been a top priority item.  That being
said, I can't see that any of us will protest if someone chooses to
chip in and add such support, at least in our providers [*]

-
[*] in other words, PR welcome...  I believe that the RSA-PSS work
can be a good enough template that RSA-OAEP key support doesn't
have to be too hard to do.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Testing

[Richard Levitte]

For a rogue test message?

However, a quick search through the mail log shows that indeed, there
are messages coming from random Amazon AWS hosts that are...  "interesting"
I smirk a bit when I see this in our mail logs:

Sep  2 10:36:06 mta postfix/smtpd[1091]: warning: non-SMTP command from 
ec2-184-72-79-140.compute-1.amazonaws.com[184.72.79.140]: GET / HTTP/1.1

As for blocking, we rely quite a bit on available spam-hauses, such as
zen.spamhaus.org, and they do catch the occasional individual Amazon
AWS machine (seen in our logs), so it seems that they do get reports
on misbehaving machinery.

Apart from hightened emotions (I understand them, believe you me), are
there tangible reasons for applying the kind of arbitrary
sledge-hammer that you propose?
I would rather not, unless I really must.

Cheers,
Richard

On Mon, 31 Aug 2020 16:28:53 +0200,
Marc Roos wrote:
> 
> 
> Why don't you block the whole compute cloud of amazon?
> ec2-3-21-30-127.us-east-2.compute.amazonaws.com
> 
> 
> -Original Message-
> 
> To: openssl-users@openssl.org
> Subject: Testing
> 
> 
> 
> --
> -BEGIN EMAIL SIGNATURE-
> 
> The Gospel for all Targeted Individuals (TIs):
> 
> [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. 
> Embassy Workers
> 
> Link: 
> https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html
> 
> 
> 
> 
> Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic 
> Qualifications as at 14 Feb 2019 and refugee seeking attempts at the 
> United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug
> 2019) and Australia (25 Dec 2019 to 9 Jan 2020):
> 
> [1] https://tdtemcerts.wordpress.com/
> 
> [2] https://tdtemcerts.blogspot.sg/
> 
> [3] https://www.scribd.com/user/270125049/Teo-En-Ming
> 
> -END EMAIL SIGNATURE-
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: error : unknown type name 'sa_family_t' in openssl 1.1.1g

[Richard Levitte]

It would be helpful if you showed us the Configure options, as they
may very well have affected diverse macros.

Cheers,
Richard

On Thu, 23 Jul 2020 21:39:45 +0200,
prudvi raj wrote:
> Hi,
> 
> We are upgrading our code base to openssl 1.1.1g from 1.0.2k. 
> During Compilation i am seeing this error :
> In file included from /openssl/include/internal/sockets.h:67:0,
>  from /openssl/crypto/bio/bio_local.h:11,
>  from /openssl/crypto/bio/bss_mem.c:12:
> /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:469:7:
>  error:
> unknown type name 'sa_family_t'
> /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:497:8:
>  error:
> unknown type name 'sa_family_t'
> /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:519:10:
>  error:
> unknown type name 'sa_family_t'
> /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:543:4:
>  error:
> unknown type name 'sa_family_t'
> /opt/toolchains/adtn-6/sysroots/ppce500v2-fsl-linux-gnuspe/usr/include/netdb.h:562:41:
>  error:
> unknown type name 'sa_family_t'
> 
> In bio_local.h , if we remove "#include"  & replace it 
> with  "#include socket.h>" , the error is gone !! .  But I am not sure is this correct ??
> Btw , even  "internal/sockets.h " has " #include".
> 
> How to resolve this , Might I have missed something during configure & 
> compilation   ??
> fwiw: have given "./configure  gcc"  & same was given when we had 
> upgraded to 1.0.2 from
> previous versions long ago.
> 
> Thanks,
> Prud.
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Generate opensslconf.h - openssl 1.0.2 vs openssl 1.1.1g

[Richard Levitte]

On Thu, 16 Jul 2020 22:01:51 +0200,
prudvi raj wrote:
> How do i  generate "opensslconf.h" in openssl 1.1.1g?
> From docs, i assume it is created after we give  "./Configure  gcc".
> I observe that "opensslconf.h" is created only on giving "make" after 
> ./Configure... But this
> additionally created .d & .o files in crypto folders.

Yes, generation of most such files have moved to the building phase
rather than the configuration phase, so to say.

The really quick way to get an individual file of this sort is to
simply make it, i.e.:

make include/openssl/opensslconf.h

> For openssl1.0.2 , the same opensslconf.h is created right after 
> "./Configure" .
> (all .h files in include directory are created after ./Configure, whereas in 
> 1.1.1 .h files appear
> in include directory - without any ./Configure)

Yeah, before 1.1.0, the public header files were spread around in
diverse crypto/ subdirectories, and they got symlinked into
include/openssl, or copied, on platforms that don't support symbolic
links.  We moved them permanently to include/openssl in 1.1.0, which
means the symlinking is no longer needed.

> For context , we are upgrading our project to openssl 1.1.1g from 1.0.2k & i 
> am concerned about
> this .d & .o files, in case i build the whole project - which is including 
> openssl folder.

I don't quite understand why .o files are a concern, they are the
normal object files that are used to build up libraries and
applications, and are produced in OpenSSL before 1.1.0 as well.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenSSL version 3.0.0-alpha5 published

[Richard Levitte]

I have it uploaded to pgp.mit.edu.  It should replicate from there, I
at least also found it on keys.gnupg.net.

Cheers,
Richard

On Thu, 16 Jul 2020 16:03:37 +0200,
Bruce Cloutier wrote:
> 
> Where can I get the PGP key for the signature for this message? Seems
> not to have been uploaded to the key servers defined in my Enigmail.
> 
> 
> On 7/16/20 9:48 AM, OpenSSL wrote:
> >
> >    OpenSSL version 3.0 alpha 5 released
> >    
> >
> >    OpenSSL - The Open Source toolkit for SSL/TLS
> >    https://www.openssl.org/
> >
> >    OpenSSL 3.0 is currently in alpha.
> >
> >    OpenSSL 3.0 alpha 5 has now been made available.
> >
> >    Note: This OpenSSL pre-release has been provided for testing ONLY.
> >    It should NOT be used for security critical purposes.
> >
> >    Specific notes on upgrading to OpenSSL 3.0 from previous versions,
> > as well
> >    as known issues are available on the OpenSSL Wiki, here:
> >
> >     https://wiki.openssl.org/index.php/OpenSSL_3.0
> >
> >    The alpha release is available for download via HTTPS and FTP from the
> >    following master locations (you can find the various FTP mirrors under
> >    https://www.openssl.org/source/mirror.html):
> >
> >  * https://www.openssl.org/source/
> >  * ftp://ftp.openssl.org/source/
> >
> >    The distribution file name is:
> >
> >     o openssl-3.0.0-alpha5.tar.gz
> >   Size: 13919931
> >   SHA1 checksum:  0e2aded2b2bd2104bcee6bfcd10132a8aec87776
> >   SHA256 checksum: 
> > 09ad89af04cbf36dbbce1fc7063e18fcc333fcaaf3eccecf22c4a99bac83e139
> >
> >    The checksums were calculated using the following commands:
> >
> >     openssl sha1 openssl-3.0.0-alpha5.tar.gz
> >     openssl sha256 openssl-3.0.0-alpha5.tar.gz
> >
> >    Please download and check this alpha release as soon as possible.
> >    To report a bug, open an issue on GitHub:
> >
> >     https://github.com/openssl/openssl/issues
> >
> >    Please check the release notes and mailing lists to avoid duplicate
> >    reports of known issues. (Of course, the source is also available
> >    on GitHub.)
> >
> >    Yours,
> >
> >    The OpenSSL Project Team.
> >
> >
> >
> -- 
> Sent using Thunderbird on Ubuntu 16.04LTS
> 
> 
> No public key for C5E3F0631FEDE337 created at 2020-07-16T16:03:37+0200 using 
> (unknown algorithm 22)
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: FTP server

[Richard Levitte]

Fixed!

On Sat, 04 Jul 2020 23:35:28 +0200,
Richard Levitte wrote:
> 
> Hmmm...  I can see issues over IPv4 from my laptop, but it works
> flawlessly over iPv6, as well as from the VMS machines I've access to
> (over IPv4).  Not sure what's going on there.
> 
> The Doctor, would you mind telling us what's going on on your end?
> 
> Cheers,
> Richard
> 
> On Sat, 04 Jul 2020 23:06:54 +0200,
> Matt Caswell wrote:
> > 
> > The infrastructure was upgraded on Thursday and so things were down for
> > a while. Should all be back to normal now. If there are still problems
> > then let us know.
> > 
> > Matt
> > 
> > On 04/07/2020 20:48, The Doctor wrote:
> > > Have there been stablility issues lately?
> > > 
> > 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: FTP server

[Richard Levitte]

Hmmm...  I can see issues over IPv4 from my laptop, but it works
flawlessly over iPv6, as well as from the VMS machines I've access to
(over IPv4).  Not sure what's going on there.

The Doctor, would you mind telling us what's going on on your end?

Cheers,
Richard

On Sat, 04 Jul 2020 23:06:54 +0200,
Matt Caswell wrote:
> 
> The infrastructure was upgraded on Thursday and so things were down for
> a while. Should all be back to normal now. If there are still problems
> then let us know.
> 
> Matt
> 
> On 04/07/2020 20:48, The Doctor wrote:
> > Have there been stablility issues lately?
> > 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenSSL 1.1.1g test failures

[Richard Levitte]

On Fri, 26 Jun 2020 16:01:09 +0200,
David Harris wrote:
> Is there a standard (i.e, approved) way of using the static RTLs instead of 
> the 
> DLL ones? Or is my only option to modify the applink code so that it checks 
> its 
> environment in a different way? The problem with the dynamic RTLs is that my 
> application is often used in environments where the user may not have 
> sufficient 
> rights to install the redistributables - whereas, if I use the static 
> versions, the 
> code is a little bigger, but there's no redistributable installation required 
> and I 
> never run into rights issues.

The standard way of getting /MT is to configure 'no-shared', i.e. not
produce DLLs.

perl Configure VC-WIN64A no-shared

However, if the main issue is *your* application, then the simplest
way is to link with the static library, regardless of configuration.
We do produce alongside static libraries alongside the DLLs since
1.1.1: libcrypto_static.lib.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: openssl with Rust

[Richard Levitte]

I have very little knowledge of Rust...  however, there seems to exist
an openssl crate available already:  https://docs.rs/openssl/0.10.29/openssl/

Does that help?

Cheers,
Richard

On Tue, 23 Jun 2020 23:38:38 +0200,
Ken Goldman wrote:
> 
> Environment is Windows, Visual Studio Code, the Shining Light openssl
> build and the openssl crate.
> 
> Does anyone have experience getting this to link?
> 
> Environment variables?
> cargo.toml
> anything else?
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: PKEY CMAC timings

[Richard Levitte]

On Thu, 18 Jun 2020 09:25:43 +0200,
Hal Murray wrote:
> 
> In the context of making things go fast/clean, do I need a reset?  If so, why?

No.  I sent another message where I pointed out that I made a mistake
when saying so.


-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: How can I tell if a name for a cipher/digest is implemented?

[Richard Levitte]

On Thu, 18 Jun 2020 09:39:11 +0200,
Hal Murray wrote:
> I think that checking for NULL from EVP_get_ciphername() works in 1.1.1
> but that changed for 3.0.0
> 
> Is there anything better/cleaner than actually calling EVP_CipherInit() or 
> such?

For 3.0 and on, the better way is to find the cipher with EVP_CIPHER_fetch().
That's essentially the new EVP_get_cipherbyname().

> I'm curious.  What does it mean to have a non-NULL cipher that doesn't work?  

It means that we made a compromise, and do support the use of
functions that return a const EVP_CIPHER, but mainly as a template for
implicit fetching in the likes of EVP_CipherInit.
This is, incidently, what happens if you pass an engine pointer to
EVP_CipherInit_ex() as well, the EVP_CIPHER pointer that you pass to
it is only a template for getting the "real" engine implementation,
and will fail if that engine doesn't implement it.  In other words,
you do have this situation in 1.1.1 as well, just less obviously.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: PKEY CMAC timings

[Richard Levitte]

On Thu, 18 Jun 2020 08:27:13 +0200,
Richard Levitte wrote:
> 
> I think 16k was enough to demonstrate that the timing difference
> becomes more marginal the larger the amount of data to encrypt in the
> same session is.
> 
> This makes me think that we might want to rethink the reset functions,
> i.e. the likes of EVP_CIPHER_CTX_reset()...  could we change that
> function to become a call down to provider code?  We do allow that for
> the non-provider back-ends, they can implement a 'cleanup' function.
> Right now, EVP_CIPHER_CTX_reset() just calls the provider's function
> to free its operation context, which forces us to re-initialize
> everything with a restarted session, i.e. pass the key anew, etc etc
> etc.

Never mind what I just said, just calling EVP_EncryptInit_ex(ctx,
NULL, NULL, NULL, NULL) performs (or should perform) the reset I was
thinking of.

Cheers,
Richard

> On Thu, 18 Jun 2020 06:50:45 +0200,
> Hal Murray wrote:
> > 
> > > How does it look for large input?  As in many kilobytes or megabytes?
> > 
> > 16K is all I was willing to wait for.  Timing for really long blocks turns 
> > into a memory test.  The right unit is ns/byte.  If that's an interesting 
> > case, I'll hack some code to do longer blocks.
> pp> 
> > 1.1.1g
> >  AES-128  16 48 16225   0.225  475ac1c053379e7dbd4ce80b87d2178e
> >  AES-128  16 1024 16   1682   1.682  159d6d5c13f35d37c72efc5f6dbf40ad
> >  AES-128  16 16384 16  24566  24.566  581f7b133ad6f3697f33c3f836fdb6e6
> > 
> > 3.0.0 alpha3
> >  AES-128  16 48 16496   0.496  475ac1c053379e7dbd4ce80b87d2178e
> >  AES-128  16 1024 16   1953   1.953  159d6d5c13f35d37c72efc5f6dbf40ad
> >  AES-128  16 16384 16  24820  24.820  581f7b133ad6f3697f33c3f836fdb6e6
> > 
> > ---
> > 
> > 3.0.0 alpha3:
> > CMAC
> >  AES-128  16 16384 16  25270  25.270  581f7b133ad6f3697f33c3f836fdb6e6
> > PKEY
> >  AES-128  16 16384 16  24839  24.839  581f7b133ad6f3697f33c3f836fdb6e6
> > EVP_MAC
> >  AES-128  16 16384 16  25462  25.462  581f7b133ad6f3697f33c3f836fdb6e6
> > EVP_MAC with Preload cipher and key
> >  AES-128  16 16384 16  24567  24.567  581f7b133ad6f3697f33c3f836fdb6e6
> > 
> > 
> > 
> > -- 
> > These are my opinions.  I hate spam.
> > 
> > 
> > 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: PKEY CMAC timings

[Richard Levitte]

I think 16k was enough to demonstrate that the timing difference
becomes more marginal the larger the amount of data to encrypt in the
same session is.

This makes me think that we might want to rethink the reset functions,
i.e. the likes of EVP_CIPHER_CTX_reset()...  could we change that
function to become a call down to provider code?  We do allow that for
the non-provider back-ends, they can implement a 'cleanup' function.
Right now, EVP_CIPHER_CTX_reset() just calls the provider's function
to free its operation context, which forces us to re-initialize
everything with a restarted session, i.e. pass the key anew, etc etc
etc.

Cheers,
Richard

On Thu, 18 Jun 2020 06:50:45 +0200,
Hal Murray wrote:
> 
> > How does it look for large input?  As in many kilobytes or megabytes?
> 
> 16K is all I was willing to wait for.  Timing for really long blocks turns 
> into a memory test.  The right unit is ns/byte.  If that's an interesting 
> case, I'll hack some code to do longer blocks.
pp> 
> 1.1.1g
>  AES-128  16 48 16225   0.225  475ac1c053379e7dbd4ce80b87d2178e
>  AES-128  16 1024 16   1682   1.682  159d6d5c13f35d37c72efc5f6dbf40ad
>  AES-128  16 16384 16  24566  24.566  581f7b133ad6f3697f33c3f836fdb6e6
> 
> 3.0.0 alpha3
>  AES-128  16 48 16496   0.496  475ac1c053379e7dbd4ce80b87d2178e
>  AES-128  16 1024 16   1953   1.953  159d6d5c13f35d37c72efc5f6dbf40ad
>  AES-128  16 16384 16  24820  24.820  581f7b133ad6f3697f33c3f836fdb6e6
> 
> ---
> 
> 3.0.0 alpha3:
> CMAC
>  AES-128  16 16384 16  25270  25.270  581f7b133ad6f3697f33c3f836fdb6e6
> PKEY
>  AES-128  16 16384 16  24839  24.839  581f7b133ad6f3697f33c3f836fdb6e6
> EVP_MAC
>  AES-128  16 16384 16  25462  25.462  581f7b133ad6f3697f33c3f836fdb6e6
> EVP_MAC with Preload cipher and key
>  AES-128  16 16384 16  24567  24.567  581f7b133ad6f3697f33c3f836fdb6e6
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: CMAC timings

[Richard Levitte]

Quick forst answer, EVP_MAC_CTX is a typedef of struct evp_mac_ctx_st,
which you find in crypto/evp/evp_local.h.  It's quite small (smaller
than EVP_MD_CTX and EVP_PKEY_CTX):

struct evp_mac_ctx_st {
EVP_MAC *meth;   /* Method structure */
void *data;  /* Individual method data */
} /* EVP_MAC_CTX */;

The slowdown isn't entirely surprising...  in pre-3.0, all back-ends
(including engines, with the help of API calls) could reach right into
the EVP_PKEY_CTX that was used by libcrypto code, i.e. central code
and back-end code shared intimate knowledge.  With providers, the
boundary between central code and provider code is much stronger,
which means a certain amount of messaging between the two.

What does surprise me, though, is that direct EVP_MAC calls would be
slower than going through the PKEY bridge.  I would very much like to
see your code to see what's going on.

Regarding preloaded cipher and key, that tells me that the actual
computation of a MAC is quick enough, that most of the slowdown is
parameter overhead.  That was expected.

Cheers,
Richard

On Sun, 14 Jun 2020 17:30:50 +0200,
Hal Murray wrote:
> 
> In general, things have slowed down.
> 
> The new EVP_MAC code takes 3 times as long as the old CMAC code on 1.1.1.
> The new PKEY code takes twice as long as the old CMAC code on 1.1.1
> 
> The one ray of hope is that the API for EVP_MAC has split the part of the 
> setup that uses the key out of the init routine.  If we can hang on to a ctx 
> for each key, we can cut the time in half - that's new ECP_MAC vs CMAC on 
> 1.1.1
> 
> So how much memory does a ctx take?  How can I find out?
> 
> Even if I can't allocate a ctx per key, I can at least keep one around from 
> recv to send.   That makes the slowdown 1.7 instead of 3.
> 
> --
> 
> Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
> 
> # KL=key length, PL=packet length, CL=CMAC length
> 
> # OpenSSL 1.1.1g FIPS  21 Apr 2020
> 
> # CMACKL PL CL  ns/op sec/run
>  AES-128  16 48 16366   0.366  475ac1c053379e7dbd4ce80b87d2178e
>  AES-192  24 48 16381   0.381  c906422bfe0963de6df50e022b4aa7d4
>  AES-256  32 48 16407   0.407  991f4017858de97515260dd9ae440b06
> 
> # PKEYKL PL CL  ns/op sec/run
>  AES-128  16 48 16436   0.436  475ac1c053379e7dbd4ce80b87d2178e
>  AES-192  24 48 16448   0.448  c906422bfe0963de6df50e022b4aa7d4
>  AES-256  32 48 16461   0.461  991f4017858de97515260dd9ae440b06
> 
> -
> 
> # OpenSSL 3.0.0-alpha3 4 Jun 2020
> 
> # CMACKL PL CL  ns/op sec/run
>  AES-128  16 48 16973   0.973  475ac1c053379e7dbd4ce80b87d2178e
>  AES-192  24 48 16987   0.987  c906422bfe0963de6df50e022b4aa7d4
>  AES-256  32 48 16   1011   1.011  991f4017858de97515260dd9ae440b06
> 
> # PKEYKL PL CL  ns/op sec/run
>  AES-128  16 48 16817   0.817  475ac1c053379e7dbd4ce80b87d2178e
>  AES-192  24 48 16824   0.824  c906422bfe0963de6df50e022b4aa7d4
>  AES-256  32 48 16842   0.842  991f4017858de97515260dd9ae440b06
> 
> # EVP_MAC KL PL CL  ns/op sec/run
>  AES-128  16 48 16   1136   1.136  475ac1c053379e7dbd4ce80b87d2178e
>  AES-192  24 48 16   1153   1.153  c906422bfe0963de6df50e022b4aa7d4
>  AES-256  32 48 16   1181   1.181  991f4017858de97515260dd9ae440b06
> 
> Preload cipher and key.
>  AES-128  16 48 16170   0.170  475ac1c053379e7dbd4ce80b87d2178e
>  AES-192  24 48 16182   0.182  c906422bfe0963de6df50e022b4aa7d4
>  AES-256  32 48 16196   0.196  991f4017858de97515260dd9ae440b06
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: PKEY for CMAC: operation not supported for this keytype.

[Richard Levitte]

On Sun, 14 Jun 2020 07:16:27 +0200,
Hal Murray wrote:
> 
> I can't get CMAC to work via PKEY.  I get the same error on 1.1.1g and 3.0.0
> 
> I'm using a cipher that works with the CMAC interface.
> 
> Can anybody see what I'm missing?

Yup.  It's designed to work with the set of functions EVP_DigestSign*.

Attached is the diff of your program, rewritten to use that.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

===File /tmp/pkey.c.diff
--- /home/levitte/tmp/pkey.c2020-06-14 14:18:14.351804812 +0200
+++ test-cmac.c 2020-06-14 14:20:04.473406566 +0200
@@ -17,7 +17,7 @@
 const unsigned char key[16];
 const EVP_CIPHER *cipher;
 EVP_PKEY *pkey;
-EVP_PKEY_CTX *ctx;
+EVP_MD_CTX *mctx;
 
 printf("Build: %lx, %s\n", \
 OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT);
@@ -34,18 +34,18 @@
 return 1;
 }
 
-ctx = EVP_PKEY_CTX_new(pkey, NULL);
-if (NULL == ctx) {
+mctx = EVP_MD_CTX_new();
+if (NULL == mctx) {
 unsigned long err = ERR_get_error();
 char * str = ERR_error_string(err, NULL);
 printf("## Oops, EVP_PKEY_CTX_new() failed:\n%s.\n", str);
 return 1;
 }
 
-if (1 != EVP_PKEY_sign_init(ctx)) {
+if (1 != EVP_DigestSignInit(mctx, NULL, NULL, NULL, pkey)) {
 unsigned long err = ERR_get_error();
 char * str = ERR_error_string(err, NULL);
-printf("## Oops, EVP_PKEY_sign_init() failed:\n%s.\n", str);
+printf("## Oops, EVP_PKEY_DigestSignInit() failed:\n%s.\n", str);
 return 1;
 }
 

Re: Cleaning up usage of CMAC_xxx

[Richard Levitte]

On Thu, 11 Jun 2020 02:49:04 +0200,
Hal Murray wrote:
> CMAC_* have been DEPRECATED for 3.0.0
> 
> CHANGES.md suggests using EVP_MAC_xxx.  Mostly, that seems reasonable, but 
> there is one loose end.
> 
> CMAC_Init includes a key and cipher.  What's the equivalent in EVP_MAC_xxx?
> 
> ---
> 
> I found the params stuff, but that's new in 3.0.0
> How do I do it in 1.1.1 or earlier?

In 1.1.1 and earlier, there is a different idea, using EVP_PKEY
routines to "sign" with a MAC.  We have a EVP_PKEY to EVP_MAC bridge
in 3.0.0 to bridge the gap.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: [openssl][uwp] SSL_CTX_load_verify_locations not working for UWP port

[Richard Levitte]

On Fri, 05 Jun 2020 03:04:47 +0200,
Feng LI wrote:
> SSL_CTX_load_verify_locations is required for UWP port to load ca file since 
> OpenSSL will not use
> the CA of the OS.
> 
> But in UWP build, stdio is disabled by default. However, 
> SSL_CTX_load_verify_locations relies on
> the default X509_STORE file lookup functionality uses stdio (via BIO_s_file). 
> That basically means
> no verification of peers and hosts is possible with OpenSSL on UWP port.
> 
> Is there a way to fix this or if there's a workaround for UWP ?

It should be enough to use BIO_s_fd() instead of BIO_s_file() (it
takes a bit more than a mere change of function name, OpenSSL's file
descriptor isn't quite designed for use with files, unfortunately).

That is, with the assumption that POSIX file descriptors can be used
at all with UWP...  otherwise, someone will have to come up with a BIO
method that supports whatever file API that UWP supports.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Building OpenSSL

[Richard Levitte]

On Thu, 28 May 2020 13:20:02 +0200,
Johnny Black wrote:
> Hi, 
> 
> I'm having problems installing openssl.
> I downloaded 1.1.1 version from the website and
> I followed all the instructions but
> when I run the "nmake" command I get an error.
> It says, I quote:
> "ias   -d debug -o crypto\aes\aes-ia64.obj "crypto\aes\aes-ia64.asm"
> "NMAKE : fatal error U1077: 'ias' : return code '0x1'"
> "'ias' is not recognized as an internal or external command"
> Perhaps you might know why I'm getting this error ?
> If so, would you be so kind to provide me with the information to solve this ?
> Thanks in advance.

'ias' is Intel's Itanium assembler, which you must download and
install separately.

The other option is to configure without assembler code; that's done
with the configuration option 'no-asm', so for example:

perl Configure VC-WIN64I no-asm

Also, just in case you made a mistake and are running on a regular
x86_64 CPU (Intel or AMD, doesn't matter), you should use the config
target 'VC-WIN64A' instead of 'VC-WIN64I'.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Asymetric crypto and OpenSSL 3.0 deprecated functions

[Richard Levitte]

On Mon, 25 May 2020 13:20:28 +0200,
Emmanuel Deloget wrote:
> In my development I'm using a idiom that's not as widely used as I
> thought (as I get it after multiple days of searching out there). In
> order to securely distribute a binary, I encrypt it using an AES key
> and the AES key itself is encrypted using a /private/ RSA key I own.

That's a perfectly viable thing to do, and is usually called "signing",
and what you're signing here is the AES key.

> Only owners of the /public/ key (which, as it is a publilc key, may
> leak) can decrypt the AES key, and therefore the binary.

Which is usually called "verifying the signature".

This looks like object signing to me.

> Of course, in order to do this I rely on RSA_private_encrypt() and
> RSA_public_decrypt() because EVP_PKEY_encrypt() / EVP_PKEY_decrypt()
> cannot be used(*).

EVP_PKEY_encrypt() and EVP_PKEY_decrypt() are the wrong functions to
use.  However, there are EVP_PKEY_sign() and EVP_PKEY_verify_recover()
(if I read you correctly, that's the function you need, rather than a
mere EVP_PKEY_verify()).

> So, after that long introduction, here is my question : is there any
> OpenSSL 3.0 sanctionned, EVP_PKEY-based way to crypt using a private
> key and decrypt using a public key?

Yes, see above.  Those functions have been around for a while, I think
you can start playing with them in any current OpenSSL version.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: How to get all certs into a .der file.

[Richard Levitte]

I'm pretty sure I can find it on my own.  Not saying that I won't
thankfully receive links to interesting information, mind you!

That being said, there is currently no support (no deserializer) for
PKIpath in OpenSSL.

(BTW, since it's a SEQUENCE OF, the outermost object in such a DER
file amounts to only one, even though it then contains a series of
certificates, so that's not really part of the discussion here)

Cheers,
Richard

On Fri, 22 May 2020 09:41:53 +0200,
Kyle Hamilton wrote:
> 
> There is a format that puts all DER certificates into a single DER-formatted 
> structure.  It is
> called PKIpath, and it's defined as `SEQUENCE OF Certificate`.  The problem 
> with it is that its
> order was standardized by X.509 2001 TC1 to begin with the root and continue 
> to the leaf, which is
> backwards from how TLS present the certificate chain.  (Java's JCA/JCE were 
> specified before that
> corrigendum issued, and its PKIpath validation goes by the convention in use 
> at the time to put
> the leaf certificate first, like pem-certificate-chain.)
> 
> I don't have my computer open to get you the PKIX-WG RFCs which define it and 
> specify the same
> order as the TC1, but if you're curious you can chase them down by looking up 
> IANA's list of media
> types and searching for "application/pkix-pkipath".
> 
> -Kyle H
> 
> On Fri, May 22, 2020, 00:55 Richard Levitte  wrote:
> 
> Generally speaking, OpenSSL hasn't exactly encouraged multiple objects
> in one DER file.  While it's theoretically possible to have several
> objects in such a file file, there is code in OpenSSL where that's
> simply not considered.  For example, this snippet in the man-page
> 'X509_LOOKUP_file' is quite clear:
>
>    Functions X509_load_cert_file and X509_load_crl_file can load both PEM
>    and DER formats depending of type value. Because DER format cannot
>    contain more than one certificate or CRL object (while PEM can contain
>    several concatenated PEM objects) X509_load_cert_crl_file with
>    FILETYPE_ASN1 is equivalent to X509_load_cert_file.
>
> The functions described there are also used by functions like
> X509_LOOKUP_load_file().
>
> Note that this may change going forward, as OSSL_STORE is gradually
> entering the scene, and does provide a bit better flexibility in this
> regard.
> (We have recently added an X509_LOOKUP variant that uses OSSL_STORE
> for its object retrieval, see the section 'OSSL_STORE Method' in
> doc/man3/X509_LOOKUP_hash_dir.pod in recent OpenSSL source, such as
> the alpha releases)
>
> Cheers,
> Richard
>
> On Fri, 22 May 2020 00:53:39 +0200,
> paul h. roubekas wrote:
> > I am a complete newbie to this list.
> >
> > I wanted to search the archive but found no such page.
> >
> > I have a requirement to convert all certs in a *.p12 file to a *.der 
> file for use in the
> curl
> > command.
> >
> > The first hop to a *.pem file has all the certs.
> >
> > But the second hop only has one cert.  The I read the docs but found 
> nothing that looked
> even
> > close.
>     >
> > Hop 1
> >
> > openssl pkcs12 -chain -in trust.p12 -out ww_temp.pem  -password 
> {redacted}
> >
> > Hop 2
> >
> > openssl x509 -outform der -in ww_temp.pem -out ww_temp.der
> >
> > The Question) How do I get all the certs in the .der file?
> >
> >
> --
> Richard Levitte         levi...@openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: How to get all certs into a .der file.

[Richard Levitte]

Generally speaking, OpenSSL hasn't exactly encouraged multiple objects
in one DER file.  While it's theoretically possible to have several
objects in such a file file, there is code in OpenSSL where that's
simply not considered.  For example, this snippet in the man-page
'X509_LOOKUP_file' is quite clear:

   Functions X509_load_cert_file and X509_load_crl_file can load both PEM
   and DER formats depending of type value. Because DER format cannot
   contain more than one certificate or CRL object (while PEM can contain
   several concatenated PEM objects) X509_load_cert_crl_file with
   FILETYPE_ASN1 is equivalent to X509_load_cert_file.

The functions described there are also used by functions like
X509_LOOKUP_load_file().

Note that this may change going forward, as OSSL_STORE is gradually
entering the scene, and does provide a bit better flexibility in this
regard.
(We have recently added an X509_LOOKUP variant that uses OSSL_STORE
for its object retrieval, see the section 'OSSL_STORE Method' in
doc/man3/X509_LOOKUP_hash_dir.pod in recent OpenSSL source, such as
the alpha releases)

Cheers,
Richard

On Fri, 22 May 2020 00:53:39 +0200,
paul h. roubekas wrote:
> I am a complete newbie to this list.
> 
> I wanted to search the archive but found no such page.
> 
> I have a requirement to convert all certs in a *.p12 file to a *.der file for 
> use in the curl
> command.
> 
> The first hop to a *.pem file has all the certs.
> 
> But the second hop only has one cert.  The I read the docs but found nothing 
> that looked even
> close.
> 
> Hop 1
> 
> openssl pkcs12 -chain -in trust.p12 -out ww_temp.pem  -password {redacted}
> 
> Hop 2
> 
> openssl x509 -outform der -in ww_temp.pem -out ww_temp.der
> 
> The Question) How do I get all the certs in the .der file?
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: liblegacy.a does not work unless compiled with -static

[Richard Levitte]

On Fri, 01 May 2020 19:22:13 +0200,
Salz, Rich via openssl-users wrote:
> 
> Hm, so DSO support is a requirement for legacy crypto now?  That
> probably needs to be made explicit, and see if the project gets
> pushback.

No.  When DSO support is turned off, the legacy provider code becomes
part of libcrypto, in an inaccessible state (in other words, you still
have to "load" it).

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenSSL version 3.0.0-alpha1 published

[Richard Levitte]

On Sun, 26 Apr 2020 11:35:14 +0200,
Yann Ylavic wrote:
> 
> On Sun, Apr 26, 2020 at 12:15 AM Kurt Roeckx  wrote:
> >
> > On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote:
> > >
> > > - DH_bits(dh) (used for logging only in httpd)
> > > Replaced by BN_num_bits(DH_get0_p(dh)).
> > > Not sure this one should be deprecated, it seems to be used in several
> > > places in openssl codebase still, no replacement?
> >
> > I think the replacement is using the EVP_PKEY API and then use
> > EVP_PKEY_bits()
> 
> Sure, but if all you have is a DH object (say obtained by
> DH_get_2048_256() or PEM_read_bio_DHparams()), the EVP_PKEY API does
> not help.
> It seems a bit odd to me that DH_bits() or DH_security_bits() are
> deprecated, but not DH_get0_*() or DH_get_length() for instance.

The DH_get0_* functions are useful in contructing other low-level DH
objects using the same numbers as the one you currently have.  I don't
quite see that DH_bits() would be useful in that manner.

Along that line of thinking, I agree that it's odd that
DH_get_length() wasn't deprecated.  I can't remember if it was
discussed in particular...  it might simply be an omission.

All that being said, DH_bits() was undeprecated yesterday.  See
https://github.com/openssl/openssl/pull/11669

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenSSL version 3.0.0-alpha1 published

[Richard Levitte]

On Fri, 01 May 2020 01:22:34 +0200,
Sam Roberts wrote:
> 
> On Fri, Apr 24, 2020 at 9:07 AM Nicola Tuveri  wrote:
> > At https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers there was 
> > already an example of how to do this programmatically, and a link to the 
> > manpage for the config file syntax.
> 
> That's not working for me:
> 
> Failed to load Legacy provider: error:2567:DSO support
> routines::could not load the shared library
> /home/sam/w/core/tls/./node[26693]: ../../src/node_crypto.cc:6804:void
> node::crypto::InitCryptoOnce(): Assertion `"Unreachable code reached"'
> failed.
>  1: 0x557630598d84 node::Abort() [/home/sam/w/core/tls/./node]
> 
> From:
>   /* Load Multiple providers into the default (NULL) library context */
>   auto legacy = OSSL_PROVIDER_load(0, "legacy");
>   if (legacy == nullptr) {
> unsigned long err = ERR_get_error();
> fprintf(stderr, "Failed to load Legacy provider: %s\n",
> ERR_error_string(err, nullptr));
> UNREACHABLE();
>   }
>   auto deflt = OSSL_PROVIDER_load(0, "default");
>   if (deflt == nullptr) {
> unsigned long err = ERR_get_error();
> fprintf(stderr, "Failed to load Default provider: %s\n",
> ERR_error_string(err, nullptr));
> OSSL_PROVIDER_unload(legacy);
> UNREACHABLE();
>   }
> 
> 
> I notice that the legacy.so isn't in the same folder as the other .so
> files, so I tried:
> 
> LD_LIBRARY_PATH=/usr/local/stow/openssl-3.0.0-alpha1/lib:/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules
> 
> But that didn't work.
> 
> It looks like  adding this did work:
> 
> OSSL_PROVIDER_set_default_search_path(0,
>"/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules");
> 
> What are the default values? I built with prefix set to /usr/local,
> but then installed to the DESTDIR directory above, is that what caused
> me trouble?

You can find out the default value with 'openssl info -modulesdir'
Yes, running from the DESTDIR "installation" gets you into trouble.
DESTDIR is intended to be a staging directory, i.e. a place to put
files that you want to put in an archive or package for more proper
(distribute) installation in the right place.  It can be used for
testing, of course, but you then need to know a little more what
you're doing.

I suggest having a look at doc/man7/openssl-env.pod, it contains a
complete enough catalogue of diverse environment variables that you
can use to affect OpenSSL's internal behaviour.  OPENSSL_MODULES is of
particular interest in this case.

Suggested command to read a .pod file comfortably:

perldoc -o man doc/man7/openssl-env.pod

I suspect, btw, that people might wonder why we install provider modules
separately from engines.  The simple reason is that they are very
different beasts, but the major one is that provider modules are
intended to be fairly OpenSSL version agnostic, by design.  Engines
are unfortunately not version agnostic at all, acutely so since
OpenSSL 1.1.0.  So while provider modules do not need to be updated
for every OpenSSL version, engines do.

Cheers,
Richard

> 
> Cheers,
> Sam
> 
> 
> 
> > I just added also a minimal config file example to load both the default 
> > and the legacy provider in the default library context.
> >
> >
> > Cheers,
> >
> > Nicola
> >
> > On Fri, 24 Apr 2020 at 17:56, Sam Roberts  wrote:
> >>
> >> On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell  wrote:
> >> > This one is interesting:
> >> >
> >> > ERR_OSSL_EVP_FETCH_FAILED
> >> >
> >> >
> >> > This means that the algorithm you are trying to use isn't available in
> >> > the loaded providers. Since you should be getting the default provider
> >> > loaded automatically it could be because some legacy algorithms were
> >> > moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF
> >> > (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're
> >> > using something from that list then that would explain it.
> >>
> >> Can we add the legacy provider, via configuration, or via code?
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: CONF_MODULE undefined?

[Richard Levitte]

   ^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:71:21: note: expanded 
> from macro 'SKM_DEFINE_STACK_OF'
> return (t2 *)OPENSSL_sk_delete_ptr((OPENSSL_STACK *)sk, \
> ^
> In file included from evp-sign.c:40:
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: use of 
> undeclared identifier 'CONF_MODULE'
> DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
>^
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type 
> name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type 
> name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:28: error: unknown type 
> name 'CONF_MODULE'
> /Users/ur20980/openssl-3/include/openssl/conf.h:37:1: error: expected 
> expression
> DEFINE_OR_DECLARE_STACK_OF(CONF_MODULE)
> ^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:175:40: note: expanded 
> from macro 'DEFINE_OR_DECLARE_STACK_OF'
> # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s)
>^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:135:29: note: expanded 
> from macro 'DEFINE_STACK_OF'
> # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t)
> ^
> /Users/ur20980/openssl-3/include/openssl/safestack.h:84:21: note: expanded 
> from macro 'SKM_DEFINE_STACK_OF'
> return (t2 *)OPENSSL_sk_pop((OPENSSL_STACK *)sk); \
> ^
> fatal error: too many errors emitted, stopping now [-ferror-limit=]
> 
> --
> Regards,
> Uri 
>  
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenSSL v3 alpha 1: include file problem

[Richard Levitte]

I hope this is fixed by https://github.com/openssl/openssl/pull/11655

On Mon, 27 Apr 2020 23:14:12 +0200,
Norm Green wrote:
> 
> I don't know if this change was intentional or not.
> With 3.0 alpha, compiling this simple program on Linux fails but
> succeeds on 1.1:
> 
> -
> #include 
> 
> 
> gcc -c -I \
> /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include test.c
> 
> 
> In file included from
> /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/types.h:20:0,
>  from
> /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/err.h:26,
>  from test.c:1:
> /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/ssl.h:235:28:
> error: 'SRTP_PROTECTION_PROFILE' does not name a type
>  DEFINE_OR_DECLARE_STACK_OF(SRTP_PROTECTION_PROFILE)
>     ^
> /home/normg/local/gs360_opensslv3/slow50/openssl/install50/include/openssl/safestack.h:30:45:
> note: in definition of macro 'SKM_DEFINE_STACK_OF'
>  typedef int (*sk_##t1##_compfunc)(const t3 * const *a, const t3
> *const *b); \
> ...
> 
> 
> 
> To fix it, all we need is to include err.h first, as follows:
> 
> -
> #include 
> #include 
> 
> 
> I scanned the wiki and readme and did not see a requirement to include
> err.h before ssl.h.  Is this intentional or a bug?
> 
> It's easy enough for me to fix this in my source code, but other
> packages that rely upon openssl break with "ssl.h is unusable" errors
> due of this change (OpenLDAP is one such example).
> 
> Norm Green
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: empty directory in the 1.1.1 series release tags

[Richard Levitte]

On Tue, 21 Apr 2020 19:55:41 +0200,
Quanah Gibson-Mount wrote:
> --On Tuesday, April 21, 2020 11:25 AM -0700 Norm Green
>  wrote:
> 
> >  >I use the git release tags, not the tarballs.
> > 
> > I do too, and I suspect many others do as well.
> > The empty krb5 directory has not caused grief for me, but it would be
> > nice if the git release tag directory structure matched the tarball.
> 
> I ended up doing a git rm on the krb5 dir, and then the rest of the
> tags all went in fine (I was last on 1.1.1d).  But I agree, overall I
> would expect the release tags to match the release tarballs.

To be a bit blunt, that's simply not reasonable.  There are a number
of files and directories, not the least diverse git related files,
that are never going to make it into the tarball.

Have a look at .gitattributes, you have a number of patterns there
with the attribute 'export-ignore'.  Those are files that don't make
it into the tarball.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 1.OU or OU.1 ?

[Richard Levitte]

The correct answer is, it depends.  This is an unfortunate
evolutionary artefact, and is governed by very different pieces of
code.

The config.pod example revolves around subject names and the config
for 'openssl req'.  The code that uses this is the function
auto_info(), found in apps/req.c.

The x509v3_config.pod example revolves around X.509 v3 extensions, and
the config for those is used by diverse functions in crypto/x509v3/
(1.1.1) or crypto/x509/ (masterand upcoming 3.0), and ultimately, the
key name comparison is done by name_cmp(), found in v3_utl.c.

So both manuals are correct.  Unfortunately...

Cheers,
Richard

On Fri, 20 Mar 2020 22:12:08 +0100,
Salz, Rich via openssl-users wrote:
> 
> 
> The doc/man5/config.pod file says to use
> 
> 1.OU = “My first OU”
> 
> 2.OU = “My second OU”
> 
> But doc/man5/x509v3_config.pod says to append the numeric, as in
> 
> email.1 = steve@here
> 
> email.2 = steve@there
> 
> I believe the second form is correct.  Can anyone confirm?
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Compiling for RISC-V

[Richard Levitte]

Hi,

when you mentioned cross compiling, that got me a bit more curious, so
I went looking, and noticed that Debian [sid] (which is what I run on
my laptop) has all the cross compiling tools I needed (see
https://wiki.debian.org/RISC-V#Cross_compilation), so I installed
them, and then tried this in my checkout of OpenSSL's master branch:

./Configure linux-generic64 no-asm no-threads \
--cross-compile-prefix=riscv64-linux-gnu-

Running 'make' was a breeze, it went through flawlessly.

I haven't done much further tests, though.

Cheers,
Richard

On Mon, 09 Mar 2020 20:23:09 +0100,
Kristin Barber wrote:
> 
> 
> I did also try configuring for "no-asm", but there still seemed to be 
> architecture-specific issues
> based on which files the errors were coming from.  I should probably also 
> mention that I am
> attempting to cross-compile for RV64 from an x86 machine.
> 
> On Mon, Mar 9, 2020 at 3:12 PM Scott Neugroschl  wrote:
> 
>  
>
> Is the “no-asm” configuration option still supported?
>
>  
>
> From: openssl-users  On Behalf Of 
> Kristin Barber
> Sent: Monday, March 9, 2020 12:03 PM
> To: Richard Levitte 
> Cc: openssl-users@openssl.org
> Subject: Re: Compiling for RISC-V
>
>  
>
> Hi Richard, thanks for the reply. It was helpful.
>
>  
>
> You are correct, I was able to find a configuration that worked by 
> passing the RISC-V compiler
> via "make variable" assignment, along with some relevant options.  Things 
> start compiling, but
> the build fails on what seems to be architecture-specific assembly files 
> which are selected
> based on which "platform" has been configured.  It did not seem to me 
> that there were RISC-V
> assembly-specific files as an option here, and based on your reply, I 
> think that is indeed the
>     issue.  Am I understanding this correctly?
>
>  
>
> Thanks,
>
>  
>
> Kristin
>
>  
>
> On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte  
> wrote:
>
> On Mon, 09 Mar 2020 05:18:17 +0100,
> Kristin Barber wrote:
> > I've looked at the INSTALL docs, and it doesn't seem that RISC-V 
> processors are
> supported
> > currently as a platform. Is this correct?
>
> That is correct.  No one has implemented that support yet.
>
> > Is there a branch which enables configuring for a RISC-V machine 
> that hasn't yet made it
> into a
> > stable release?  
>
> Not that I know of.  Although, this same question has also been raised
> on github (I forget the issue number).
>
> > Any advice on where to look for information or changes to the build 
> process in order to
> compile
> > for RISC-V?
>
> The first thing to attempt is a generic build with no assembler.
> There are some really simply config targets that could be a first
> step, one of:
>
>     ./Configure cc
>
>     ./Configure gcc
>
> A (pretty big) step up from that, at least if Linux is your target,
> would be one of these:
>
>     ./Configure linux-generic32
>
>     ./Configure linux-generic64
>
> Note that in either case, you may have to add C flags and ld flags,
> which you can do in one of two ways:
>
> 1)  directly on the configuration command line, like this (Configure
>     makes an educated guess on what flags go where):
>
>     ./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something
>
> 2)  via "make variable" assignment:
>
>     ./Configure linux-generic64 \
>                 CPPFLAGS='-DWHATEVER=value' \
>                 CFLAGS='-m64' \
>                 LDFLAGS='-Wl,-something'
>
> At some point, you might find a combination that works for you.  We
> would definitely like to know what you figure out, and it may be that
> the result makes it into our database of config targets (which, if
> you're curious, are the files Configurations/*.conf).
>
> Now, configuration is the easy bit when it comes to new CPUs,
> relatively speaking.  I assume that part of your question is whether
> there is assembler support.  This is the hard par

Re: Compiling for RISC-V

[Richard Levitte]

On Mon, 09 Mar 2020 05:18:17 +0100,
Kristin Barber wrote:
> I've looked at the INSTALL docs, and it doesn't seem that RISC-V processors 
> are supported
> currently as a platform. Is this correct?

That is correct.  No one has implemented that support yet.

> Is there a branch which enables configuring for a RISC-V machine that hasn't 
> yet made it into a
> stable release?  

Not that I know of.  Although, this same question has also been raised
on github (I forget the issue number).

> Any advice on where to look for information or changes to the build process 
> in order to compile
> for RISC-V?

The first thing to attempt is a generic build with no assembler.
There are some really simply config targets that could be a first
step, one of:

./Configure cc

./Configure gcc

A (pretty big) step up from that, at least if Linux is your target,
would be one of these:

./Configure linux-generic32

./Configure linux-generic64

Note that in either case, you may have to add C flags and ld flags,
which you can do in one of two ways:

1)  directly on the configuration command line, like this (Configure
makes an educated guess on what flags go where):

./Configure linux-generic64 -m64 -DWHATEVER=value -Wl,-something

2)  via "make variable" assignment:

./Configure linux-generic64 \
CPPFLAGS='-DWHATEVER=value' \
CFLAGS='-m64' \
LDFLAGS='-Wl,-something'

At some point, you might find a combination that works for you.  We
would definitely like to know what you figure out, and it may be that
the result makes it into our database of config targets (which, if
you're curious, are the files Configurations/*.conf).

Now, configuration is the easy bit when it comes to new CPUs,
relatively speaking.  I assume that part of your question is whether
there is assembler support.  This is the hard part in terms of
effort.  We currently have no such thing at all for RISC-V, and I
haven't seen any attempts to start such an effort...  PRs would
certainly be welcome, but anyone who tries this will have to be
prepared for it to take a while to get into the main source.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: writev over OpenSSL

[Richard Levitte]

So if I understand correctly, the desirable advantages with writev(2)
are atomicity across the set of buffers passed as well as minimum
system call overhead.

I can't see that we have support for this kind of construct.  We
*could* simulate something like that with smartly written BIOs, but
it would be just that, a simulation, and I'm quite sceptical that it
would gain you much more than the mere comfort of having an interface
that you're used to deal with.

Cheers,
Richard

On Sun, 02 Feb 2020 15:27:52 +0100,
Eran Borovik wrote:
> I am in the process of integrating OpenSSL with my application. My 
> application uses scatter-gather unencrypted
> buffers. Without OpenSSL, I would use writev with no issues. Is there a way 
> to do the equivalent over OpenSSL?
> I understand that I can split the vector into multiple SSL_write/SSL_read 
> operations but that defeats the
> purpose and has a large overhead. Creating a temporary buffer and then 
> consolidating the vector is a problem
> because of the performance cost associated with memory copy.
> Is there a clean way to achieve this without the performance overhead. 
> Perhaps dealing with BIOs directly?
> 
> Many thanks,
> Eran
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Daily snapshots

[Richard Levitte]

Fixed.

Side note: openssl-...@openssl.org does not exist any more.

Cheers,
Richard

On Sat, 21 Dec 2019 07:32:30 +0100,
The Doctor wrote:
> 
> What is happening.
> 
> For 2 days in a row, the snapshots are not available.  
> 
> What gives?
> -- 
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> doctor@@nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist 
> rising!
> https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on Atheism
> Merry Christmas 2019 and Happy New Year 2020 !
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Writing an ENGINE for OpenSSL-1.1.1 and 3.0

[Richard Levitte]

When you say you put it in "the appropriate of the lib/", what
directory is that exactly?  Does it correspond to the output of
"openssl3 version -e"?

On Sun, 01 Dec 2019 00:58:00 +0100,
Blumenthal, Uri - 0553 - MITLL wrote:
> 
> 
> In preparation for writing a new engine that supports message digest and 
> asymmetric crypto (sign
> and decrypt), I am trying to port the existing simple/demo engines from the 
> Engine Corner examples
> (thanks, Richard!).
> 
> The fork of https://github.com/engine-corner/Lesson-2-A-digest.git that 
> compiles and runs
> correctly (apparently) on OpenSSL-1.1.1 is 
> https://github.com/mouse07410/Lesson-2-A-digest.git .
> 
> But no matter what, I was unable to make either of these two repos to run 
> successfully with
> OpenSSL-3.0 (master), even though the latter repo at least seems to compile 
> correctly, and answers
> “Available”. Here’s what I’m getting (for both versions I built the sample 
> “emd5”engine and copied
> to the appropriate subdir of the lib/;  “openssl3” is an alias that points 
> OPENSSL_CONF at the
> correct file, and invokes the correct OpenSSL-3.0 “openssl” binary, as it’s 
> not on the main path):
> 
> $ penssl version
> 
> OpenSSL 1.1.1d  10 Sep 2019
> 
> $ openssl engine -t -c emd5
> 
> (emd5) A simple md5 engine for demonstration purposes
> 
>  [MD5]
> 
>  [ available ]
> 
> $ echo "shoot" | openssl dgst -md5 -engine emd5
> 
> engine "emd5" set.
> 
> (stdin)= 61a08703a6a4c774cad650afaedd9c10
> 
> $ echo "shoot" | openssl dgst -md5
> 
> (stdin)= 61a08703a6a4c774cad650afaedd9c10
> 
> $ 
> 
> $ openssl3 version
> 
> OpenSSL 3.0.0-dev xx XXX  (Library: OpenSSL 3.0.0-dev xx XXX )
> 
> $ openssl3 engine -t -vv -c emd5
> 
> (emd5) A simple md5 engine for demonstration purposes
> 
>  [MD5]
> 
>  [ available ]
> 
> $ echo "shoot" | openssl3 dgst -md5
> 
> MD5(stdin)= 61a08703a6a4c774cad650afaedd9c10
> 
> $ echo "shoot" | openssl3 dgst -md5 -engine emd5
> 
> engine "emd5" set.
> 
> Error setting digest
> 
> C0:05:98:0C:01:00:00:00:error:digital envelope 
> routines:EVP_DigestInit_ex:initialization
> error:crypto/evp/digest.c:224:
> 
> $
> 
> Something must be missing from the configuration/setup – but what…? Help 
> would be greatly
> appreciated!
> 
> Thanks!
> 
> —
> 
> Regards,
> 
> Uri
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 1.1.1d build failure with no-shared

[Richard Levitte]

You don't happen to have a libcrypto.so lying around in your build
directory?

Just now, I noticed that test/build.info is a bit sloppy, this patch
should help:

diff --git a/test/build.info b/test/build.info
index e4fff15883..e5e1eef153 100644
--- a/test/build.info
+++ b/test/build.info
@@ -449,7 +449,7 @@ IF[{- !$disabled{tests} -}]
 PROGRAMS{noinst}=cipher_overhead_test
 SOURCE[cipher_overhead_test]=cipher_overhead_test.c
 INCLUDE[cipher_overhead_test]=.. ../include ../apps/include
-DEPEND[cipher_overhead_test]=../libcrypto ../libssl libtestutil.a
+DEPEND[cipher_overhead_test]=../libcrypto.a ../libssl.a libtestutil.a
   ENDIF
 
   SOURCE[uitest]=uitest.c ../apps/lib/apps_ui.c

Cheers,
Richard ( I'll check if there are others with the same problem )

On Fri, 22 Nov 2019 17:20:53 +0100,
Claus Assmann wrote:
> 
> Just FYI: trying to build openssl 1.1.1d with no-shared fails (on
> OpenBSD 6.5) see below. I'm not sure why test/cipher_overhead_test
> is needed for the build.
> 
> rm -f test/cipher_overhead_test
> ${LDCMD:-cc} -Wa,--noexecstack -Qunused-arguments -Wall -O3 -L.-o 
> test/cipher_overhead_test test/cipher_overhead_test.o  -lssl 
> test/libtestutil.a -lcrypto  
> ld: error: undefined symbol: ssl3_num_ciphers
> >>> referenced by cipher_overhead_test.c
> >>>   test/cipher_overhead_test.o:(cipher_overhead)
> 
> ld: error: undefined symbol: ssl3_get_cipher
> >>> referenced by cipher_overhead_test.c
> >>>   test/cipher_overhead_test.o:(cipher_overhead)
> 
> ld: error: undefined symbol: ssl_cipher_get_overhead
> >>> referenced by cipher_overhead_test.c
> >>>   test/cipher_overhead_test.o:(cipher_overhead)
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error 1 in . (Makefile:8181 'test/cipher_overhead_test')
> *** Error 1 in [[path removed]]/openssl-1.1.1d (Makefile:174 'all')
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: use of makedepend in openssl 1.1.1

[Richard Levitte]

For C compilers that can't generate makefile dependency files, we have 
makedepend as a fallback.

Cheers
Richard


shiva kumar  skrev: (24 oktober 2019 20:41:28 CEST)
>what is the use of makedepend in openssl 1.1.1?
>openssl 1.1.1 can build without makepend then what's the use of
>makedepend?
>is it good to use makedepend while building openssl 1.1.1?
>please answer me
>thanks in advance

-- 
Richard by mobile

Re: Linux linking issues moving from 1.0.2t to 1.1.1c

[Richard Levitte]

On Tue, 08 Oct 2019 18:53:37 +0200,
Dan Heinz wrote:
> 
> Another question is why I now need to link pthreads when I did not
> in the 1.0.2 version?  I've added no-threads to the configuration,
> but I'm curious why I didn't need to previously link it.  And I'd
> prefer not to change too many configuration parameters if possible.

We have radically changed how threads-related things are handled.
Previous to 1.1.0, we required the application to provide us with the
locking functionality in form of callbacks.  Since 1.1.0, these
matters are entirely internal, so libcrypto requires the presence of
the platform specific thread implementation of our choosing, which is
pthread on everything but Windows, where we use Windows thread calls.

So if you really really really want to have nothing to do with threads
in your applications, the 'no-threads' configuration option is the
right move.  However, if your applications do deal with threads,
directly or indirectly, disabling threads in libcrypto is of course a
bad move.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Blake2b with key

[Richard Levitte]

On Tue, 08 Oct 2019 15:44:23 +0200,
van Hemel, Wouter J M wrote:
> 
> Hello,
> 
> I'm trying to create a blake2b512 digest with a key. I've made an attempt to 
> follow the source code and I'm assuming the algorithm's name for blake2b MAC 
> is blake2bmac, though I have tried different values. I don't seem to be able 
> to create a valid checksum:
> 
> $ openssl version; echo -n "hello" | openssl dgst -blake2b512 -mac blake2bmac 
> -macopt key:secret
> OpenSSL 1.1.1d  10 Sep 2019
> Algorithm blake2bmac not found
> 
> Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)?

No, sorry.  It has been added for upcoming OpenSSL 3.0, though.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Linux linking issues moving from 1.0.2t to 1.1.1c

[Richard Levitte]

On Tue, 08 Oct 2019 14:59:23 +0200,
Richard Levitte wrote:
> 
> On Mon, 07 Oct 2019 21:55:50 +0200,
> Dan Heinz wrote:
> > 
> > >The no-dso is silently not valid in 1.1.1c.  That option didn't work 
> > >right, so it was unusable in practice anyway.  However, someone recently 
> > >fixed that up, unfortunately after the last 1.1.1 release.
> > >The specific patch may be possible to find on github (unless that branch 
> > >has been deleted), otherwise you will have to cherry-pick the appropriate 
> > >commit.
> > 
> > >Github PR: https://github.com/openssl/openssl/pull/9889
> > >Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054
> > 
> > >Cheers,
> > >Richard
> > 
> > Thanks for the info.  I did some more digging and you had actually posted a 
> > workaround in this thread:
> > https://github.com/openssl/openssl/issues/9036
> > 
> > I thought I would try it out.
> > I used your example and created my own config target in file named 
> > no_dos.conf. 
> > (
> > 'my-linux-x86_64' => {
> > inherit_from=> [ 'linux-x86_64' ],
> > dso_scheme => undef,
> > }
> > );
> > 
> > ./Configure --config ../no_dso.conf my-linux-x86_64  -m32 
> > --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm 
> > no-shared no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp 
> > no-afalgeng no-pinshared
> > 
> > But I'm getting this error from the script when Configure is run:
> > target already defined - ../no_dso.conf (offending arg: my-linux-x86_64)
> > 
> > What did I miss?
> 
> You don't happen to have edited some Configurations/*.conf and added
> that name already?  I'm otherwise unsure for the moment.

Figured it out.  Configure requires that '--config' be joined to its
value with an equal sign.  In other words, this slight variation
works:

./Configure --config=../no_dso.conf my-linux-x86_64  -m32 
--prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared 
no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng 
no-pinshared

Cheers,
Richard ( is just a messenger in this case, yeah? )

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Linux linking issues moving from 1.0.2t to 1.1.1c

[Richard Levitte]

On Mon, 07 Oct 2019 21:55:50 +0200,
Dan Heinz wrote:
> 
> >The no-dso is silently not valid in 1.1.1c.  That option didn't work right, 
> >so it was unusable in practice anyway.  However, someone recently fixed that 
> >up, unfortunately after the last 1.1.1 release.
> >The specific patch may be possible to find on github (unless that branch has 
> >been deleted), otherwise you will have to cherry-pick the appropriate commit.
> 
> >Github PR: https://github.com/openssl/openssl/pull/9889
> >Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054
> 
> >Cheers,
> >Richard
> 
> Thanks for the info.  I did some more digging and you had actually posted a 
> workaround in this thread:
> https://github.com/openssl/openssl/issues/9036
> 
> I thought I would try it out.
> I used your example and created my own config target in file named 
> no_dos.conf. 
> (
> 'my-linux-x86_64' => {
> inherit_from=> [ 'linux-x86_64' ],
> dso_scheme => undef,
> }
> );
> 
> ./Configure --config ../no_dso.conf my-linux-x86_64  -m32 
> --prefix=$install_path/openssl_32 -DPURIFY -DOPENSSL_NO_COMP no-asm no-shared 
> no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng 
> no-pinshared
> 
> But I'm getting this error from the script when Configure is run:
> target already defined - ../no_dso.conf (offending arg: my-linux-x86_64)
> 
> What did I miss?

You don't happen to have edited some Configurations/*.conf and added
that name already?  I'm otherwise unsure for the moment.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Linux linking issues moving from 1.0.2t to 1.1.1c

[Richard Levitte]

The no-dso is silently not valid in 1.1.1c.  That option didn't work
right, so it was unusable in practice anyway.  However, someone
recently fixed that up, unfortunately after the last 1.1.1 release.
The specific patch may be possible to find on github (unless that
branch has been deleted), otherwise you will have to cherry-pick the
appropriate commit.

Github PR: https://github.com/openssl/openssl/pull/9889
Commit ID: 8dcd57461972dceaaf014b71d173d0a8758e7054

Cheers,
Richard

On Mon, 07 Oct 2019 17:19:26 +0200,
Dan Heinz wrote:
> 
> 
> Please bear with me as I am a Windows developer, and not too adept with 
> Linux.  
> 
> Our library has been using the OpenSSL 1.0.2x branch, and we are moving to 
> 1.1.1c.  I have the
> Windows build of our libraries working, and now I’ve moved to Linux.
> 
> Our library is built as a shared library as well as static library and both 
> use the static OpenSSL
> library (we archive the OpenSSL static library with our static library).  
> 
> When I built our shared library I had some linker errors:
> e/Debug32/mylib.so: undefined reference to `dlopen'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to 
> `pthread_rwlock_rdlock'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_rwlock_init'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_getspecific'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to 
> `pthread_rwlock_destroy'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlclose'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_key_create'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to 
> `pthread_rwlock_wrlock'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_once'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_atfork'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_setspecific'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlerror'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to 
> `pthread_rwlock_unlock'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `dlsym'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `pthread_key_delete'
> 
> ../../MyLib/Debug32/libMyLib.so: undefined reference to `dladdr'
> 
> And the Configuration line from our build script:
> ./Configure linux-x86_64 --prefix=$install_path/openssl_64 -DPURIFY 
> -DOPENSSL_NO_COMP no-shared
> no-dso no-sse2 no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp no-afalgeng 
> no-pinshared
> 
> As our library does not use multiple threads, I can build the OpenSSL library 
> with the no-threads
> configuration parameter to remove the pthread references.  Is there anything 
> I should be aware of
> when doing so? 
> 
> For the dlopen, dlclose, dlerror,dlsym, and dladdr references, it seems I 
> need to link libld using
> -ldl.  Isn’t the no-dso configuration option supposed to remove the need for 
> this library?  Is
> there a way to do so with 1.1.1c?  While I can link this in our shared 
> library, our static library
> will require anyone using our library to link libld.  I’d like to avoid this 
> if possible, and it
> seems we could with the 1.0.2 branch. 
> 
> Am I missing something here?
> 
> Thanks in advance!
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: AW: Test failed with openssl-1.1.1d ../test/recipes/20-test_enc.t

[Richard Levitte]

On Thu, 12 Sep 2019 10:31:51 +0200,
Dr. Matthias St. Pierre wrote:
> 
> > > I think this is a problem with the 20-test_enc.t Test and not with 
> > > OPENSSL.
> > >
> > > Can you please help me to fix the Test ?
> > >
> > 
> > Did you enable zlib by any chance? If so it could be this:
> > 
> > https://github.com/openssl/openssl/issues/9866
> > 
> > No resolution as yet.
> > 
> > Matt
> 
> 
> If you need a quick workaround, you have two options:
> 
> - Don't use the 'zlib' option when configuring OpenSSL
> 
> - Revert the offending commit 8be96f2369. It is dispensible, because it only 
> fixes
>   a 'cosmetical' problem, namely that in certain situations you have to press
>   CTRL-D in the console more often than expected in order to indicate EOF to 
> the
>   openssl application.
> 
>
> https://github.com/openssl/openssl/commit/8be96f236969caabf303bec389a2f812b4869c1c

Reverting the "offending commit" is a bad idea, because the code it
corrected was obviously hiding bugs, which would hit others who treat
BIO filters correctly (i.e. actually check if there's any pending
input or output).

Simply put, the zlib BIO filter doesn't behave correctly in this
regard.  Corrective PR here: https://github.com/openssl/openssl/pull/9876

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Richard Levitte]

Thanks for the heads up.

For some reason, the information at our CDN remained incorrect for the
"BAD" files, so I purged all the current release files there, so their
cache for them would rebuild from scratch.  They look better now.

Cheers,
Richard

On Thu, 12 Sep 2019 00:25:40 +0200,
Carl Tietjen wrote:
> 
> 
> Still seeing the issue for SOME of the SHA256 files...  I waited for a while 
> thinking it might be
> a cache issue, but no change.
> 
> https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256  -- BAD
> 
> https://www.openssl.org/source/openssl-1.1.0l.tar.gz.sha256  -- OK
> 
> https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256 -- BAD
> 
> https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz.sha256 -- OK
> 
> https://www.openssl.org/source/openssl-fips-ecp-2.0.16.tar.gz.sha256 -- OK
> 
> -Original Message-
> From: Richard Levitte [mailto:levi...@openssl.org]
> Sent: Wednesday, September 11, 2019 2:41 PM
> To: Michael Wojcik 
> Cc: Carl Tietjen ; Matt Caswell 
> ;
> openssl-users@openssl.org
> Subject: Re: Problem with the SHA256 signatures (download files) for the new 
> releases 1.1.1d,
> 1.0.2t, 1.1.0l etc
> 
> Issue found...  Apache detected .gz in the file name and set the encoding to 
> 'application/
> x-gzip'...  Apparently, we already force .asc and .sha1 files to 
> application/binary, but have
> apparently not added a similar directive for .sha256 files.
> 
> Now done.
> 
> Cheers,
> 
> Richard
> 
> On Wed, 11 Sep 2019 22:04:53 +0200,
> 
> Michael Wojcik wrote:
> 
> >
> 
> > I can confirm Carl's issue when I download using Pale Moon (a Firefox fork):
> 
> >
> 
> > -
> 
> > $ file openssl-1.1.1d.tar.gz.sha256
> 
> > openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT
> 
> > filesystem (MS-DOS,  OS/2, NT)
> 
> >
> 
> > $ file openssl-1.1.1d.tar.gz.sha1
> 
> > openssl-1.1.1d.tar.gz.sha1: ASCII text
> 
> >
> 
> > $ file openssl-1.1.1d.tar.gz.asc
> 
> > openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old)
> 
> >
> 
> > $ gpg --verify  openssl-1.1.1d.tar.gz.asc  openssl-1.1.1d.tar.gz
> 
> > gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491
> 
> > gpg: Good signature from "Matt Caswell " [full]
> 
> > gpg: aka "Matt Caswell " [full]
> 
> > -
> 
> >
> 
> > So the .sha1 file and the signature look fine, but the .sha256 file is 
> > apparently a fragment of
> gzip-compressed data. And ... let's see ... gunzip'ing it gives us the SHA256 
> hash in ASCII. So my
> guess the server is gzip'ing it (or it's gzip'ed at rest on the server), but 
> the server isn't
> setting the content-transfer-encoding correctly. Chrome might be 
> content-sniffing and
> decompressing based on that. I haven't looked at the response headers though.
> 
> >
> 
> > (Personally, I always check the signature and don't bother with the
> 
> > posted hashes.)
> 
> >
> 
> > --
> 
> > Michael Wojcik
> 
> > Distinguished Engineer, Micro Focus
> 
> >
> 
> >
> 
> --
> 
> Richard Levitte levi...@openssl.org
> 
> OpenSSL Project http://www.openssl.org/~levitte/
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Richard Levitte]

Issue found...  Apache detected .gz in the file name and set the
encoding to 'application/x-gzip'...  Apparently, we already force .asc
and .sha1 files to application/binary, but have apparently not added a
similar directive for .sha256 files.

Now done.

Cheers,
Richard

On Wed, 11 Sep 2019 22:04:53 +0200,
Michael Wojcik wrote:
> 
> I can confirm Carl's issue when I download using Pale Moon (a Firefox fork):
> 
> -
> $ file openssl-1.1.1d.tar.gz.sha256
> openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT filesystem 
> (MS-DOS,
>  OS/2, NT)
> 
> $ file openssl-1.1.1d.tar.gz.sha1
> openssl-1.1.1d.tar.gz.sha1: ASCII text
> 
> $ file openssl-1.1.1d.tar.gz.asc
> openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old)
> 
> $ gpg --verify  openssl-1.1.1d.tar.gz.asc  openssl-1.1.1d.tar.gz
> gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491
> gpg: Good signature from "Matt Caswell " [full]
> gpg: aka "Matt Caswell " [full]
> -
> 
> So the .sha1 file and the signature look fine, but the .sha256 file is 
> apparently a fragment of gzip-compressed data. And ... let's see ... 
> gunzip'ing it gives us the SHA256 hash in ASCII. So my guess the server is 
> gzip'ing it (or it's gzip'ed at rest on the server), but the server isn't 
> setting the content-transfer-encoding correctly. Chrome might be 
> content-sniffing and decompressing based on that. I haven't looked at the 
> response headers though.
> 
> (Personally, I always check the signature and don't bother with the posted 
> hashes.)
> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: IPv6 address encoding in commonName

[Richard Levitte]

On Thu, 15 Aug 2019 00:47:41 +0200,
Michael Richardson wrote:
> 
> 
> Robert Moskowitz  wrote:
> > I am fiddling around with an intermediate CA signing cert that the CA's
> > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually 
> a
> > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised 
> soon).
> 
> > For a client cert, it would be easy to put the HIT in subjectAltName 
> per RFC
> > 8002 (with a null subjectName), but a CA cert MUST have a non-empty
> > subjectName.
> 
> > Thus all I want in this subjectName is commonName with the HIT.
> > I am looking for examples of IPv6 addresses in commonName.
> 
> I thought that RFC3779 did exactly what you want, but it does not define new
> Subject DN, but rather a new extension that will be bound to the Subject.
> (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but
> I guess it preceeded the SIDR working group, and occured in PKIX)

OpenSSL does support that extension...  crypto/x509v3/v3_addr.c (moved
to crypto/x509/v3_addr.c in next major version) is all about that as
far as I can see.

Thanks for bringing that up.  Trying to infer some kind of meaning
into commonName would be a mistake (isn't previous such hacks the very
reason we have the subjectAltName extension?)

> > In practice you could follow the nibble notation as already used
> > for delegation of IPv6 reverse lookups in DNS.
> 
> so more correctly:
>  DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8
> 
> > However for the CN in the end cert you could perhaps use the full
> > DNS reverse IPv6 name
> > 
> "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa"
> > or the URL/Mail notation "[:::::::]"
> > where the hex notation shall be the shortest form permitted by the
> > IPv6 notation spec.
> 
> Bob, this seems like the best immediate hack to me.

"hack" would be the operative word here.  While it's true that this
would fulfill the objective, I frankly wouldn't like to see such a
cert.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: bug in ghash-x86_64.pl for non-AVX assemblers?

[Richard Levitte]

This bug was found a couple of days after 1.1.1b was released. The fix us found 
in commit dbb1340314fcec37662d79720e6566fdd5a232e8

The best thing you can do is to update your source to 1.1.1c, which has this 
fix and more.

Cheers
Richard


Michael Wojcik  skrev: (2 augusti 2019 16:00:59 
CEST)
>I'm trying to build 1.1.1b on an old RHEL 5.5 machine (for reasons too
>tiresome to explain). It has a rather ancient version of the Gnu
>assembler, 2.17.50, which ghash-x86_64.pl decides means it doesn't have
>AVX support. (The script looks for 2.20 or later, basically. I assume
>that's correct.)
>
>The problem is that it generates invalid assembly when AVX isn't
>available. The output from the assembler is:
>
>-
>crypto/modes/ghash-x86_64.s: Assembler messages:
>crypto/modes/ghash-x86_64.s:1311: Error: previous CFI entry not closed
>(missing .cfi_endproc)
>crypto/modes/ghash-x86_64.s:1374: Error: open CFI at the end of file;
>missing .cfi_endproc directive
>-
>
>Looking at ghash-x86_64.s, I can see that indeed there's no
>.cfi_endproc before line 1311. gcm_init_avx is missing its endproc. And
>looking at the script, the reason seems obvious, unless I'm missing
>something:
>
>-
>$code.=<<___;
>.globl   gcm_init_avx
>.type gcm_init_avx,\@abi-omnipotent
>.align   32
>gcm_init_avx:
>.cfi_startproc
>___
>if ($avx) {
>...
>$code.=<<___;
>   ret
>.cfi_endproc
>.size gcm_init_avx,.-gcm_init_avx
>___
>} else {
>$code.=<<___;
>   jmp   .L_init_clmul
>.size gcm_init_avx,.-gcm_init_avx
>___
>}
>
>
>There's a .cfi_endproc in the here-doc on the if ($avx) branch, but
>none in the here-doc on the else branch. So if the assembler doesn't
>have AVX support, the script doesn't emit the .cfi_endproc directive.
>
>Same thing with gcm_ghash_avx.
>
>Is this a bug in ghash-x86_64.pl, or am I misinterpreting?
>
>I've just started looking at this, so apologies if it's a known issue
>that's already been fixed in a later release or on the master.
>
>Thanks,
>Michael Wojcik
>Distinguished Engineer, Micro Focus

-- 
Richard by mobile

Re: Cryptography API: Next Generation (CNG) Engine

[Richard Levitte]

I have a branch where I've worked on such a thing.  It's still work in
progress, and I haven't looked at it for a while due to other things
having priority, but I intend to get back to it.

It won't be a straight port, as there are bits in there that are...
ugly, especially the ad-hoc controls to fetch stuff that the ENGINE
API doesn't have specific support for (certs and list of certs and
whatever other stuff I forget).  I'm replacing with support for the
OSSL_STORE API, so those things can be fetched in a better supported
manner.

Cheers,
Richard ( https://github.com/openssl/openssl/pull/3481 )

On Fri, 26 Jul 2019 11:44:01 +0200,
HORIZONT, Armin Stauber wrote:
> 
> 
> Hi,
> 
> is there any plan or any current work to provide an engine for Cryptography 
> API: Next Generation
> (CNG) e.g. by porting the existing capi engine?
> 
> Regards,
> 
> Armin
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 20190726 snapshots

[Richard Levitte]

I did some server maintenance this morning, and that may have interrupted 
today's snapshot production.

I don't intend to fix it. A new snapshot should appear tomorrow.

Cheers
Richard


The Doctor  skrev: (26 juli 2019 12:23:15 CEST)
>What happened?  I do not see any.

-- 
Richard by mobile

Re: Ciphers provided by engine not accessible...?

[Richard Levitte]

On Mon, 22 Jul 2019 21:17:01 +0200,
Blumenthal, Uri - 0553 - MITLL wrote:
> 
> Turned out the failure was my misconfiguration - but the "config"
> man page doesn't seem to describe the *exact* order of the
> statements/sections.

It does, but perhaps not in a way you expected.  Here's a paragraph
from config(5), about the so called default section:

   The first section of a configuration file is special and is referred to
   as the default section. This section is usually unnamed and spans from
   the start of file until the first named section. When a name is being
   looked up it is first looked up in a named section (if any) and then
   the default section.

"start of the file until the first section" is key.  This is found
fairly early in the description.

And then, early in "OPENSSL_LIBRARY CONFIGURATION":

   To enable library configuration the default section needs to contain an
   appropriate line which points to the main configuration section. The
   default name is openssl_conf which is used by the openssl utility.
   Other applications may use an alternative name such as
   myapplication_conf.  All library configuration lines appear in the
   default section at the start of the configuration file.

"the default section" is key.

So the "openssl_conf = openssl_init" line must be early in the config
file.  The order of the different named sections doesn't (or
shouldn't) really matter.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: How to set "e" in RSA structure ?

[Richard Levitte]

RSA_set0_key() is the function you should use.

For more information, do 'man RSA_set0_key', or have a look here:

https://www.openssl.org/docs/man1.1.0/man3/RSA_set0_key.html

Cheers,
Richard

On Wed, 10 Jul 2019 11:51:01 +0200,
Swamy J-S wrote:
> 
> 
> Recently i upgraded openssl from 1.0.2 to 1.1.0. As RSA structure is opaque 
> in new opnessl i made
> some modifications in my code as follows :
> 
> Old Code
> 
> RSA* rsa = EVP_PKEY_get1_RSA(PKey);
> 
> if(NULL != rsa)
> 
> {
> 
> if(!BN_set_word(rsa->e, 65537) || !EVP_PKEY_set1_RSA(PKey, rsa))
> 
> --
> 
> New Code
> 
> RSA* rsa = EVP_PKEY_get1_RSA(PKey);
> 
> BIGNUM *e_new = BN_new();
> 
> if(NULL != rsa)
> 
> {
> 
> if(!BN_set_word(e_new, 65537) || !EVP_PKEY_set1_RSA(PKey, rsa))
> 
> But Now "e" variable is not set in 'rsa', So how to set "e" inside rsa? Pls 
> suggest me
> corresponding API
> 
> Thanks and Regards,
> 
> SWAMY J S
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Information on Build.info

[Richard Levitte]

A very simple answer would be to have 'no-shared' as a configuration option.
That does mean that no shared libraries will be built, and that might not be 
satisfactory.

Any, for the question "what would happen?" is that any program or module that 
get this change will be linked with the static library instead of the shared 
one, unconditionally.

Cheers
Richard


"J. J. Farrell"  skrev: (19 juni 2019 20:11:53 CEST)
>Have you tried it? It's the simplest way to find out what would happen,
>
>though it's a very strange thing to do. It's almost certainly not the 
>best way to do whatever you're trying to do.
>
>If you take a step back and tell us what you are trying to achieve 
>overall you'll be more likely to get useful advice. What do you want to
>
>end up with when you do the build? How is what you want different from 
>what you get when you do a build without any modifications?
>
>On 18/06/2019 08:20, shiva kumar wrote:
>> Hi,
>> Actually I wanted to know how build.info  file in 
>> each directory such as apps, engines etc, will used generate the Make
>
>> file, what would happen If I wanted to change the build.info 
>>  file
>>
>> 1) in openssl/*apps/build.info *
>> what would happen if I change
>> *DEPEND[openssl]=libapps.a ../libssl*
>> to
>> *DEPEND[openssl]=libapps.a ../libssl.a*
>>
>> 2)in openssl/*engines/build.info *
>> what would hapen if I change
>> *  LIBS=../libcrypto*
>>   to
>> *  LIBS=../libcrypto.a*
>> *
>> *
>> *  DEPEND[padlock]=../libcrypto*
>>   to
>> *DEPEND[padlock]=../libcrypto*
>>
>> *DEPEND[capi]=../libcrypto*
>>   to
>> *DEPEND[capi]=../libcrypto.a*
>>
>> *DEPEND[afalg]=../libcrypto*
>>   to
>> *DEPEND[afalg]=../libcrypto*
>>
>> * DEPEND[dasync]=../libcrypto*
>>    to
>> *DEPEND[dasync]=../libcrypto*
>>
>> *DEPEND[ossltest]=../libcrypt*
>>    to
>> *DEPEND[ossltest]=../libcrypt*
>>
>> 3) in *openssl/build.file*
>>     what would happen if I change
>> *DEPEND[libssl]=libcrypto*
>>     to
>> * DEPEND[libssl]=libcrypto.a*
>>
>> please let me know
>>
>> Thanks and Regards
>> Shivakumar

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

Re: building openssl for windows - missing do_win64a from ms directory.

[Richard Levitte]

I'd suggest reading the files called 'README' and 'INSTALL' as a start.

Cheers
Richard


"Lewis, Michael L"  skrev: (11 juni 2019 18:55:48 
CEST)
>Hi,
>
>I'm trying to build OpenSSL for windows (openssl-1.1.1c), I do the
>following steps:
>
>
>1.   cd into open ssl directory.
>
>2.   Run: perl Configure VC-WIN64A, this appears to work fine ...
>
>
>
>C:\develop\ignite\openssl-1.1.1c>perl Configure VC-WIN64A
>
>Configuring OpenSSL version 1.1.1c (0x1010103fL) for VC-WIN64A
>
>Using os-specific seed configuration
>
>Creating configdata.pm
>
>Creating makefile
>
>The issue I have is that I don't see 'do_win64a' within the 'ms'
>directory (I'm following build instructions here:
>http://eran.geek.co.il/wp/archives/3897
>and
>https://wiki.openssl.org/index.php/Compilation_and_Installation#W64)
>
>Anyone have any ideas on what I'm doing wrong? (The output from perl
>configdata.pm -dump is shown below).
>
>Thanks,
>Mike Lewis
>
>
>C:\develop\ignite\openssl-1.1.1c>perl configdata.pm -dump
>
>Command line (with current working directory = .):
>
>C:\Strawberry\perl\bin\perl.exe Configure VC-WIN64A
>
>Perl information:
>
>C:\Strawberry\perl\bin\perl.exe
>5.12.3 for MSWin32-x86-multi-thread
>
>Enabled features:
>
>aria
>asm
>async
>autoalginit
>autoerrinit
>autoload-config
>bf
>blake2
>buildtest-c\+\+
>camellia
>capieng
>cast
>chacha
>cmac
>cms
>comp
>ct
>deprecated
>des
>dgram
>dh
>dsa
>dtls
>dynamic-engine
>ec
>ec2m
>ecdh
>ecdsa
>engine
>err
>filenames
>gost
>hw(-.+)?
>idea
>makedepend
>md4
>mdc2
>multiblock
>nextprotoneg
>pinshared
>ocb
>ocsp
>pic
>poly1305
>posix-io
>psk
>rc2
>rc4
>rdrand
>rfc3779
>rmd160
>scrypt
>seed
>shared
>siphash
>sm2
>sm3
>sm4
>sock
>srp
>srtp
>sse2
>ssl
>static-engine
>stdio
>tests
>threads
>tls
>ts
>ui-console
>whirlpool
>tls1
>tls1-method
>tls1_1
>tls1_1-method
>tls1_2
>tls1_2-method
>tls1_3
>dtls1
>dtls1-method
>dtls1_2
>dtls1_2-method
>
>Disabled features:
>
>afalgeng[not-linux]
>asan[default]   OPENSSL_NO_ASAN
>crypto-mdebug   [default]   OPENSSL_NO_CRYPTO_MDEBUG
> crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>devcryptoeng[default]   OPENSSL_NO_DEVCRYPTOENG
>ec_nistp_64_gcc_128 [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
>egd [default]   OPENSSL_NO_EGD
>external-tests  [default]   OPENSSL_NO_EXTERNAL_TESTS
>fuzz-libfuzzer  [default]   OPENSSL_NO_FUZZ_LIBFUZZER
>fuzz-afl[default]   OPENSSL_NO_FUZZ_AFL
>heartbeats  [default]   OPENSSL_NO_HEARTBEATS
>   md2 [default]   OPENSSL_NO_MD2 (skip crypto\md2)
>msan[default]   OPENSSL_NO_MSAN
>   rc5 [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
>sctp[default]   OPENSSL_NO_SCTP
>ssl-trace   [default]   OPENSSL_NO_SSL_TRACE
>ubsan   [default]   OPENSSL_NO_UBSAN
>unit-test   [default]   OPENSSL_NO_UNIT_TEST
>weak-ssl-ciphers[default]   OPENSSL_NO_WEAK_SSL_CIPHERS
>zlib[default]
>zlib-dynamic[default]
>ssl3[default]   OPENSSL_NO_SSL3
>ssl3-method [default]   OPENSSL_NO_SSL3_METHOD
>
>Config target attributes:
>
>AR => "lib",
>ARFLAGS => "/nologo",
>AS => "nasm",
>ASFLAGS => "-g",
>CC => "cl",
>CFLAGS => "/W3 /wd4090 /nologo /O2",
>CPP => "\$(CC) /EP /C",
>HASHBANGPERL => "/usr/bin/env perl",
>LD => "link",
>LDFLAGS => "/nologo /debug",
>MT => "mt",
>MTFLAGS => "-nologo",
>RANLIB => "CODE(0x253c2ac)",
>RC => "rc",
>aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
>aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
>aesni-mb-x86_64.s",
>aes_obj => "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",
>apps_aux_src => "win32_init.c",
>apps_init_src => "../ms/applink.c",
>apps_obj => "win32_init.o",
>aroutflag => "/out:",
>asflags => "-Ox -f win64 -DNEAR",
>asoutflag => "-o ",
>bf_asm_src => "bf_enc.c",
>bf_obj => "bf_enc.o",
>bin_cflags => "/Zi /Fdapp.pdb",
>bin_lflags => "/subsystem:console /opt:ref",
>bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
>rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
>bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
>rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
>bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
>build_file => "makefile",
>build_scheme => [ "unified",

Re: debugging a make/dependency issue

[Richard Levitte]

The first thing to do is reconfigure, as that will regenerate the
Makefile.

Otherwise, the thing I can think of is if someone mixed up INCLUDE and
SOURCE in a build.info.  The following in crypto/bn/build.info
would probably generate that kind of fault:

SOURCE[../../libcrypto]=../include

The correct line would be:

INCLUDE[../../libcrypto]=../include

(or well, if there's a '../include' somewhere in a SOURCE directive,
it should be removed)

Cheers,
Richard

On Tue, 04 Jun 2019 22:12:09 +0200,
Salz, Rich via openssl-users wrote:
> 
> 
> I am importing some code into openssl and getting a strange build error:
> 
> make[1]: *** No rule to make target 'crypto/bn/crypto/include.o', needed by 
> 'libcrypto.a'.  Stop.
> 
> Any common ideas on what to look for (e.g., missing header file, wrong 
> INCLUDE settings in
> build.info, etc) ?
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Reg missing rc4-ia64.pl in openssl 1.1.1

[Richard Levitte]

On Wed, 29 May 2019 19:39:38 +0200,
ramakrushna mishra wrote:
> In Openssl 1.1.1,  the file "rc4-ia64.pl" is missing. This cause degradation 
> of performance on
> AIX.  Is this intentional for deprecating the support for RC4 ? 

It got remove as part of a larger cleanup commit:

commit 624265c60e07f8e5f251d0f5b79e34cf0221af73
Author: Rich Salz 
Date:   Thu Jun 15 12:03:40 2017 -0400

Cleanup some copyright stuff

Remove some incorrect copyright references.
Move copyright to standard place
Add OpenSSL copyright where missing.
Remove copyrighted file that we don't use any more
Remove Itanium assembler for RC4 and MD5 (assembler versions of old and
weak algorithms for an old chip)
Standardize apps/rehash copyright comment; approved by Timo
Put dual-copyright notice on mkcert

    Reviewed-by: Richard Levitte 
(Merged from https://github.com/openssl/openssl/pull/3691)

> Similarly If I build Openssl 1.1.1 on nt64  with flags 
> "enable-weak-ssl-ciphers" and "
> enable-deprecated"  , I witness degrade in performance.  Could you please 
> help me understand how
> these flags can be related to speed test of all ciphers and digests ? 

Degradation, compared to what?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

[Richard Levitte]

In what way does it link to both?  What output do you get when running
'ldd' in your application?  Is it using some kind of dynamic module
that happens to be linked with an older OpenSSL version?

Cheers,
Richard

On Tue, 28 May 2019 06:59:27 +0200,
Chethan Kumar wrote:
> 
> 
> Dear all,
> 
> Any help for the below query would be appreciated.
> 
> Thanks in advance,
> 
> Chethan Kumar
> 
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Chethan Kumar
> Sent: Wednesday, May 22, 2019 11:35 AM
> To: openssl-users@openssl.org
> Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
> 
> Dear all,
> 
> While migrating from openssl 1.0.2n to openssl 1.1.1b, application which uses 
> openssl was
> compiling against openssl 1.1.1b.
> 
> Compilation is fine but its linking to both libcrypto.so.1.0.0[from 
> /usr/lib/] and
> libcrypto.so.1.1.
> 
> Its linking correctly to libssl.1.1.
> 
> Is this correct? If so, what could be the possible reason.
> 
> Thanks in advance,
> 
> Chethan Kumar
> 
> The information contained in this e-mail message and in any 
> attachments/annexure/appendices is
> confidential to the
> recipient and may contain privileged information. If you are not the intended 
> recipient, please
> notify the
> sender and delete the message along with any attachments/annexure/appendices. 
> You should not
> disclose,
> copy or otherwise use the information contained in the message or any 
> annexure. Any views
> expressed in this e-mail
> are those of the individual sender except where the sender specifically 
> states them to be the
> views of 
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> Although this transmission and any attachments are believed to be free of any 
> virus or other
> defect that might affect any computer system into which it is received and 
> opened, it is the
> responsibility of the recipient to ensure that it is virus free and no 
> responsibility is accepted
> by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way 
> from its use.
> 
> The information contained in this e-mail message and in any 
> attachments/annexure/appendices is
> confidential to the
> recipient and may contain privileged information. If you are not the intended 
> recipient, please
> notify the
> sender and delete the message along with any attachments/annexure/appendices. 
> You should not
> disclose,
> copy or otherwise use the information contained in the message or any 
> annexure. Any views
> expressed in this e-mail
> are those of the individual sender except where the sender specifically 
> states them to be the
> views of 
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> Although this transmission and any attachments are believed to be free of any 
> virus or other
> defect that might affect any computer system into which it is received and 
> opened, it is the
> responsibility of the recipient to ensure that it is virus free and no 
> responsibility is accepted
> by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way 
> from its use.
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: MAKE file not found in openssl 1.1.1b

[Richard Levitte]

On Mon, 27 May 2019 08:54:23 +0200,
shiva kumar wrote:
> In the openssl 1.1.1b make files are missing when compared with the 1.0.2r
> openssl-1.1.1b/Makefile.org (not present)
> openssl-1.1.1b/apps/Makefile (not present) 
> openssl-1.1.1b/engines/Makefile (not present) 
> and may more are not present.
> 
> How can I modify the make file options, in the above mentioned make files in 
> 1.1.1b, which i was
> doing in 1.0.2r ?
> please help me

That is correct, there are no pre-existing Makefiles since 1.1.0.  You
have to run Configure, with the options you desire, to generate one (a
single top Makefile).

Please read INSTALL for more information.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Building 1.1.1a on Windows - how to "make update"?

[Richard Levitte]

The diverse things that 'make update' generates is supposed to be the
same across platforms, so the intention is that they get generated on
one platform (Linux / Unix) and that these changes get distributed to
all others.

Cheers,
Richard

On Fri, 24 May 2019 14:38:14 +0200,
Lynch, Andrew wrote:
> 
> Hi,
> 
> I have been working with OpenSSL 1.1.1a on Linux.  We have a number of 
> patches that are applied, including a specific version of cmpossl.  To ensure 
> that all new error codes, objects etc. are available I run "make update" 
> after config.  I.e. the build process is
> 
> Unpack original distribution openssl-1.1.1a.tar.gz
> Apply list of patches
> ./config
> make update && make && make test
> 
> Some colleagues have asked me for a Windows executable, so I have now 
> installed ActivePerl 5.26.3 and Visual Studio 2019 on my Windows 7 desktop.
> 
> The unmodified openssl-1.1.1a builds and runs just fine using Configure 
> VC-WIN64A-masm.  But with our patches applied the build fails once it gets to 
> crypto/cmp because the include files cmperr.h and crmferr.h do not exist.  On 
> Linux these are created by make update.  The Windows Makefile does not have a 
> target "update" (or "errors" for that matter).
> 
> So what is the equivalent of make update or make errors on Windows?
> 
> I am wondering if I can simply copy the updated files from Linux (new _err.h, 
> modified obj_dat.h and probably a few more) but I would prefer an official 
> way to (re)generate them on Windows.
> 
> Regards,
> Andrew.
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Fw:Re:Re: Building openssl outside of the source tree" doesn't work well

[Richard Levitte]

Well, those -I options are directly generated from 'INCLUDE'
statements in build.info files.

Would you mind giving me the output from this command?

perl configdata.pm --dump

Cheers,
Richard

On Fri, 24 May 2019 04:45:11 +0200,
dengwenbin_0301 wrote:
> 
> 
> I tried on openssl-1.1.1a and openssl-1.1.1b and they all have the same 
> issue. I think it has
> something to do with my env. But i am not able to figure out what is the 
> cause.
> 
> Thanks,
> Wenbin
> 
>  Forwarding messages 
> From: "dengwenbin_0301" 
> Date: 2019-05-22 09:40:19
> To: "Richard Levitte" 
> Subject: Re:Re: Building openssl outside of the source tree" doesn't work well
> Thanks for your reply, Richard.
> 
> Yes,  the "-Iinclude -Iapps/include" is missing. I don't know why this 
> happened. I attached the
> the configdata.pm and its dump. Please help have a check.
> 
> wdeng@pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ git log -n 1
> commit d3136af3c3905a730bd8fb44158aab36a2549d9b
> Author: Richard Levitte 
> Date:   Sat May 18 16:24:21 2019 -0700
> 
> Configure: let platform->dsoext() default with platform->shlibextsimple()
>
> We still use '.so' as a last resort...
>    
> Fixes #8950
>
> Reviewed-by: Tim Hudson 
> (Merged from https://github.com/openssl/openssl/pull/8951)
> 
> At 2019-05-21 11:47:14, "Richard Levitte"  wrote:
> >On Tue, 21 May 2019 03:26:41 +0200,
> >dengwenbin_0301 wrote:
> >> 
> >> wdeng@pek-dliu4-u1:~/wenbindfiles/openssl/openssl [master]$ cd obj/
> >> 
> >> wdeng@pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ ../config
> >> Operating system: x86_64-whatever-linux2
> >> Configuring OpenSSL version 3.0.0-dev for target linux-x86_64
> >> Using os-specific seed configuration
> >> Creating configdata.pm
> >> Creating Makefile
> >> 
> >> **
> >> ******
> >> ***   OpenSSL has been successfully configured ***
> >> ******
> >> ***   If you encounter a problem while building, please open an***
> >> ***   issue on GitHub <https://github.com/openssl/openssl/issues> ; ***
> >> ***   and include the output from the following command:   ***
> >> ******
> >> ***   perl configdata.pm --dump***
> >> ******
> >> ***   (If you are new to OpenSSL, you might want to consult the***
> >> ***   'Troubleshooting' section in the INSTALL file first) ***
> >> ******
> >> **
> >> wdeng:~/wenbindfiles/openssl/openssl/obj [master]$ make
> >> make depend && make _all
> >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
> >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
> >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
> >> gcc   -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 
> >> -DOPENSSL_USE_NODELETE -DL_ENDIAN
> >> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 
> >> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> >> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
> >> -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM
> >> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
> >> -DX25519_ASM -DPOLY1305_ASM
> >> -DOPENSSLDIR="\"/usr/local/ssl\"" 
> >> -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr
> >> /local/lib/ossl-modules\"" -DNDEBUG  -MMD -MF 
> >> apps/libapps-lib-app_rand.d.tmp -MT apps/
> >> libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c
> >> ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory
> >> compilation terminated.
> >> Makefile:826: recipe for target 'apps/libapps-lib-app_rand.o' failed
> >> make[1]: *** [apps/libapps-lib-app_rand.o] Error 1
> >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/

Re: Compiling openssl executable as static binary

[Richard Levitte]

How static do you want it to be?  There is the configuration option
'-static' that makes the binary as independent as possible, i.e. even
links it with static libc.

Cheers,
Richard

On Thu, 23 May 2019 08:26:43 +0200,
Raveendra Padasalagi via openssl-users wrote:
> 
> 
> Hi,
> 
>  
> 
> Any help/pointers on compiling openssl library to generate static version of 
> openssl executable
> for ARM64 bit linux platform will help.
> 
>  
> 
> Thanks,
> 
> Raveendra
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: why does RAND_add() take "randomness" as a "double"?

[Richard Levitte]

"Salz, Rich via openssl-users"  skrev: (21 maj 2019 
17:27:44 CEST)
>>If it's a sarcasm, I'm missing the point.
>  
>I was't being sarcastic, I was trying to show that the team, recently,
>still liked the use of floating point.
>
>>There are use cases when one wants to mix/add extra randomness
>from, e.g., an external source (that, for whatever reasons, is trusted
>more than what's provided by the system).
> 
>Then just set it to 1.0 and be done with it.

That hardly helps on systems that don't have floating point at all. 

Cheers 
Richard 
>
>
>

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

Re: Building openssl outside of the source tree" doesn't work well

[Richard Levitte]

On Tue, 21 May 2019 03:26:41 +0200,
dengwenbin_0301 wrote:
> 
> wdeng@pek-dliu4-u1:~/wenbindfiles/openssl/openssl [master]$ cd obj/
> 
> wdeng@pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ ../config
> Operating system: x86_64-whatever-linux2
> Configuring OpenSSL version 3.0.0-dev for target linux-x86_64
> Using os-specific seed configuration
> Creating configdata.pm
> Creating Makefile
> 
> **
> ******
> ***   OpenSSL has been successfully configured ***
> ******
> ***   If you encounter a problem while building, please open an***
> ***   issue on GitHub <https://github.com/openssl/openssl/issues> ; ***
> ***   and include the output from the following command:   ***
> ******
> ***   perl configdata.pm --dump***
> ******
> ***   (If you are new to OpenSSL, you might want to consult the***
> ***   'Troubleshooting' section in the INSTALL file first) ***
> ******
> **
> wdeng:~/wenbindfiles/openssl/openssl/obj [master]$ make
> make depend && make _all
> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
> gcc   -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE 
> -DL_ENDIAN
> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
> -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM 
> -DRC4_ASM -DMD5_ASM
> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM 
> -DPOLY1305_ASM
> -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" 
> -DMODULESDIR="\"/usr
> /local/lib/ossl-modules\"" -DNDEBUG  -MMD -MF apps/libapps-lib-app_rand.d.tmp 
> -MT apps/
> libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c
> ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory
> compilation terminated.
> Makefile:826: recipe for target 'apps/libapps-lib-app_rand.o' failed
> make[1]: *** [apps/libapps-lib-app_rand.o] Error 1
> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
> Makefile:165: recipe for target 'all' failed
> make: *** [all] Error 2

I tried exactly that just now, exactly same 'obj' ubdirectory, and it
works with no problem.

Something I'm noticing from your command line is that all -I options
that I expect to see there are gone.  This is what I expect (note that
I go directly at the object file for demonstration purposes):

: ; make apps/libapps-lib-app_rand.o 
gcc  -I. -Iinclude -Iapps/include -I.. -I../include
-I../apps/include  -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3
-DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC
-DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
-DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/lib/engines-3\""
-DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG  -MMD -MF
    apps/libapps-lib-app_rand.d.tmp -MT apps/libapps-lib-app_rand.o -c
-o apps/libapps-lib-app_rand.o ../apps/app_rand.c

So the question is what happened to '-I. -Iinclude -Iapps/include
-I.. -I../include -I../apps/include' in your build.

I cannot say right now, but it might help if you show the output from
'./configdata.pm --dump'

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Building OpenSSL with Emscripten

[Richard Levitte]

The issue isn't with any defined or not so defined macro, but most
probably rather with how you're loading the library in the 3rd party
code base.  Could it be that you're linking with libssl only?

Cheers,
Richard

On Fri, 10 May 2019 22:29:36 +0200,
Sunghyun Park wrote:
> 
> Hi, all. Thanks for your help, I could finish compilation to the end. 
> However, athough I successfully compiled with _no-asm_ options, I found a 
> problem when loading the
> compiled library in the 3rd party code base.
> When looking into the source code, the definition of some function seems to 
> require a specific
> preprocessor to be compiled. 
> (For example, PEM_write_bio_DSAPrivateKey needs '#define OPENSSL_FIPS'.)
> I installed openssl-1.0.2r.tar.gz and only provided no-asm for configuration.
> Am I missing some dependencies or necessary options?
> The error I'm facing is as follows:
> 
> error: undefined symbol: AES_ctr128_encrypt
> warning: To disable errors for undefined symbols use `-s 
> ERROR_ON_UNDEFINED_SYMBOLS=0`
> error: undefined symbol: AES_set_encrypt_key
> error: undefined symbol: BIO_ctrl
> error: undefined symbol: BIO_free
> error: undefined symbol: BIO_new
> error: undefined symbol: BIO_s_mem
> error: undefined symbol: BN_bn2bin
> error: undefined symbol: BN_free
> error: undefined symbol: BN_is_bit_set
> error: undefined symbol: BN_new
> error: undefined symbol: BN_num_bits
> error: undefined symbol: BN_set_word
> error: undefined symbol: CRYPTO_free
> error: undefined symbol: CRYPTO_malloc
> error: undefined symbol: DSA_free
> error: undefined symbol: DSA_generate_key
> error: undefined symbol: DSA_generate_parameters_ex
> error: undefined symbol: DSA_new
> error: undefined symbol: EC_KEY_free
> error: undefined symbol: EC_KEY_generate_key
> error: undefined symbol: EC_KEY_get0_group
> error: undefined symbol: EC_KEY_get0_public_key
> error: undefined symbol: EC_KEY_new_by_curve_name
> error: undefined symbol: EC_KEY_set_asn1_flag
> error: undefined symbol: EC_POINT_point2oct
> 
> 
> 
> Any advice would be a great help!
> Thank you.
> 
> On Thu, May 9, 2019 at 10:43 PM Dr Paul Dale  wrote:
> 
> Configure with the _no-asm_ option.
>
> It will be a **lot** slower.
> 
> Pauli
> -- 
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> On 10 May 2019, at 3:33 pm, Sunghyun Park  wrote:
>
> Nice to meet you all :)
>
> I faced a problem while building assembly code in OpenSSL (e.g., 
> crypto/x86_64cpuid.s)
> with Emscripten. 
> Since Emscripten does not support compilation for assembly code (As 
> far as I know), I'm
> wondering if there is any version of OpenSSL that does not require 
> compiling assembly
> code.
> Or, if there is anyone who experienced the similar problem, please 
> share your experience. 
>
> Thank you!
>
> --
> Best, Sung
> 
> --
> Best, Sung
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Fwd: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

[Richard Levitte]

And now, to openssl-users. Oops... 


 Originalmeddelande 
Från: Richard Levitte 
Skickat: 16 maj 2019 08:34:06 GMT-07:00
Till: John Unsworth 
Ämne: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

The actual problem is the call of DEFINE macros in safestack.h. They should not 
be there.

The only reason those lines haven't been removed us that we fear someone might 
have use of them. I plan to submit a PR for 3.0 that does remove those lines.

Cheers
Richard 

John Unsworth  skrev: (16 maj 2019 03:46:49 
GMT-07:00)
>In the absence of any steer from openssl gurus we will proceed by
>removing the #pragmas in safestack.h and lhash.h while we build the
>no-shared libraries on solaris. Hopefully someone will come up with a
>proper fix at some point.
>
>Regards,
>John
>
>From: openssl-users  On Behalf Of
>John Unsworth
>Sent: 15 May 2019 21:08
>To: openssl-users@openssl.org
>Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible
>fix
>
>>> Issue #pragma weak for a symbol only in the files that define that
>symbol, not in the ones that merely reference it.
>The problem is that those pragmas are in .h files. They contain inline
>functions that use those symbols. The pragmas were added because of
>problems with apps that used the .h files (hard to avoid since they are
>basic crypto header files) but did not link with libcrypto.so. That
>library was explicitly loaded by the app, but the app would not start
>because of the missing symbols.
>
>See issues 6912 and 8102.
>
>Regards,
>John.
>
>-Original Message-
>From: openssl-users  On Behalf Of
>Jakob Bohm via openssl-users
>Sent: 15 May 2019 16:11
>To: openssl-users@openssl.org
>Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and
>possible fix
>
>Alternative suggestion (from my understanding of the documentation
>quoted
>below):
>
>Issue #pragma weak for a symbol only in the files that define that
>symbol, not in the ones that merely reference it.
>
>The hoped effect would be:
>
>1. Object files that merely reference a symbol will contain regular
>UNDEF
>   entries
>2. Object files that do define such a symbol will contain a WEAK
>defined
>   entry
>3. When seeing the UNDEF entries, the linker will look for an actual
>   definition
>4. If finding multiple WEAK defined entries, the linker will not
>complain,
>   just use the first found.
>
>I suspect the specified linker semantics of not trying to satisfy "WEAK
>UNDEF" entries would be suitable for optional link-time selected
>callbacks or data where a referencing library do runtime tests to see
>if the library- using program has provided a definition or not.  For
>example, it could be used for a symbol holding a list of global C++
>constructors/destructors with libc code invoking that list if present
>without requiring dummy lists in programs without.
>
>The .so case mentioned probably works "by chance" because libssl.so
>references non-weak libcrypto.so symbols, forcing the definition to be
>included in the runtime process anyway.
>
>On 14/05/2019 11:29, John Unsworth wrote:
>> Because of the #pragma weak directive the functions are defined
>multiple times in both libcrypto.a and libssl.a:
>>
>> libcrypto.a
>>
>> Many UNDEF:
>> ct_log.o
>> [47]|   0|   0|FUNC |WEAK |0   
>|UNDEF  |OPENSSL_sk_new_null
>> ... and more
>>
>> One definition from stack.c as you'd expect:
>> stack.o
>> [33]  |1232|  20|FUNC |WEAK |2|2 
>|OPENSSL_sk_new_null
>>
>> libssl.a has multiple instances also, all UNDEF:
>> d1_srtp.o
>> [43]  |   0|   0|FUNC |WEAK |0   
>|UNDEF  |OPENSSL_sk_new_null
>> s3_lib.o
>> [107] |   0|   0|FUNC |WEAK |0   
>|UNDEF  |OPENSSL_sk_new_null
>> and so on.
>>
>>  From the linker docs:
>> B.2.17.1 #pragma weak name
>> In the form #pragma weak name, the directive makes name a weak
>symbol. The linker will not complain if it does not find a symbol
>definition for name. It also does not complain about multiple weak
>definitions of the symbol. The linker simply takes the first one it
>encounters.
>>
>> So when linking with libcrypto.a and libssl.a the first definition is
>taken which is UNDEF in both cases leading to the error.
>> This can be fixed in libcrypto.a by making stack.o, lh_stats.o and
>lhash.o the first files included. It could also be fixed by not
>defining those pragmas when compiling stack.c, lh_stats.c and lhash.c
>because they will then be GLOB inst

Re: opensslconf.h file not generated

[Richard Levitte]

Well, you do need to actually build it, i.e. run "make"

What I want to do is exactly what you did that got you that error.
What command did you run after configuring?

Cheers,
Richard

On Mon, 13 May 2019 07:19:31 -0700,
Samiya Khanum wrote:
> 
> 
> Hi Richard,
> 
> I have extracted tar file and executed Configure command. Do we need to set 
> anything before
> Configure?
> 
> On Mon 13 May, 2019, 7:33 PM Richard Levitte,  wrote:
> 
> What else did you do other than configuring?
>
> Cheers
> Richard
>
> Samiya Khanum via openssl-users  skrev: (13 
> maj 2019 05:19:18
> GMT-07:00)
> >Hi,
> >
> >Earlier our application used openSSL version 1.0.2n. We want to upgrade
> >to
> >1.1.1b.
> >When I compile openssl, I see "opensslconf.h" not found error.
> >
> >../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal error:
> >openssl/opensslconf.h: No such file or directory
> >
> >With below configure options, opensslconf.h file is not generated. I
> >tried
> >giving --prefix, --openssldir, disable-deprecated options as well.
> >
> >./Configure linux-generic32
> >
> >./Configure \
> >            no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \
> >            -DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6
> >-DOPENSSL_IMPLEMENTS_strncasecmp \
> >            -ffunction-sections -fdata-sections \
> >            shared no-hw no-asm \
> >            -m32 linux-generic32
> >
> >Am I missing any option in Configure. Can someone help me on this.
> >
> >Thanks & Regards,
> >Samiya khanum
>
> --
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: opensslconf.h file not generated

[Richard Levitte]

What else did you do other than configuring?

Cheers
Richard 

Samiya Khanum via openssl-users  skrev: (13 maj 2019 
05:19:18 GMT-07:00)
>Hi,
>
>Earlier our application used openSSL version 1.0.2n. We want to upgrade
>to
>1.1.1b.
>When I compile openssl, I see "opensslconf.h" not found error.
>
>../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal error:
>openssl/opensslconf.h: No such file or directory
>
>With below configure options, opensslconf.h file is not generated. I
>tried
>giving --prefix, --openssldir, disable-deprecated options as well.
>
>./Configure linux-generic32
>
>./Configure \
>no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \
>-DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6
>-DOPENSSL_IMPLEMENTS_strncasecmp \
>-ffunction-sections -fdata-sections \
>shared no-hw no-asm \
>-m32 linux-generic32
>
>Am I missing any option in Configure. Can someone help me on this.
>
>Thanks & Regards,
>Samiya khanum

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

Re: Where to copy custom openssl engine library in openssl 1.1.0

[Richard Levitte]

You can ask the openssl app where it goes looking for engines by
default.  Here's what it looks like with the installed openssl on my
machine:

: ; openssl version -e
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"

Note that engines aren't agnostic to the OpenSSL version...

Cheers,
Richard

On Thu, 25 Apr 2019 10:06:53 +0200,
Swamy J-S wrote:
> 
> 
> Am working in Ubuntu 18.04 with openssl 1.1.0g version. I built a custom 
> openssl engine and now i
> want to use this engine instead of default openssl engine.
> 
> My engine library name is libstoreengine.so and i copied this to 
> /usr/lib/x86_64-linux-gnu/
> openssl-1.0.0/engines/ path.
> 
> When i run my application the it says Store Engine not found. There is path 
> issue here, am i
> copying the library in right path? I copied my library in 
> /lib/x86_64-linux-gnu still am getting
> same error.
> 
> Please let me know the right path where i have to copy this engine?
> 
> Thanks and Regards,
> 
> SWAMY J S
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Reg: Building Openssl 1.1.1b for Borland

[Richard Levitte]

On Fri, 26 Apr 2019 07:05:01 +0200,
Ande Vishnuvardhan Reddy wrote:
> We would like to build Openssl 1.1.1b with Borland compiler (bcc32 - 
> Embarcadero C++ 7.40). Seems
> support for Borland is removed from 1.1.x .

It was dropped, that's true.  The main reason was lack of docs (or not
being able to find the docs)

> Could you please help in building Openssl 1.1.1b with Borland?
> Please suggest what are the conf files to be added to generate makefile.

It's not just about the conf file, you most probably need a separate
Makefile template too.  For starters, I assume Borland comes with some
kind of make utility...  or do Borland users use something else?
What's its default Makefile name?

Cheers,
Richard ( slowly working out something that is more flexible )

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel & Sparc)

[Richard Levitte]

Tentative fix: https://github.com/openssl/openssl/pull/8548

On Thu, 21 Mar 2019 07:22:39 +0100,
Richard Levitte wrote:
> 
> Said and done: https://github.com/openssl/openssl/issues/8547
> 
> I would appreciate it if you followed what's happening there and
> helped out getting it right...
> 
> Cheers,
> Richard
> 
> On Thu, 21 Mar 2019 07:09:37 +0100,
> Richard Levitte wrote:
> > 
> > "collect2" indicates that this isn't Solaris ld, but GNU ld in
> > action.  With GNU ld, -Map doesn't do what you think it does
> > (from https://sourceware.org/binutils/docs/ld/Options.html#Options):
> > 
> > -Map=mapfile
> > 
> > Print a link map to the file mapfile. See the description of
> > the -M option, above.
> > 
> > Also, with GNU ld, -M has a different meaning than for Solaris:
> > 
> > -M
> > --print-map
> > 
> > Print a link map to the standard output. A link map provides
> > information about the link, including the following:
> > ...
> > 
> > What you actually want is -Wl,--version-script=
> > 
> > However, it seems like our solaris configs need more than just a small
> > tweak.  The way they're currently written, they assume that the linker
> > is Solaris ld at all times...  I'm told, though, that this is a
> > correct assumption with the default gcc on Solaris, but that doesn't
> > mean a non-default gcc that uses GNU ld instead of Solaris ld is
> > impossible.
> > 
> > I'll raise an issue on this.
> > 
> > Cheers,
> > Richard
> > 
> > On Thu, 21 Mar 2019 06:22:35 +0100,
> > Erik Forsberg wrote:
> > > 
> > > I see this is Solaris 10, dont use that anywhere anymore.
> > > But in Solaris 11, its fine. From ld(1)
> > > 
> > >   -M mapfile
> > > 
> > >   Reads mapfile as a text file of directives to the link-editor. 
> > > This
> > >   option can be specified multiple times. If mapfile is a 
> > > directory,
> > >   then all regular files, as defined by stat(2), within the 
> > > directory
> > >   are processed. See Chapter 10, Mapfiles in the Link-Editor in 
> > > Ora-
> > >   cle Solaris 11.4 Linkers and Libraries Guide. Example mapfiles 
> > > are
> > >   provided in /usr/lib/ld. See also FILES.
> > > 
> > > 
> > > >-- Original Message --
> > > >
> > > >Hi All,
> > > >
> > > >We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails 
> > > >with
> > > >following error:
> > > >
> > > >libcrypto.map: file format not recognized; treating as linker script
> > > >collect2: error: ld returned 1 exit status
> > > >gmake[2]: *** [libcrypto.so] Error 1
> > > >gmake[1]: *** [all] Error 2
> > > >
> > > >$ uname -a
> > > >SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
> > > >sun4v
> > > >
> > > >
> > > >This is happening because of the flags defined in
> > > >Configurations/10-main.conf:
> > > >
> > > > Solaris configurations
> > > >"solaris-common" => {
> > > >inherit_from => [ "BASE_unix" ],
> > > >template => 1,
> > > >lib_cppflags => "-DFILIO_H",
> > > >ex_libs  => add("-lsocket -lnsl -ldl"),
> > > >dso_scheme   => "dlfcn",
> > > >thread_scheme=> "pthreads",
> > > >shared_target=> "self",
> > > >shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
> > > >shared_ldflag=> "-Wl,-Bsymbolic",
> > > >shared_defflag   => "-Wl,-M,",
> > > >shared_sonameflag=> "-Wl,-h,",
> > > >},
> > > >
> > > >After changing the shared_defflag to "-Wl, -Map," it works fine. i.e 
> > > >"-Wl,
> > > >-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
> > > >Couple of queries here:
> > > >1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
> > > >2. Can we modify 'Configurations/10-main.conf' in our local copy of 
> > > >OpenSSL
> > > >which is used internally by our product?Will it cause any licensing
> > > >problem(OpenSSL license and GPL)?
> > > >
> > > >Any help would be greatly appreciated.
> > > >
> > > >Regards,
> > > >Parth
> > > 
> > > 
> > > 
> > -- 
> > Richard Levitte levi...@openssl.org
> > OpenSSL Project http://www.openssl.org/~levitte/
> > 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel & Sparc)

[Richard Levitte]

Said and done: https://github.com/openssl/openssl/issues/8547

I would appreciate it if you followed what's happening there and
helped out getting it right...

Cheers,
Richard

On Thu, 21 Mar 2019 07:09:37 +0100,
Richard Levitte wrote:
> 
> "collect2" indicates that this isn't Solaris ld, but GNU ld in
> action.  With GNU ld, -Map doesn't do what you think it does
> (from https://sourceware.org/binutils/docs/ld/Options.html#Options):
> 
> -Map=mapfile
> 
> Print a link map to the file mapfile. See the description of
> the -M option, above.
> 
> Also, with GNU ld, -M has a different meaning than for Solaris:
> 
> -M
> --print-map
> 
> Print a link map to the standard output. A link map provides
> information about the link, including the following:
> ...
> 
> What you actually want is -Wl,--version-script=
> 
> However, it seems like our solaris configs need more than just a small
> tweak.  The way they're currently written, they assume that the linker
> is Solaris ld at all times...  I'm told, though, that this is a
> correct assumption with the default gcc on Solaris, but that doesn't
> mean a non-default gcc that uses GNU ld instead of Solaris ld is
> impossible.
> 
> I'll raise an issue on this.
> 
> Cheers,
> Richard
> 
> On Thu, 21 Mar 2019 06:22:35 +0100,
> Erik Forsberg wrote:
> > 
> > I see this is Solaris 10, dont use that anywhere anymore.
> > But in Solaris 11, its fine. From ld(1)
> > 
> >   -M mapfile
> > 
> >   Reads mapfile as a text file of directives to the link-editor. 
> > This
> >   option can be specified multiple times. If mapfile is a directory,
> >   then all regular files, as defined by stat(2), within the 
> > directory
> >   are processed. See Chapter 10, Mapfiles in the Link-Editor in Ora-
> >   cle Solaris 11.4 Linkers and Libraries Guide. Example mapfiles are
> >   provided in /usr/lib/ld. See also FILES.
> > 
> > 
> > >-- Original Message --
> > >
> > >Hi All,
> > >
> > >We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails with
> > >following error:
> > >
> > >libcrypto.map: file format not recognized; treating as linker script
> > >collect2: error: ld returned 1 exit status
> > >gmake[2]: *** [libcrypto.so] Error 1
> > >gmake[1]: *** [all] Error 2
> > >
> > >$ uname -a
> > >SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
> > >sun4v
> > >
> > >
> > >This is happening because of the flags defined in
> > >Configurations/10-main.conf:
> > >
> > > Solaris configurations
> > >"solaris-common" => {
> > >inherit_from => [ "BASE_unix" ],
> > >template => 1,
> > >lib_cppflags => "-DFILIO_H",
> > >ex_libs  => add("-lsocket -lnsl -ldl"),
> > >dso_scheme   => "dlfcn",
> > >thread_scheme=> "pthreads",
> > >shared_target=> "self",
> > >shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
> > >shared_ldflag=> "-Wl,-Bsymbolic",
> > >shared_defflag   => "-Wl,-M,",
> > >shared_sonameflag=> "-Wl,-h,",
> > >},
> > >
> > >After changing the shared_defflag to "-Wl, -Map," it works fine. i.e "-Wl,
> > >-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
> > >Couple of queries here:
> > >1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
> > >2. Can we modify 'Configurations/10-main.conf' in our local copy of OpenSSL
> > >which is used internally by our product?Will it cause any licensing
> > >problem(OpenSSL license and GPL)?
> > >
> > >Any help would be greatly appreciated.
> > >
> > >Regards,
> > >Parth
> > 
> > 
> > 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel & Sparc)

[Richard Levitte]

"collect2" indicates that this isn't Solaris ld, but GNU ld in
action.  With GNU ld, -Map doesn't do what you think it does
(from https://sourceware.org/binutils/docs/ld/Options.html#Options):

-Map=mapfile

Print a link map to the file mapfile. See the description of
the -M option, above.

Also, with GNU ld, -M has a different meaning than for Solaris:

-M
--print-map

Print a link map to the standard output. A link map provides
information about the link, including the following:
...

What you actually want is -Wl,--version-script=

However, it seems like our solaris configs need more than just a small
tweak.  The way they're currently written, they assume that the linker
is Solaris ld at all times...  I'm told, though, that this is a
correct assumption with the default gcc on Solaris, but that doesn't
mean a non-default gcc that uses GNU ld instead of Solaris ld is
impossible.

I'll raise an issue on this.

Cheers,
Richard

On Thu, 21 Mar 2019 06:22:35 +0100,
Erik Forsberg wrote:
> 
> I see this is Solaris 10, dont use that anywhere anymore.
> But in Solaris 11, its fine. From ld(1)
> 
>   -M mapfile
> 
>   Reads mapfile as a text file of directives to the link-editor. This
>   option can be specified multiple times. If mapfile is a directory,
>   then all regular files, as defined by stat(2), within the directory
>   are processed. See Chapter 10, Mapfiles in the Link-Editor in Ora-
>   cle Solaris 11.4 Linkers and Libraries Guide. Example mapfiles are
>   provided in /usr/lib/ld. See also FILES.
> 
> 
> >-- Original Message --
> >
> >Hi All,
> >
> >We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails with
> >following error:
> >
> >libcrypto.map: file format not recognized; treating as linker script
> >collect2: error: ld returned 1 exit status
> >gmake[2]: *** [libcrypto.so] Error 1
> >gmake[1]: *** [all] Error 2
> >
> >$ uname -a
> >SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
> >sun4v
> >
> >
> >This is happening because of the flags defined in
> >Configurations/10-main.conf:
> >
> > Solaris configurations
> >"solaris-common" => {
> >inherit_from => [ "BASE_unix" ],
> >template => 1,
> >lib_cppflags => "-DFILIO_H",
> >ex_libs  => add("-lsocket -lnsl -ldl"),
> >dso_scheme   => "dlfcn",
> >thread_scheme=> "pthreads",
> >shared_target=> "self",
> >shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
> >shared_ldflag=> "-Wl,-Bsymbolic",
> >shared_defflag   => "-Wl,-M,",
> >shared_sonameflag=> "-Wl,-h,",
> >},
> >
> >After changing the shared_defflag to "-Wl, -Map," it works fine. i.e "-Wl,
> >-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
> >Couple of queries here:
> >1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
> >2. Can we modify 'Configurations/10-main.conf' in our local copy of OpenSSL
> >which is used internally by our product?Will it cause any licensing
> >problem(OpenSSL license and GPL)?
> >
> >Any help would be greatly appreciated.
> >
> >Regards,
> >Parth
> 
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Developers, a small request

[Richard Levitte]

On Wed, 13 Mar 2019 17:56:16 +0100,
Salz, Rich via openssl-users wrote:
> It would be really good if code being merged to master had --strict-warnings 
> and the mdebug
> backtrace stuff turned on. In the past few days there have been a flurry of 
> checkins that these
> flags would have caught.

Well, we do have CIs to show us already in the PRs...  but sometimes,
we are a bit excited and forget to pause and give them a look before
merging.

That being said, if the corrections come soon after, I don't think
much harm is done.

We do have an internal checker that double checks if we've forgotten
to look after some configuration option, and the same CIs as mentioned
above continually fully rebuilding and testing (including extended
tests) all release branches as well as master.  We have shown many
times that we do react on those fairly quickly.

So yeah, we do need to remember that PRs go through the CIs before
merging.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: build error with openssl-1.1.1b on solaris sparc 32 bit (solaris-sparcv9-gcc)

[Richard Levitte]

You might want to show the whole command line that caused this error,
and it would help if we could have a look at the libcrypto.map you
got.

To be more effective, it might be a good idea to create an issue for
this on github:  https://github.com/openssl/openssl/issues/new/choose

Cheers,
Richard

On Wed, 13 Mar 2019 11:13:14 +0100,
Parth Patel wrote:
> 
> 
> Hi,
> 
>  Trying to build openssl-1.1.1b on solaris sparc 32 bit machine.
>   Getting some error with respect to "file format not recognized"
> 
>  -lsocket -lnsl -ldl -pthread
> /v/toolchain/SunOS-5.10-sparc/binutils-2.30/bin/gld:libcrypto.map: file 
> format not recognized;
> treating as linker script
> /v/toolchain/SunOS-5.10-sparc/binutils-2.30/bin/gld:libcrypto.map:1: syntax 
> error
> collect2: error: ld returned 1 exit status
> make[1]: *** [libcrypto.so] Error 1
> make[1]: Leaving directory 
> `/netapp-home/ppatel/lmadmin_parth/3rdparty/openssl/openssl-1.1.1b'
> 
> Can any one help me on this issue ?
> 
> Thanks,
> Parth
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenSSL 1.1.1b version chooses wrong AS(assembler) on Windows

[Richard Levitte]

With the default configuration, I see it using the C compiler...  how
did you configure OpenSSL?

Cheers,
Richard

On Mon, 11 Mar 2019 04:48:16 +0100,
Vinay Kumar via openssl-users wrote:
> 
> 
> Hi All,
> 
> The OpenSSL version 1.1.1b chooses wrong AS(assembler) on running through 
> Cygwin in Windows. It
> chooses 'ml' instead of 'nasm'(but uses the syntax of nasm) which causes 
> OpenSSL build failure on
> Windows. The same works fine with OpenSSL 1.1.0i version.
> Looks like a bug with 1.1.1b version.
> Setting 'AS=nasm' before running the configure script in the Cygwin shell 
> resolves the problem.
> Can someone please confirm if the above workaround is acceptable and can be 
> logged as bug in
> OpenSSL 1.1.1b version?
> 
> Regards,
> Vinay
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Add pkcs11 command

[Richard Levitte]

Not only.

What you need to do on bind is to create a whole OSSL_STORE_LOADER for
pkcs11.  OSSL_STORE_LOADER_set_open only sets the opening functions,
which is expected to take a URI and parse that into something
sensible, and return a context.  There are other functions to set as
well, such as the 'load', 'eof', 'error' and 'close' functions.

The OSSL_STORE_LOADER callback set is designed to work somewhat
vaguely like the stdio API, but instead of handling a set of bytes, it
handles a set of objects, which can be whatever the OSSL_STORE API
knows how to handle.

When you're done building the OSSL_STORE_LOADER (including a scheme
name, that's absolutely important), you hook it into libcrypto with
OSSL_STORE_register_loader(), an voilà, you should be able to do this:

openssl storeutil -engine yourengine \
'pkcs11:token=yourtoken;object=my-certificate;objecttype=cert;id=1234'

(I'm sorry, I don't know the URI scheme enough to say how to specify
that you want to get a list of all accessible certificates or other
objects)

There is the manual OSSL_STORE_LOADER(3) found in 
doc/man3/OSSL_STORE_LOADER.pod,
and the 'file:' scheme loader is in crypto/store/loader_file.c, but
fair warning, that one is a bit more complex than you would probably
expect from the average store loader.

Cheers,
Richard

On Wed, 06 Mar 2019 16:01:05 +0100,
Antonio Iacono wrote:
> 
> OSSL_STORE_LOADER_set_open on bind ?
> 
> On Wed, Mar 6, 2019 at 10:35 AM Richard Levitte  wrote:
> >
> > There is a more generic command to do exactly this sort of thing,
> > 'openssl storeutil', available since OpenSSL 1.1.1.
> >
> > The pkcs11 backend / engine needs to implement the functionality
> > required to hook with the OSSL_STORE functionality for storeutil to be
> > useful.
> >
> > Cheers,
> > Richard
> >
> > On Wed, 06 Mar 2019 09:47:01 +0100,
> > Antonio Iacono wrote:
> > >
> > > There are some good tools for pkcs11, like pkcs11-tool of the OpenSC
> > > project, but often only need the list of key ids to perform signature
> > > operations with the engine.
> > >
> > > I would propose a new pkcs11 command which, for now, only makes the
> > > list of ids and labels of keys present in a token.
> > >
> > > I have already prepared a draft in this branch
> > > https://github.com/opensignature/openssl/tree/add-pkcs11-command/apps
> > >
> > > Thanks,
> > > Antonio
> > >
> > --
> > Richard Levitte levi...@openssl.org
> > OpenSSL Project http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Richard Levitte]

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
> as a follow-up:  Richard's analysis/suspicion was spot on.
> However, it was the *server* side certificate that was causing the
> error, and the server certificate does indeed contain a poorly
> formatted date:
> 
> $ openssl asn1parse -in server.crt | grep UTC
>   157:d=3  hl=2 l=  13 prim: UTCTIME   :091022132829Z
>   172:d=3  hl=2 l=  17 prim: UTCTIME   :370308132808+

I'm glad I could help find the answer.

> OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Add pkcs11 command

[Richard Levitte]

There is a more generic command to do exactly this sort of thing,
'openssl storeutil', available since OpenSSL 1.1.1.

The pkcs11 backend / engine needs to implement the functionality
required to hook with the OSSL_STORE functionality for storeutil to be
useful.

Cheers,
Richard

On Wed, 06 Mar 2019 09:47:01 +0100,
Antonio Iacono wrote:
> 
> There are some good tools for pkcs11, like pkcs11-tool of the OpenSC
> project, but often only need the list of key ids to perform signature
> operations with the engine.
> 
> I would propose a new pkcs11 command which, for now, only makes the
> list of ids and labels of keys present in a token.
> 
> I have already prepared a draft in this branch
> https://github.com/opensignature/openssl/tree/add-pkcs11-command/apps
> 
> Thanks,
> Antonio
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Shouldn't no-pinshared be the default?

[Richard Levitte]

Tomas Mraz  skrev: (5 mars 2019 14:47:18 CET)
>On Tue, 2019-03-05 at 14:16 +0100, Yann Ylavic wrote:
>> On Tue, Mar 5, 2019 at 12:51 PM Matt Caswell 
>> wrote:
>> > 
>> > 2) The no-pinshared option does not appear in 1.1.1 or 1.1.1a. It
>> > first appears
>> > in 1.1.1b. Backporting the option was considered ok. But changing
>> > the default
>> > mid-series is probably not a good idea.
>> > 
>> > Changing the default could be considered for 3.0.
>> 
>> Yes please, as it stands the 1.1 series is unloadable on the most
>> used
>> openssl libraries, distros'. I find this a bit unfortunate, and more
>> #ifdef-ery to come (though I'd like the OPENSSL_INIT_[NO_]UNLOAD one
>> :) ).
>
>But is it in reality at all possible to explicitly unload OpenSSL?
>You're talking here about mod_ssl but what if the OpenSSL is loaded not
>just by mod_ssl but by other shared library loaded into the httpd
>process - for example libkrb5 or libldap. Then you can see what
>disaster can happen if mod_ssl on unload explicitly calls
>OpenSSL_cleanup().
>
>The explicit cleanup is thus simply a no-go in distro-wide use of
>OpenSSL.

It sounds like an allocatable library context that could be used to store all 
the "global" stuff would be a good thing. 
Incidently, we've introduced that concept for 3.0.0. Exactly what will end up 
in it is not decided, apart from the new provider related stuff. 

Cheers 
Richard 

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

Re: OpenSSL 3.0 (or 4.0) API goals

[Richard Levitte]

Matt Caswell  skrev: (4 mars 2019 12:59:26 CET)
>
>
>On 01/03/2019 22:26, Paul Smith wrote:
>> Hi all.
>> 
>> I'm reading with interest the details coming out with respect to the
>> next release of OpenSSL.
>> 
>> I'm curious if there's any consideration being given to updating the
>> API for existing interfaces, and/or checking the APIs of any new
>> interfaces for issues that are seen in the current API.
>> 
>> I'm talking about things like:
>> 
>>  * Const-correctness for arguments
>
>const correctness is an ongoing thing. I'd welcome PRs that address
>this.

Incidentally, I looked at clang-tidy today. It seems to have some helpful 
options for this kind of work. 

>
>>  * Signed vs. unsigned values for integer values
>
>We did do quite a bit of work internally in libssl to implement more
>consistent
>use of size_t where appropriate. We need to do something similar in
>libcrypto
>although that's probably a much bigger job. Dealing with things
>internally is
>much easier than changing the API - because that is obviously a
>breaking change
>which we try to avoid where possible.
>
>>  * Avoiding non-portable types in the API (the most obvious example:
>>using "int" as the type for socket descriptors, which is only
>>portable to Windows due to an implementation detail).
>
>I would hope that we're not introducing any new instances of this. Any
>that we
>have are likely to be historical. Removing such instances would be a
>matter of
>deprecating the relevant APIs and making sure they have suitable
>portable
>replacements in place.
>
>>  * Possibly using something like uint8_t* for pointers to buffers
>>containing binary "stuff" (this could be more annoying than
>helpful,
>>requiring a lot of casting, so I'm not sure about that).
>> 
>> Just wondering... seems like a good time to think about cleanups like
>> that, if feasible.
>> 
>
>
>
>On 02/03/2019 09:18, Angus Robertson - Magenta Systems Ltd wrote:
>> Also replacing all C macros such as those for SSL_CTX_ctrl with
>proper
>> external functions.
>>
>> This will ease use of OpenSSL with languages other than C, where we
>> currently have to code functions to replace the macros.
>>
>> Google did this when creating BoringSSL, there may be other similar
>> 'improvements' that could help OpenSSL.
>
>I'd be in favour of that for SSL_ctrl/SSL_CTX_ctrl where I don't think
>the
>"ctrl" pattern adds much value. All SSL_METHOD implementations share
>the same
>ctrl implementation, with the exception of DTLS which adds a few extra
>ctrls.
>
>For other areas that may not be the case. For example with BIO_ctrl all
>the
>different BIO_METHODs all have quite separate ctrl implementations so
>there
>seems a bigger benefit to this pattern there.
>
>
>Matt

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Richard Levitte]

On Mon, 04 Mar 2019 10:06:54 +0100,
Jan Just Keijser wrote:
...
> Having said that, I just created a certificate set to expire on Mar 9 2037 
> and it passed the
> following command:
>   c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in 
> mycert.crt
> 
> can you run the same command on the failing certificate?

That's a poor test.  'openssl x509' doesn't verify the certificate,
and the error comes up during verification.  To verify, use 'openssl
verify'.  Here's an example with OpenSSL test files:

openssl verify -trusted test/certs/root-cert.pem test/certs/ca-cert.pem 

So in Wolfgang's case, I suspect something like this would say more:

openssl verify -trusted .....ca.crt .user.crt

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Richard Levitte]

tomer provided us with a „…..ca.crt“ file, a „….user.crt“ file and a 
> „user.key“ file. But I
> fear it is not smart to post those files in the internet ;-).
> 
> Best regards
> 
> Wolfgang
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: 1.1.1: patches to compile on OpenBSD

[Richard Levitte]

So if I'm reading the patches correctly,
patch-Configurations_unix-Makefile_tmpl is all about that "e" stuff,
while the others are the more central things.

To my judgement, the "e" stuff is a vendor specific packaging problem,
i.e. not our table, while the other two are interesting.

Cheers,
Richard

On Sun, 03 Mar 2019 16:11:12 +0100,
Claus Assmann wrote:
> 
> There are some patches for OpenSSL 1.1.1X in the OpenBSD ports tree.
> Are there any plans to put (parts of) them into the next OpenSSL
> version?
> 
> patch-Configurations_10-main_conf
> patch-Configurations_shared-info_pl
> patch-Configurations_unix-Makefile_tmpl
> 
> The changes in the last one which add an "e" to various names aren't
> needed, but the rest is (AFAICT).
> $OpenBSD: patch-Configurations_10-main_conf,v 1.1 2019/01/31 22:04:40 sthen 
> Exp $
> 
> Index: Configurations/10-main.conf
> --- Configurations/10-main.conf.orig
> +++ Configurations/10-main.conf
> @@ -953,6 +953,7 @@ my %targets = (
>  },
>  "BSD-x86-elf" => {
>  inherit_from => [ "BSD-x86" ],
> +shared_target=> "bsd-gcc-shared",
>  perlasm_scheme   => "elf",
>  },
>  
> $OpenBSD: patch-Configurations_shared-info_pl,v 1.1 2019/01/31 22:04:40 sthen 
> Exp $
> 
> Also match lld's "compatible with GNU linkers".
> 
> Probably not really used at current (1.1.1a) as $config{CC} isn't even
> set up when this is called...
> 
> Index: Configurations/shared-info.pl
> --- Configurations/shared-info.pl.orig
> +++ Configurations/shared-info.pl
> @@ -12,9 +12,9 @@
>  # environments on Windows.
>  
>  sub detect_gnu_ld {
>  my @lines =
>  `$config{CROSS_COMPILE}$config{CC} -Wl,-V /dev/null 2>&1`;
> -return grep /^GNU ld/, @lines;
> +return grep /^GNU ld|GNU linker/, @lines;
>  }
>  sub detect_gnu_cc {
>  my @lines =
> $OpenBSD: patch-Configurations_unix-Makefile_tmpl,v 1.3 2018/11/20 22:19:57 
> sthen Exp $
> 
> Index: Configurations/unix-Makefile.tmpl
> --- Configurations/unix-Makefile.tmpl.orig
> +++ Configurations/unix-Makefile.tmpl
> @@ -885,7 +885,7 @@ libcrypto.pc:
>   else \
>   echo 'libdir=$(libdir)'; \
>   fi; \
> - echo 'includedir=$${prefix}/include'; \
> + echo 'includedir=$${prefix}/include/eopenssl11'; \
>   echo 'enginesdir=$${libdir}/engines-{- $sover_dirname -}'; \
>   echo ''; \
>   echo 'Name: OpenSSL-libcrypto'; \
> @@ -903,12 +903,12 @@ libssl.pc:
>   else \
>   echo 'libdir=$(libdir)'; \
>   fi; \
> - echo 'includedir=$${prefix}/include'; \
> + echo 'includedir=$${prefix}/include/eopenssl11'; \
>   echo ''; \
>   echo 'Name: OpenSSL-libssl'; \
>   echo 'Description: Secure Sockets Layer and cryptography 
> libraries'; \
>   echo 'Version: '$(VERSION); \
> - echo 'Requires.private: libcrypto'; \
> + echo 'Requires.private: libecrypto'; \
>   echo 'Libs: -L$${libdir} -lssl'; \
>   echo 'Cflags: -I$${includedir}' ) > libssl.pc
>  
> @@ -920,12 +920,12 @@ openssl.pc:
>   else \
>   echo 'libdir=$(libdir)'; \
>   fi; \
> - echo 'includedir=$${prefix}/include'; \
> + echo 'includedir=$${prefix}/include/eopenssl11'; \
>   echo ''; \
>   echo 'Name: OpenSSL'; \
>   echo 'Description: Secure Sockets Layer and cryptography libraries 
> and tools'; \
>   echo 'Version: '$(VERSION); \
> - echo 'Requires: libssl libcrypto' ) > openssl.pc
> + echo 'Requires: libessl libecrypto' ) > openssl.pc
>  
>  configdata.pm: $(SRCDIR)/Configure $(SRCDIR)/config {- join(" ", 
> @{$config{build_file_templates}}, @{$config{build_infos}}, 
> @{$config{conf_files}}) -}
>   @echo "Detected changed: $?"
> @@ -984,7 +984,7 @@ EOF
>if ($args{generator}->[0] =~ /\.pl$/) {
>$generator = 'CC="$(CC)" $(PERL)'.$generator_incs.' 
> '.$generator;
>} elsif ($args{generator}->[0] =~ /\.m4$/) {
> -  $generator = 'm4 -B 8192'.$generator_incs.' '.$generator.' >'
> +  $generator = 'm4'.$generator_incs.' '.$generator.' >'
>} elsif ($args{generator}->[0] =~ /\.S$/) {
>$generator = undef;
>} else {
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/