Re: Linux linking issues moving from 1.0.2t to 1.1.1c
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: debian openssh issue with openssl 1.1.1d
> On Oct 8, 2019, at 6:27 AM, Benjamin Kaduk via openssl-users > wrote: > > The RNG uses sysV shm to convey to other processes that /dev/[u]random has > been > properly seeded, under some configurations/kernel versions. This apprently affects some sandboxed configurations: https://anongit.mindrot.org/openssh.git/commit/?id=3ef92a657444f172b61f92d5da66d94fa8265602 aka https://github.com/openssh/openssh-portable/commit/3ef92a657444f172b61f92d5da66d94fa8265602 -- Viktor.
RE: Linux linking issues moving from 1.0.2t to 1.1.1c
> > > >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
>
Thank you! That seems to have fixed things up nicely, and I no longer need to
link libdl when linking my library.
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.
Re: Blake2b with key
> > Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)? > No, sorry. It has been added for upcoming OpenSSL 3.0, though. Doesn't look like it's there: $ openssl3 version OpenSSL 3.0.0-dev xx XXX (Library: OpenSSL 3.0.0-dev xx XXX ) $ echo -n "hello" | openssl3 dgst -blake2b512 BLAKE2b512(stdin)= e4cfa39a3d37be31c59609e807970799caa68a19bfaa15135f165085e01d41a65ba1e1b146aeb6bd0092b49eac214c103ccfa3a365954bbbe52f74a2b3620c94 $ echo -n "hello" | openssl3 dgst -blake2b512 -mac blake2bmac -macopt key:secret Algorithm blake2bmac not found $ Besides, how does one print a list of supported MAC algorithms? smime.p7s Description: S/MIME cryptographic signature
Re: Blake2b with key
Answered my own questions: $ openssl3 list -mac-algorithms Provided MACs: BLAKE2bMAC @ default BLAKE2sMAC @ default CMAC @ default GMAC @ default HMAC @ default KMAC128 @ default KMAC256 @ default Poly1305 @ default SipHash @ default $ $ echo -n "hello" | openssl3 mac -macopt key:secret blake2bmac 6EDF9AA44DFC7590DE00FCFDBE2F0D917CDEEB170301416929CC625D19D24EDC1040FF760C1F9BB61AD439A0AF5D492FBB01B46ED3FEB4E6076383B7885A9486 $ On 10/8/19, 11:03 AM, "Uri Blumenthal" wrote: > > Is keyed blake2b supported in openssl-dgst (latest OpenSSL release)? > No, sorry. It has been added for upcoming OpenSSL 3.0, though. Doesn't look like it's there: $ openssl3 version OpenSSL 3.0.0-dev xx XXX (Library: OpenSSL 3.0.0-dev xx XXX ) $ echo -n "hello" | openssl3 dgst -blake2b512 BLAKE2b512(stdin)= e4cfa39a3d37be31c59609e807970799caa68a19bfaa15135f165085e01d41a65ba1e1b146aeb6bd0092b49eac214c103ccfa3a365954bbbe52f74a2b3620c94 $ echo -n "hello" | openssl3 dgst -blake2b512 -mac blake2bmac -macopt key:secret Algorithm blake2bmac not found $ Besides, how does one print a list of supported MAC algorithms? smime.p7s Description: S/MIME cryptographic signature
Re: Blake2b with key
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
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/
Blake2b with key
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)? Thanks!
Re: Linux linking issues moving from 1.0.2t to 1.1.1c
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: debian openssh issue with openssl 1.1.1d
On Tue, Oct 08, 2019 at 05:23:56AM -0400, Michael Richardson wrote: > Salvatore Bonaccorso wrote: > > > - > > Debian Security Advisory DSA-4539-2 > secur...@debian.org > > https://www.debian.org/security/ Salvatore > Bonaccorso > > October 07, 2019 > https://www.debian.org/security/faq > > > - > > > Package: openssh > > Debian Bug : 941663 > > > A change introduced in openssl 1.1.1d (which got released as DSA 4539-1) > > requires sandboxing features which are not available in Linux kernels > > before 3.19, resulting in OpenSSH rejecting connection attempts if > > I've gone through the changelog for 1.1.1d, but I can't figure out what > 1.1.1d would have changed that would have caused this. The RNG uses sysV shm to convey to other processes that /dev/[u]random has been properly seeded, under some configurations/kernel versions. -Ben
debian openssh issue with openssl 1.1.1d
Salvatore Bonaccorso wrote: > - > Debian Security Advisory DSA-4539-2 secur...@debian.org > https://www.debian.org/security/ Salvatore Bonaccorso > October 07, 2019 https://www.debian.org/security/faq > - > Package: openssh > Debian Bug : 941663 > A change introduced in openssl 1.1.1d (which got released as DSA 4539-1) > requires sandboxing features which are not available in Linux kernels > before 3.19, resulting in OpenSSH rejecting connection attempts if I've gone through the changelog for 1.1.1d, but I can't figure out what 1.1.1d would have changed that would have caused this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
Re: OPENSSL_config vs OPENSSL_init_crypto
On 08/10/2019 00:20, Samuel Williams wrote: > Hello, > > I am trying to understand what is the correct initialization process for > Ruby's > SSL module. It's not my area so any input would be most welcome. > > https://github.com/ruby/openssl/pull/267 Reading that PR it seems your objective is to ensure that the config file is loaded before you do any libssl work. How OpenSSL behaves depends on the version. Note that OpenSSL 1.1.0 is now out of support, and OpenSSL 1.0.2 goes out of support at the end of this year. >From OpenSSL 1.1.0 and onwards OpenSSL auto-initialises so, in most cases, >there is no need to explicitly call initialisation functions such as OPENSSL_init_crypto() or OPENSSL_init_ssl(). The only reason for applications to ever call these functions directly is if you want some non-default initialisation to occur. I notice that Ruby's SSL module is explicitly calling OPENSSL_init_ssl() with 0 and NULL for arguments - which just gives you the default initialisation. There seems little point in this - that will happen automatically the first time you create an SSL_CTX. >From OpenSSL 1.1.1 onwards loading the config file is part of libssl's default initialisation, i.e. as soon as you create an SSL_CTX OPENSSL_init_ssl() is called automatically and the config file is loaded. Therefore there is no need to take any specific action on this version of OpenSSL. In OpenSSL 1.1.0 (which is now out of support), loading the config file was *not* part of the default initialisation. You can force it to be loaded using the OPENSSL_INIT_LOAD_CONFIG option to OPENSSL_init_ssl(): OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL); You *may* choose to do this unconditionally in both 1.1.0 and 1.1.1 if you wish. In 1.1.1 it has no effect because that's the default anyway - but it does no harm. OpenSSL 1.0.2 (out of support from the end of this year) does not automatically initialise/de-initialise and OPENSSL_init_crypto() and OPENSSL_init_ssl() do not even exist. Therefore you have to call initialisation functions explicitly. Calling OPENSSL_config() there would seem reasonable. Hope that helps, Matt
