[openssl-dev] [openssl.org #4699] Bug in OpenSSL 1.0.2j-fips 26 Sep 2016 or maybe affects all

[Richard Levitte via RT]

It affects all 1.0.2 variants. I've a fix on github:
https://github.com/openssl/openssl/pull/1668

Cheers,
Richard

On Thu Oct 06 07:15:52 2016, valen...@astro.rug.nl wrote:
> Hi,
>
> While playing around with prime number generation I noticed that the
> following generates a core dump. I think this is definitely a bug.
>
> How to reproduce:
>
> $ openssl prime ''
> Segmentation fault (core dumped)
>
> I haven't included any strace output but this can be reproduced by you
> as well.
>
>
> Kind regards,


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

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

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

[openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser

[Richard Levitte via RT]

To be noted, there's more in section 2:

   Most extant parsers ignore blanks at the ends of lines; blanks at the
   beginnings of lines or in the middle of the base64-encoded data are
   far less compatible.  These observations are codified in Figure 1.
   The most lax parser implementations are not line-oriented at all and
   will accept any mixture of whitespace outside of the encapsulation
   boundaries (see Figure 2).  Such lax parsing may run the risk of
   accepting text that was not intended to be accepted in the first
   place (e.g., because the text was a snippet or sample).

I haven't looked enough in our code recently to remember if we're doing
"standard" (figure 1) or "strict" (figure 3) parsing... what I hear is a
request for us to move to "lax" (figure 2) parsing.

Cheers,
Richard


On Wed Oct 05 12:02:54 2016, l...@acm.org wrote:
> On 05-Oct-16 07:52, Salz, Rich via RT wrote:
>
> > Well, it is a SHOULD not a MUST. But point taken it could be (much)
> > better :)
> >
> >
> It's an important SHOULD. Whitespace introduction happens in the
> wild.
>
> This is the quote from the OpenXPKI folks:
> > I just saw this today at a customer install that a user uploaded a
> > PCSK10 request with extra newlines, anything based on Crypt::PKCS10
> > is
> > happy with it but openssl crashes when it tries to sign.
>
> See https://github.com/openxpki/openxpki/issues/437


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

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

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

[openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i

[Richard Levitte via RT]

On Mon Sep 26 14:34:17 2016, rs...@akamai.com wrote:
> We have a fix waiting for internal review; see GitHub issue 1546.

That's not related to this issue.

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i

[Richard Levitte via RT]

That has already been fixed in the 1.0.2 branch, and is part of 1.0.2j, which
was released today.

Cheers,
Richard

On Mon Sep 26 14:32:31 2016, jan-markus.pumpa...@bittium.com wrote:
>
>
> Hi,
>
> When building the OpenSSL 1.0.2i with -DHAVE_CRYPTODEV flag the build
> will fail in crypto/engine/eng_cryptodev.c. I am using 64-bit Ubuntu
> 14.04 in my build machine with gcc toolchain.
>
> For me it looks like there has been a typo in the OPENSSL_malloc
> return value check. Attached patch solves the issue. Below is the
> original error message:
>
> | gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
> -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -i/build/tmp/sysroots/x86_64-
> linux/usr/include -O2 -pipe -Wall -Wa,--noexecstack -DHAVE_CRYPTODEV
> -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM
> -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> -ibuild/tmp/sysroots/x86_64-linux/usr/include -c -o eng_cryptodev.o
> eng_cryptodev.c
> | eng_cryptodev.c: In function 'cryptodev_digest_copy':
> | eng_cryptodev.c:942:23: error: 'struct dev_crypto_state' has no
> member named 'ac_data'
> | if (dstate->ac_data == NULL) {
> | ^
> | make[2]: *** [eng_cryptodev.o] Error 1
>
>
> Kind regards,
> Jan-Markus Pumpanen
>
> 
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.


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

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

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

[openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files

[Richard Levitte via RT]

Fix in place in master, OpenSSL_1_1_0-stable and OpenSSL_1_0_2-stable

Closing ticket.

Cheers,
Richard

On Fri Sep 02 14:57:41 2016, rs...@akamai.com wrote:
> Yeah, something like that for 1.0.2; simpler for 1.1.0. I'll do it.
>


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

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

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

[openssl-dev] [openssl.org #4677] Options after parameters are ignored in OpenSSL 1.1.0

[Richard Levitte via RT]

On Sat Sep 17 17:54:11 2016, pe...@lekensteyn.nl wrote:
> Hi,
>
> Commands which execute normally with OpenSSL 1.0.2h fail in OpenSSL
> 1.1.0. Presumably after the "Big apps cleanup (option-parsing, etc)",
>
> Options after parameters are no longer interpreted. For example,
> 'openssl dhparam 128 -out /dev/null' used to discard the DH params
> output, but since 1.0.2 it no longer happens.

You're right. There should at least be a warning

> I also noticed that 'openssl genrsa -help' no longer displays the
> 'numbits' option.

Good point.

I'll have a closer look at this and the other commands in the next few days.

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request

[Richard Levitte via RT]

And finally got committed to master, with all suggested fixups.

Closing this ticket.

Cheers,
Richard

On Wed Sep 14 02:09:15 2016, levitte wrote:
> Issue 2 is implemented in https://github.com/openssl/openssl/pull/1572
>
> Please try it out.
>
> Cheers,
> Richard
>
> On Tue Sep 13 22:32:37 2016, levitte wrote:
> > Issue 1 now resolved, fix pushed to master branch as well as
> > OpenSSL_1_1_0-stable.
> >
> > Issue 2 remaining.
> >
> > Cheers,
> > Richard
> >
> > On Tue Sep 13 20:32:18 2016, levitte wrote:
> > > I can confirm issue one and raise you one: it's not just on Windows
> > >
> > > On it.
> > >
> > > Cheers,
> > > Richard
> > >
> > > On Tue Sep 13 17:23:48 2016, bkhow...@gmail.com wrote:
> > > > This may be two requests, one a bug and one a feature request.
> > > >
> > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5
> > > > passwords
> > > > (-1 / -apr1), returns "". I haven't tested other platforms.
> > > > See
> > > > output below.
> > > >
> > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password
> > > > hashing
> > > > algorithms used by unix / linux platforms. This limitation may
> > > > force
> > > > people to use weaker password storage than possible, for example if
> > > > generating crypts using openssl passwd to feed into usermod -p.
> > > > Please add
> > > > support for password types 5 (SHA-256) and 6 (SHA-512).
> > > >
> > > > http://man7.org/linux/man-pages/man3/crypt.3.html
> > > >
> > > > ID | Method
> > > > ─
> > > > 1 | MD5
> > > > 2a | Blowfish (not in mainline glibc; added in some
> > > > | Linux distributions)
> > > > 5 | SHA-256 (since glibc 2.7)
> > > > 6 | SHA-512 (since glibc 2.7)
> > > >
> > > >
> > > > Issue 1: collateral:
> > > >
> > > > Working in OpenSSL 1.0.2.h:
> > > > D:\>openssl version
> > > > OpenSSL 1.0.2h 3 May 2016
> > > >
> > > > D:\>openssl passwd -apr1 password
> > > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO.
> > > >
> > > > D:\>openssl passwd -1 password
> > > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0
> > > >
> > > > Compiled Openssl 1.1.0:
> > > >
> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> > > > OpenSSL 1.1.0 25 Aug 2016
> > > >
> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> > > > OpenSSL 1.1.0 25 Aug 2016
> > > >
> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password
> > > > UZ8kfkzdGoYTQ
> > > >
> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password
> > > > 
> > > >
> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password
> > > > 
> > > >
> > > > (To show that MD5 wasn't compiled out):
> > > >
> > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help
> > > > Usage: passwd [options]
> > > > Valid options are:
> > > > -help Display this summary
> > > > -in infile Pead passwords from file
> > > > -noverify Never verify when reading password from terminal
> > > > -quiet No warnings
> > > > -table Format output as table
> > > > -reverse Switch table columns
> > > > -salt val Use provided salt
> > > > -stdin Read passwords from stdin
> > > > -apr1 MD5-based password algorithm, Apache variant
> > > > -1 MD5-based password algorithm
> > > > -crypt Standard Unix password algorithm (default)
> > >
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request

[Richard Levitte via RT]

Done!

On Wed Sep 14 03:16:11 2016, bkhow...@gmail.com wrote:
> Richard,
> I had taken a crack at this and got to the point of actually
> needing
> sha2crypt(). I compared your changes to mine, which is all pretty
> predictable so matched line by line. The only exception is 203, which
> is
> because it's entirely redundant as the max_pwlen defaults to 256.
>
> So maybe:
>
> - else if (use1 || useapr1)
> + else if (use1 || useapr1 || use5 || use6)
>
> or
>
> - else if (use1 || useapr1)
> - pw_maxlen = 256; /* arbitrary limit, should be enough
> for
> most
> - * passwords */
>
> Cheers,
> Brian
>
>
> On Tue, Sep 13, 2016 at 10:57 PM, Brian Howson <bkhow...@gmail.com>
> wrote:
>
> > Thanks Richard,
> > Quick work on issue 1, I git cloned & tested it, works as
> > expected.
> > I downloaded the pull above, built it and it appears to work.
> >
> > I found test vectors in the specification document here:
> > https://www.akkadia.org/drepper/sha-crypt.html
> >
> >
> > openssl passwd -5 -salt saltstring "Hello world!" | find
> > "$5$saltstring$5B8vYYiY.CVt1RlTTf8KbXBH3hsxY/GNooZaBBGWEc5"
> >
> > openssl passwd -6 -salt saltstring "Hello world!" | find
> > "$6$saltstring$
> > svn8UoSVapNtMuq1ukKS4tPQd8iKwSMHWjl/O817G3uBnIFNjnQJuesI68u4OTLiBF
> > dcbYEdFCoEOfaS35inz1"
> >
> >
> > So looks good. One suggestion is to re-order the help output so it's
> > in declining "best to worst" 6 -> 5 -> 1 -> apr1 -> des), but that's
> > minor.
> >
> >
> > Cheers,
> > Brian
> >
> > On Tue, Sep 13, 2016 at 10:09 PM, Richard Levitte via RT
> > <r...@openssl.org>
> > wrote:
> >
> >> Issue 2 is implemented in
> >> https://github.com/openssl/openssl/pull/1572
> >>
> >> Please try it out.
> >>
> >> Cheers,
> >> Richard
> >>
> >> On Tue Sep 13 22:32:37 2016, levitte wrote:
> >> > Issue 1 now resolved, fix pushed to master branch as well as
> >> > OpenSSL_1_1_0-stable.
> >> >
> >> > Issue 2 remaining.
> >> >
> >> > Cheers,
> >> > Richard
> >> >
> >> > On Tue Sep 13 20:32:18 2016, levitte wrote:
> >> > > I can confirm issue one and raise you one: it's not just on
> >> > > Windows
> >> > >
> >> > > On it.
> >> > >
> >> > > Cheers,
> >> > > Richard
> >> > >
> >> > > On Tue Sep 13 17:23:48 2016, bkhow...@gmail.com wrote:
> >> > > > This may be two requests, one a bug and one a feature request.
> >> > > >
> >> > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate
> >> > > > MD5
> >> > > > passwords
> >> > > > (-1 / -apr1), returns "". I haven't tested other
> >> > > > platforms.
> >> > > > See
> >> > > > output below.
> >> > > >
> >> > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password
> >> > > > hashing
> >> > > > algorithms used by unix / linux platforms. This limitation may
> >> > > > force
> >> > > > people to use weaker password storage than possible, for
> >> > > > example if
> >> > > > generating crypts using openssl passwd to feed into usermod
> >> > > > -p.
> >> > > > Please add
> >> > > > support for password types 5 (SHA-256) and 6 (SHA-512).
> >> > > >
> >> > > > http://man7.org/linux/man-pages/man3/crypt.3.html
> >> > > >
> >> > > > ID | Method
> >> > > > ─
> >> > > > 1 | MD5
> >> > > > 2a | Blowfish (not in mainline glibc; added in some
> >> > > > | Linux distributions)
> >> > > > 5 | SHA-256 (since glibc 2.7)
> >> > > > 6 | SHA-512 (since glibc 2.7)
> >> > > >
> >> > > >
> >> > > > Issue 1: collateral:
> >> > > >
> >> > > > Working in OpenSSL 1.0.2.h:
> >> > > > D:\>openssl version
> >> > > > OpenSSL 1.0.2h 3 May 2016
> >> > > >
> >> > > > D:\>openssl passwd -apr1 password
> >>

[openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request

[Richard Levitte via RT]

Those test vectors are already in test/recipes/20-test_passwd.t

On Wed Sep 14 02:58:09 2016, bkhow...@gmail.com wrote:
> Thanks Richard,
> Quick work on issue 1, I git cloned & tested it, works as
> expected.
> I downloaded the pull above, built it and it appears to work.
>
> I found test vectors in the specification document here:
> https://www.akkadia.org/drepper/sha-crypt.html
>
>
> openssl passwd -5 -salt saltstring "Hello world!" | find
> "$5$saltstring$5B8vYYiY.CVt1RlTTf8KbXBH3hsxY/GNooZaBBGWEc5"
>
> openssl passwd -6 -salt saltstring "Hello world!" | find
>
"$6$saltstring$svn8UoSVapNtMuq1ukKS4tPQd8iKwSMHWjl/O817G3uBnIFNjnQJuesI68u4OTLiBFdcbYEdFCoEOfaS35inz1"
>
>
> So looks good. One suggestion is to re-order the help output so it's
> in declining "best to worst" 6 -> 5 -> 1 -> apr1 -> des), but that's
> minor.
>
>
> Cheers,
> Brian
>
> On Tue, Sep 13, 2016 at 10:09 PM, Richard Levitte via RT
> <r...@openssl.org>
> wrote:
>
> > Issue 2 is implemented in
> > https://github.com/openssl/openssl/pull/1572
> >
> > Please try it out.
> >
> > Cheers,
> > Richard
> >
> > On Tue Sep 13 22:32:37 2016, levitte wrote:
> > > Issue 1 now resolved, fix pushed to master branch as well as
> > > OpenSSL_1_1_0-stable.
> > >
> > > Issue 2 remaining.
> > >
> > > Cheers,
> > > Richard
> > >
> > > On Tue Sep 13 20:32:18 2016, levitte wrote:
> > > > I can confirm issue one and raise you one: it's not just on
> > > > Windows
> > > >
> > > > On it.
> > > >
> > > > Cheers,
> > > > Richard
> > > >
> > > > On Tue Sep 13 17:23:48 2016, bkhow...@gmail.com wrote:
> > > > > This may be two requests, one a bug and one a feature request.
> > > > >
> > > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate
> > > > > MD5
> > > > > passwords
> > > > > (-1 / -apr1), returns "". I haven't tested other
> > > > > platforms.
> > > > > See
> > > > > output below.
> > > > >
> > > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password
> > > > > hashing
> > > > > algorithms used by unix / linux platforms. This limitation may
> > > > > force
> > > > > people to use weaker password storage than possible, for
> > > > > example if
> > > > > generating crypts using openssl passwd to feed into usermod -p.
> > > > > Please add
> > > > > support for password types 5 (SHA-256) and 6 (SHA-512).
> > > > >
> > > > > http://man7.org/linux/man-pages/man3/crypt.3.html
> > > > >
> > > > > ID | Method
> > > > > ─
> > > > > 1 | MD5
> > > > > 2a | Blowfish (not in mainline glibc; added in some
> > > > > | Linux distributions)
> > > > > 5 | SHA-256 (since glibc 2.7)
> > > > > 6 | SHA-512 (since glibc 2.7)
> > > > >
> > > > >
> > > > > Issue 1: collateral:
> > > > >
> > > > > Working in OpenSSL 1.0.2.h:
> > > > > D:\>openssl version
> > > > > OpenSSL 1.0.2h 3 May 2016
> > > > >
> > > > > D:\>openssl passwd -apr1 password
> > > > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO.
> > > > >
> > > > > D:\>openssl passwd -1 password
> > > > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0
> > > > >
> > > > > Compiled Openssl 1.1.0:
> > > > >
> > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> > > > > OpenSSL 1.1.0 25 Aug 2016
> > > > >
> > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> > > > > OpenSSL 1.1.0 25 Aug 2016
> > > > >
> > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password
> > > > > UZ8kfkzdGoYTQ
> > > > >
> > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password
> > > > > 
> > > > >
> > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password
> > > > > 
> > > > >
> > > > > (To show that MD5 wasn't compiled out):
> > > > >
> > > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help
> > > > > Usage: passwd [options]
> > > > > Valid options are:
> > > > > -help Display this summary
> > > > > -in infile Pead passwords from file
> > > > > -noverify Never verify when reading password from terminal
> > > > > -quiet No warnings
> > > > > -table Format output as table
> > > > > -reverse Switch table columns
> > > > > -salt val Use provided salt
> > > > > -stdin Read passwords from stdin
> > > > > -apr1 MD5-based password algorithm, Apache variant
> > > > > -1 MD5-based password algorithm
> > > > > -crypt Standard Unix password algorithm (default)
> > > >
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > >
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674
> > Please log in as guest with password guest if prompted
> >
> >


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

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

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

[openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request

[Richard Levitte via RT]

Issue 2 is implemented in https://github.com/openssl/openssl/pull/1572

Please try it out.

Cheers,
Richard

On Tue Sep 13 22:32:37 2016, levitte wrote:
> Issue 1 now resolved, fix pushed to master branch as well as
> OpenSSL_1_1_0-stable.
>
> Issue 2 remaining.
>
> Cheers,
> Richard
>
> On Tue Sep 13 20:32:18 2016, levitte wrote:
> > I can confirm issue one and raise you one: it's not just on Windows
> >
> > On it.
> >
> > Cheers,
> > Richard
> >
> > On Tue Sep 13 17:23:48 2016, bkhow...@gmail.com wrote:
> > > This may be two requests, one a bug and one a feature request.
> > >
> > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5
> > > passwords
> > > (-1 / -apr1), returns "". I haven't tested other platforms.
> > > See
> > > output below.
> > >
> > > Issue 2: openssl 1.1.0 passwd doesn't support newer password
> > > hashing
> > > algorithms used by unix / linux platforms. This limitation may
> > > force
> > > people to use weaker password storage than possible, for example if
> > > generating crypts using openssl passwd to feed into usermod -p.
> > > Please add
> > > support for password types 5 (SHA-256) and 6 (SHA-512).
> > >
> > > http://man7.org/linux/man-pages/man3/crypt.3.html
> > >
> > > ID | Method
> > > ─
> > > 1 | MD5
> > > 2a | Blowfish (not in mainline glibc; added in some
> > > | Linux distributions)
> > > 5 | SHA-256 (since glibc 2.7)
> > > 6 | SHA-512 (since glibc 2.7)
> > >
> > >
> > > Issue 1: collateral:
> > >
> > > Working in OpenSSL 1.0.2.h:
> > > D:\>openssl version
> > > OpenSSL 1.0.2h 3 May 2016
> > >
> > > D:\>openssl passwd -apr1 password
> > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO.
> > >
> > > D:\>openssl passwd -1 password
> > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0
> > >
> > > Compiled Openssl 1.1.0:
> > >
> > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> > > OpenSSL 1.1.0 25 Aug 2016
> > >
> > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> > > OpenSSL 1.1.0 25 Aug 2016
> > >
> > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password
> > > UZ8kfkzdGoYTQ
> > >
> > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password
> > > 
> > >
> > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password
> > > 
> > >
> > > (To show that MD5 wasn't compiled out):
> > >
> > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help
> > > Usage: passwd [options]
> > > Valid options are:
> > > -help Display this summary
> > > -in infile Pead passwords from file
> > > -noverify Never verify when reading password from terminal
> > > -quiet No warnings
> > > -table Format output as table
> > > -reverse Switch table columns
> > > -salt val Use provided salt
> > > -stdin Read passwords from stdin
> > > -apr1 MD5-based password algorithm, Apache variant
> > > -1 MD5-based password algorithm
> > > -crypt Standard Unix password algorithm (default)
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request

[Richard Levitte via RT]

Issue 1 now resolved, fix pushed to master branch as well as
OpenSSL_1_1_0-stable.

Issue 2 remaining.

Cheers,
Richard

On Tue Sep 13 20:32:18 2016, levitte wrote:
> I can confirm issue one and raise you one: it's not just on Windows
>
> On it.
>
> Cheers,
> Richard
>
> On Tue Sep 13 17:23:48 2016, bkhow...@gmail.com wrote:
> > This may be two requests, one a bug and one a feature request.
> >
> > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 passwords
> > (-1 / -apr1), returns "". I haven't tested other platforms. See
> > output below.
> >
> > Issue 2: openssl 1.1.0 passwd doesn't support newer password hashing
> > algorithms used by unix / linux platforms. This limitation may force
> > people to use weaker password storage than possible, for example if
> > generating crypts using openssl passwd to feed into usermod -p. Please add
> > support for password types 5 (SHA-256) and 6 (SHA-512).
> >
> > http://man7.org/linux/man-pages/man3/crypt.3.html
> >
> > ID | Method
> > ─
> > 1 | MD5
> > 2a | Blowfish (not in mainline glibc; added in some
> > | Linux distributions)
> > 5 | SHA-256 (since glibc 2.7)
> > 6 | SHA-512 (since glibc 2.7)
> >
> >
> > Issue 1: collateral:
> >
> > Working in OpenSSL 1.0.2.h:
> > D:\>openssl version
> > OpenSSL 1.0.2h 3 May 2016
> >
> > D:\>openssl passwd -apr1 password
> > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO.
> >
> > D:\>openssl passwd -1 password
> > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0
> >
> > Compiled Openssl 1.1.0:
> >
> > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> > OpenSSL 1.1.0 25 Aug 2016
> >
> > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> > OpenSSL 1.1.0 25 Aug 2016
> >
> > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password
> > UZ8kfkzdGoYTQ
> >
> > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password
> > 
> >
> > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password
> > 
> >
> > (To show that MD5 wasn't compiled out):
> >
> > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help
> > Usage: passwd [options]
> > Valid options are:
> > -help Display this summary
> > -in infile Pead passwords from file
> > -noverify Never verify when reading password from terminal
> > -quiet No warnings
> > -table Format output as table
> > -reverse Switch table columns
> > -salt val Use provided salt
> > -stdin Read passwords from stdin
> > -apr1 MD5-based password algorithm, Apache variant
> > -1 MD5-based password algorithm
> > -crypt Standard Unix password algorithm (default)
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request

[Richard Levitte via RT]

A note for the future: since this is really two issues, they should be one
ticket each. I'll let this one slip by, 'cause it's relatively simple to fix
both. However, please understand that while issue 1 will be fixed in OpenSSL
1.1.0a, issue 2 will not appear before OpenSSL 1.1.1.

Cheers,
Richard

On Tue Sep 13 17:23:48 2016, bkhow...@gmail.com wrote:
> This may be two requests, one a bug and one a feature request.
>
> Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 passwords
> (-1 / -apr1), returns "". I haven't tested other platforms. See
> output below.
>
> Issue 2: openssl 1.1.0 passwd doesn't support newer password hashing
> algorithms used by unix / linux platforms. This limitation may force
> people to use weaker password storage than possible, for example if
> generating crypts using openssl passwd to feed into usermod -p. Please add
> support for password types 5 (SHA-256) and 6 (SHA-512).
>
> http://man7.org/linux/man-pages/man3/crypt.3.html
>
> ID | Method
> ─
> 1 | MD5
> 2a | Blowfish (not in mainline glibc; added in some
> | Linux distributions)
> 5 | SHA-256 (since glibc 2.7)
> 6 | SHA-512 (since glibc 2.7)
>
>
> Issue 1: collateral:
>
> Working in OpenSSL 1.0.2.h:
> D:\>openssl version
> OpenSSL 1.0.2h 3 May 2016
>
> D:\>openssl passwd -apr1 password
> $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO.
>
> D:\>openssl passwd -1 password
> $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0
>
> Compiled Openssl 1.1.0:
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> OpenSSL 1.1.0 25 Aug 2016
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> OpenSSL 1.1.0 25 Aug 2016
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password
> UZ8kfkzdGoYTQ
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password
> 
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password
> 
>
> (To show that MD5 wasn't compiled out):
>
> D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help
> Usage: passwd [options]
> Valid options are:
> -help Display this summary
> -in infile Pead passwords from file
> -noverify Never verify when reading password from terminal
> -quiet No warnings
> -table Format output as table
> -reverse Switch table columns
> -salt val Use provided salt
> -stdin Read passwords from stdin
> -apr1 MD5-based password algorithm, Apache variant
> -1 MD5-based password algorithm
> -crypt Standard Unix password algorithm (default)


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

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

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

[openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request

[Richard Levitte via RT]

I can confirm issue one and raise you one: it's not just on Windows

On it.

Cheers,
Richard

On Tue Sep 13 17:23:48 2016, bkhow...@gmail.com wrote:
> This may be two requests, one a bug and one a feature request.
>
> Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 passwords
> (-1 / -apr1), returns "". I haven't tested other platforms. See
> output below.
>
> Issue 2: openssl 1.1.0 passwd doesn't support newer password hashing
> algorithms used by unix / linux platforms. This limitation may force
> people to use weaker password storage than possible, for example if
> generating crypts using openssl passwd to feed into usermod -p. Please add
> support for password types 5 (SHA-256) and 6 (SHA-512).
>
> http://man7.org/linux/man-pages/man3/crypt.3.html
>
> ID | Method
> ─
> 1 | MD5
> 2a | Blowfish (not in mainline glibc; added in some
> | Linux distributions)
> 5 | SHA-256 (since glibc 2.7)
> 6 | SHA-512 (since glibc 2.7)
>
>
> Issue 1: collateral:
>
> Working in OpenSSL 1.0.2.h:
> D:\>openssl version
> OpenSSL 1.0.2h 3 May 2016
>
> D:\>openssl passwd -apr1 password
> $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO.
>
> D:\>openssl passwd -1 password
> $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0
>
> Compiled Openssl 1.1.0:
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> OpenSSL 1.1.0 25 Aug 2016
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl version
> OpenSSL 1.1.0 25 Aug 2016
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password
> UZ8kfkzdGoYTQ
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password
> 
>
> D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password
> 
>
> (To show that MD5 wasn't compiled out):
>
> D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help
> Usage: passwd [options]
> Valid options are:
> -help Display this summary
> -in infile Pead passwords from file
> -noverify Never verify when reading password from terminal
> -quiet No warnings
> -table Format output as table
> -reverse Switch table columns
> -salt val Use provided salt
> -stdin Read passwords from stdin
> -apr1 MD5-based password algorithm, Apache variant
> -1 MD5-based password algorithm
> -crypt Standard Unix password algorithm (default)


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

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

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

[openssl-dev] [openssl.org #4130] Provide enginesdir in pkgconfig file

[Richard Levitte via RT]

Fixed in the 1.1.0 and 1.0.2 branches, as well as master.

Closing ticket. Thank you!

Cheers,
Richard

On Mon Nov 09 08:15:26 2015, dw...@infradead.org wrote:
> External engines such as engine_pkcs11 want to install into
> $ENGINESDIR. Would be nice if we could tell where it is by using
> $(pkg-config --variable=enginesdir openssl)
>
> It's theoretically possible to find it by defining HEADER_CRYPTLIB_H
> and then including opensslconf.h, although that's horrid enough even
> before you consider cross-compilation (i.e. you can't just use printf).
>
> Can we put it in openssl.pc please?
>
> (Of course, something as fundamental as engine_pkcs11 shouldn't be
> external anyway, but that's a different story...)
>


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

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

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

[openssl-dev] [openssl.org #4672] BUG: NEWSLOG - an error occurred while processing this directive

[Richard Levitte via RT]

Thanks for the notification. Problem fixed, will be visible in a couple of
minutes.

Closing ticket

Cheers,
Richard

On Tue Sep 06 06:44:32 2016, tallev...@yahoo.com wrote:
> Hi,
> I've encountered the following error: "an error occurred while
> processing this directive" when
> opening the news log. https://www.openssl.org/news/newslog.html
> Thanks.
> Tal.


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

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

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

[openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles

[Richard Levitte via RT]

On Fri Sep 02 14:37:30 2016, rs...@akamai.com wrote:
> There is a bug. Navigate around and then right-click on the back
> button. All the pages just say openssl.

Errr, yes. That's because all pages include the same header, which has:

OpenSSL

I thought that was by design...

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files

[Richard Levitte via RT]

On Thu Sep 01 13:18:44 2016, stef...@sdaoden.eu wrote:
> Hello.
>
> From the documentation i cannot tell what is wrong with the
> following:
>
> echo abc > a; echo def > b; echo ghi > c
> openssl genpkey -algorithm RSA -out k.prv
> openssl pkey -in k.prv -pubout -out k.pub
> openssl dgst -sha512 -sign k.prv -out .sig a b c
> openssl dgst -sha512 -verify k.pub -signature .sig a b c
> rm k.prv k.pub a b c

The manual for dgst has this little note

The signing and verify options should only be used if a single file is being
signed or verified.
In other words, don't do that.

While I can understand the desire to do multiple files in one swoop, the
signature file (.sig in this case) isn't formatted in any special way, it's
litterally just a stream of bytes. So it does contain all the signatures, but
in an unstructured format. Verification will read that file and use the first n
bytes from it when verifying each file you give it. That's why you get correct
verification on the first file but not the others.

The solution to this is to enhance dgst so it loudly refuses to sign or verify
more than one file.

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

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

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

[openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles

[Richard Levitte via RT]

On Thu Sep 01 13:13:44 2016, stef...@sdaoden.eu wrote:
> Before sending the last message i looked around on the website (it
> has become particularly complicated to find the bug tracker), and
> looking at the "go-back" list i saw dozens of "OpenSSL" entries,
> rather than rt, "Getting started as a contributor", etc.

Not sure what you're on about... I just had a look through the whole set of
files, and there's only one page that has that string. This one:
https://www.openssl.org/community/getting-started.html

As for page titles, all our pages have the title 'OpenSSL'

To sum it up, I don't think we have a problem here. Closing this ticket.

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

[Richard Levitte via RT]

Curious. The diverse flags for the aix config targets' information in 1.1.0 are
exact copies from the 1.0.x series...

The best way you can help out here is to show us the build command lines you
got for building crypto/ppccap.o in both 1.1.0 and 1.0.2, so we can see what
actually differs.

Cheers,
Richard

On Wed Aug 31 16:06:30 2016, tony.r...@atos.net wrote:
> Hi,
>
> I do ports of OpenSSL on AIX 6.1 for one year.
> I had no issue with 1.0.1* and 1.0.2* versions, compiled with XLC.
> With version 1.1.0, I am encountering an issue with -O, both with XLC
> and GCC .
>
> 30-test_evp.t fails because using -O when compiling crypto/ppccap.c
> generates something wrong.
> Compiling only crypto/ppccap.c with -O0 does fix the issue.
> It is the same with XLC.
>
> I have put in place a simple work-around: use -O0 for crypto/ppccap.c
> .
>
> However, do you have an idea about: why crypto/ppccap.c seems
> sensitive to optimization ?
>
> Thanks/Regards,
>
> Tony Reix
> http://www.bullfreeware.com
>
>
>
>


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

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

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

[openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces

[Richard Levitte via RT]

Haven't heard if this worked for you, John... the change has been reviewed and
is now merged into master and the 1.1.0 release branch, so I'll close this
ticket. If you have further problems, please report anew.

Cheers,
Richard

On Tue Aug 30 16:44:08 2016, levitte wrote:
> https://github.com/openssl/openssl/pull/1519
>
> Cheers,
> Richard
>
> On Tue Aug 30 09:35:42 2016, levitte wrote:
> > Good find. I'll fix.
> >
> > Cheers,
> > Richard
> >
> > On Mon Aug 29 22:06:51 2016, jvea...@gmail.com wrote:
> > > I have a Windows machine where Perl is installed in "C:\Program
> > > Files\Perl64\bin\perl.exe".
> > >
> > >
> > >
> > > When executing "perl Configure VC-WIN32", I get the following error
> > >
> > >
> > >
> > > 'C:\Program' is not recognized as an internal or external command,
> > >
> > > operable program or batch file.
> > >
> > >
> > >
> > > I've fixed the problem, by modifying line #2394 in Configure and adding
> > > double quotes around $config{perl}.
> > >
> > >
> > >
> > > my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\"
> > > -o\"Configure\" \"".join("\" \"",@templates)."\" > \"$out.new\"";
> > >
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces

[Richard Levitte via RT]

https://github.com/openssl/openssl/pull/1519

Cheers,
Richard

On Tue Aug 30 09:35:42 2016, levitte wrote:
> Good find. I'll fix.
>
> Cheers,
> Richard
>
> On Mon Aug 29 22:06:51 2016, jvea...@gmail.com wrote:
> > I have a Windows machine where Perl is installed in "C:\Program
> > Files\Perl64\bin\perl.exe".
> >
> >
> >
> > When executing "perl Configure VC-WIN32", I get the following error
> >
> >
> >
> > 'C:\Program' is not recognized as an internal or external command,
> >
> > operable program or batch file.
> >
> >
> >
> > I've fixed the problem, by modifying line #2394 in Configure and adding
> > double quotes around $config{perl}.
> >
> >
> >
> > my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\"
> > -o\"Configure\" \"".join("\" \"",@templates)."\" > \"$out.new\"";
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4665] Bug with OpenSSL 1.1.0 when path to Perl contains spaces

[Richard Levitte via RT]

Good find. I'll fix.

Cheers,
Richard

On Mon Aug 29 22:06:51 2016, jvea...@gmail.com wrote:
> I have a Windows machine where Perl is installed in "C:\Program
> Files\Perl64\bin\perl.exe".
>
>
>
> When executing "perl Configure VC-WIN32", I get the following error
>
>
>
> 'C:\Program' is not recognized as an internal or external command,
>
> operable program or batch file.
>
>
>
> I've fixed the problem, by modifying line #2394 in Configure and adding
> double quotes around $config{perl}.
>
>
>
> my $cmd = "\"$config{perl}\" \"-I.\" \"-Mconfigdata\" \"$dofile\"
> -o\"Configure\" \"".join("\" \"",@templates)."\" > \"$out.new\"";
>


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

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

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

[openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS

[Richard Levitte via RT]

On Mon Aug 29 12:27:59 2016, appro wrote:
> > With the current build system, user-defined CFLAGS are accepted as
> > any
> > unrecognized command line argument passed to Configure. This seems a
> > little dangerous to me since it means a simple typo could end up
> > getting passed to the C compiler.
>
> Is it more dangerous than interactive access? But on serious note I
> don't quite grasp the problem. How do you pass CFLAGS? Or rather how
> is
> it specific to OpenSSL? I mean you either set CFLAGS environment
> variable and call 'make -e' or call 'make CFLAGS=something', right?
> But
> this is the way *make* is. Or is suggestion that we should implement
> own
> internal .ext1.ext2 rules independent on CFLAGS?
>
> > As well, the current build system forcibly enables optimization (-O3)
> > or debug symbols (-g) depending on the build type (--release or
> > --debug).
>
> Could you elaborate on the problem? If you need release build with
> debug
> symbols you can simply add -g when configuring...
>
> > There does not appear to be any method for the user to pass
> > additional
> > LDFLAGS to the build system.
>
> You can pass them as arguments to ./Configure script. It recognizes
> -L,
> -l and -Wl,.
>
> > I would like to propose the following changes:
> >
> > 1. Read CFLAGS and LDFLAGS from the environment within the Configure
> > script.
> > 2. Allow the user to opt-out of the default release or debug cflags,
> > perhaps by adding a third build type (neither release nor debug).
> >
> > These changes would my job as a distro maintainer on Gentoo Linux
> > just
> > a little bit easier.
>
> Or maybe ("maybe" is reference to "I don't quite grasp" above) what we
> are talking about is Configure reading CFLAGS and LDFLAGS and *adding*
> them to generated Makefile. I mean we are not talking about passing
> them
> to 'make', but "freezing" them to their values at configure time.
> Could
> you clarify?

I assume, and please correct me if I'm wrong, that the request is to treat the
environment variables CFLAGS and LDFLAGS the same way we treat CC, i.e. as an
initial value to be used instead of what we get from the configuration target
information.

This should be quite easy to implement, and we can also continue to use
whatever additional Configure arguments as compiler or linker flags to be used
*in addition* to the initial value (that comes from the config target
information, or if we decide to implement it, CFLAGS)

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc

[Richard Levitte via RT]

This has now been merged into the master branch, and will be part of version
1.1.0.

Cheers,
Richard ( closing ticket )

On Wed Aug 24 11:32:54 2016, levitte wrote:
> After much internal deliberation, we ended up checking __GNUC__ rather
> than
> dissing __SUBPRO_C. Our hope is that a compiler that implements GNU
> extensions
> will also define __GNUC__. Our checks of the Intel compiler (which
> someone
> referred to) does so, for example (if I understood correctly).
>
> https://github.com/openssl/openssl/pull/1484
>
> Cheers,
> Richard
>
> On Tue Aug 23 10:48:46 2016, levitte wrote:
> > Ok. I'm going with that solution, then. See attached diff.
> >
> > Cheers,
> > Richard
> >
> > On Wed Aug 17 21:21:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> > > Yes, __SUNPRO_C is defined by DeveloperStudio compiler.
> > >
> > > > To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED
> > > > is
> > > > non-zero
> > >
> > > > isn't the right move here. So it seems that different compilers
> > > > either only
> > > > implement a subset of the __atomic builtins, or name them
> > > > differently.
> > > >
> > > > What was the macro defined by the DeveloperStudio compiler?
> > > > __SUNPRO_C or
> > > > something else? In that case, the correct method might be to
> > > > exclude
> > > > it, like
> > > > this:
> > > >
> > > > #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C)
> > > >
> > > > On Mon Aug 08 08:33:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> > > >> Hello,
> > > >>
> > > >> % ./Configure solaris-x86-cc
> > > >> % make
> > > >> :
> > > >> Undefined first referenced
> > > >> symbol in file
> > > >> __atomic_add_fetch ./libcrypto.so
> > > >> ld: fatal: symbol referencing errors. No output written to
> > > >> fuzz/asn1parse-test
> > > >>
> > > >>
> > > >> % ./Configure solaris64-x86_64-cc
> > > >> % make
> > > >> has the same error.
> > > >>
> > > >> Tested on Solaris10 x86/64, with Solaris developerstudio12.5.
> > > >>
> > > >>
> > > >> This is caused because __ATOMIC_RELAXED is #defined as 0
> > > >> in
> > > >> /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h
> > > >>
> > > >>
> > > >> Sample patch:
> > > >> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c
> > > >> +++ ./crypto/threads_pthread.c
> > > >> @@ -109,7 +109,7 @@
> > > >>
> > > >> int CRYPTO_atomic_add(int *val, int amount, int *ret,
> > > >> CRYPTO_RWLOCK
> > > >> *lock)
> > > >> {
> > > >> -#ifdef __ATOMIC_RELAXED
> > > >> +#if __ATOMIC_RELAXED
> > > >> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED);
> > > >> #else
> > > >> if (!CRYPTO_THREAD_write_lock(lock))
> > > >>
> > > >>
> > > >> With this patch,
> > > >> % ./Configure solaris-x86-cc
> > > >> % make
> > > >> % make test
> > > >> passes.
> > > >>
> > > >> % ./Configure solaris64-x86_64-cc
> > > >> % make
> > > >> passes but
> > > >> % make test
> > > >> stops.
> > > >> This is another problem, which seems to be the same as bug
> > > >> #4641.
> > > >>
> > > >>
> > > >> Regards,
> > > >>
> > > >> --- Kiyoshi 
> > > >
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > >
> > > > --
> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642
> > > > Please log in as guest with password guest if prompted
> > > >
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc

[Richard Levitte via RT]

After much internal deliberation, we ended up checking __GNUC__ rather than
dissing __SUBPRO_C. Our hope is that a compiler that implements GNU extensions
will also define __GNUC__. Our checks of the Intel compiler (which someone
referred to) does so, for example (if I understood correctly).

https://github.com/openssl/openssl/pull/1484

Cheers,
Richard

On Tue Aug 23 10:48:46 2016, levitte wrote:
> Ok. I'm going with that solution, then. See attached diff.
>
> Cheers,
> Richard
>
> On Wed Aug 17 21:21:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> > Yes, __SUNPRO_C is defined by DeveloperStudio compiler.
> >
> > > To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is
> > > non-zero
> >
> > > isn't the right move here. So it seems that different compilers
> > > either only
> > > implement a subset of the __atomic builtins, or name them
> > > differently.
> > >
> > > What was the macro defined by the DeveloperStudio compiler?
> > > __SUNPRO_C or
> > > something else? In that case, the correct method might be to exclude
> > > it, like
> > > this:
> > >
> > > #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C)
> > >
> > > On Mon Aug 08 08:33:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> > >> Hello,
> > >>
> > >> % ./Configure solaris-x86-cc
> > >> % make
> > >> :
> > >> Undefined first referenced
> > >> symbol in file
> > >> __atomic_add_fetch ./libcrypto.so
> > >> ld: fatal: symbol referencing errors. No output written to
> > >> fuzz/asn1parse-test
> > >>
> > >>
> > >> % ./Configure solaris64-x86_64-cc
> > >> % make
> > >> has the same error.
> > >>
> > >> Tested on Solaris10 x86/64, with Solaris developerstudio12.5.
> > >>
> > >>
> > >> This is caused because __ATOMIC_RELAXED is #defined as 0
> > >> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h
> > >>
> > >>
> > >> Sample patch:
> > >> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c
> > >> +++ ./crypto/threads_pthread.c
> > >> @@ -109,7 +109,7 @@
> > >>
> > >> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK
> > >> *lock)
> > >> {
> > >> -#ifdef __ATOMIC_RELAXED
> > >> +#if __ATOMIC_RELAXED
> > >> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED);
> > >> #else
> > >> if (!CRYPTO_THREAD_write_lock(lock))
> > >>
> > >>
> > >> With this patch,
> > >> % ./Configure solaris-x86-cc
> > >> % make
> > >> % make test
> > >> passes.
> > >>
> > >> % ./Configure solaris64-x86_64-cc
> > >> % make
> > >> passes but
> > >> % make test
> > >> stops.
> > >> This is another problem, which seems to be the same as bug #4641.
> > >>
> > >>
> > >> Regards,
> > >>
> > >> --- Kiyoshi 
> > >
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > >
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642
> > > Please log in as guest with password guest if prompted
> > >
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc

[Richard Levitte via RT]

Ok. I'm going with that solution, then. See attached diff.

Cheers,
Richard

On Wed Aug 17 21:21:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> Yes, __SUNPRO_C is defined by DeveloperStudio compiler.
>
> > To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is
> > non-zero
>
> > isn't the right move here. So it seems that different compilers
> > either only
> > implement a subset of the __atomic builtins, or name them
> > differently.
> >
> > What was the macro defined by the DeveloperStudio compiler?
> > __SUNPRO_C or
> > something else? In that case, the correct method might be to exclude
> > it, like
> > this:
> >
> > #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C)
> >
> > On Mon Aug 08 08:33:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> >> Hello,
> >>
> >> % ./Configure solaris-x86-cc
> >> % make
> >> :
> >> Undefined first referenced
> >> symbol in file
> >> __atomic_add_fetch ./libcrypto.so
> >> ld: fatal: symbol referencing errors. No output written to
> >> fuzz/asn1parse-test
> >>
> >>
> >> % ./Configure solaris64-x86_64-cc
> >> % make
> >> has the same error.
> >>
> >> Tested on Solaris10 x86/64, with Solaris developerstudio12.5.
> >>
> >>
> >> This is caused because __ATOMIC_RELAXED is #defined as 0
> >> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h
> >>
> >>
> >> Sample patch:
> >> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c
> >> +++ ./crypto/threads_pthread.c
> >> @@ -109,7 +109,7 @@
> >>
> >> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK
> >> *lock)
> >> {
> >> -#ifdef __ATOMIC_RELAXED
> >> +#if __ATOMIC_RELAXED
> >> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED);
> >> #else
> >> if (!CRYPTO_THREAD_write_lock(lock))
> >>
> >>
> >> With this patch,
> >> % ./Configure solaris-x86-cc
> >> % make
> >> % make test
> >> passes.
> >>
> >> % ./Configure solaris64-x86_64-cc
> >> % make
> >> passes but
> >> % make test
> >> stops.
> >> This is another problem, which seems to be the same as bug #4641.
> >>
> >>
> >> Regards,
> >>
> >> --- Kiyoshi 
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642
> > Please log in as guest with password guest if prompted
> >


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

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

commit 7a73fd48ee58b7792b7c89526c7d3c650091559e
Author: Richard Levitte 
Date:   Tue Aug 23 03:41:46 2016 -0700

Don't use __atomic_add_fetch with DeveloperStudio on Solaris

It seems that, although __ATOMIC_RELAXED is defined, that function
isn't necessarely present.

RT#4642

diff --git a/crypto/threads_pthread.c b/crypto/threads_pthread.c
index 6f5e812..87a2cd6 100644
--- a/crypto/threads_pthread.c
+++ b/crypto/threads_pthread.c
@@ -109,7 +109,7 @@ int CRYPTO_THREAD_compare_id(CRYPTO_THREAD_ID a, CRYPTO_THREAD_ID b)
 
 int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK *lock)
 {
-#ifdef __ATOMIC_RELAXED
+#if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C)
 *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED);
 #else
 if (!CRYPTO_THREAD_write_lock(lock))
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4653] [1.0.2] fails to compile on VC-WIN32

[Richard Levitte via RT]

This was merged yesterday. Please try out a new snapshot. Closing this ticket.

Cheers,
Richard

On Fri Aug 19 15:08:29 2016, levitte wrote:
> Please try out this github pull request:
> https://github.com/openssl/openssl/pull/1470
>
> Cheers,
> Richard
>
> On Fri Aug 19 14:40:02 2016, levitte wrote:
> > We totally missed out on adapting util/mk1mf.pl. Fix on its way.
> >
> > On Fri Aug 19 14:20:20 2016, simon.rich...@hogyros.de wrote:
> > > Hi,
> > >
> > > the 1.0.2 branch fails to compile for me:
> > >
> > > link /nologo /subsystem:console /opt:ref /debug
> > > /out:out32dll\dtlstest.exe @C:\Windows\TEMP\nm8D73.tmp
> > > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp
> > > dtlstest.obj : error LNK2019: unresolved external symbol
> > > _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed
> > > dtlstest.obj : error LNK2019: unresolved external symbol
> > > _create_ssl_objects referenced in function _test_dtls_unprocessed
> > > dtlstest.obj : error LNK2019: unresolved external symbol
> > > _create_ssl_connection referenced in function _test_dtls_unprocessed
> > > dtlstest.obj : error LNK2019: unresolved external symbol
> > > _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed
> > > dtlstest.obj : error LNK2019: unresolved external symbol
> > > _mempacket_test_inject referenced in function _test_dtls_unprocessed
> > > out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals
> > >
> > > Changes in this build:
> > >
> > > http://ci.kicad-pcb.org/job/windows-openssl-
> > > msvc/build=release,cpu=x86,label=windows/458/changes'
> > >
> > > Full build log:
> > >
> > > http://ci.kicad-pcb.org/job/windows-openssl-
> > > msvc/build=release,cpu=x86,label=windows/458/consoleFull
> > >
> > > Simon
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key

[Richard Levitte via RT]

All merged now, closing ticket.

On Mon Aug 22 13:30:02 2016, levitte wrote:
> Perfect.
>
> Fix has been merged into master, but I'll wait with closing this until
> I get a
> yay or nay about the corresponding 1.0.2 fix.
>
> Cheers,
> Richard
>
> On Mon Aug 22 13:12:58 2016, beld...@gmail.com wrote:
> > Dear Richard,
> >
> > Thank you, it works.
> >
> > On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT
> > <r...@openssl.org>
> > wrote:
> >
> > > The issue isn't with the pre-created key, but because '-x509'
> > > doesn't
> > > fully
> > > flag that something new is to be created. The freeze is because
> > > 'openssl
> > > req'
> > > tries to read a csr... '-newkey', however, does flag the creation
> > > of
> > > a csr
> > > /
> > > x509, that's why the alternative command works.
> > >
> > > Fix in https://github.com/openssl/openssl/pull/1479
> > >
> > > Cheers,
> > > Richard
> > >
> > > On Mon Aug 22 12:33:47 2016, beld...@gmail.com wrote:
> > > > Hello openssl team,
> > > >
> > > > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev
> > > >
> > > > I use Debian GNU Linux, the version is 8.5
> > > > The kernel version is
> > > > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-
> > > > 04-
> > > > 08)
> > > > x86_64 GNU/Linux
> > > >
> > > > I have created a private key with a command
> > > >
> > > > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048
> > > >
> > > > in the build directory.
> > > >
> > > > When I execute the command
> > > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req
> > > > -x509
> > > -key
> > > > rsa2048.pem -keyform PEM -out cert.pem
> > > >
> > > > in the build directory, it seems to hang and does not print any
> > > > prompt.
> > > >
> > > > The command line
> > > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req
> > > > -x509
> > > > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes
> > > >
> > > > works ok.
> > > >
> > > > What's done wrong by me?
> > > >
> > >
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > >
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655
> > > Please log in as guest with password guest if prompted
> > >
> > >
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key

[Richard Levitte via RT]

Perfect.

Fix has been merged into master, but I'll wait with closing this until I get a
yay or nay about the corresponding 1.0.2 fix.

Cheers,
Richard

On Mon Aug 22 13:12:58 2016, beld...@gmail.com wrote:
> Dear Richard,
>
> Thank you, it works.
>
> On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT
> <r...@openssl.org>
> wrote:
>
> > The issue isn't with the pre-created key, but because '-x509' doesn't
> > fully
> > flag that something new is to be created. The freeze is because
> > 'openssl
> > req'
> > tries to read a csr... '-newkey', however, does flag the creation of
> > a csr
> > /
> > x509, that's why the alternative command works.
> >
> > Fix in https://github.com/openssl/openssl/pull/1479
> >
> > Cheers,
> > Richard
> >
> > On Mon Aug 22 12:33:47 2016, beld...@gmail.com wrote:
> > > Hello openssl team,
> > >
> > > I experience problems with openssl version OpenSSL 1.1.0-pre7-dev
> > >
> > > I use Debian GNU Linux, the version is 8.5
> > > The kernel version is
> > > Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-
> > > 08)
> > > x86_64 GNU/Linux
> > >
> > > I have created a private key with a command
> > >
> > > LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048
> > >
> > > in the build directory.
> > >
> > > When I execute the command
> > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req
> > > -x509
> > -key
> > > rsa2048.pem -keyform PEM -out cert.pem
> > >
> > > in the build directory, it seems to hang and does not print any
> > > prompt.
> > >
> > > The command line
> > > OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req
> > > -x509
> > > -newkey rsa:2048 -keyout key.pem -out req.pem -nodes
> > >
> > > works ok.
> > >
> > > What's done wrong by me?
> > >
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4655
> > Please log in as guest with password guest if prompted
> >
> >


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

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

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

[openssl-dev] [openssl.org #4655] Openssl req seems not to work with precreated key

[Richard Levitte via RT]

The issue isn't with the pre-created key, but because '-x509' doesn't fully
flag that something new is to be created. The freeze is because 'openssl req'
tries to read a csr... '-newkey', however, does flag the creation of a csr /
x509, that's why the alternative command works.

Fix in https://github.com/openssl/openssl/pull/1479

Cheers,
Richard

On Mon Aug 22 12:33:47 2016, beld...@gmail.com wrote:
> Hello openssl team,
>
> I experience problems with openssl version OpenSSL 1.1.0-pre7-dev
>
> I use Debian GNU Linux, the version is 8.5
> The kernel version is
> Linux vr-dev 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
> x86_64 GNU/Linux
>
> I have created a private key with a command
>
> LD_LIBRARY_PATH=. apps/openssl genrsa -out rsa2048.pem 2048
>
> in the build directory.
>
> When I execute the command
> OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509 -key
> rsa2048.pem -keyform PEM -out cert.pem
>
> in the build directory, it seems to hang and does not print any prompt.
>
> The command line
> OPENSSL_CONF=apps/openssl.cnf LD_LIBRARY_PATH=. apps/openssl req -x509
> -newkey rsa:2048 -keyout key.pem -out req.pem -nodes
>
> works ok.
>
> What's done wrong by me?
>


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

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

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

[openssl-dev] [openssl.org #4653] [1.0.2] fails to compile on VC-WIN32

[Richard Levitte via RT]

Please try out this github pull request:
https://github.com/openssl/openssl/pull/1470

Cheers,
Richard

On Fri Aug 19 14:40:02 2016, levitte wrote:
> We totally missed out on adapting util/mk1mf.pl. Fix on its way.
>
> On Fri Aug 19 14:20:20 2016, simon.rich...@hogyros.de wrote:
> > Hi,
> >
> > the 1.0.2 branch fails to compile for me:
> >
> > link /nologo /subsystem:console /opt:ref /debug
> > /out:out32dll\dtlstest.exe @C:\Windows\TEMP\nm8D73.tmp
> > Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp
> > dtlstest.obj : error LNK2019: unresolved external symbol
> > _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed
> > dtlstest.obj : error LNK2019: unresolved external symbol
> > _create_ssl_objects referenced in function _test_dtls_unprocessed
> > dtlstest.obj : error LNK2019: unresolved external symbol
> > _create_ssl_connection referenced in function _test_dtls_unprocessed
> > dtlstest.obj : error LNK2019: unresolved external symbol
> > _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed
> > dtlstest.obj : error LNK2019: unresolved external symbol
> > _mempacket_test_inject referenced in function _test_dtls_unprocessed
> > out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals
> >
> > Changes in this build:
> >
> > http://ci.kicad-pcb.org/job/windows-openssl-
> > msvc/build=release,cpu=x86,label=windows/458/changes'
> >
> > Full build log:
> >
> > http://ci.kicad-pcb.org/job/windows-openssl-
> > msvc/build=release,cpu=x86,label=windows/458/consoleFull
> >
> > Simon
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4653] [1.0.2] fails to compile on VC-WIN32

[Richard Levitte via RT]

We totally missed out on adapting util/mk1mf.pl. Fix on its way.

On Fri Aug 19 14:20:20 2016, simon.rich...@hogyros.de wrote:
> Hi,
>
> the 1.0.2 branch fails to compile for me:
>
> link /nologo /subsystem:console /opt:ref /debug
> /out:out32dll\dtlstest.exe @C:\Windows\TEMP\nm8D73.tmp
> Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp
> dtlstest.obj : error LNK2019: unresolved external symbol
> _create_ssl_ctx_pair referenced in function _test_dtls_unprocessed
> dtlstest.obj : error LNK2019: unresolved external symbol
> _create_ssl_objects referenced in function _test_dtls_unprocessed
> dtlstest.obj : error LNK2019: unresolved external symbol
> _create_ssl_connection referenced in function _test_dtls_unprocessed
> dtlstest.obj : error LNK2019: unresolved external symbol
> _bio_f_tls_dump_filter referenced in function _test_dtls_unprocessed
> dtlstest.obj : error LNK2019: unresolved external symbol
> _mempacket_test_inject referenced in function _test_dtls_unprocessed
> out32dll\dtlstest.exe : fatal error LNK1120: 5 unresolved externals
>
> Changes in this build:
>
> http://ci.kicad-pcb.org/job/windows-openssl-
> msvc/build=release,cpu=x86,label=windows/458/changes'
>
> Full build log:
>
> http://ci.kicad-pcb.org/job/windows-openssl-
> msvc/build=release,cpu=x86,label=windows/458/consoleFull
>
> Simon


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

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

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

[openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold

[Richard Levitte via RT]

On Fri Jul 08 09:36:42 2016, levitte wrote:
> On Fri Jul 08 09:33:01 2016, noloa...@gmail.com wrote:
> > Hmmm... If I want to use ld.gold as my linker, the easiest path is to
> > set LD=ld.gold. It makes perfect sense to some
>
> Did it work for you when doing this?
>
> ./config -fuse-ld=gold

Jeff, please respond.

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

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

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

[openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc

[Richard Levitte via RT]

To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is non-zero
isn't the right move here. So it seems that different compilers either only
implement a subset of the __atomic builtins, or name them differently.

What was the macro defined by the DeveloperStudio compiler? __SUNPRO_C or
something else? In that case, the correct method might be to exclude it, like
this:

#if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C)

On Mon Aug 08 08:33:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> Hello,
>
> % ./Configure solaris-x86-cc
> % make
> :
> Undefined first referenced
> symbol in file
> __atomic_add_fetch ./libcrypto.so
> ld: fatal: symbol referencing errors. No output written to
> fuzz/asn1parse-test
>
>
> % ./Configure solaris64-x86_64-cc
> % make
> has the same error.
>
> Tested on Solaris10 x86/64, with Solaris developerstudio12.5.
>
>
> This is caused because __ATOMIC_RELAXED is #defined as 0
> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h
>
>
> Sample patch:
> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c
> +++ ./crypto/threads_pthread.c
> @@ -109,7 +109,7 @@
>
> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK
> *lock)
> {
> -#ifdef __ATOMIC_RELAXED
> +#if __ATOMIC_RELAXED
> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED);
> #else
> if (!CRYPTO_THREAD_write_lock(lock))
>
>
> With this patch,
> % ./Configure solaris-x86-cc
> % make
> % make test
> passes.
>
> % ./Configure solaris64-x86_64-cc
> % make
> passes but
> % make test
> stops.
> This is another problem, which seems to be the same as bug #4641.
>
>
> Regards,
>
> --- Kiyoshi 


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

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

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

[openssl-dev] [openssl.org #4584] Self test failures under X32

[Richard Levitte via RT]

On Mon Aug 01 16:50:21 2016, matt wrote:
> On Mon Jul 25 08:49:27 2016, matt wrote:
> > Ping Jeff?
> 
> Ping again?
> 
> Matt

It's worth mentioning that time is getting short, next beta in a few days, 
final in 3 weeks. 

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

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

[openssl-dev] [openssl.org #4590] accessors without const return arguments

[Richard Levitte via RT]

On Fri Jul 22 14:09:12 2016, steve wrote:
> On Sat Jun 25 22:09:59 2016, open...@roumenpetrov.info wrote:
> >
> > Above is reason the request to remove const from return argument of
> > get0
> > methods.
> >
>
> We had a discussion about this and the preference was to have get
> methods
> retain const for various reasons.
>
> Instead the DSA_SIG/ECDSA_SIG structures now no longer pre-allocate
> r/s so they
> aren't immediately freed when you set them.
>
> > The issue is not only for ECDSA but also for DSA_SIG and RSA, DSA, DH
> > keys where situation is similar.
> >
>
> Do you have some examples of how this affects other structures? For
> RSA/DSA/DH
> keys the fields are NULL initially unless I've missed something.

Can this ticket be closed?

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Mon Jul 25 15:11:10 2016, levitte wrote:
> On Mon Jul 25 14:28:04 2016, levitte wrote:
> > BUT... I'm realising that when you do recognise a GT3 proxy (I think
> > I've seen
> > check_issued functions being used for that), there's no way for
> > external code
> > to set the proxy path length for the certificate in question. While
> > that's fine
> > for GT2 proxies (there's no pc path length there that I can see), it
> > does need
> > to be properly set for GT3 proxies.
>
> For this, https://github.com/openssl/openssl/pull/1348

... and it got through our review process pretty quickly.

All github PRs that have been mentioned so far have now been merged into
master.

I'm closing this ticket on our side (this will hopefully happen on the Debian
side as well) as it seems to be covered by the code that has now been added.

As for everything else that has been discussed here, which also touches on
external methods of verification via the verification callback, I would say
it's out of scope for this ticket. I am interested in these talks, but then by
direct email.

--

Richard Levitte
levi...@openssl.org

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Mon Jul 25 14:28:04 2016, levitte wrote:
> BUT... I'm realising that when you do recognise a GT3 proxy (I think
> I've seen
> check_issued functions being used for that), there's no way for
> external code
> to set the proxy path length for the certificate in question. While
> that's fine
> for GT2 proxies (there's no pc path length there that I can see), it
> does need
> to be properly set for GT3 proxies.

For this, https://github.com/openssl/openssl/pull/1348

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Mon Jul 25 12:39:43 2016, msa...@nikhef.nl wrote:
> Hi Richard,
>
> On Mon, Jul 25, 2016 at 11:46:50AM +, Richard Levitte via RT
> wrote:
> > Is that code to cope with pathlen checking bugs? That's what it looks
> > to me. In
> > that case, it might no longer be needed with OpenSSL 1.1, along with
> > some other
> > stuff (the subject checking stuff comes to mind). Quite frankly, I
> > think the
> > grid source needs a good and hard look over, quite a bit of it
> > shouldn't be
> > needed any more. The exception is recognising pre-3820 proxy certs.
> Yes it is, and although it's true that it's probably not needed for
> RFC3820 proxy certs (although I haven't checked that) but we will need
> to be able to verify GT3 proxies and we will need to be able to do the
> whole chain verification there with the callback...

Why do you need to do that? That sounds like your duplicating what's already
being done for reasons I cannot fathom.

BUT... I'm realising that when you do recognise a GT3 proxy (I think I've seen
check_issued functions being used for that), there's no way for external code
to set the proxy path length for the certificate in question. While that's fine
for GT2 proxies (there's no pc path length there that I can see), it does need
to be properly set for GT3 proxies.

For the rest, though, I don't quite see why you'd need to check that path
length *again* in the verification callback. The verification callback is meant
to be used for the certification currently being checked, and should return 0
or 1, depending on if you want the current certificate to verify to to fail.
That's it.

The remaining thing to check, as far as I understand, is proxy policy. The
X509_STORE_CTX ex_data is the place to accumulate data in to make sure policy
continues to be valid thoughout the verification process.

What, in all this, am I missing?

>
> Mischa
>
> > > Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> > > http://www.nikhef.nl/~janjust/proxy-verify/
> > > line 346, but I'm not sure that's necessary.
> >
> > > Mischa
> > >
> > > >
> > > > Those functions are already present in pre-1.1 OpenSSL (at least
> > > > in
> > > > the 1.0.2
> > > > series)
> > > >
> > > > On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > > > > Hi,
> > > > >
> > > > > unless I didn't look careful enough I think we might still be
> > > > > missing
> > > > > the current_cert (and current_issuer) from the X509_STORE_CTX,
> > > > > as
> > > > > advertised in
> > > > >
> > > >
> >
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > > > and used in e.g.
> > > > >
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > > > and many other places for verifying the proxy chain or is there
> > > > > a
> > > > > better/other solution for that?
> > > > >
> > > > > Best wishes,
> > > > > Mischa
> > > > >
> > > > > On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via
> > > > > RT
> > > > > wrote:
> > > > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > > > adds
> > > > > > the function to set the EXFLAG_PROXY flag on a given
> > > > > > certificate.
> > > > > >
> > > > > > Also, PR 1295 has been updated. Instead of a function that
> > > > > > returns a
> > > > > > lock, there is now a lock and an unlock function.
> > > > > >
> > > > > > To me, it seems that that covers what's being asked for.
> > > > > > Perhaps
> > > > > > not
> > > > > > exactly (the setters are for X509_STORE only), but should be
> > > > > > workable.
> > > > > >
> > > > > > (writing this from my mobile, sorry for the lack of github
> > > > > > links)
> > > > > >
> > > > > > --
> > > > > > Richard Levitte
> > > > > > levi...@openssl.org
> > > > > > --
> > > > > > Ticket here:
> > > > > > http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > > > Please log in as guest with password guest if prompted
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, send mail to 829272-
> > > > > > unsubscr...@bugs.debian.org.
> > > >
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > >
> > > > --
> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > Please log in as guest with password guest if prompted
> > > >
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >


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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Mon Jul 25 11:32:17 2016, msa...@nikhef.nl wrote:
> On Sat, Jul 23, 2016 at 09:44:18AM +0000, Richard Levitte via RT
> wrote:
> > To get current_cert, it's X509_STORE_CTX_get_current_cert().
> > To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()
>
> Hi Richard,
>
> yes, those I know, but the problem is the *setting* of the failing
> cert.
> Since we need to walk the whole chain for the proxy pathlength
> verification, we need to be able to indicate which cert is failing.
> See
> e.g.
> https://github.com/globus/globus-
>
toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L1691
> and further, in particular line 1731.
> VOMS is basically using the same code
> https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c#L2236
> and further, in particular line 2255.

Is that code to cope with pathlen checking bugs? That's what it looks to me. In
that case, it might no longer be needed with OpenSSL 1.1, along with some other
stuff (the subject checking stuff comes to mind). Quite frankly, I think the
grid source needs a good and hard look over, quite a bit of it shouldn't be
needed any more. The exception is recognising pre-3820 proxy certs.

> Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> http://www.nikhef.nl/~janjust/proxy-verify/
> line 346, but I'm not sure that's necessary.

> Mischa
>
> >
> > Those functions are already present in pre-1.1 OpenSSL (at least in
> > the 1.0.2
> > series)
> >
> > On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > > Hi,
> > >
> > > unless I didn't look careful enough I think we might still be
> > > missing
> > > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > > advertised in
> > >
> >
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > and used in e.g.
> > > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > and many other places for verifying the proxy chain or is there a
> > > better/other solution for that?
> > >
> > > Best wishes,
> > > Mischa
> > >
> > > On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> > > wrote:
> > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > adds
> > > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > > >
> > > > Also, PR 1295 has been updated. Instead of a function that
> > > > returns a
> > > > lock, there is now a lock and an unlock function.
> > > >
> > > > To me, it seems that that covers what's being asked for. Perhaps
> > > > not
> > > > exactly (the setters are for X509_STORE only), but should be
> > > > workable.
> > > >
> > > > (writing this from my mobile, sorry for the lack of github links)
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > > --
> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > Please log in as guest with password guest if prompted
> > > >
> > > > --
> > > > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >


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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

To get current_cert, it's X509_STORE_CTX_get_current_cert().
To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()

Those functions are already present in pre-1.1 OpenSSL (at least in the 1.0.2
series)

On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> Hi,
>
> unless I didn't look careful enough I think we might still be missing
> the current_cert (and current_issuer) from the X509_STORE_CTX, as
> advertised in
>
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> and used in e.g.
> https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> and many other places for verifying the proxy chain or is there a
> better/other solution for that?
>
> Best wishes,
> Mischa
>
> On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> wrote:
> > In addition to github PR 1294, there's now also PR 1339 which adds
> > the function to set the EXFLAG_PROXY flag on a given certificate.
> >
> > Also, PR 1295 has been updated. Instead of a function that returns a
> > lock, there is now a lock and an unlock function.
> >
> > To me, it seems that that covers what's being asked for. Perhaps not
> > exactly (the setters are for X509_STORE only), but should be
> > workable.
> >
> > (writing this from my mobile, sorry for the lack of github links)
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >
> > --
> > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.


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

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

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

[openssl-dev] [openssl.org #4619] compile errors with no-srp

[Richard Levitte via RT]

Now part of master, commit 8b9546c7085733c88f1df66da48d48a3bc5230a2

Cheers,
Richard

On Fri Jul 22 19:53:01 2016, levitte wrote:
> It's a spelling error. Fix in https://github.com/openssl/openssl/pull/1341
>
> Cheers,
> Richard
>
> On Wed Jul 20 21:45:53 2016, c...@five-ten-sg.com wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Source from master on github,
> >
> > ./Configure --prefix=/usr/local --openssldir=/usr/local/etc/pki/tls
> > enable-ec_nistp_64_gcc_128 zlib sctp enable-camellia enable-seed enable-
> > rfc3779 enable-cms enable-md2 no-mdc2 no-rc5 no-ec2m no-gost no-srp -Wa,
> > - --noexecstack -DPURIFY enable-deprecated shared linux-x86_64
> > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> > no-asan [default] OPENSSL_NO_ASAN (skip dir)
> > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> > no-crypto-mdebug-backtrace [default]
> > OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> > no-ec2m [option] OPENSSL_NO_EC2M (skip dir)
> > no-egd [default] OPENSSL_NO_EGD (skip dir)
> > no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir)
> > no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
> > no-gost [option] OPENSSL_NO_GOST (skip dir)
> > no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> > no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir)
> > no-rc5 [option] OPENSSL_NO_RC5 (skip dir)
> > no-srp [option] OPENSSL_NO_SRP (skip dir)
> > no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> > no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir)
> > no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir)
> > no-ubsan [default] OPENSSL_NO_UBSAN (skip dir)
> > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip
> > dir)
> > no-zlib-dynamic [default]
> >
> >
> > make depend
> > make all
> > 
> >
> > gcc -I. -Iinclude -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
> > - -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
> > - -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> > - -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> > - -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > - -DPOLY1305_ASM -DPURIFY -DOPENSSLDIR="\"/usr/local/etc/pki/tls\""
> > - -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wall -O3 -pthread
> > -m64
> > - -DL_ENDIAN -Wa,--noexecstack -fPIC -MMD -MF ssl/t1_ext.d.tmp -MT
> > ssl/t1_ext.o -c -o ssl/t1_ext.o ssl/t1_ext.c
> > ssl/statem/statem_clnt.c: In function 'tls_construct_cke_srp':
> > ssl/statem/statem_clnt.c:2455: error: 'SSL' has no member named
> > 'srp_ctx'
> > ssl/statem/statem_clnt.c:2457: error: 'SSL' has no member named
> > 'srp_ctx'
> > ssl/statem/statem_clnt.c:2459: error: 'SSL' has no member named
> > 'srp_ctx'
> > ssl/statem/statem_clnt.c:2465: error: 'SSL_SESSION' has no member named
> > 'srp_username'
> > ssl/statem/statem_clnt.c:2466: error: 'SSL_SESSION' has no member named
> > 'srp_username'
> > ssl/statem/statem_clnt.c:2466: error: 'SSL' has no member named
> > 'srp_ctx'
> > ssl/statem/statem_clnt.c:2467: error: 'SSL_SESSION' has no member named
> > 'srp_username'
> > make[2]: *** [ssl/statem/statem_clnt.o] Error 1
> >
> >
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.14 (GNU/Linux)
> >
> > iEYEAREKAAYFAleP41cACgkQL6j7milTFsHYBACdGbcmT0xsANaKhaFz7pGNoU2F
> > R3cAnif6xhWLvWjTUMPkNfv/+rYV7yMc
> > =NEzZ
> > -END PGP SIGNATURE-
> >
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4619] compile errors with no-srp

[Richard Levitte via RT]

It's a spelling error. Fix in https://github.com/openssl/openssl/pull/1341

Cheers,
Richard

On Wed Jul 20 21:45:53 2016, c...@five-ten-sg.com wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Source from master on github,
>
> ./Configure --prefix=/usr/local --openssldir=/usr/local/etc/pki/tls
> enable-ec_nistp_64_gcc_128 zlib sctp enable-camellia enable-seed enable-
> rfc3779 enable-cms enable-md2 no-mdc2 no-rc5 no-ec2m no-gost no-srp -Wa,
> - --noexecstack -DPURIFY enable-deprecated shared linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> no-asan [default] OPENSSL_NO_ASAN (skip dir)
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [default]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> no-ec2m [option] OPENSSL_NO_EC2M (skip dir)
> no-egd [default] OPENSSL_NO_EGD (skip dir)
> no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir)
> no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
> no-gost [option] OPENSSL_NO_GOST (skip dir)
> no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir)
> no-rc5 [option] OPENSSL_NO_RC5 (skip dir)
> no-srp [option] OPENSSL_NO_SRP (skip dir)
> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir)
> no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir)
> no-ubsan [default] OPENSSL_NO_UBSAN (skip dir)
> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip
> dir)
> no-zlib-dynamic [default]
>
>
> make depend
> make all
> 
>
> gcc -I. -Iinclude -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
> - -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
> - -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> - -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> - -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> - -DPOLY1305_ASM -DPURIFY -DOPENSSLDIR="\"/usr/local/etc/pki/tls\""
> - -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wall -O3 -pthread
> -m64
> - -DL_ENDIAN -Wa,--noexecstack -fPIC -MMD -MF ssl/t1_ext.d.tmp -MT
> ssl/t1_ext.o -c -o ssl/t1_ext.o ssl/t1_ext.c
> ssl/statem/statem_clnt.c: In function 'tls_construct_cke_srp':
> ssl/statem/statem_clnt.c:2455: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2457: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2459: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2465: error: 'SSL_SESSION' has no member named
> 'srp_username'
> ssl/statem/statem_clnt.c:2466: error: 'SSL_SESSION' has no member named
> 'srp_username'
> ssl/statem/statem_clnt.c:2466: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2467: error: 'SSL_SESSION' has no member named
> 'srp_username'
> make[2]: *** [ssl/statem/statem_clnt.o] Error 1
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAleP41cACgkQL6j7milTFsHYBACdGbcmT0xsANaKhaFz7pGNoU2F
> R3cAnif6xhWLvWjTUMPkNfv/+rYV7yMc
> =NEzZ
> -END PGP SIGNATURE-
>
>


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

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

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

[openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs

[Richard Levitte via RT]

On Fri Jul 22 12:52:18 2016, rs...@akamai.com wrote:
> And now, with subject clearly stated, I think we should not do this.

After some discussion, we decided to abandon this line of thought and get back
to accessors as off RT4602.

Closing this ticket.

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

Hi, 

Good point, I'll look into that. Also, thanks for the reminder, that HOWTO 
needs a rewrite, badly. 

Cheers 
Richard 

On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> Hi,
> 
> unless I didn't look careful enough I think we might still be missing
> the current_cert (and current_issuer) from the X509_STORE_CTX, as
> advertised in
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> and used in e.g.
> https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> and many other places for verifying the proxy chain or is there a
> better/other solution for that?
> 
> Best wishes,
> Mischa
> 
> On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> wrote:
> > In addition to github PR 1294, there's now also PR 1339 which adds
> > the function to set the EXFLAG_PROXY flag on a given certificate.
> >
> > Also, PR 1295 has been updated. Instead of a function that returns a
> > lock, there is now a lock and an unlock function.
> >
> > To me, it seems that that covers what's being asked for. Perhaps not
> > exactly (the setters are for X509_STORE only), but should be
> > workable.
> >
> > (writing this from my mobile, sorry for the lack of github links)
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >
> > --
> > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.


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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

In addition to github PR 1294, there's now also PR 1339 which adds the function 
to set the EXFLAG_PROXY flag on a given certificate. 

Also, PR 1295 has been updated. Instead of a function that returns a lock, 
there is now a lock and an unlock function. 

To me, it seems that that covers what's being asked for. Perhaps not exactly 
(the setters are for X509_STORE only), but should be workable. 

(writing this from my mobile, sorry for the lack of github links) 

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

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

[openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs

[Richard Levitte via RT]

Forgive me for being sloppy, I forgot to add a subject. Now added, it says what
the actual issue is.

On Fri Jul 22 11:32:27 2016, levitte wrote:
> Ticket derived from RT4602 (missing accessors)
>
> Reports have been coming in that in the grid world, there are two pre-
> rfc3820
> forms of proxy certs still being used.
>
> Old (pre-draft) format: Looks like a regular EE cert, but has been
> issued by
> another EE (real or proxy), and can be recognised by having the issuer
> name as
> subject name with an extra CN appended, either 'CN=proxy' or
> 'CN=limited proxy'
>
> draft format: looks like a RFC3820 proxy cert, but uses OID
> 1.3.6.1.4.1.3536.1.222 instead of the RFC3820 OID for proxyCertInfo.
>
> Cc to Mattias and Mischa, who have provided valuable info on this
> issue in
> RT4602. Guys, I hope it was ok to add you. If not, please tell me and
> I'll take
> you off this ticket.
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4622]

[Richard Levitte via RT]

Ticket derived from RT4602 (missing accessors)

Reports have been coming in that in the grid world, there are two pre-rfc3820
forms of proxy certs still being used.

Old (pre-draft) format: Looks like a regular EE cert, but has been issued by
another EE (real or proxy), and can be recognised by having the issuer name as
subject name with an extra CN appended, either 'CN=proxy' or 'CN=limited proxy'

draft format: looks like a RFC3820 proxy cert, but uses OID
1.3.6.1.4.1.3536.1.222 instead of the RFC3820 OID for proxyCertInfo.

Cc to Mattias and Mischa, who have provided valuable info on this issue in
RT4602. Guys, I hope it was ok to add you. If not, please tell me and I'll take
you off this ticket.

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Fri Jul 22 07:38:25 2016, mattias.ell...@physics.uu.se wrote:
> tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > >
> > > ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > > >
> > > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > >
> > > > >
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > >
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > >
> > >
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > >
> > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > >
> > > > Hi Richard, Mattias, others,
> > > >
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > >
> > > > Best wishes,
> > > > Mischa Sallé
> > > >
> >
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
>
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
>
> For example see "grid-proxy-init -help":
>
> -draft Creates a draft (GSI-3) proxy
> -old Creates a legacy globus proxy
> -rfc Creates a RFC 3820 compliant proxy
>
> The really tricky one is the old legacy version 2 proxy I think.

Ok, so after doing quite a bit of searching, I found some references to GT2
(old) in a 3.0 document:

http://toolkit.globus.org/toolkit/docs/3.0/gsi/GSI-message-specification-02.doc
(section 5)

As I understand it, the GT2 format is a simple EE cert, with just two
differences:

1. the issuer is also a EE (so it has the basic constraint CA set to false)...
or it's another GT2 proxy, which amounts to the same thing.
2. the subject name is the issuer name plus an appended 'CN=Proxy' or
'CN=LimitedProxy'

Good so far?

My main problem here is GT3 (draft) proxy certs. If I look at
https://tools.ietf.org/html/draft-ietf-pkix-proxy-10, they look exactly the
same as RFC3820 proxy certs, down to the extension OID. If I look at a really
old draft
(http://sigillum.pl/upload/pdf/Internet%20X.509%20Public%20Key%20Infrastructure.%20Proxy%20Certificate%20Profile.pdf),
the difference is *wild*, and if look at a random shell script
(https://www.nikhef.nl/~janjust/proxy-verify/genproxy) I found while searching
for OID 1.3.6.1.4.1.3536.1.222, I find a third variant that has a slightly
different proycertinfo extension...

Btw, this should really become a new ticket, along the lines of "OpenSSL
doesn't recognise earlier proxy certs".

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > >
> > > I guess having a more restrictive accessor that only sets the
> > > EXFLAG_PROXY bit could work. I suggested the more general solution
> > > of
> > > having set/clear accessors for arbitrary flags since it was - well
> > > more
> > > general.
> >
> > So let me ask this in a different manner, does OpenSSL 1.1 still not
> > set the
> > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > That may be
> > worth a bug report of its own.
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
>
> The answer to this is related to Mischa's reply, which unfortunately
> was only sent to the Debian BTS and not the the OpenSSL RT. I quote it
> below. As indicated in the answer, setting the EXFLAG_PROXY allows
> handling non-RFC proxies in OpenSSL.
>
> mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > Hi Richard, Mattias, others,
> >
> > I agree with you that it would be nice if OpenSSL could figure out
> > itself whether a cert needs to be treated as a proxy, but currently
> > that
> > doesn't work reliably as far as I know.
> > The flag is certainly needed in the case of non-RFC3820 proxies, also
> > known as legacy proxies. Unfortunately these are still very widely
> > used
> > (majority of the proxies actually) and hence our code must be able to
> > handle them correctly.
> >
> > Best wishes,
> > Mischa Sallé
> >

Ok... From looking at the voms code that was linked to earlier, I can see that
legacy proxy certs are recognised by an older OID (called PROXYCERTINFO_V3 in
the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions in that
version, whether they are critical or not and so on, that I can reach? Or is
the OID the only actual difference? If it's easy enough (and it currently does
look quite easy), I can certainly see adding some code in OpenSSL to recognise
those...

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

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

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

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Richard Levitte via RT]

On Tue Jul 19 17:47:43 2016, levitte wrote:
> On Tue Jul 19 16:41:13 2016, k...@roeckx.be wrote:
> > On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote:
> > > Previously we've changed return-types from void to int. If there's
> > > still time, that seems like the thing to do here.
> >
> > I've pushed a branched on github that at least does some of the
> > things. See github #1330.
>
> Likewise for the CRYPTO_THREAD_run_once() issue, in
> https://github.com/openssl/openssl/pull/1332

All now merged into master branch. Closing this ticket.

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Wed Jul 20 16:58:20 2016, janj...@nikhef.nl wrote:
> Hi Richard,
>
> On 20/07/16 17:14, Richard Levitte via RT wrote:
> > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> >> I guess having a more restrictive accessor that only sets the
> >> EXFLAG_PROXY bit could work. I suggested the more general solution
> >> of
> >> having set/clear accessors for arbitrary flags since it was - well
> >> more
> >> general.
> > So let me ask this in a different manner, does OpenSSL 1.1 still not
> > set the
> > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > That may be
> > worth a bug report of its own.
> >
> this ties into my earlier question and example of verifying proxy
> certificates. What if I want to explicitly *set* the EXFLAG_PROXY for
> a
> stack of certificates?

I assume you only want that flag set for actual proxy certs a no other. If you
simply want to make sure the certs in a stack are properly flagged by OpenSSL,
call X509_check_purpose for each of them.

> how would I do that? how can I ensure that
> OpenSSL 1.1 will automagically trigger this flag for me? Is there a
> 'get_*' function to determine which flags were set during certificate
> verification?
>
> thanks for any pointers or advice,

The function to retrieve the extension flags is X509_get_extension_flags(). You
call that for each X509*.
Incidently, this function calls X509_check_purpose to make sure the caches are
properly built up...

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> I guess having a more restrictive accessor that only sets the
> EXFLAG_PROXY bit could work. I suggested the more general solution of
> having set/clear accessors for arbitrary flags since it was - well
> more
> general.

So let me ask this in a different manner, does OpenSSL 1.1 still not set the
EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
worth a bug report of its own.

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote:
> I was using store.get_issuer() in OpenConnect too, because I need to
> manually build the trust chain to include it on the wire — because
> even today the server might *still* suffer RT#1942 and fail to trust
> our client cert unless we help it by providing the *right* chain.

Is this still true with OpenSSL 1.1? If so, please file a report.

> I've worked around the lack of access to get_issuer() by doing a dummy
> call to X509_verify_cert(), throwing away its result and then hoping
> that we have something useful in store.chain (which we *can* still
> access). That seems to work but I'm not stunningly happy with it; if
> we
> can have an accessor I'd much rather go back to doing it the old way.
>
> http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> (in workaround_openssl_certchain_bug() in the hunk around line 1306)

https://github.com/openssl/openssl/pull/1294 currently provides a setter for
get_issuer in X509_STORE.

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

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

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

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Richard Levitte via RT]

On Tue Jul 19 16:41:13 2016, k...@roeckx.be wrote:
> On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote:
> > Previously we've changed return-types from void to int. If there's
> > still time, that seems like the thing to do here.
>
> I've pushed a branched on github that at least does some of the
> things. See github #1330.

Likewise for the CRYPTO_THREAD_run_once() issue, in
https://github.com/openssl/openssl/pull/1332

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

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

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

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Richard Levitte via RT]

On Tue Jul 19 15:36:04 2016, levitte wrote:
> Ok, so the other way I can think of is a bit ugly, but... using oob
> data, in
> this case a variable that the init routine must set to signal that
> everything
> went well. I'm thinking a variable in CRYPTO_THREAD_run_once() that
> gets passed
> by reference to the init routine

Never mind that, I wasn't thinking straight...

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

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

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

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Richard Levitte via RT]

On Tue Jul 19 15:36:04 2016, levitte wrote:
> To be noted is that we never check the value CRYPTO_THREAD_run_once()
> returns... Should we make it __owur?

I spoke too fast. We do... just not always.

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

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

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

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Richard Levitte via RT]

On Tue Jul 19 15:26:58 2016, matt wrote:
>
>
> On 19/07/16 16:23, Richard Levitte via RT wrote:
> > On Mon Jul 11 16:20:29 2016, k...@roeckx.be wrote:
> >> Hi,
> >>
> >> When trying to check what happens if we simulate malloc()
> >> returning NULL I'm running into a problem that I'm not sure how to
> >> deal with.
> >>
> >> We have CRYPTO_THREAD_run_once(), which takes an init() function
> >> that returns void, so it can't return failures. At least the
> >> pthread_once() function also has it as void.
> >>
> >> But if those functions call malloc() and that returns NULL, we now
> >> don't catch that error, and later just try to use a NULL pointer.
> >>
> >> Anybody a good idea how to solve this?
> >
> > Rethinking this...
> >
> > Most of all, we use CRYPTO_THREAD_run_once() internally to initiate
> > the first
> > locks, so pretty much in an initial state of the library (not
> > entirely true,
> > since we do these inits opportunistically, but it's probable that
> > they happen
> > very early on). If they are having memory allocation, the running app
> > is
> > probably in deep shit anyway, so a hard assert in our diverse inits
> > would
> > probably be appropriate either way.
>
> You are assuming that the application loads and inits OpenSSL early
> and
> that it is critical to its function. It may not be.

True, I made that assumption.

Ok, so the other way I can think of is a bit ugly, but... using oob data, in
this case a variable that the init routine must set to signal that everything
went well. I'm thinking a variable in CRYPTO_THREAD_run_once() that gets passed
by reference to the init routine

To be noted is that we never check the value CRYPTO_THREAD_run_once()
returns... Should we make it __owur?

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

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

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

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Richard Levitte via RT]

On Mon Jul 11 16:20:29 2016, k...@roeckx.be wrote:
> Hi,
>
> When trying to check what happens if we simulate malloc()
> returning NULL I'm running into a problem that I'm not sure how to
> deal with.
>
> We have CRYPTO_THREAD_run_once(), which takes an init() function
> that returns void, so it can't return failures. At least the
> pthread_once() function also has it as void.
>
> But if those functions call malloc() and that returns NULL, we now
> don't catch that error, and later just try to use a NULL pointer.
>
> Anybody a good idea how to solve this?

Rethinking this...

Most of all, we use CRYPTO_THREAD_run_once() internally to initiate the first
locks, so pretty much in an initial state of the library (not entirely true,
since we do these inits opportunistically, but it's probable that they happen
very early on). If they are having memory allocation, the running app is
probably in deep shit anyway, so a hard assert in our diverse inits would
probably be appropriate either way.

It was suggested that we change the return type of the init routine to int and
have it return something appropriate (0 for error, 1 for success, say?), but
since at least pthread_once() takes a function returning void (and thereby
doesn't care about any returned value), it seems like our hands are forced
anyway.

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

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

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

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Richard Levitte via RT]

On Mon Jul 11 17:48:06 2016, rs...@akamai.com wrote:
> Previously we've changed return-types from void to int. If there's
> still time, that seems like the thing to do here.

I agree.

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

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

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

[openssl-dev] [openssl.org #4584] Self test failures under X32

[Richard Levitte via RT]

On Tue Jul 19 14:01:17 2016, matt wrote:
>
>
> On 19/07/16 14:41, Richard Levitte via RT wrote:
> > Hi Jeff,
> >
> > I'm going to assume that a newer checkout of the master branch won't
> > change
> > much, so if you please, try this command and send mack the result:
>
> Who is Mack? ;-)

Mack is back ;-)

> > make test TESTS='test_afalg test_rehash'
>
> Did you mean to include "VERBOSE=1"?
>
> VERBOSE=1 make TESTS='test_afalg test_rehash' test

Ah, yes, of course...

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4584] Self test failures under X32

[Richard Levitte via RT]

Hi Jeff,

I'm going to assume that a newer checkout of the master branch won't change
much, so if you please, try this command and send mack the result:

make test TESTS='test_afalg test_rehash'

Cheers,
Richard

On Thu Jun 23 11:10:04 2016, noloa...@gmail.com wrote:
> I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
> and working from HEAD:
>
> # git rev-parse HEAD
> b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
>
> Running 'make test' under a machine configured with './Configure
> linux-x32 enable-ec_nistp_64_gcc_128' results in two failed self
> tests:
>
> make[1]: Leaving directory '/openssl'
> ( cd test; \
> SRCTOP=../. \
> BLDTOP=../. \
> PERL="perl" \
> EXE_EXT= \
> OPENSSL_ENGINES=.././engines \
> perl .././test/run_tests.pl )
> ../test/recipes/01-test_abort.t  ok
> ../test/recipes/01-test_ordinals.t . ok
> ../test/recipes/01-test_symbol_presence.t .. ok
> ../test/recipes/05-test_bf.t ... ok
> ../test/recipes/05-test_cast.t . ok
> ../test/recipes/05-test_des.t .. ok
> ../test/recipes/05-test_hmac.t . ok
> ../test/recipes/05-test_idea.t . ok
> ../test/recipes/05-test_md2.t .. skipped: md2 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_md4.t .. ok
> ../test/recipes/05-test_md5.t .. ok
> ../test/recipes/05-test_mdc2.t . ok
> ../test/recipes/05-test_rand.t . ok
> ../test/recipes/05-test_rc2.t .. ok
> ../test/recipes/05-test_rc4.t .. ok
> ../test/recipes/05-test_rc5.t .. skipped: rc5 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_rmd.t .. ok
> ../test/recipes/05-test_sha1.t . ok
> ../test/recipes/05-test_sha256.t ... ok
> ../test/recipes/05-test_sha512.t ... ok
> ../test/recipes/05-test_wp.t ... ok
> ../test/recipes/10-test_bn.t ... ok
> ../test/recipes/10-test_exp.t .. ok
> ../test/recipes/15-test_dh.t ... ok
> ../test/recipes/15-test_dsa.t .. ok
> ../test/recipes/15-test_ec.t ... ok
> ../test/recipes/15-test_ecdh.t . ok
> ../test/recipes/15-test_ecdsa.t  ok
> ../test/recipes/15-test_rsa.t .. ok
> ../test/recipes/20-test_enc.t .. ok
> ../test/recipes/25-test_crl.t .. ok
> ../test/recipes/25-test_d2i.t .. ok
> ../test/recipes/25-test_pkcs7.t  ok
> ../test/recipes/25-test_req.t .. ok
> ../test/recipes/25-test_sid.t .. ok
> ../test/recipes/25-test_verify.t ... ok
> ../test/recipes/25-test_x509.t . ok
> ../test/recipes/30-test_afalg.t  1/1
> # Failed test 'running afalgtest'
> # at ../test/recipes/30-test_afalg.t line 23.
> # Looks like you failed 1 test of 1.
> ../test/recipes/30-test_afalg.t  Dubious, test returned 1
> (wstat 256, 0x100)
> Failed 1/1 subtests
> ../test/recipes/30-test_engine.t ... ok
> ../test/recipes/30-test_evp.t .. ok
> ../test/recipes/30-test_evp_extra.t  ok
> ../test/recipes/30-test_pbelu.t  ok
> ../test/recipes/40-test_rehash.t ... 1/5
> # Failed test 'Testing that we aren't running as a privileged user,
> such as root'
> # at ../test/recipes/40-test_rehash.t line 49.
> # Looks like you failed 1 test of 5.
> ../test/recipes/40-test_rehash.t ... Dubious, test returned 1
> (wstat 256, 0x100)
> Failed 1/5 subtests
> (less 1 skipped subtest: 3 okay)
> ../test/recipes/70-test_asyncio.t .. ok
> ../test/recipes/70-test_clienthello.t .. ok
> ../test/recipes/70-test_packet.t ... ok
> ../test/recipes/70-test_sslcertstatus.t  ok
> ../test/recipes/70-test_sslextension.t . ok
> ../test/recipes/70-test_sslrecords.t ... ok
> ../test/recipes/70-test_sslsessiontick.t ... ok
> ../test/recipes/70-test_sslskewith0p.t . ok
> ../test/recipes/70-test_sslvertol.t  ok
> ../test/recipes/70-test_tlsextms.t . ok
> ../test/recipes/70-test_verify_extra.t . ok
> ../test/recipes/80-test_ca.t ... ok
> ../test/recipes/80-test_cipherlist.t ... ok
> ../test/recipes/80-test_cms.t .. ok
> ../test/recipes/80-test_ct.t ... ok
> ../test/recipes/80-test_dane.t . ok
> ../test/recipes/80-test_dtlsv1listen.t . ok
> ../test/recipes/80-test_ocsp.t . ok
> ../test/recipes/80-test_ssl_new.t .. ok
> ../test/recipes/80-test_ssl_old.t .. ok
> ../test/recipes/80-test_ssl_test_ctx.t . ok
> ../test/recipes/80-test_tsa.t .. ok
> ../test/recipes/80-test_x509aux.t .. ok
> ../test/recipes/90-test_async.t  ok
> ../test/recipes/90-test_bioprint.t . ok
> ../test/recipes/90-test_constant_time.t  ok
> ../test/recipes/90-test_gmdiff.t ... ok
> ../test/recipes/90-test_heartbeat.t  skipped: heartbeats is
> 

[openssl-dev] [openssl.org #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

[Richard Levitte via RT]

My answer was incorrect...

What happens when trying to find a CRL is that get_cert_by_subject (in
crypto/x509/by_dir.c) gets called, and it will try to load every file it finds
(so both $hash{sub_ca}.r0 and $hash{sub_ca}.r1). However, when trying to
storing them in the internal store, it will only do so if no other object with
the same hash is already there. Hence, $hash{sub_ca}.r1 will essentially be
ignored.

Either way, if both CRLs (with the same issuer name) were stored internally, it
would still be a good question which one would actually be used. How would that
be determined.

I suggest you try with replacing the old with the new.

Furthermore, I'm not sure this is a bug, at least in current OpenSSL. Maybe
this will be reconsidered in the future, but that will certainly be seen as a
new feature.

Time to close this ticket.

Cheers,
Richard

On Tue Jul 19 08:31:18 2016, levitte wrote:
> So let me see if I understand this correctly... $hash(sub_ca).r1 and
> $hash(sub_ca).r0, being of the same sub_ca, will of course have the
> same issuer
> name. Right?
>
> Unless I misread the source, OpenSSL will actually load both files.
> However,
> since both CRLs have the same issuer, and cached CRLs are looked up by
> issuer
> name, only one of them will be used (whichever the code happens to
> find first).
>
> If one of those CRLs was a delta CRL, things might work differently
> (I'm
> frankly not sure, I haven't experimented with that, and haven't spent
> enough
> time studying that part of the code)... I assume that this isn't the
> case.
>
> Is there a reason in particular you want to have two active CRLs for
> the
> sub-CA? Does simply replacing the old with the new now work for you
> somehow?
>
> Cheers,
> Richard
>
> On Thu Jul 14 11:25:22 2016, patel3.anir...@gmail.com wrote:
> > Hi,
> >
> > I have a query related to how these APIs X509_STORE_add_lookup()
> > and X509_LOOKUP_add_dir() work. Let me give you a brief explanation
> > of what
> > I am doing:
> >
> > Purpose was to add lookup for CRLs.
> >
> > First when my server starts and my SSL initializes I have
> > successfully
> > created a store to which lookup has been added for CRL directory.
> >
> > - pLookup = X509_STORE_add_lookup(store, X509_LOOKUP_hash_dir());
> > - X509_LOOKUP_add_dir(pLookup, mCRLPath.c_str(), X509_FILETYPE_PEM)
> >
> > Example CRL Directory: /var/cert/CRL/
> > Scenario:
> > 1) When the system start no CRL files are present in the CRL
> > Directory
> > 2) Client_1 initiates a connection to my server (using openssl
> > s_client)
> > 3) Openssl does the lookup of CRLs for the corresponding (Sub) CAs
> > and does
> > not find anything thus, giving error in the verify_callback
> > (UNABLE_TO_GET_CRL). In the application code I have handled these
> > errors gracefully Callback is again called for further validation and
> > the
> > connection is accepted.
> > *Result: Satisfied*
> >
> > 1) Now, I place two CRLs (Sub CA,Root CA) in the CRL directory
> > (server was
> > still up and I did not stopped it)
> > I have created a crl -hash (issuer hash) and linked them to CRL pem
> > certificates.
> > *$hash(rootca).r0 -> root_ca.pem*
> > *$hash(subca).r0 -> sub_ca.pem*
> > 2) Client_1 again initiates a connection to my server (using openssl
> > s_client) (client certificate chain is : ID/Sub CA/Root CA)
> > 3) Openssl does a lookup of CRLs and does not throw any error.
> > Validation
> > happened with verify_callback getting invoked 3 times with
> > preverify_ok =
> > 1. Client connection is accepted
> > *Result: Satisfied*
> >
> > 1) Now, I removed the above CRL files (Sub CA/Root CA) from the CRL
> > directory. Based on the manual page these CRLs should be now in the
> > cached
> > memory of X509_OBJECT.
> > 2) I repeated steps (2) and (3). Connection gets accepted from the
> > client.
> > Everything still works fine because openssl maintined CRL files in
> > its
> > cache and found them during the lookup.
> > *Result: Satisfied*
> >
> > Now from here the problem starts:
> > =
> > 1) My Sub_CA revoked Client_1 certificate (since Sub_CA was the
> > issuing CA
> > in the first place)
> > 2) I recreated Sub_CA CRL and placed it in the CRL Directory.
> > 3) Created the hash and linked it as follows:
> > *$hash(sub_ca).r1* -> sub_ca.pem (hoping that openssl still has
> > $hash(sub_ca).r0 in its cache, since above we have seen that the
> > lookup
> > worked even when I removed the CRL files from the CRL Directory)
> > 4) Client_1 initiates a connection to my server and gets accepted
> > successfully  Should Not Have Happened
> > Based on the manual page for *X509_LOOKUP_hash_dir
> > - https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html
> > *
> >
> > > When checking for new CRLs once one CRL for given hash value is
> > > loaded,
> > > hash_dir lookup method checks only for certificates with sequence
> > > number
> > > greater than 

[openssl-dev] [openssl.org #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

[Richard Levitte via RT]

So let me see if I understand this correctly... $hash(sub_ca).r1 and
$hash(sub_ca).r0, being of the same sub_ca, will of course have the same issuer
name. Right?

Unless I misread the source, OpenSSL will actually load both files. However,
since both CRLs have the same issuer, and cached CRLs are looked up by issuer
name, only one of them will be used (whichever the code happens to find first).

If one of those CRLs was a delta CRL, things might work differently (I'm
frankly not sure, I haven't experimented with that, and haven't spent enough
time studying that part of the code)... I assume that this isn't the case.

Is there a reason in particular you want to have two active CRLs for the
sub-CA? Does simply replacing the old with the new now work for you somehow?

Cheers,
Richard

On Thu Jul 14 11:25:22 2016, patel3.anir...@gmail.com wrote:
> Hi,
>
> I have a query related to how these APIs X509_STORE_add_lookup()
> and X509_LOOKUP_add_dir() work. Let me give you a brief explanation of what
> I am doing:
>
> Purpose was to add lookup for CRLs.
>
> First when my server starts and my SSL initializes I have successfully
> created a store to which lookup has been added for CRL directory.
>
> - pLookup = X509_STORE_add_lookup(store, X509_LOOKUP_hash_dir());
> - X509_LOOKUP_add_dir(pLookup, mCRLPath.c_str(), X509_FILETYPE_PEM)
>
> Example CRL Directory: /var/cert/CRL/
> Scenario:
> 1) When the system start no CRL files are present in the CRL Directory
> 2) Client_1 initiates a connection to my server (using openssl s_client)
> 3) Openssl does the lookup of CRLs for the corresponding (Sub) CAs and does
> not find anything thus, giving error in the verify_callback
> (UNABLE_TO_GET_CRL). In the application code I have handled these
> errors gracefully Callback is again called for further validation and the
> connection is accepted.
> *Result: Satisfied*
>
> 1) Now, I place two CRLs (Sub CA,Root CA) in the CRL directory (server was
> still up and I did not stopped it)
> I have created a crl -hash (issuer hash) and linked them to CRL pem
> certificates.
> *$hash(rootca).r0 -> root_ca.pem*
> *$hash(subca).r0 -> sub_ca.pem*
> 2) Client_1 again initiates a connection to my server (using openssl
> s_client) (client certificate chain is : ID/Sub CA/Root CA)
> 3) Openssl does a lookup of CRLs and does not throw any error. Validation
> happened with verify_callback getting invoked 3 times with preverify_ok =
> 1. Client connection is accepted
> *Result: Satisfied*
>
> 1) Now, I removed the above CRL files (Sub CA/Root CA) from the CRL
> directory. Based on the manual page these CRLs should be now in the cached
> memory of X509_OBJECT.
> 2) I repeated steps (2) and (3). Connection gets accepted from the client.
> Everything still works fine because openssl maintined CRL files in its
> cache and found them during the lookup.
> *Result: Satisfied*
>
> Now from here the problem starts:
> =
> 1) My Sub_CA revoked Client_1 certificate (since Sub_CA was the issuing CA
> in the first place)
> 2) I recreated Sub_CA CRL and placed it in the CRL Directory.
> 3) Created the hash and linked it as follows:
> *$hash(sub_ca).r1* -> sub_ca.pem (hoping that openssl still has
> $hash(sub_ca).r0 in its cache, since above we have seen that the lookup
> worked even when I removed the CRL files from the CRL Directory)
> 4) Client_1 initiates a connection to my server and gets accepted
> successfully  Should Not Have Happened
> Based on the manual page for *X509_LOOKUP_hash_dir
> - https://www.openssl.org/docs/manmaster/crypto/X509_LOOKUP_file.html
> *
>
> > When checking for new CRLs once one CRL for given hash value is loaded,
> > hash_dir lookup method checks only for certificates with sequence number
> > greater than that of the already cached CRL.
>
> Since, the sequence number has changed from r0 to r1 for same issuer
> (sub_ca in my case) openssl should have done a lookup and based on the
> latest sequence number should have given me an error stating Client
> Certificate has been revoked.
>
> Just to let you know, I have tested revoked certificates with the CRL and
> it works fine. So no problem with that.
> Openssl Version I am using is *OpenSSL 1.0.1e-fips 11 Feb 2013*
>
> Eagerly awaiting your response. Need to implement CRL functionality ASAP
> and hoping to get all the help from you guys.
>
> Regards,
> Anirudh


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

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

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

[openssl-dev] [openssl.org #4611] PKCS12_create() not thread-safe for ECDSA

[Richard Levitte via RT]

On Sun Jul 10 19:38:03 2016, ms...@barracuda.com wrote:
> OpenSSL 1.0.2h
>
> The function eckey_priv_encode() may crash if the same pkey is
> serialized from multiple threads. Here is a sample backtrace:
>
> #0 0x7fff8f321f92 in _platform_memmove$VARIANT$Haswell ()
> #1 0x000100196132 in i2c_ASN1_BIT_STRING
> #2 0x0001001a1fb2 in asn1_ex_i2c
> #3 0x0001001a1e68 in asn1_i2d_ex_primitive
> #4 0x0001001a19fd in ASN1_item_ex_i2d
> #5 0x0001001a1d8b in asn1_template_ex_i2d
> #6 0x0001001a1a8b in ASN1_item_ex_i2d
> #7 0x0001001a16d0 in asn1_item_flags_i2d
> #8 0x000100149d3e in i2d_ECPrivateKey
> #9 0x00010014e576 in eckey_priv_encode
> #10 0x00010018e9f9 in EVP_PKEY2PKCS8_broken
> #11 0x0001001d38d9 in PKCS12_add_key
> #12 0x0001001d35a3 in PKCS12_create
>
> EC_KEY_set_enc_flags() is called to modify/restore the encoding flags
> within the EC_KEY. Two calls are made to i2d_ECPrivateKey(). The first
> calculates the necessary buffer length, the second serializes the data
> into an allocated buffer. If the flags change during this period, the
> second call overwrites the buffer.
>
> These APIs are documented as thread safe, and should not change the
> internal flags of the pkey without proper locking.

Problem fixed in upcoming 1.1.0 and 1.0.2 releases. The issue was actually that
the input EC_KEY was modified at all. The code has been modified to take a
temporary shallow copy of the input EC_KEY and modify the copy instead.

Relevant commits are:

b8a7bd83e68405fdf595077973035ac6fe24cb97 (master branch)
427b22646d4642809f67352513590549650b916f (1.0.2 branch)

Closing this ticket.
Cheers,
Richard
--
Richard Levitte
levi...@openssl.org

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
> > Mattias,
> >
> > Can you explain why this is needed, what the code is trying to do?
> >
> >
> > Kurt
> >
>
> Hi!
>
> The modification of the extension flags happens in at least four
> different packages. The modification they do is to add the
> EXFLAG_PROXY
> bit to the flags.

Ok, I just had a look:

>
https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L692

This looks like an old workaround, and I wonder if it's really needed any more.
If it's still needed, I'd say this may uncover a bug within OpenSSL, but in
that case, I'd rather fix that in 1.1

> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1665
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1740

I see what this code does, it makes a name constraint check that should have
been present in OpenSSL but wasn't... until 1.1. However, there's other stuff
in that function that looks odd..

> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1655
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1719

This is the same code as the voms you pointed at above.

>
https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L184

This is the same code as the globus-gsi-callback pointer above.

> I guess having a more restrictive accessor that only sets the
> EXFLAG_PROXY bit could work. I suggested the more general solution of
> having set/clear accessors for arbitrary flags since it was - well
> more
> general.

Mm, I'm really unsure about this one. ex_flags is part of a cache of
information that OpenSSL fiddles with whenever it checks the extensions for a
certificate. Calling anything that ends up calling X509_check_issued(),
X509_check_ca() or X509_check_purpose() will cause values to be checked and
cached for the certificates involved in the call of those functions. In the
proxy certificate case, EXFLAG_PROXY will be set for a certificate any time the
proxyCertInfo is found among its extensions.

To be blunt, I would much rather see a bug report that shows when that cache
isn't being built properly, and possibly a fix for it.

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold

[Richard Levitte via RT]

On Fri Jul 08 09:33:01 2016, noloa...@gmail.com wrote:
> Hmmm... If I want to use ld.gold as my linker, the easiest path is to
> set LD=ld.gold. It makes perfect sense to some

Did it work for you when doing this?

./config -fuse-ld=gold

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

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

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

[openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold

[Richard Levitte via RT]

On Fri Jul 08 07:47:14 2016, noloa...@gmail.com wrote:
> $ ./config LD=ld.gold
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already defined - linux-x86_64 (offending arg: LD=ld.gold)
>
> And:
>
> $ LD=ld.gold ./config
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> ...
>
> $ cat Makefile | grep ld.gold
> $ cat Makefile.shared | grep ld.gold
> $
>
> I don't believe CFLAG -fuse-ld=gold is an option because the linker is
> invoked directly rather than using the compiler driver. (Or at least
> it used to be that way).

'ld' is only used in one case, in Makefile.shared. That's for AIX, when
building shared objects directly from object files instead of going from the
static library. Therefore, trying to set LD makes absolutely no sense.

Also, please please please read INSTALL, it tells you what environment
variables are considered by the configuration scripts, and please please please
understand that our configuration scripts are not autoconf generated ones and
currently do not understand 'FOO=value' arguments. This has been pointed out
quite a few times already.

That being said, have you tried the following (the configuration scripts will
assume that any argument starting with a dash that they don't understand
internally are to be taken as C flags... this too has been pointed out before)?

./config -fuse-ld=gold

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Thu Jul 07 21:29:09 2016, levitte wrote:
> On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > /* Add to include/openssl/x509_vfy.h : */
> >
> > typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX
> > *ctx, X509 *x);
> > typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509
> > *x, X509 *issuer);
> >
> > void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> > X509_STORE_CTX_get_issuer
> > get_issuer);
> > X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> > *ctx);
> > void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> > X509_STORE_CTX_check_issued
> > check_issued);
> > X509_STORE_CTX_check_issued
> > X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);
>
> For this part, https://github.com/openssl/openssl/pull/1294

So, looking at this again after some sleep, there's a part of this solution
that I'm unsure of, and it all comes back to X509_STORE_CTX_init(), where the
X509_STORE context gets initialised from the X509_STORE, including all the
function pointers. This has me wonder if the X509_STORE_CTX setters should
really be made available (perhaps with the exception of the verify and
verify_cb ones). Doesn't it make more sense to set those function pointers when
creating the X509_STORE itself? Why would those functions need to be changed in
the context?

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> /* Add to some header file */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *ctx);
>
> /* Add to some implementation file */
>
> /* Add to crypto/x509/x509_lu.c */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *v)
> {
> return v->lock;
> }

https://github.com/openssl/openssl/pull/1295

> Repeat for other relevant classes with locks.

This has to be considered carefully. For most opaque types, it makes zero sense
to give out the lock. However, for opaque types that contain function pointers
that leads to user code, I can see scenarios where it does make sense.

For this case, I've only considered X509_STORE.

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> /* Add to include/openssl/x509v3.h */
>
> void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
>
>
> /* Add to crypto/x509v3/v3_purp.c */
>
> void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> {
> x->ex_flags |= ex_flags;
> }
>
> void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> {
> x->ex_flags &= ~ex_flags;
> }

This gives me the heebie jeebies. ex_flags is used a lot internally, and I
can't begin to imagine the consequences of letting external code manipulate
this. I understand that in some cases, it seems easy and quick, but...

So, if someone else wants to have a go at this and can make something sensible,
please be my guest. Me, I'm backing off from this particular idea.

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> /* Add to include/openssl/x509_vfy.h : */
>
> typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX
> *ctx, X509 *x);
> typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509
> *x, X509 *issuer);
>
> void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> X509_STORE_CTX_get_issuer
> get_issuer);
> X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> *ctx);
> void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> X509_STORE_CTX_check_issued
> check_issued);
> X509_STORE_CTX_check_issued
> X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);

For this part, https://github.com/openssl/openssl/pull/1294

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

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

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

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> Hi,
>
> I received the following bug in debian:
> https://bugs.debian.org/829272
>
>
> I got a lot of bugs filed about packages FTBFS with openssl 1.1.0.
> I started to look at some of them, and many of them are due too
> structures having been made opaque. In many cases accessors already
> exists, but definitely not for all.
>
> Here is a list of accessors I so far have identified as missing. The
> filenames given in the "Add to ..." comments below are suggestions
> based on where similar functions are defined and implemented.
>
>
> /* Add to include/openssl/x509_vfy.h : */
>
> typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX
> *ctx, X509 *x);
> typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509
> *x, X509 *issuer);
>
> void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> X509_STORE_CTX_get_issuer
> get_issuer);
> X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> *ctx);
> void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> X509_STORE_CTX_check_issued
> check_issued);
> X509_STORE_CTX_check_issued
> X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);

And I suppose that was only those that particular submitter needed. Looking at
crypto/include/internal/x509_int.h, I can see a whole lot more function
pointers that are unreachable.

> Regarding the new locking. Do I understand it correctly that e.g.
>
> CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
>
> should be replaced by something like
>
> CRYPTO_THREAD_write_lock(X509_STORE_get_lock(ctx));
>
> But then the accessors to get hold of the lock objects in the opaque
> structs are missing. E.g.
>
> /* Add to some header file */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *ctx);
>
> /* Add to some implementation file */
>
> /* Add to crypto/x509/x509_lu.c */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *v)
> {
> return v->lock;
> }
>
> Repeat for other relevant classes with locks.

I'll look into all of this.

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in OpenSSL RAND_poll() Is Ineffective

[Richard Levitte via RT]

On Tue Jul 05 22:38:44 2016, ncarb...@prodigitalsoftware.com wrote:
> Knowing that made all the difference, thank you. It wasn't clear since
> there's some evidence of "2.0" in the various downloads.

That's "openssl-fips" which is a FIPS module. Separate thing with its own
versioning.

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

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

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

[openssl-dev] [openssl.org #4604] Missing includes for ARM on Android

[Richard Levitte via RT]

What part of this is a bug in OpenSSL proper?

To me it looks like the classic issue when linking with static libraries, that
you have to explicitely specify the libraries that libcrypto and libssl depend
on.

Cheers,
Richard

On Mon Jul 04 23:40:25 2016, noloa...@gmail.com wrote:
> From http://stackoverflow.com/q/38192458/608639:
>
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigfillset'
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
> jni/openssl/lib/armeabi-v7a/libcrypto.a(armcap.o):armcap.c:function
> OPENSSL_cpuid_setup: error: undefined reference to 'sigdelset'
> jni/openssl/lib/armeabi-
> v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> open_console: error: undefined reference to 'tcgetattr'
> jni/openssl/lib/armeabi-
> v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'signal'
> jni/openssl/lib/armeabi-
> v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> jni/openssl/lib/armeabi-
> v7a/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> collect2: error: ld returned 1 exit status
> make[1]: *** [obj/local/armeabi-v7a/libpjsipjni.so] Error 1
> make[1]: *** Waiting for unfinished jobs
> jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> open_console: error: undefined reference to 'tcgetattr'
> jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'signal'
> jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> jni/openssl/lib/armeabi/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> collect2: error: ld returned 1 exit status
> make[1]: *** [obj/local/armeabi/libpjsipjni.so] Error 1
> jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> open_console: error: undefined reference to 'tcgetattr'
> jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'signal'
> jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> jni/openssl/lib/x86/libcrypto.a(ui_openssl.o):ui_openssl.c:function
> read_string_inner: error: undefined reference to 'tcsetattr'
> collect2: error: ld returned 1 exit status
> make[1]: *** [obj/local/x86/libpjsipjni.so] Error 1
> jni/openssl/lib/mips/libcrypto.a(ui_openssl.o): In function
> `open_console':
> ui_openssl.c:(.text.open_console+0xb4): undefined reference to
> `tcgetattr'
> jni/openssl/lib/mips/libcrypto.a(ui_openssl.o): In function
> `read_string_inner':
> ui_openssl.c:(.text.read_string_inner+0xf0): undefined reference to
> `signal'
> ui_openssl.c:(.text.read_string_inner+0x2c0): undefined reference to
> `tcsetattr'
> ui_openssl.c:(.text.read_string_inner+0x39c): undefined reference to
> `tcsetattr'
> collect2: error: ld returned 1 exit status


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

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

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

[openssl-dev] [openssl.org #4598] OpenSSL fails to Configure on Windows 10

[Richard Levitte via RT]

On Fri Jul 01 23:31:45 2016, noloa...@gmail.com wrote:
> On Wed, Jun 29, 2016 at 5:19 PM, Richard Levitte via RT
> <r...@openssl.org> wrote:
> > This has nothing to do with Windows 10 per se, it's the space-in-
> > directory
> > issue that's come back.
> > I'm working on a solution that should avoid that problem more
> > consistently,
> > going forward.
>
> Close it; its good as of fe964f0c88f6780fd30b26e306484b981b0a8480.

Done

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

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

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

[openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir

[Richard Levitte via RT]

That's correct for 1.1.0. install_sw honors --prefix. We made that change to
get away from all the weird magic around the combinations of --prefix and
--openssldir that happened in previous versions.

In other words, it's not a bug, it's a feature. Closing this ticket.

Cheers,
Richard

On Thu Jun 30 14:31:33 2016, noloa...@gmail.com wrote:
> Working on OS 10.8.5. Working from Master,
> 8a3c000c8f621cd01929313fcb7d0cc23fb516a6.
>
> Using the following configure line:
>
> $ KERNEL_BITS=64 ./config no-shared enable-ec_nistp_64_gcc_128
> --openssldir=/usr/local/ssl/1.1.0
>
> Later, when I attempt to compile:
>
> $ gcc -I/usr/local/ssl/1.1.0/include test.cc -o test.exe
> /usr/local/ssl/1.1.0/lib/libcrypto.a
> clang: error: no such file or directory:
> '/usr/local/ssl/1.1.0/lib/libcrypto.a'
>
> And:
>
> $ ls /usr/local/ssl/1.1.0/
> misc
>
> **
>
> $ sudo make install_sw
> /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \
> "-oMakefile" crypto/include/internal/bn_conf.h.in >
> crypto/include/internal/bn_conf.h
> /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \
> "-oMakefile" crypto/include/internal/dso_conf.h.in >
> crypto/include/internal/dso_conf.h
> /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \
> "-oMakefile" include/openssl/opensslconf.h.in >
> include/openssl/opensslconf.h
> /opt/local/bin/perl5.22 util/mkbuildinf.pl "cc -DDSO_DLFCN
> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE
> -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM -DPOLY1305_ASM
> -DOPENSSLDIR=\"\\\"/usr/local/ssl/1.1.0\\\"\"
> -DENGINESDIR=\"\\\"/usr/local/lib/engines\\\"\" " "darwin64-x86_64-cc"
> > crypto/buildinf.h
> cc -Iinclude -I. -Icrypto/include -Icrypto -DDSO_DLFCN -DHAVE_DLFCN_H
> -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl/1.1.0\""
> -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch
> x86_64 -DL_ENDIAN -Wall -fPIC -MMD -MF crypto/cversion.d.tmp -MT
> crypto/cversion.o -c -o crypto/cversion.o crypto/cversion.c
> ar r libcrypto.a crypto/cversion.o
> /usr/bin/ranlib: file: libcrypto.a(async_null.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(async_win.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(cms_cd.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(dso_dl.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(dso_openssl.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(dso_vms.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(dso_win32.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(ebcdic.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(e_rc5.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(m_md2.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(rand_egd.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(rand_vms.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(rand_win.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(threads_none.o) has no symbols
> /usr/bin/ranlib: file: libcrypto.a(threads_win.o) has no symbols
> ranlib -c libcrypto.a || echo Never mind.
> ranlib: file: libcrypto.a(async_null.o) has no symbols
> ranlib: file: libcrypto.a(async_win.o) has no symbols
> ranlib: file: libcrypto.a(cms_cd.o) has no symbols
> ranlib: file: libcrypto.a(dso_dl.o) has no symbols
> ranlib: file: libcrypto.a(dso_openssl.o) has no symbols
> ranlib: file: libcrypto.a(dso_vms.o) has no symbols
> ranlib: file: libcrypto.a(dso_win32.o) has no symbols
> ranlib: file: libcrypto.a(ebcdic.o) has no symbols
> ranlib: file: libcrypto.a(e_rc5.o) has no symbols
> ranlib: file: libcrypto.a(m_md2.o) has no symbols
> ranlib: file: libcrypto.a(rand_egd.o) has no symbols
> ranlib: file: libcrypto.a(rand_vms.o) has no symbols
> ranlib: file: libcrypto.a(rand_win.o) has no symbols
> ranlib: file: libcrypto.a(threads_none.o) has no symbols
> ranlib: file: libcrypto.a(threads_win.o) has no symbols
> rm -f apps/openssl
> make -f ./Makefile.shared -e \
> PERL="/opt/local/bin/perl5.22" SRCDIR=. \
> APPNAME=apps/openssl OBJECTS="apps/app_rand.o apps/apps.o
> apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o
> apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o
> apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o
> apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o
> apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o
> apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o
> apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o
> apps/s_cb.o apps/s_client.o 

[openssl-dev] [openssl.org #1852] Invalid Proxy Certificates Pass Validation

[Richard Levitte via RT]

On Wed Jun 29 21:16:31 2016, levitte wrote:
> On Mon Jun 20 19:37:41 2016, levitte wrote:
> > On Tue Feb 02 01:44:47 2016, openssl-dev@openssl.org wrote:
> > > On Mon, Feb 01, 2016 at 07:18:04PM +, Rich Salz via RT wrote:
> > >
> > > > This is reported against 0.9.x; please open a new ticket if still a
> > > > problem
> > > > with current releases.
> > >
> > > The same behaviour is present in all releases including master.
> > > I don't see any code in OpenSSL that imposes any constraints on
> > > the subject names of proxy certificates.
> > >
> > > If strict adherence to the rules in RFC3820 is important for security
> > > (I don't where proxy certs are used and what real semantics
> > > applications expect), then this issue remains to be addressed.
> > >
> > > Perhaps reopen this one.
> >
> > This has now been fixed in master, along with a pc pathlength checking
> > bug fix.
> >
> > The backport to 1.0.2 (and possibly 1.0.1) is still pending review.
>
> Fix merged into 1.0.2

... and finally, fix merged into the 1.0.1 branch as well

That closes this ticket.

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4598] OpenSSL fails to Configure on Windows 10

[Richard Levitte via RT]

This has nothing to do with Windows 10 per se, it's the space-in-directory
issue that's come back.
I'm working on a solution that should avoid that problem more consistently,
going forward.

Cheers,
Richard

On Wed Jun 29 09:04:12 2016, noloa...@gmail.com wrote:
> Working on a Windows 10, 32-bit netbook. HEAD,
> 03cb37acec0c23a01bee4357cd59ec9f97e528ba.
>
> It looks like configure dies if it can't find NASM. Perhpas it would
> be better to automatically add no-asm.
>
> Once NASM is added, Configure dies because it tries to write outside
> %HOME%. Windows 8 used to tolerate it and create the directories, but
> Windows 10 returns the access denied.
>
> A small nit: "Configure LIST" does not list VC-WIN32, VC-WIN64A or
> VC-WIN64I. VC-WIN32 is present in WIN.NOTES, but the other selections
> are also missing.
>
> Also, the configuration target VC-WIN32 is listed twice in WIN.NOTES,
> which appears to be a copy/paste error. If I am parsing things
> correctly, one of them should be VC-WIN32 and the other should be
> VC-WIN64A or VC-WIN64I.
>
> **
>
> C:\Users\Jeffrey Walton\openssl>perl .\Configure VC-WIN32
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> no-asan [default] OPENSSL_NO_ASAN (skip dir)
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [default]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
> (skip dir)
> no-egd [default] OPENSSL_NO_EGD (skip dir)
> no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir)
> no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
> no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
> no-sctp [default] OPENSSL_NO_SCTP (skip dir)
> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir)
> no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir)
> no-ubsan [default] OPENSSL_NO_UBSAN (skip dir)
> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip
> dir)
> no-zlib [default]
> no-zlib-dynamic [default]
> Configuring for VC-WIN32
> NASM not found - please read INSTALL and NOTES.WIN for further details
>
> C:\Users\Jeffrey Walton\openssl>perl .\Configure VC-WIN32 no-asm
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> no-asan [default] OPENSSL_NO_ASAN (skip dir)
> no-asm [option] OPENSSL_NO_ASM
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [default]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
> (skip dir)
> no-egd [default] OPENSSL_NO_EGD (skip dir)
> no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir)
> no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
> no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
> no-sctp [default] OPENSSL_NO_SCTP (skip dir)
> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir)
> no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir)
> no-ubsan [default] OPENSSL_NO_UBSAN (skip dir)
> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip
> dir)
> no-zlib [default]
> no-zlib-dynamic [default]
> Configuring for VC-WIN32
> mkdir C:\Users\Jeffrey: Permission denied; Access is denied at
> .\Configure line 1314.
>
> C:\Users\Jeffrey Walton\openssl>


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

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

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

[openssl-dev] [openssl.org #1852] Invalid Proxy Certificates Pass Validation

[Richard Levitte via RT]

On Mon Jun 20 19:37:41 2016, levitte wrote:
> On Tue Feb 02 01:44:47 2016, openssl-dev@openssl.org wrote:
> > On Mon, Feb 01, 2016 at 07:18:04PM +, Rich Salz via RT wrote:
> >
> > > This is reported against 0.9.x; please open a new ticket if still a
> > > problem
> > > with current releases.
> >
> > The same behaviour is present in all releases including master.
> > I don't see any code in OpenSSL that imposes any constraints on
> > the subject names of proxy certificates.
> >
> > If strict adherence to the rules in RFC3820 is important for security
> > (I don't where proxy certs are used and what real semantics
> > applications expect), then this issue remains to be addressed.
> >
> > Perhaps reopen this one.
>
> This has now been fixed in master, along with a pc pathlength checking
> bug fix.
>
> The backport to 1.0.2 (and possibly 1.0.1) is still pending review.

Fix merged into 1.0.2

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure

[Richard Levitte via RT]

Like Rich says, our build system in 1.0.2 doesn't support parallell building or
testing. For upcoming 1.1.0, the build system has been remade from the ground
up, with parallell building in mind. Parallell testing hasn't been tested there
either, though... it might work, it might not. However, the '-j' option for
make till not affect the parallellism of testing in any way.

Closing this ticket.

Cheers,
Richard

On Tue Jun 21 13:14:12 2016, pmen...@molgen.mpg.de wrote:
> Dear OpenSSL folks,
>
>
> downloading the latest 1.0.1t release [1], building it, and running the
> tests in parallel I get the failure below.
>
> I am able to reproduce this, with the branch.*OpenSSL_1_0_2-stable* [2],
> but not with the branch *master*.
>
> With `-j1` and `-j2` the failure is unreproducible. With `-j3` it
> sometimes works and sometimes fails. With `-j4` and greater it reliably
> fails.
>
> ```
> ...long/negative scalar tests allowing precomputation ... without
> precomputation ... ok
> combined multiplication p -> p
> d -> d
> .camellia-128-cbc
> ..n -> d
> ..p -> d
> .camellia-128-cbc base64
> .d -> n
> ...n -> n
> ok
>
> ..testing internal curves: ..camellia-128-ecb
> ..p -> n
> d -> p
> ..n -> p
> .p -> p
> ... ok
>
> camellia-128-ecb base64
> .rsa
> .testing rsa conversions
> p -> d
> .Parsing test certificates
> ...camellia-192-cbc
> p -> p
> OK
> .camellia-192-cbc base64
> d -> d
> .testing crl conversions
> p -> d
> ..p -> d
> ..p -> p
> .camellia-192-ecb
> .d -> p
> ..p -> p
> d -> d
> ...p -> d
> camellia-192-ecb base64
> ..d -> p
> .../util/shlib_wrap.sh ./rsa_test
> ..p -> p
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> ..camellia-256-cbc
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> .PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> ...testing session-id conversions
> p -> d
> ..p -> p
> ..d -> d
> ..camellia-256-cbc base64
> .p -> d
> ...PKCS #1 v1.5 encryption/decryption ok
> d -> p
> OAEP encryption/decryption ok
> .camellia-256-ecb
> ...PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> p -> p
> ...PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> ...camellia-256-ecb base64
> Generate and verify a certificate request
> .generating certificate request
> ...rsa
> .There should be a 2 sequences of .'s and some +'s.
> There should not be more that at most 80 per line
> This could take some time.
> cast
> ..Generating a 1024 bit RSA private key
> .cast base64
> ++
> ..cast-cbc
> ..testing req conversions
> ..p -> d
> ...cast-cbc base64
> .Makefile:237: recipe for target 'test_req' failed
> make[1]: *** [test_req] Error 1
> make[1]: *** Waiting for unfinished jobs
> ```
>
>
> Thanks,
>
> Paul
>
>
> PS: I am sorry, if Mozilla Thunderbird wraps the pasted lines.
>
>
> [1] https://www.openssl.org/source/openssl-1.0.1t.tar.gz
> [2] OpenSSL_1_0_2h-88-g4824496 (Fix missing opening braces)
> [3] 6feb3c5 Avoid using latest clang since repo not available
>


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

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

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

[openssl-dev] [openssl.org #1852] [BUG] Invalid Proxy Certificates Pass Validation

[Richard Levitte via RT]

On Tue Feb 02 01:44:47 2016, openssl-dev@openssl.org wrote:
> On Mon, Feb 01, 2016 at 07:18:04PM +, Rich Salz via RT wrote:
>
> > This is reported against 0.9.x; please open a new ticket if still a
> > problem
> > with current releases.
>
> The same behaviour is present in all releases including master.
> I don't see any code in OpenSSL that imposes any constraints on
> the subject names of proxy certificates.
>
> If strict adherence to the rules in RFC3820 is important for security
> (I don't where proxy certs are used and what real semantics
> applications expect), then this issue remains to be addressed.
>
> Perhaps reopen this one.

This has now been fixed in master, along with a pc pathlength checking bug fix.

The backport to 1.0.2 (and possibly 1.0.1) is still pending review.

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4575] 1.0.2 stable branch: .\apps\speed.c(335): error C2065: 'err': undeclared identifier

[Richard Levitte via RT]

Thanks.

Fixup currently in https://github.com/openssl/openssl/pull/1220, pending
approval.

Cheers,
Richard

On Thu Jun 16 02:29:22 2016, simon.rich...@hogyros.de wrote:
> Hi,
>
> the 1.0.2 branch fails to compile on VC-WIN32:
>
> .\apps\speed.c(335): error C2065: 'err': undeclared identifier
>
> The responsible commit is
>
>
https://github.com/openssl/openssl/commit/75f90688fb2dec0f897cad8be8b92be725c5016b
>
> - ExitProcess(ret);
> + TerminateProcess(GetCurrentProcess(), err);
>
> Simon


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

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

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

[openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS

[Richard Levitte via RT]

Cool. That closes this ticket.

BTW, you're right, we don't honor a CFLAGS env var. We never did. We take the
cflags on the configuration command line.

Cheers,
Richard

On Tue Jun 14 07:35:11 2016, noloa...@gmail.com wrote:
> On Tue, Jun 14, 2016 at 3:33 AM, Richard Levitte via RT
> <r...@openssl.org> wrote:
> > Is this enough to satisfy you?
> >
> > ./config -DNDEBUG -g3 -O0
>
> Yes, that would be good.
>
> no-asm and no-omit-frame-pointer on x86 may be good choices, too.
>
> Jeff
>
> > On Tue Jun 14 07:24:31 2016, noloa...@gmail.com wrote:
> >> Working from latest sources. I'm trying to build a "debug"
> >> configuration with both -DNDEBUG (I don't want asserts firing) and
> >> -g3
> >> (I want the symbolic constants).
> >>
> >> $ ./config no-asm -g3 -O0 -fno-omit-frame-pointer
> >> Operating system: i86pc-whatever-solaris2
> >> Configuring for solaris64-x86_64-gcc
> >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> >> ...
> >> CC =gcc
> >> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -g3 -O0
> >> -fno-omit-frame-pointer
> >> ...
> >>
> >>
> >> And:
> >>
> >> $ export CFLAGS="-DNDEBUG -g3 -O0"
> >> $ ./config
> >> Operating system: i86pc-whatever-solaris2
> >> Configuring for solaris64-x86_64-gcc
> >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> >> ...
> >> CC =gcc
> >> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,--
> >> noexecstack
> >> SHARED_CFLAG =-fPIC
> >> ...


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

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

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

[openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS

[Richard Levitte via RT]

Is this enough to satisfy you?

./config -DNDEBUG -g3 -O0

On Tue Jun 14 07:24:31 2016, noloa...@gmail.com wrote:
> Working from latest sources. I'm trying to build a "debug"
> configuration with both -DNDEBUG (I don't want asserts firing) and -g3
> (I want the symbolic constants).
>
> $ ./config no-asm -g3 -O0 -fno-omit-frame-pointer
> Operating system: i86pc-whatever-solaris2
> Configuring for solaris64-x86_64-gcc
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> ...
> CC =gcc
> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -g3 -O0
> -fno-omit-frame-pointer
> ...
>
>
> And:
>
> $ export CFLAGS="-DNDEBUG -g3 -O0"
> $ ./config
> Operating system: i86pc-whatever-solaris2
> Configuring for solaris64-x86_64-gcc
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> ...
> CC =gcc
> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,--
> noexecstack
> SHARED_CFLAG =-fPIC
> ...


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

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

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

[openssl-dev] [openssl.org #3772] Bug: Only ActivePerl could be used to build on Windows

[Richard Levitte via RT]

Apologies for the delay before responding.

I believe we have fixed that by replacing 'chomp' with 's|\R$||' in the master
branch.

It this is still an issue, please open a new ticket.

Cheers,
Richard

On Mon Mar 30 07:51:29 2015, esado...@eniks.com wrote:
> It is well known issue with build on Windows: It requires ActivePerl
> to
> correctly create configuration.
> Every other Perl implementation fails to execute correctly. The reason
> it
> fails outlined in this report:
> https://github.com/openssl/openssl/issues/174
> Although it is stated that only cloned code exhibits this behavior I
> believe
> it also happens when Git or Strawberry Perl is being used for build of
> official releases.
>
> As suggested in the comments adding $/= "\r\n"; line to Perl script
> fixes this
> issue for every other Perl implementation.
> I've successfully built openssl with Perl distributed with Git as well
> as
> Strawberry Perl.


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

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

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

[openssl-dev] [openssl.org #4557] Nit: temporary files left over after [master:8d054a5] installation process

[Richard Levitte via RT]

Thank you! Found the tests that generated this and made sure the temporary
files get removed.

Please get a fresh checkout of the master branch and check again.

Closing this ticket.

Cheers,
Richard

On Thu Jun 02 15:50:32 2016, stef...@sdaoden.eu wrote:
> Yep:
>
> -rw--- 1 steffen steffen 1848 Jun 2 14:46 VhXl383LiQ
> -rw--- 1 steffen steffen 1612 Jun 2 14:46 F1RkvxEZi0
> -rw--- 1 steffen steffen 1848 Jun 2 14:46 qg_wML0XIF
> -rw--- 1 steffen steffen 1848 Jun 2 14:46 4MUN7KIs69
> -rw--- 1 steffen steffen 1840 Jun 2 14:46 fU_zMQI7Wb
> -rw--- 1 steffen steffen 1848 Jun 2 14:46 gbNE7UjUAJ
> -rw--- 1 steffen steffen 1848 Jun 2 14:46 P2Vff7Duiz
> -rw--- 1 steffen steffen 1840 Jun 2 14:46 3E_oztoePh
>
> ;do head -n 1 $i; done:
>
> -BEGIN SSL SESSION PARAMETERS-
> -BEGIN SSL SESSION PARAMETERS-
> -BEGIN SSL SESSION PARAMETERS-
> -BEGIN SSL SESSION PARAMETERS-
> -BEGIN SSL SESSION PARAMETERS-
> -BEGIN SSL SESSION PARAMETERS-
> -BEGIN SSL SESSION PARAMETERS-
> -BEGIN SSL SESSION PARAMETERS-
>
> --steffen
>


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

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

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

[openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process

[Richard Levitte via RT]

On Thu Jun 02 15:50:31 2016, stef...@sdaoden.eu wrote:
> Hello.
>
> I have never seen something like this:
>
> Parser.c: loadable library and perl binaries are mismatched (got
> handshake key 0xdb00080, needed 0xdb80080)
>
> This is v5.24 on a Linux system, and it flawless afaik.

Are you sure that you don't have perl modules that you installed separately
with an earlier perl version? You may need to update those.

Either way, this is not an OpenSSL issue, it's a perl one. Closing this ticket.

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

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

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

[openssl-dev] [openssl.org #4555] Enhancement request: allow installation without manuals, but anyway without HTML manuals

[Richard Levitte via RT]

On Thu Jun 02 15:50:31 2016, stef...@sdaoden.eu wrote:
> Oh yes, please!

The 'install' target calls three other targets:

install_sw
install_ssldirs
install_docs

So if you simple do 'make install_sw' or 'nmake install_sw', I think you'll get
what you want.

Closing this ticket.

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

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

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

[openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols

[Richard Levitte via RT]

Applied and merged into master. Thank you.

Closing this ticket.

Cheers,
Richard

On Wed Jun 01 22:31:14 2016, sebast...@breakpoint.cc wrote:
> On 2016-05-30 21:28:06 [+], Andy Polyakov via RT wrote:
> > For what it's worth I can't reproduce problem on Fedora or RedHat.
>
> The test
> |…
> |# The following symbols are missing in libcrypto.so:
> |# _shadow_DES_check_key
> |not ok 2 - check that there are no missing symbols in libcrypto.so
> |…
>
> So it is about DES_check_key which is the only variable using
> OPENSSL_IMPLEMENT_GLOBAL (and I don't see it beeing used).
>
> On x86-64 :
> | $ nm -Pg crypto/des/set_key.o|grep _shadow_DES_check_key
> | _shadow_DES_check_key B  0004
>
> and on powerpc I get:
> | $ nm -Pg crypto/des/set_key.o|grep _shadow_DES_check_key
> | _shadow_DES_check_key S  0004
>
> and this fixes it:
>
> --- a/test/recipes/01-test_symbol_presence.t
> +++ b/test/recipes/01-test_symbol_presence.t
> @@ -57,7 +57,7 @@ foreach my $libname (@libnames) {
> note "Number of lines in \@def_lines before massaging: ",
> scalar @def_lines;
>
> # Massage the nm output to only contain defined symbols
> - @nm_lines = sort map { s| .*||; $_ } grep(m|.* [BCDT] .*|,
> @nm_lines);
> + @nm_lines = sort map { s| .*||; $_ } grep(m|.* [BCDST] .*|,
> @nm_lines);
>
> # Massage the mkdef.pl output to only contain global symbols
> # The output we got is in Unix .map format, which has a global
>
> I make a proper pull req later…
>
> Sebastian


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

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

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

[openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type

[Richard Levitte via RT]

On Wed Jun 01 22:45:08 2016, noloa...@gmail.com wrote:
> On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT
> <r...@openssl.org> wrote:
> > Please give us the full configuration command you used, including
> > environment
> > variables that may affect it. Just the presence of '-ansi' tells me
> > that you
> > didn't just say './config' without any arguments.
>
> I know what happened here... I'm working on OS X, and I built the ISO
> from OpenSSL's git. Those are OS X artifacts that were added to the
> ISO.
>
> Shouldn't a new configure clear that sort of thing? (We no longer have
> 'make dclean' to prepare the sources).

If you want a pristine git workspace, I suggest using the following:

git clean -dfx

Cheers,
Richard

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

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

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

[openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type

[Richard Levitte via RT]

Does it make a difference if you add 'no-sse2' to your configuration command?

On Wed Jun 01 21:22:24 2016, noloa...@gmail.com wrote:
> On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT
> <r...@openssl.org> wrote:
> > Please give us the full configuration command you used, including
> > environment
> > variables that may affect it. Just the presence of '-ansi' tells me
> > that you
> > didn't just say './config' without any arguments.
>
> Sorry Richard. Yes, it was a straight "./config" followed by a "make".
>
> I deleted the the openssl directory and started over. Previously I
> just unzipped overtop the old installation. I'm guessing something was
> misconfigured because I get further now.
>
> Here's the new issue: chacha-x86.s assembler problems,
> http://postimg.org/image/sl28mxfmz/.
>
> I also "git pull" followed by a new ISO build for the VM. Same result.
>
> Jeff
>
> > On Wed Jun 01 19:54:51 2016, noloa...@gmail.com wrote:
> >> So testing with 1.1.0-pre6 from 1 JUN 2016 appears to show some new
> >> issues.
> >>
> >> ./config detects as i686-linux-whatever. However, there are some
> >> issues with CFLAGS. The '-arch x86_64' makes it appear to be
> >> configured for quasi-OS X mode. I believe -m32 should be used if an
> >> arch is needed. There's also some complaints about -c and -o, but I
> >> think the compiler confusion starts earlier.
> >>
> >> Here's a screen capture of the error:
> >> http://postimg.org/image/e9nvrko17/ .
> >>
> >> My apologies for the screen capture. I kind of cheat and get the
> >> tarball onto the VM by building an ISO and mounting it with the
> >> CDROM.
> >> I have not figured out how to get data to travel the other way.
> >>
> >> Jeff
> >>
> >> On Sun, Mar 20, 2016 at 8:31 AM, Jeffrey Walton <noloa...@gmail.com>
> >> wrote:
> >> > I know this is kind of an old machine with GCC 3.3...
> >> >
> >> > With an updated PERL and a './config no-asm -D_XOPEN_SOURCE=600',
> >> > I
> >> > can almost get through a compile. After libcrypto.a is built, the
> >> > next
> >> > compile line is:
> >> >
> >> > gcc ... -c -o ssl/bio_ssl.o ssl/bio_ssl.c
> >> >
> >> > At that point, there's a:
> >> >
> >> > In file included from ssl/bio_ssl.c:65
> >> > ssl/ssl_locl.h:1501: error: field `next_timeout` has incomplete
> >> > type
> >> > [ssl/bio_ssl.o] Error 1
> >> >
> >> > The issue was cleared by adding  to "ssl/ssl_locl.h".
> >> >
> >> > **
> >> >
> >> > ar r libcrypto.a crypto/aes/aes_cbc.o crypto/aes/aes_cfb.o
> >> > crypto/aes/aes_core.o crypto/aes/aes_ecb.o crypto/aes/aes_ige.o
> >> > crypto/aes/aes_misc.o crypto/aes/aes_ofb.o crypto/aes/aes_wrap.o
> >> > crypto/asn1/a_bitstr.o crypto/asn1/a_d2i_fp.o
> >> > crypto/asn1/a_digest.o
> >> > crypto/asn1/a_dup.o crypto/asn1/a_gentm.o crypto/asn1/a_i2d_fp.o
> >> > crypto/asn1/a_int.o crypto/asn1/a_mbstr.o crypto/asn1/a_object.o
> >> > crypto/asn1/a_octet.o crypto/asn1/a_print.o crypto/asn1/a_sign.o
> >> > crypto/asn1/a_strex.o crypto/asn1/a_strnid.o crypto/asn1/a_time.o
> >> > crypto/asn1/a_type.o crypto/asn1/a_utctm.o crypto/asn1/a_utf8.o
> >> > crypto/asn1/a_verify.o crypto/asn1/ameth_lib.o
> >> > crypto/asn1/asn1_err.o
> >> > crypto/asn1/asn1_gen.o crypto/asn1/asn1_lib.o
> >> > crypto/asn1/asn1_par.o
> >> > crypto/asn1/asn_mime.o crypto/asn1/asn_moid.o
> >> > crypto/asn1/asn_mstbl.o
> >> > crypto/asn1/asn_pack.o crypto/asn1/bio_asn1.o
> >> > crypto/asn1/bio_ndef.o
> >> > crypto/asn1/d2i_pr.o crypto/asn1/d2i_pu.o crypto/asn1/evp_asn1.o
> >> > crypto/asn1/f_int.o crypto/asn1/f_string.o crypto/asn1/i2d_pr.o
> >> > crypto/asn1/i2d_pu.o crypto/asn1/n_pkey.o crypto/asn1/nsseq.o
> >> > crypto/asn1/p5_pbe.o crypto/asn1/p5_pbev2.o
> >> > crypto/asn1/p5_scrypt.o
> >> > crypto/asn1/p8_pkey.o crypto/asn1/t_bitst.o crypto/asn1/t_pkey.o
> >> > crypto/asn1/t_spki.o crypto/asn1/tasn_dec.o crypto/asn1/tasn_enc.o
> >> > crypto/asn1/tasn_fre.o crypto/asn1/tasn_new.o
> >> > crypto/asn1/tasn_prn.o
> >> > crypto/asn1/tasn_scn.o crypto/asn1/tasn_typ.o
> >> > crypto/asn1/tasn_utl.o
> >> > crypto/asn1/x_algor.o crypto/asn1/x_bignum.o 

[openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type

[Richard Levitte via RT]

Please give us the full configuration command you used, including environment
variables that may affect it. Just the presence of '-ansi' tells me that you
didn't just say './config' without any arguments.

On Wed Jun 01 19:54:51 2016, noloa...@gmail.com wrote:
> So testing with 1.1.0-pre6 from 1 JUN 2016 appears to show some new issues.
>
> ./config detects as i686-linux-whatever. However, there are some
> issues with CFLAGS. The '-arch x86_64' makes it appear to be
> configured for quasi-OS X mode. I believe -m32 should be used if an
> arch is needed. There's also some complaints about -c and -o, but I
> think the compiler confusion starts earlier.
>
> Here's a screen capture of the error: http://postimg.org/image/e9nvrko17/ .
>
> My apologies for the screen capture. I kind of cheat and get the
> tarball onto the VM by building an ISO and mounting it with the CDROM.
> I have not figured out how to get data to travel the other way.
>
> Jeff
>
> On Sun, Mar 20, 2016 at 8:31 AM, Jeffrey Walton  wrote:
> > I know this is kind of an old machine with GCC 3.3...
> >
> > With an updated PERL and a './config no-asm -D_XOPEN_SOURCE=600', I
> > can almost get through a compile. After libcrypto.a is built, the next
> > compile line is:
> >
> > gcc ... -c -o ssl/bio_ssl.o ssl/bio_ssl.c
> >
> > At that point, there's a:
> >
> > In file included from ssl/bio_ssl.c:65
> > ssl/ssl_locl.h:1501: error: field `next_timeout` has incomplete type
> > [ssl/bio_ssl.o] Error 1
> >
> > The issue was cleared by adding  to "ssl/ssl_locl.h".
> >
> > **
> >
> > ar r libcrypto.a crypto/aes/aes_cbc.o crypto/aes/aes_cfb.o
> > crypto/aes/aes_core.o crypto/aes/aes_ecb.o crypto/aes/aes_ige.o
> > crypto/aes/aes_misc.o crypto/aes/aes_ofb.o crypto/aes/aes_wrap.o
> > crypto/asn1/a_bitstr.o crypto/asn1/a_d2i_fp.o crypto/asn1/a_digest.o
> > crypto/asn1/a_dup.o crypto/asn1/a_gentm.o crypto/asn1/a_i2d_fp.o
> > crypto/asn1/a_int.o crypto/asn1/a_mbstr.o crypto/asn1/a_object.o
> > crypto/asn1/a_octet.o crypto/asn1/a_print.o crypto/asn1/a_sign.o
> > crypto/asn1/a_strex.o crypto/asn1/a_strnid.o crypto/asn1/a_time.o
> > crypto/asn1/a_type.o crypto/asn1/a_utctm.o crypto/asn1/a_utf8.o
> > crypto/asn1/a_verify.o crypto/asn1/ameth_lib.o crypto/asn1/asn1_err.o
> > crypto/asn1/asn1_gen.o crypto/asn1/asn1_lib.o crypto/asn1/asn1_par.o
> > crypto/asn1/asn_mime.o crypto/asn1/asn_moid.o crypto/asn1/asn_mstbl.o
> > crypto/asn1/asn_pack.o crypto/asn1/bio_asn1.o crypto/asn1/bio_ndef.o
> > crypto/asn1/d2i_pr.o crypto/asn1/d2i_pu.o crypto/asn1/evp_asn1.o
> > crypto/asn1/f_int.o crypto/asn1/f_string.o crypto/asn1/i2d_pr.o
> > crypto/asn1/i2d_pu.o crypto/asn1/n_pkey.o crypto/asn1/nsseq.o
> > crypto/asn1/p5_pbe.o crypto/asn1/p5_pbev2.o crypto/asn1/p5_scrypt.o
> > crypto/asn1/p8_pkey.o crypto/asn1/t_bitst.o crypto/asn1/t_pkey.o
> > crypto/asn1/t_spki.o crypto/asn1/tasn_dec.o crypto/asn1/tasn_enc.o
> > crypto/asn1/tasn_fre.o crypto/asn1/tasn_new.o crypto/asn1/tasn_prn.o
> > crypto/asn1/tasn_scn.o crypto/asn1/tasn_typ.o crypto/asn1/tasn_utl.o
> > crypto/asn1/x_algor.o crypto/asn1/x_bignum.o crypto/asn1/x_info.o
> > crypto/asn1/x_long.o crypto/asn1/x_pkey.o crypto/asn1/x_pubkey.o
> > crypto/asn1/x_sig.o crypto/asn1/x_spki.o crypto/asn1/x_val.o
> > crypto/async/arch/async_null.o crypto/async/arch/async_posix.o
> > crypto/async/arch/async_win.o crypto/async/async.o
> > crypto/async/async_err.o crypto/async/async_wait.o
> > crypto/bf/bf_cfb64.o crypto/bf/bf_ecb.o crypto/bf/bf_enc.o
> > crypto/bf/bf_ofb64.o crypto/bf/bf_skey.o crypto/bio/b_addr.o
> > crypto/bio/b_dump.o crypto/bio/b_print.o crypto/bio/b_sock.o
> > crypto/bio/b_sock2.o crypto/bio/bf_buff.o crypto/bio/bf_nbio.o
> > crypto/bio/bf_null.o crypto/bio/bio_cb.o crypto/bio/bio_err.o
> > crypto/bio/bio_lib.o crypto/bio/bss_acpt.o crypto/bio/bss_bio.o
> > crypto/bio/bss_conn.o crypto/bio/bss_dgram.o crypto/bio/bss_fd.o
> > crypto/bio/bss_file.o crypto/bio/bss_log.o crypto/bio/bss_mem.o
> > crypto/bio/bss_null.o crypto/bio/bss_sock.o crypto/blake2/blake2b.o
> > crypto/blake2/blake2s.o crypto/blake2/m_blake2b.o
> > crypto/blake2/m_blake2s.o crypto/bn/bn_add.o crypto/bn/bn_asm.o
> > crypto/bn/bn_blind.o crypto/bn/bn_const.o crypto/bn/bn_ctx.o
> > crypto/bn/bn_depr.o crypto/bn/bn_dh.o crypto/bn/bn_div.o
> > crypto/bn/bn_err.o crypto/bn/bn_exp.o crypto/bn/bn_exp2.o
> > crypto/bn/bn_gcd.o crypto/bn/bn_gf2m.o crypto/bn/bn_intern.o
> > crypto/bn/bn_kron.o crypto/bn/bn_lib.o crypto/bn/bn_mod.o
> > crypto/bn/bn_mont.o crypto/bn/bn_mpi.o crypto/bn/bn_mul.o
> > crypto/bn/bn_nist.o crypto/bn/bn_prime.o crypto/bn/bn_print.o
> > crypto/bn/bn_rand.o crypto/bn/bn_recp.o crypto/bn/bn_shift.o
> > crypto/bn/bn_sqr.o crypto/bn/bn_sqrt.o crypto/bn/bn_srp.o
> > crypto/bn/bn_word.o crypto/bn/bn_x931p.o crypto/buffer/buf_err.o
> > crypto/buffer/buffer.o crypto/camellia/camellia.o
> > crypto/camellia/cmll_cbc.o crypto/camellia/cmll_cfb.o
> > crypto/camellia/cmll_ctr.o crypto/camellia/cmll_ecb.o
> > 

[openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests

[Richard Levitte via RT]

Please try this and send us the result:

make test TESTS=test_afalg VERBOSE=1

On Wed Jun 01 19:15:47 2016, noloa...@gmail.com wrote:
> It looks like there's still some problems with our old friend afalgtest.
>
> Below is from 1.1.0-pre6 on 1 JUN 2016
>
> **
>
> $ cat gentoo-result.txt
> ( cd test; \
> SRCTOP=../. \
> BLDTOP=../. \
> PERL="/usr/bin/perl" \
> EXE_EXT= \
> OPENSSL_ENGINES=.././engines \
> /usr/bin/perl .././test/run_tests.pl )
> sh: line 1: 27759 Aborted ../util/shlib_wrap.sh
> ./aborttest 2> /dev/null
> ../test/recipes/01-test_abort.t  ok
> ../test/recipes/01-test_ordinals.t . ok
> ../test/recipes/01-test_symbol_presence.t .. ok
> ../test/recipes/05-test_bf.t ... ok
> ../test/recipes/05-test_cast.t . ok
> ../test/recipes/05-test_des.t .. ok
> ../test/recipes/05-test_hmac.t . ok
> ../test/recipes/05-test_idea.t . ok
> ../test/recipes/05-test_md2.t .. skipped: md2 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_md4.t .. ok
> ../test/recipes/05-test_md5.t .. ok
> ../test/recipes/05-test_mdc2.t . ok
> ../test/recipes/05-test_rand.t . ok
> ../test/recipes/05-test_rc2.t .. ok
> ../test/recipes/05-test_rc4.t .. ok
> ../test/recipes/05-test_rc5.t .. skipped: rc5 is not
> supported by this OpenSSL build
> ../test/recipes/05-test_rmd.t .. ok
> ../test/recipes/05-test_sha1.t . ok
> ../test/recipes/05-test_sha256.t ... ok
> ../test/recipes/05-test_sha512.t ... ok
> ../test/recipes/05-test_wp.t ... ok
> ../test/recipes/10-test_bn.t ... ok
> ../test/recipes/10-test_exp.t .. ok
> ../test/recipes/15-test_dh.t ... ok
> ../test/recipes/15-test_dsa.t .. ok
> ../test/recipes/15-test_ec.t ... ok
> ../test/recipes/15-test_ecdh.t . ok
> ../test/recipes/15-test_ecdsa.t  ok
> ../test/recipes/15-test_rsa.t .. ok
> ../test/recipes/20-test_enc.t .. ok
> ../test/recipes/25-test_crl.t .. ok
> ../test/recipes/25-test_d2i.t .. ok
> ../test/recipes/25-test_gen.t .. ok
> ../test/recipes/25-test_pkcs7.t  ok
> ../test/recipes/25-test_req.t .. ok
> ../test/recipes/25-test_sid.t .. ok
> ../test/recipes/25-test_verify.t ... ok
> ../test/recipes/25-test_x509.t . ok
>
> # Failed test 'running afalgtest'
> # at ../test/recipes/30-test_afalg.t line 23.
> # Looks like you failed 1 test of 1.
> ../test/recipes/30-test_afalg.t 
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/1 subtests
> ../test/recipes/30-test_engine.t ... ok
> ../test/recipes/30-test_evp.t .. ok
> ../test/recipes/30-test_evp_extra.t  ok
> ../test/recipes/30-test_pbelu.t  ok
> ../test/recipes/40-test_rehash.t ... ok
> ../test/recipes/70-test_asyncio.t .. ok
> ../test/recipes/70-test_clienthello.t .. ok
> ../test/recipes/70-test_packet.t ... ok
> ../test/recipes/70-test_sslcertstatus.t  ok
> ../test/recipes/70-test_sslextension.t . ok
> ../test/recipes/70-test_sslsessiontick.t ... ok
> ../test/recipes/70-test_sslskewith0p.t . ok
> ../test/recipes/70-test_sslvertol.t  ok
> ../test/recipes/70-test_tlsextms.t . ok
> ../test/recipes/70-test_verify_extra.t . ok
> ../test/recipes/80-test_ca.t ... ok
> ../test/recipes/80-test_cipherlist.t ... ok
> ../test/recipes/80-test_cms.t .. ok
> ../test/recipes/80-test_ct.t ... ok
> ../test/recipes/80-test_dane.t . ok
> ../test/recipes/80-test_dtlsv1listen.t . ok
> ../test/recipes/80-test_ocsp.t . ok
> ../test/recipes/80-test_ssl_new.t .. ok
> ../test/recipes/80-test_ssl_old.t .. ok
> ../test/recipes/80-test_ssl_test_ctx.t . ok
> ../test/recipes/80-test_tsa.t .. ok
> ../test/recipes/80-test_x509aux.t .. ok
> ../test/recipes/90-test_async.t  ok
> ../test/recipes/90-test_bioprint.t . ok
> ../test/recipes/90-test_constant_time.t  ok
> ../test/recipes/90-test_gmdiff.t ... ok
> ../test/recipes/90-test_heartbeat.t  skipped: heartbeats is
> not supported by this OpenSSL build
> ../test/recipes/90-test_ige.t .. ok
> ../test/recipes/90-test_memleak.t .. ok
> ../test/recipes/90-test_networking.t ... ok
> ../test/recipes/90-test_np.t ... ok
> ../test/recipes/90-test_p5_crpt2.t . ok
> ../test/recipes/90-test_secmem.t ... ok
> ../test/recipes/90-test_srp.t .. ok
> ../test/recipes/90-test_threads.t .. ok
> ../test/recipes/90-test_v3name.t ... ok
>
> Test Summary Report
> ---
> ../test/recipes/30-test_afalg.t (Wstat: 256 Tests: 1 Failed: 1)
> 

[openssl-dev] [openssl.org #4458] "implicitly declared function" warnings due to missing include

[Richard Levitte via RT]

This has been fixed in commit 7233bea263

Closing this ticket.

Cheers,
Richard

On Wed May 25 21:46:01 2016, levitte wrote:
> I don't get such warnings. Can you tell me what system and with what
> tool chain
> (including versions)?
>
> On Sun Mar 20 13:07:43 2016, noloa...@gmail.com wrote:
> > The missing  include caused a number of "implicitly
> > declared function" warnings due to use of strcmpcase and strncmpcase.
> >
> > $ egrep -IR '(strcasecmp|strncasecmp)' * | cut -f 1 -d ':' | sort |
> > uniq
> > apps/apps.c
> > apps/ca.c
> > apps/ocsp.c
> > apps/rehash.c
> > apps/s_server.c
> > crypto/asn1/ameth_lib.c
> > crypto/engine/tb_asnmth.c
> > crypto/o_str.c
> > crypto/x509v3/v3_ncons.c
> > crypto/x509v3/v3_tlsf.c
> > crypto/x509v3/v3_utl.c
> > e_os.h
> > include/internal/o_str.h
> > ssl/ssl_conf.c
> > test/ssltest.c
> > test/v3nametest.c
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org


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

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

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

[openssl-dev] [openssl.org #4552] Bug report: hex string is too long, problem in set_hex()?

[Richard Levitte via RT]

That hex key string looks off. It seems to include an ending \n (0a), which I
suspect is because at an earlier time, someone forgot to peal off the ending
linefeed. Take away the endine 0a and I'm sure things will be fine.

The 'set_hex' check is exactly the same in the 1.0.1, 1.0.2 and upcoming 1.1.0
series, so I'm pretty sure *that* part is a red herring.

Why 1.0.1 accepts a too long hex string is a good question, but it's too late
in its life cycle to bother.

Cheers,
Richard

On Tue May 31 20:37:19 2016, david-e.yo...@db.com wrote:
> Classification: Public
> OS: SUSE Linux Enterprise Server 11 SP2 (x86_64)
> OpenSSL: versions 1.0.1m, 1.1.0-pre5
>
> Using this command sequence:
>
> echo WuNhPwuWAOiG86RfO4A5jITR9WZ+kF1L+iBgGPQJ4dEJk8Sxiqb014bJsEGDbCfk
> | $ssl/bin/openssl enc -aes128 -d -a -iv
> 57fd56a7e47b9482096ab4707ca9d383 -K 617364696f69636a61736f3932336b3b0a
>
> we get different behavior between version 1.0.1m and later versions.
> With version 1.0.1m the above sequence works fine. Using later
> versions, including 1.1.0-pre5, we get:
>
> hex string is too long
> invalid hex key value
>
> The trouble is in set_hex():
>
> static int set_hex(char *in, unsigned char *out, int size)
> {
> ...
> if (n > (size * 2)) {
> // hex string is too long
> ...
> }
> }
>
> If the size multiplier is changed to, say, 4, then the problem goes
> away with no apparent ill effects. Reading the code for set_hex() and
> its caller, it does not appear that the size multiplier is related to
> a buffer size or some other limitation.
>
> I've read that the "hex string is too long" issue is a bug in OpenSSL
> that was supposed to be fixed in the 1.0.2 branch, but that appears
> not to be the case. Please let us know if we've missed something or if
> this issue is in fact an OpenSSL bug.
>
> Kind Regards,
>
> David
>
>
>
> ---
> This communication may contain confidential and/or privileged
> information. If you are not the intended recipient (or have received
> this communication in error) please notify the sender immediately and
> destroy this communication. Any unauthorized copying, disclosure or
> distribution of the material in this communication is strictly
> forbidden.
>
> Deutsche Bank does not render legal or tax advice, and the information
> contained in this communication should not be regarded as such.


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

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

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

[openssl-dev] [openssl.org #4457] apps/apps.c and apps/ocsp.c needs for fd_set

[Richard Levitte via RT]

On Tue May 31 18:26:56 2016, rs...@akamai.com wrote:
> Since it 'just works' for now, maybe remove the 1.1 milestone?
>
I agree. Making it post-1.1.0

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

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

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

[openssl-dev] [openssl.org #4457] apps/apps.c and apps/ocsp.c needs for fd_set

[Richard Levitte via RT]

On Tue May 31 18:04:39 2016, rsalz wrote:
> Is this *literally* a Fedora 1 machine? If so, then I'm inclined to
> close this
> as it went end-of-life more than 12 years ago.

On the other hand, according to The Open Group, sys/select.h should be included
to get select() and all things belonging with it (except timeval).

http://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html

So this is a bigger issue than just Fedora 1, we're just lucky that most
platforms still have select() in unistd.h as well...

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

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

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

[openssl-dev] [openssl.org #4487] Dirty compile under Windows 7 and MSVC 2012 (four to six non-trivial)

[Richard Levitte via RT]

On Tue May 31 17:14:12 2016, rsalz wrote:
> We fixed the naming issue for unlink et al. Can this ticket be closed?

I'll do another check, just to make sure.

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

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

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

[openssl-dev] [openssl.org #4473] Compile errors when compiling with C++ compiler

[Richard Levitte via RT]

We have rejected it a number of times. Doing so again. Please do not respond to
this ticket again.

On Tue May 31 17:00:39 2016, rsalz wrote:
> So this got tagged with the 1.1 milestone. What exactly is there for
> us to do
> here?
> The header files without 'extern "C"' are all okay, they just have
> pre-processor directives in them.


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

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

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