Re: [openssl-dev] pkcs12 settings, Was: Re: [openssl.org #4588] pkcs12 -info doesn't handle PKCS#12 files with PKCS#5 v2.0 PBE

[Dr. Stephen Henson]

On Tue, Jul 19, 2016, Hubert Kario wrote:

> I have few questions now though:
> 
> I've noticed that 1.0.2 uses sha1 hmac for the PRF while the master
> uses sha256
> 
> is there a way to set this?
> 

Not currently no (at least not from the command line, maybe by delving
into the pkcs12 internals). It's determined by the encryption algorithm (if it 
has a
preference: most don't) or the value is hard coded in p5_pbev2.c

> also, is there a way to report the MAC algorithm used over the whole
> file (the one set using -macalg)
> 

Not from the command line currently. The PKCS12_get0_mac() function can be
used to retrieve the X509_ALGOR structure corresponding to the MAC though.

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

[openssl-dev] [openssl.org #4600] Core dump when using -keymatexport and receiving a handshake alert

[Stephen Henson via RT]

Fixed now, thanks for the report.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4600
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 #4591] asynctest: double free or corruption on hppa

[Matt Caswell via RT]

On Tue Jul 19 16:22:22 2016, k...@roeckx.be wrote:
> On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote:
> >
> > Is this still an issue? And if so are you able to provide a backtrace?
>
> This might be a combination of kernel, glibc and gcc bugs, some of
> which might have been fixed. In any case, I don't think it's an
> openssl problem.

Ok - closing this ticket then.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591
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 #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

[Stephen Henson via RT]

On Tue Jul 19 08:47:11 2016, levitte wrote:
> 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.
>

If there are multiple CRLs with the appropriate scope then the first one where
the current time falls between lastUpdate and nextUpdate is used.

It is possible to dynamically update CRLs but currently only the time criteria
is used. So if the first one fails the time test the next is used. This isn't
ideal and something relying on the most recent or the highest CRL number would
be preferable.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.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

Re: [openssl-dev] doc/crypto/BIO_set_callback.pod still not fixed in the master

[Salz, Rich]

This was also reported as https://github.com/openssl/openssl/pull/1312 and 
fixed with commit 2a5f907 moments ago.


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

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

[Patel, Anirudh (Anirudh)]

Guys,

I will make things more simpler based on all the explanations that you have 
given.

A $hash.r0 CRL file has been loaded in the internal store since it was unique 
(new name) as suggested by you. Currently, this file was present on disk under 
the CRL directory.
Now, this CRL file has been purged from the CRL directory (now the directory is 
empty with no CRL files).
As suggested by you, I got a new refreshed CRL file (which has a new list of 
certificates that have been revoked) from the same issuer. I save this file on 
disk under the CRL directory with extension same as before i.e $hash.r0. 
Problem persists again, that openssl does not do a lookup for this newly placed 
CRL file but only refers to the old CRL file of the issuer from its cache as 
you have mentioned below:
“Once that file is loaded, it's not been loaded from disk again (as implied by 
the 'caches'), also not when it changes.”

How to make this new CRL file count which is just a replacement of the old CRL 
file belonging to the same issuer. We cannot every time reload the store so 
that the cache refreshes for every new (refreshed/replaced) CRL file.

So, another question linked to this is: Is there any way to clear the store 
cache every time before the validation begins (so that it may look for disk 
files and load them since they will always be unique)? Is there any API which 
does that?

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Patel, 
Anirudh (Anirudh)
Sent: Tuesday, July 19, 2016 2:42 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange 
with X509_LOOKUP_add_dir

Fine and thanks for all the explanation.

First let me give my scenario again and then I will come to Mischa’s point.

I got your point Richard but, my scenario is slightly different. What you are 
considering is that both $hash{sub_ca}.r0 and $hash{sub_ca}.r1 are already 
present in the CRL directory and has been loaded up. There might be issues with 
this as you mentioned below.



My case is slightly different:

1. At time T1, CRL file $hash{sub_ca}.r0 is present in the CRL directory. Store 
is loaded up with it and maybe as you said if, no other object with the same 
hash is already there this will be put in the internal store.

2. Now I get an incoming client connection and for which this CRL file is 
looked up and everything is fine.

3. At time T2, I removed this CRL file $hash{sub_ca}.r0 from the CRL directory 
(but remember it is in the internal store/cache).

4. Now I get the same incoming connection from the client as above for which 
openssl is currently doing a lookup and gives no error as the corresponding CRL 
file $hash{sub_ca}.r0 was there in the internal

store/cache. I was expecting an error since I removed the CRL file but I 
did not and that is how I understood that openssl is keeping the file in the 
cache.

5. Above client has now been revoked by sub_ca which generated a new CRL.

6. At time T3, I placed the new CRL file as $hash{sub_ca}.r1 under the CRL 
directory and it is the only one since I have deleted the old one 
$hash{sub_ca}.r0 from the directory.

7. Again the same client tries to connect and passes away which now becomes a 
security concern. As per the statement mentioned on the man page, the lookup 
should have found and considered the new CRL (.r1)

   and not the one in the cache since its sequence number is old.

Now, from what you have just said let me ask you this:
I have .r0 file which has been loaded up in the internal store since, that 
issuer was not already present. Right, this is what you are saying: ”if the 
file is new or if that issuer is not already in the store it, it will be 
loaded”.
Suppose, I remove this file from the disk (.r0) and place a replacement of it 
as you said (this replaced CRL file has been recently published which has a 
list of new certificates that have been revoked). I place this file under the 
CRL directory as .r0 again, but openssl will now again not lookup for this file 
as the same issuer name file was already present in its internal store/cache. 
This is a replaced CRL file of an existing file CRL file but how to make it 
count. We need to start and stop the server again for loading up the store and 
refreshing the cache. This seems to be lot of work and inefficient.

Hope I have been able to made my point.

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mischa 
Salle
Sent: Tuesday, July 19, 2016 2:28 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange 
with X509_LOOKUP_add_dir

Hi,
the point is that they are loaded when a new file appears, meaning, a file with 
a name not yet present. Once that file is loaded, it's not been loaded from 
disk again (as implied by the 'caches'), also not when it changes.
The .r1 files are rarely used (only for rekeying of the CA etc., as far as I 
remember), 

[openssl-dev] [openssl.org #4617] openssl Issue/Bug

[Lapprich, Harold via RT]

Thanks!

-Original Message-
From: Jan Just Keijser via RT [mailto:r...@openssl.org] 
Sent: Tuesday, July 19, 2016 2:35 PM
To: Lapprich, Harold (GE Aviation, US)
Cc: openssl-dev@openssl.org
Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug

Hi Harold,

On 18/07/16 21:31, Lapprich, Harold via RT wrote:
> JJK,
>
> Thanks for the quick response, it is really appreciated. Can I ask where you 
> picked up the syntax for this command line (familiar with the various shells 
> and /dev/null but couldn't put this together)?
this is off-topic for this list, but I cannot email you directly. You could try 
reading up at
   
https://urldefense.proofpoint.com/v2/url?u=http-3A__tldp.org_HOWTO_Bash-2DProg-2DIntro-2DHOWTO-2D3.html=CwIDaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg=MQLfDlYo7OMhseYkTLlCMQbmsjTa3oYqZ9VxCNa6TKs=CTpRJ8DNhRCKHc4VF3OhqAJu7asgyZYRD-fD_MgQIIs=
 

or any other hit that comes up when searching for "linux shell stderr redirect"

HTH,

JJK

> -Original Message-
> From: Jan Just Keijser via RT [mailto:r...@openssl.org]
> Sent: Monday, July 18, 2016 2:26 PM
> To: Lapprich, Harold (GE Aviation, US)
> Cc: openssl-dev@openssl.org
> Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
>
> Hi,
>
> On 18/07/16 18:39, Lapprich, Harold via RT wrote:
>> To Whom It May Concern,
>>
>> openssl version -a:
>>
>>   OpenSSL 1.0.2a 19 Mar 2015
>>
>> built on: reproducible build, date unspecified
>>
>> platform: linux-ppc
>>
>> options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) 
>> blowfish(idx)
>>
>> compiler:
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/u
>> s
>> r/bin/ccache
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/u
>> s r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC 
>> -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE 
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2 
>> -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
>> -DAES_ASM -DVPAES_ASM
>>
>> OPENSSLDIR: "/etc/ssl"
>>
>>
>>
>>   OS Name, Version, Hardware platform:
>>
>> uname -a
>>
>> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT
>> 2016 ppc GNU/Linux
>>
>>
>>
>>
>> Using 'openssl' in a Linux design and since it is a command line application 
>> it is always outputting content to the screen, for example:
>>
>>
>> openssl req -new -x509 -nodes -days 365 -subj 
>> "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT"
>> -keyout start -out start
>>
>> Generating a 2048 bit RSA private key
>>
>> ..
>> ...+++
>>
>> .+++
>>
>> writing new private key to 'start'
>>
>> -
>>
>>
>> Trying to find a way to prevent the output being output to 'stdout' but have 
>> not found a parameter (can redirect to a file but  the .+ characters are 
>> still written to the console).
>>
>>
>> There either has to be a missed parameter or bug exist?
>>
> This is not a bug or lacking feature.
> The + characters are written to stderr, so if you use
> openssl .> stdout 2> stderr
> the characters disappear (into the file 'stderr'; use '2> /dev/null' to send 
> then straight to bit-heaven).  This depends slightly on the shell you use, 
> BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax 
> applies.
>
> HTH,
>
> JJK
>
>
> --
> Ticket here: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Tic
> ket_Display.html-3Fid-3D4617=CwIDaQ=IV_clAzoPDE253xZdHuilRgztyh_Ri
> V3wUrLrDQYWSI=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg=hC-ePxGk
> l2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOv
> f7Q4veAdNVo= Please log in as guest with password guest if prompted
>
>


--
Ticket here: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617=CwIDaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg=MQLfDlYo7OMhseYkTLlCMQbmsjTa3oYqZ9VxCNa6TKs=hGWJ1xajmyidWsrr6QU3K8QnvOLwDwiowB44Kltrd1E=
Please log in as guest with password guest if prompted


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

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

Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug

[Jan Just Keijser via RT]

Hi Harold,

On 18/07/16 21:31, Lapprich, Harold via RT wrote:
> JJK,
>
> Thanks for the quick response, it is really appreciated. Can I ask where you 
> picked up the syntax for this command line (familiar with the various shells 
> and /dev/null but couldn't put this together)?
this is off-topic for this list, but I cannot email you directly. You 
could try reading up at
   http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html

or any other hit that comes up when searching for "linux shell stderr 
redirect"

HTH,

JJK

> -Original Message-
> From: Jan Just Keijser via RT [mailto:r...@openssl.org]
> Sent: Monday, July 18, 2016 2:26 PM
> To: Lapprich, Harold (GE Aviation, US)
> Cc: openssl-dev@openssl.org
> Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
>
> Hi,
>
> On 18/07/16 18:39, Lapprich, Harold via RT wrote:
>> To Whom It May Concern,
>>
>> openssl version -a:
>>
>>   OpenSSL 1.0.2a 19 Mar 2015
>>
>> built on: reproducible build, date unspecified
>>
>> platform: linux-ppc
>>
>> options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx)
>>
>> compiler:
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
>> r/bin/ccache
>> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
>> r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC
>> -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2
>> -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
>> -DAES_ASM -DVPAES_ASM
>>
>> OPENSSLDIR: "/etc/ssl"
>>
>>
>>
>>   OS Name, Version, Hardware platform:
>>
>> uname -a
>>
>> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT
>> 2016 ppc GNU/Linux
>>
>>
>>
>>
>> Using 'openssl' in a Linux design and since it is a command line application 
>> it is always outputting content to the screen, for example:
>>
>>
>> openssl req -new -x509 -nodes -days 365 -subj
>> "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT"
>> -keyout start -out start
>>
>> Generating a 2048 bit RSA private key
>>
>> ..
>> ...+++
>>
>> .+++
>>
>> writing new private key to 'start'
>>
>> -
>>
>>
>> Trying to find a way to prevent the output being output to 'stdout' but have 
>> not found a parameter (can redirect to a file but  the .+ characters are 
>> still written to the console).
>>
>>
>> There either has to be a missed parameter or bug exist?
>>
> This is not a bug or lacking feature.
> The + characters are written to stderr, so if you use
> openssl .> stdout 2> stderr
> the characters disappear (into the file 'stderr'; use '2> /dev/null' to send 
> then straight to bit-heaven).  This depends slightly on the shell you use, 
> BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax 
> applies.
>
> HTH,
>
> JJK
>
>
> --
> Ticket here: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617=CwIDaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg=hC-ePxGkl2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOvf7Q4veAdNVo=
> Please log in as guest with password guest if prompted
>
>


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

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

Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug

[Jan Just Keijser]

Hi Harold,

On 18/07/16 21:31, Lapprich, Harold via RT wrote:

JJK,

Thanks for the quick response, it is really appreciated. Can I ask where you 
picked up the syntax for this command line (familiar with the various shells 
and /dev/null but couldn't put this together)?
this is off-topic for this list, but I cannot email you directly. You 
could try reading up at

  http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html

or any other hit that comes up when searching for "linux shell stderr 
redirect"


HTH,

JJK


-Original Message-
From: Jan Just Keijser via RT [mailto:r...@openssl.org]
Sent: Monday, July 18, 2016 2:26 PM
To: Lapprich, Harold (GE Aviation, US)
Cc: openssl-dev@openssl.org
Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug

Hi,

On 18/07/16 18:39, Lapprich, Harold via RT wrote:

To Whom It May Concern,

openssl version -a:

  OpenSSL 1.0.2a 19 Mar 2015

built on: reproducible build, date unspecified

platform: linux-ppc

options:  bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx)

compiler:
/home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
r/bin/ccache
/home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us
r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include  -fPIC
-DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -mcpu=8540 -pipe -O2
-Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
-DAES_ASM -DVPAES_ASM

OPENSSLDIR: "/etc/ssl"



  OS Name, Version, Hardware platform:

uname -a

Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT
2016 ppc GNU/Linux




Using 'openssl' in a Linux design and since it is a command line application it 
is always outputting content to the screen, for example:


openssl req -new -x509 -nodes -days 365 -subj
"/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT"
-keyout start -out start

Generating a 2048 bit RSA private key

..
...+++

.+++

writing new private key to 'start'

-


Trying to find a way to prevent the output being output to 'stdout' but have 
not found a parameter (can redirect to a file but  the .+ characters are 
still written to the console).


There either has to be a missed parameter or bug exist?


This is not a bug or lacking feature.
The + characters are written to stderr, so if you use
openssl .> stdout 2> stderr
the characters disappear (into the file 'stderr'; use '2> /dev/null' to send 
then straight to bit-heaven).  This depends slightly on the shell you use, BTW. 
The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax applies.

HTH,

JJK


--
Ticket here: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617=CwIDaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg=hC-ePxGkl2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOvf7Q4veAdNVo=
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

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

[Viktor Dukhovni via RT]

> On Jul 19, 2016, at 5:26 PM, Matt Caswell via RT  wrote:
> 
>> 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.

Postfix expects to be able to continue "degraded" operation without TLS,
when TLS initialization fails.  Asserts are not acceptable.  They would
cause Postfix to look for a different SSL library.

When initialization fails, all subsequent calls can return errors, but
assert is not an option.

-- 
Viktor.


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



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

[openssl-dev] doc/crypto/BIO_set_callback.pod still not fixed in the master

[Blumenthal, Uri - 0553 - MITLL]

Please add a blank line after the “+over” around line 39 in
doc/crypto/BIO_set_callback.pod
-- 
Regards,
Uri Blumenthal


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

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

[Kurt Roeckx via RT]

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.


Kurt


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

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

[Kurt Roeckx]

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.


Kurt

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

Re: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

[Kurt Roeckx via RT]

On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote:
> 
> Is this still an issue? And if so are you able to provide a backtrace?

This might be a combination of kernel, glibc and gcc bugs, some of
which might have been fixed.  In any case, I don't think it's an
openssl problem.

See the thread starting at:
https://lists.debian.org/debian-hppa/2016/06/msg00046.html


Kurt


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

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

Re: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

[Kurt Roeckx]

On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote:
> 
> Is this still an issue? And if so are you able to provide a backtrace?

This might be a combination of kernel, glibc and gcc bugs, some of
which might have been fixed.  In any case, I don't think it's an
openssl problem.

See the thread starting at:
https://lists.debian.org/debian-hppa/2016/06/msg00046.html


Kurt

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

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

[Matt Caswell via RT]

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.

Matt


-- 
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 #4591] asynctest: double free or corruption on hppa

[Matt Caswell via RT]

On Mon Jun 27 09:51:21 2016, matt wrote:
>
>
> On 26/06/16 15:44, Kurt Roeckx via RT wrote:
> > Hi,
> >
> > My last upload of openssl to experimental show this on hppa:
> > *** Error in `./asynctest': double free or corruption (out):
> > 0x007307d8 ***
> > ../util/shlib_wrap.sh ./asynctest => 134
> >
> > # Failed test 'running asynctest'
> > # at ../test/testlib/OpenSSL/Test/Simple.pm line 77.
> > # Looks like you failed 1 test of 1.
> >
> > A full log can be seen at:
> >
https://buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-
> > 4=1466951184
> >
> > This is with commit c32bdbf171ce6650ef045ec47b5abe0de7c264db
> >
> > The previous upload was succesful, the log of that is:
> >
https://buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-
> > 3=1465602753
> >
> > That was with commit 5000a6d1215ea7d6ed6179d0bcd44263f6e3c26b
>
>
> There do not appear to be any changes at all in either the asynctest
> or
> the async code between those two commits.
>
> >
> >
> > I'm not sure if this is reproducible or not, I can try a new build
> > if needed.
>
> That would be good to know, although to take this any further I think
> we're going to need more information, e.g. a backtrace.

Is this still an issue? And if so are you able to provide a backtrace?

Thanks

Matt

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

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

[Matt Caswell via RT]

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

> 
> make test TESTS='test_afalg test_rehash'

Did you mean to include "VERBOSE=1"?

VERBOSE=1 make TESTS='test_afalg test_rehash' test

Matt


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

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

[Matt Caswell]

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

> 
> make test TESTS='test_afalg test_rehash'

Did you mean to include "VERBOSE=1"?

VERBOSE=1 make TESTS='test_afalg test_rehash' test

Matt


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

[openssl-dev] pkcs12 settings, Was: Re: [openssl.org #4588] pkcs12 -info doesn't handle PKCS#12 files with PKCS#5 v2.0 PBE

[Hubert Kario]

On Tuesday, 19 July 2016 12:07:33 CEST Stephen Henson via RT wrote:
> Thanks for the report, fixed now in master and 1.0.2.
> 
> Steve.

Thanks!

I have few questions now though:

I've noticed that 1.0.2 uses sha1 hmac for the PRF while the master
uses sha256

is there a way to set this?

also, is there a way to report the MAC algorithm used over the whole
file (the one set using -macalg)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
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 #4593] [PATCH] pod: fix nits related to spacing around commas and assignments

[Rich Salz via RT]

merged, thanks!

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4593
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 #4588] pkcs12 -info doesn't handle PKCS#12 files with PKCS#5 v2.0 PBE

[Stephen Henson via RT]

Thanks for the report, fixed now in master and 1.0.2.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

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

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

Re: [openssl-dev] [openssl.org #4617] Resolved: openssl Issue/Bug

[Lapprich, Harold via RT]

Hi Rich,

The organization developing and supporting 'openssl' is very professional from 
submittal of bugs, response, fix and maintained database of fit.

Pleasure working with the organization, thanks again,
Harold M. Lapprich

-Original Message-
From: Rich Salz via RT [mailto:r...@openssl.org] 
Sent: Monday, July 18, 2016 5:00 PM
To: Lapprich, Harold (GE Aviation, US)
Subject: EXT: [openssl.org #4617] Resolved: openssl Issue/Bug

According to our records, your request has been resolved. If you have any 
further questions or concerns, please respond to this message.

--
Ticket here: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617=CwIDaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg=5CIQ-EZ_0WWSG-n85-0XLk063Z1JTQiz6wTsG6RLlJI=ROOFDP2D1dlMNzY-PIvDQX9jGtqFu402cseNBoio4Hk=
Please log in as guest with password guest if prompted


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

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

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

[Patel, Anirudh (Anirudh)]

Fine and thanks for all the explanation.

First let me give my scenario again and then I will come to Mischa’s point.

I got your point Richard but, my scenario is slightly different. What you are 
considering is that both $hash{sub_ca}.r0 and $hash{sub_ca}.r1 are already 
present in the CRL directory and has been loaded up. There might be issues with 
this as you mentioned below.



My case is slightly different:

1. At time T1, CRL file $hash{sub_ca}.r0 is present in the CRL directory. Store 
is loaded up with it and maybe as you said if, no other object with the same 
hash is already there this will be put in the internal store.

2. Now I get an incoming client connection and for which this CRL file is 
looked up and everything is fine.

3. At time T2, I removed this CRL file $hash{sub_ca}.r0 from the CRL directory 
(but remember it is in the internal store/cache).

4. Now I get the same incoming connection from the client as above for which 
openssl is currently doing a lookup and gives no error as the corresponding CRL 
file $hash{sub_ca}.r0 was there in the internal

store/cache. I was expecting an error since I removed the CRL file but I 
did not and that is how I understood that openssl is keeping the file in the 
cache.

5. Above client has now been revoked by sub_ca which generated a new CRL.

6. At time T3, I placed the new CRL file as $hash{sub_ca}.r1 under the CRL 
directory and it is the only one since I have deleted the old one 
$hash{sub_ca}.r0 from the directory.

7. Again the same client tries to connect and passes away which now becomes a 
security concern. As per the statement mentioned on the man page, the lookup 
should have found and considered the new CRL (.r1)

   and not the one in the cache since its sequence number is old.

Now, from what you have just said let me ask you this:
I have .r0 file which has been loaded up in the internal store since, that 
issuer was not already present. Right, this is what you are saying: ”if the 
file is new or if that issuer is not already in the store it, it will be 
loaded”.
Suppose, I remove this file from the disk (.r0) and place a replacement of it 
as you said (this replaced CRL file has been recently published which has a 
list of new certificates that have been revoked). I place this file under the 
CRL directory as .r0 again, but openssl will now again not lookup for this file 
as the same issuer name file was already present in its internal store/cache. 
This is a replaced CRL file of an existing file CRL file but how to make it 
count. We need to start and stop the server again for loading up the store and 
refreshing the cache. This seems to be lot of work and inefficient.

Hope I have been able to made my point.

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mischa 
Salle
Sent: Tuesday, July 19, 2016 2:28 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange 
with X509_LOOKUP_add_dir

Hi,
the point is that they are loaded when a new file appears, meaning, a file with 
a name not yet present. Once that file is loaded, it's not been loaded from 
disk again (as implied by the 'caches'), also not when it changes.
The .r1 files are rarely used (only for rekeying of the CA etc., as far as I 
remember), so normally you would get only replacements of existing files, 
meaning OpenSSL will get then from its cache.
Note that I don't like this behaviour, but I think it is as intended.
Mischa


On Tue, Jul 19, 2016 at 10:24 AM, Patel, Anirudh (Anirudh) 
> wrote:
Man page for X509_LOOKUP_hash_dir states something different though:


X509_LOOKUP_hash_dir is a more advanced method, which loads certificates and 
CRLs on demand, and caches them in memory once they are loaded. As of OpenSSL 
1.0.0, it also checks for newer CRLs upon each lookup, so that newer CRLs are 
as soon as they appear in the directory

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.

a)  If you look at my scenario, firstly I did not had any CRL files under 
the CRL directory which has been loaded in the store when my server starts. For 
the incoming chain as ID/Sub CA/Root CA verify_callback is invoked which gives 
3 errors X509_V_ERR_UNABLE_TO_GET_CRL one for each certificate and then follows 
with further validation.

b)  Then, when I placed the respective CRL files under the directory and I 
get the same incoming connection (chain: ID/Sub CA/Root CA) openssl 
verify_callback stops complaining about CRL files not found for the certs. 
Please note that I did not stop/start the server to load the store with CRL 
directory again. As stated in the man page, openssl rightly did a lookup and 
found new CRL files during the handshake.

c)   The problem is when a new CRL file for one the above issuer is 

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

[Mischa Salle]

Hi,
the point is that they are loaded when a new file appears, meaning, a file
with a name not yet present. Once that file is loaded, it's not been loaded
from disk again (as implied by the 'caches'), also not when it changes.
The .r1 files are rarely used (only for rekeying of the CA etc., as far as
I remember), so normally you would get only replacements of existing files,
meaning OpenSSL will get then from its cache.
Note that I don't like this behaviour, but I think it is as intended.

Mischa


On Tue, Jul 19, 2016 at 10:24 AM, Patel, Anirudh (Anirudh) <
aniru...@avaya.com> wrote:

> Man page for X509_LOOKUP_hash_dir states something different though:
>
>
>
> X509_LOOKUP_hash_dir is a more advanced method, which loads certificates
> and CRLs on demand, and caches them in memory once they are loaded. As of
> OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that
> newer CRLs are as soon as they appear in the directory
>
> 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.
>
> a)  If you look at my scenario, firstly I did not had any CRL files
> under the CRL directory which has been loaded in the store when my server
> starts. For the incoming chain as ID/Sub CA/Root CA verify_callback is
> invoked which gives 3 errors *X509_V_ERR_UNABLE_TO_GET_CRL *one for each
> certificate and then follows with further validation.
>
> b)  Then, when I placed the respective CRL files under the directory
> and I get the same incoming connection (chain: ID/Sub CA/Root CA) openssl
> verify_callback stops complaining about CRL files not found for the certs.
> Please note that I did not stop/start the server to load the store with CRL
> directory again. As stated in the man page, openssl rightly did a lookup
> and found new CRL files during the handshake.
>
> c)   The problem is when a new CRL file for one the above issuer is
> placed under the CRL directory (with an incremented sequence number .rN)
> openssl is not looking at the newer CRL file but only considering the ones
> in the cache.
>
>
>
> Let me know if the manual page description meant something different.
>
>
>
> Thanks.
>
>
>
> *From:* openssl-dev [mailto:openssl-dev-boun...@openssl.org] *On Behalf
> Of *Mischa Salle
> *Sent:* Tuesday, July 19, 2016 1:27 PM
>
> *To:* openssl-dev@openssl.org
> *Subject:* Re: [openssl-dev] openssl.org #4615 Cache utility behaving
> strange with X509_LOOKUP_add_dir
>
>
>
> Hi Anirudh,
>
> this is as far as I know a very old issue (at least since 2002 or so).
> Basically a server needs to restart periodically in order to pick up
> changed CRLs. There are some workarounds, like forcibly reloading all the
> CRLs periodically, even those already in the store.
>
> Mischa Salle
>
>
>
> On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) <
> aniru...@avaya.com> wrote:
>
> It is not re-checking the files (new CRL for the same issuer) in the CRL
> directory
> IssuerHash_.r0 (old crl for sub-ca)
> IssuerHash_.r1 (new crl for sub-ca) ---> not looked up for an incoming
> client connection
> Issuer.r0 (old crl for root ca)
>
> I have mentioned the complete scenario in the ticket#4615
>
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of
> Salz, Rich
> Sent: Tuesday, July 19, 2016 12:55 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] openssl.org
> 
> #4615 Cache utility behaving strange with X509_LOOKUP_add_dir
>
>
> > I have earlier raised an issue on how openssl is not looking up for
> newer CRLs in each lookup. The only CRL files it is taking into
> consideration are the ones present in the cache.
>
> > Could you please provide some inputs on this as I am blocked on the
> implementation front.
>
> You mean it's not fetching CRL's over the network?  Or re-checking the
> files?
>
> --
> openssl-dev mailing list
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=CwIF-g=BFpWQw8bsuKpl1SgiZH64Q=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs=
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 

[openssl-dev] [openssl.org #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

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

[Patel, Anirudh (Anirudh)]

Man page for X509_LOOKUP_hash_dir states something different though:


X509_LOOKUP_hash_dir is a more advanced method, which loads certificates and 
CRLs on demand, and caches them in memory once they are loaded. As of OpenSSL 
1.0.0, it also checks for newer CRLs upon each lookup, so that newer CRLs are 
as soon as they appear in the directory

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.

a)  If you look at my scenario, firstly I did not had any CRL files under 
the CRL directory which has been loaded in the store when my server starts. For 
the incoming chain as ID/Sub CA/Root CA verify_callback is invoked which gives 
3 errors X509_V_ERR_UNABLE_TO_GET_CRL one for each certificate and then follows 
with further validation.

b)  Then, when I placed the respective CRL files under the directory and I 
get the same incoming connection (chain: ID/Sub CA/Root CA) openssl 
verify_callback stops complaining about CRL files not found for the certs. 
Please note that I did not stop/start the server to load the store with CRL 
directory again. As stated in the man page, openssl rightly did a lookup and 
found new CRL files during the handshake.

c)   The problem is when a new CRL file for one the above issuer is placed 
under the CRL directory (with an incremented sequence number .rN) openssl is 
not looking at the newer CRL file but only considering the ones in the cache.

Let me know if the manual page description meant something different.

Thanks.

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mischa 
Salle
Sent: Tuesday, July 19, 2016 1:27 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange 
with X509_LOOKUP_add_dir

Hi Anirudh,
this is as far as I know a very old issue (at least since 2002 or so). 
Basically a server needs to restart periodically in order to pick up changed 
CRLs. There are some workarounds, like forcibly reloading all the CRLs 
periodically, even those already in the store.
Mischa Salle

On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) 
> wrote:
It is not re-checking the files (new CRL for the same issuer) in the CRL 
directory
IssuerHash_.r0 (old crl for sub-ca)
IssuerHash_.r1 (new crl for sub-ca) ---> not looked up for an incoming 
client connection
Issuer.r0 (old crl for root ca)

I have mentioned the complete scenario in the ticket#4615

-Original Message-
From: openssl-dev 
[mailto:openssl-dev-boun...@openssl.org]
 On Behalf Of Salz, Rich
Sent: Tuesday, July 19, 2016 12:55 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] 
openssl.org
 #4615 Cache utility behaving strange with X509_LOOKUP_add_dir


> I have earlier raised an issue on how openssl is not looking up for newer 
> CRLs in each lookup. The only CRL files it is taking into consideration are 
> the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the 
> implementation front.

You mean it's not fetching CRL's over the network?  Or re-checking the files?

--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=CwIF-g=BFpWQw8bsuKpl1SgiZH64Q=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs=
--
openssl-dev mailing list
To unsubscribe: 
https://mta.openssl.org/mailman/listinfo/openssl-dev
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Mischa Salle]

Hi Anirudh,

this is as far as I know a very old issue (at least since 2002 or so).
Basically a server needs to restart periodically in order to pick up
changed CRLs. There are some workarounds, like forcibly reloading all the
CRLs periodically, even those already in the store.

Mischa Salle

On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) <
aniru...@avaya.com> wrote:

> It is not re-checking the files (new CRL for the same issuer) in the CRL
> directory
> IssuerHash_.r0 (old crl for sub-ca)
> IssuerHash_.r1 (new crl for sub-ca) ---> not looked up for an incoming
> client connection
> Issuer.r0 (old crl for root ca)
>
> I have mentioned the complete scenario in the ticket#4615
>
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of
> Salz, Rich
> Sent: Tuesday, July 19, 2016 12:55 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving
> strange with X509_LOOKUP_add_dir
>
>
> > I have earlier raised an issue on how openssl is not looking up for
> newer CRLs in each lookup. The only CRL files it is taking into
> consideration are the ones present in the cache.
>
> > Could you please provide some inputs on this as I am blocked on the
> implementation front.
>
> You mean it's not fetching CRL's over the network?  Or re-checking the
> files?
>
> --
> openssl-dev mailing list
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=CwIF-g=BFpWQw8bsuKpl1SgiZH64Q=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs=
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich]

> It is not re-checking the files (new CRL for the same issuer) in the CRL
> directory

I believe that is working as designed and what you want is a new feature.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Patel, Anirudh (Anirudh)]

It is not re-checking the files (new CRL for the same issuer) in the CRL 
directory
IssuerHash_.r0 (old crl for sub-ca) 
IssuerHash_.r1 (new crl for sub-ca) ---> not looked up for an incoming 
client connection
Issuer.r0 (old crl for root ca)

I have mentioned the complete scenario in the ticket#4615

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, 
Rich
Sent: Tuesday, July 19, 2016 12:55 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange 
with X509_LOOKUP_add_dir


> I have earlier raised an issue on how openssl is not looking up for newer 
> CRLs in each lookup. The only CRL files it is taking into consideration are 
> the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the 
> implementation front.  

You mean it's not fetching CRL's over the network?  Or re-checking the files?

-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=CwIF-g=BFpWQw8bsuKpl1SgiZH64Q=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich]

> I have earlier raised an issue on how openssl is not looking up for newer 
> CRLs in each lookup. The only CRL files it is taking into consideration are 
> the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the 
> implementation front.  

You mean it's not fetching CRL's over the network?  Or re-checking the files?

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

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

[Patel, Anirudh (Anirudh)]

Hi,

I have earlier raised an issue on how openssl is not looking up for newer CRLs 
in each lookup. The only CRL files it is taking into consideration are the ones 
present in the cache.

Could you please provide some inputs on this as I am blocked on the 
implementation front.

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