Re: [openssl-dev] [openssl.org #4237] Failed self-tests on AARCH64 (ARM64)

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

On Thu, Feb 11, 2016 at 3:46 PM, Andy Polyakov via RT  wrote:
> Hi,
>
>> $ uname -a
>> Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC
>> 2015 aarch64 GNU/Linux
>>
>> $ make test
>> ...
>> ../test/recipes/80-test_dane.t  ok
>> ../test/recipes/80-test_ocsp.t  ok
>> ../test/recipes/80-test_ssl.t . 1/43
>> #   Failed test 'test sslv3 with client authentication via BIO pair'
>> #   at ../test/recipes/80-test_ssl.t line 345.
>> # Looks like you failed 1 test of 27.
>
> Double-check attached patch and report back, please. Cheers.

I believe that cleared the issue.

Thank you very much.

-

...
$ make test
...
TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests
../test/recipes/00-check_testexes.t ... ok
../test/recipes/01-test_ordinals.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_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
../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_clienthello.t . ok
../test/recipes/70-test_packet.t .. ok
../test/recipes/70-test_sslcertstatus.t ... skipped:
test_sslcertstatus can only be performed with OpenSSL configured
shared
../test/recipes/70-test_sslextension.t  skipped: test_sslextension
can only be performed with OpenSSL configured shared
../test/recipes/70-test_sslsessiontick.t .. skipped:
test_sslsessiontick can only be performed with OpenSSL configured
shared
../test/recipes/70-test_sslskewith0p.t  skipped: test_sslskewith0p
can only be performed with OpenSSL configured shared
../test/recipes/70-test_sslvertol.t ... skipped: test_sslextension
can only be performed with OpenSSL configured shared
../test/recipes/70-test_tlsextms.t  skipped: test_tlsextms can
only be performed with OpenSSL configured shared
../test/recipes/70-test_verify_extra.t  ok
../test/recipes/80-test_ca.t .. ok
../test/recipes/80-test_cms.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.t . ok
../test/recipes/80-test_tsa.t . ok
../test/recipes/90-test_async.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_jpake.t ... skipped: jpake is not
supported by this OpenSSL build
../test/recipes/90-test_memleak.t . ok
../test/recipes/90-test_networking.t .. skipped: test_networking
can only be performed with OpenSSL configured shared
../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_v3name.t .. ok
All tests successful.
Files=70, Tests=409, 153 wallclock secs ( 3.54 usr  0.34 sys + 112.32
cusr  9.31 csys = 125.51 CPU)
Result: PASS
make[1]: Leaving directory '/home/jwalton/openssl/test'
OpenSSL 1.1.0-pre3-dev  xx XX

Re: [openssl-dev] [openssl.org #4237] Failed self-tests on AARCH64 (ARM64)

[Jeffrey Walton]

On Thu, Feb 11, 2016 at 3:46 PM, Andy Polyakov via RT  wrote:
> Hi,
>
>> $ uname -a
>> Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC
>> 2015 aarch64 GNU/Linux
>>
>> $ make test
>> ...
>> ../test/recipes/80-test_dane.t  ok
>> ../test/recipes/80-test_ocsp.t  ok
>> ../test/recipes/80-test_ssl.t . 1/43
>> #   Failed test 'test sslv3 with client authentication via BIO pair'
>> #   at ../test/recipes/80-test_ssl.t line 345.
>> # Looks like you failed 1 test of 27.
>
> Double-check attached patch and report back, please. Cheers.

I believe that cleared the issue.

Thank you very much.

-

...
$ make test
...
TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests
../test/recipes/00-check_testexes.t ... ok
../test/recipes/01-test_ordinals.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_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
../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_clienthello.t . ok
../test/recipes/70-test_packet.t .. ok
../test/recipes/70-test_sslcertstatus.t ... skipped:
test_sslcertstatus can only be performed with OpenSSL configured
shared
../test/recipes/70-test_sslextension.t  skipped: test_sslextension
can only be performed with OpenSSL configured shared
../test/recipes/70-test_sslsessiontick.t .. skipped:
test_sslsessiontick can only be performed with OpenSSL configured
shared
../test/recipes/70-test_sslskewith0p.t  skipped: test_sslskewith0p
can only be performed with OpenSSL configured shared
../test/recipes/70-test_sslvertol.t ... skipped: test_sslextension
can only be performed with OpenSSL configured shared
../test/recipes/70-test_tlsextms.t  skipped: test_tlsextms can
only be performed with OpenSSL configured shared
../test/recipes/70-test_verify_extra.t  ok
../test/recipes/80-test_ca.t .. ok
../test/recipes/80-test_cms.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.t . ok
../test/recipes/80-test_tsa.t . ok
../test/recipes/90-test_async.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_jpake.t ... skipped: jpake is not
supported by this OpenSSL build
../test/recipes/90-test_memleak.t . ok
../test/recipes/90-test_networking.t .. skipped: test_networking
can only be performed with OpenSSL configured shared
../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_v3name.t .. ok
All tests successful.
Files=70, Tests=409, 153 wallclock secs ( 3.54 usr  0.34 sys + 112.32
cusr  9.31 csys = 125.51 CPU)
Result: PASS
make[1]: Leaving directory '/home/jwalton/openssl/test'
OpenSSL 1.1.0-pre3-dev  xx XX

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Peter Waltenberg via RT]

The problem with making those little "Oh we'll allow it  for
interoperability' choices is that they may end up as security
vulnerabilities elsewhere. Particularly when there are multiple of them
made.

So - it is quite reasonable to reject a change like that because it's near
impossible to check all the little corner cases that it might expose.

Peter





From:   "Blumenthal, Uri - 0553 - MITLL via RT" 
To: bcri...@gmail.com
Cc: openssl-dev@openssl.org
Date:   12/02/2016 10:13
Subject:Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
fails to parse x509 certificate in DER format
Sent by:"openssl-dev" 



Again, you are right, but what's the lesser evil‎ - being unable to use the
new OpenSSL because it refuses to deal with the cert that some dim-witten
TPM maker screwed up, or accept a certificate with a (minor) violation of
DER (but not of BER)? What bad in your opinion could happen if OpenSSL
allowed parsing an integer with a leading zero byte (when it shouldn't be
there by DER)?

Even in crypto (and that's the area I've been working in for quite a while)
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I
won't gain from this decision, whichever way it turns. ;-)

Sent from my BlackBerry 10 smartphone on the
Verizon Wireless 4G LTE network.
  Original Message
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: openssl-dev@openssl.org‎
Reply To: openssl-dev@openssl.org
Cc: Stephen Henson via RT; bcri...@gmail.com
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
fails to parse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Might I suggest that the right thing in this case would be to keep
generation strict, but relax the rules on parsing? "Be conservative in what
you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

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


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

[attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] --
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Peter Waltenberg]

The problem with making those little "Oh we'll allow it  for
interoperability' choices is that they may end up as security
vulnerabilities elsewhere. Particularly when there are multiple of them
made.

So - it is quite reasonable to reject a change like that because it's near
impossible to check all the little corner cases that it might expose.

Peter





From:   "Blumenthal, Uri - 0553 - MITLL via RT" 
To: bcri...@gmail.com
Cc: openssl-dev@openssl.org
Date:   12/02/2016 10:13
Subject:Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
fails to parse x509 certificate in DER format
Sent by:"openssl-dev" 



Again, you are right, but what's the lesser evil‎ - being unable to use the
new OpenSSL because it refuses to deal with the cert that some dim-witten
TPM maker screwed up, or accept a certificate with a (minor) violation of
DER (but not of BER)? What bad in your opinion could happen if OpenSSL
allowed parsing an integer with a leading zero byte (when it shouldn't be
there by DER)?

Even in crypto (and that's the area I've been working in for quite a while)
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I
won't gain from this decision, whichever way it turns. ;-)

Sent from my BlackBerry 10 smartphone on the
Verizon Wireless 4G LTE network.
  Original Message
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: openssl-dev@openssl.org‎
Reply To: openssl-dev@openssl.org
Cc: Stephen Henson via RT; bcri...@gmail.com
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
fails to parse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Might I suggest that the right thing in this case would be to keep
generation strict, but relax the rules on parsing? "Be conservative in what
you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

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


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

[attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] --
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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Blumenthal, Uri - 0553 - MITLL via RT]

Again, you are right, but what's the lesser evil‎ - being unable to use the new 
OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker 
screwed up, or accept a certificate with a (minor) violation of DER (but not of 
BER)? What bad in your opinion could happen if OpenSSL allowed parsing an 
integer with a leading zero byte (when it shouldn't be there by DER)?

Even in crypto (and that's the area I've been working in for quite a while) 
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I 
won't gain from this decision, whichever way it turns. ;-) 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: openssl-dev@openssl.org‎
Reply To: openssl-dev@openssl.org
Cc: Stephen Henson via RT; bcri...@gmail.com
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails 
toparse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation 
> strict, but relax the rules on parsing? "Be conservative in what you send, 
> and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

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


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

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Blumenthal, Uri - 0553 - MITLL]

Again, you are right, but what's the lesser evil‎ - being unable to use the new 
OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker 
screwed up, or accept a certificate with a (minor) violation of DER (but not of 
BER)? What bad in your opinion could happen if OpenSSL allowed parsing an 
integer with a leading zero byte (when it shouldn't be there by DER)?

Even in crypto (and that's the area I've been working in for quite a while) 
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I 
won't gain from this decision, whichever way it turns. ;-) 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: openssl-dev@openssl.org‎
Reply To: openssl-dev@openssl.org
Cc: Stephen Henson via RT; bcri...@gmail.com
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails 
toparse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation 
> strict, but relax the rules on parsing? "Be conservative in what you send, 
> and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

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



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

Re: [openssl-dev] PKCS12_Parse() no longer extract certificate

[Michel]

Thank you Steve.

-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Dr.
Stephen Henson
Envoyé : vendredi 12 février 2016 00:30
À : openssl-dev@openssl.org
Objet : Re: [openssl-dev] PKCS12_Parse() no longer extract certificate

On Thu, Feb 11, 2016, Michel wrote:

> Hi,
> 
>  
> 
> I have a test program which is failing using version 1.1 because
> PKCS12_Parse() doesn't return the certificate, just the key. No error 
> is signaled.
> 
> I supposed it is not intended. Is it work in progress ?
> 

That's a bug which should be fixed by commit b3ca51559b1a6cd80d

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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] PKCS12_Parse() no longer extract certificate

[Dr. Stephen Henson]

On Thu, Feb 11, 2016, Michel wrote:

> Hi,
> 
>  
> 
> I have a test program which is failing using version 1.1 because
> PKCS12_Parse() doesn't return the certificate, just the key. No error is
> signaled. 
> 
> I supposed it is not intended. Is it work in progress ?
> 

That's a bug which should be fixed by commit b3ca51559b1a6cd80d

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

Re: [openssl-dev] [openssl.org #4218] Invalid typecasting in CRYPTO_ctr128_encrypt

[Andy Polyakov via RT]

Hi,

>> OpenSSL 1.0.2e
>>
>> At line 156 of crypto/modes/ctr128.c
>>
>> const unsigned char *in, 
>> unsigned char *out,
>> unsigned char ivec[16],
>> unsigned char ecount_buf[16]
>>
>>*(size_t *)(out + n) =
>>*(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n);
>>
>> If the buffers are not aligned, the application crashes due to the invalid 
>> type casting of unsigned char (1 byte) to size_t (4 to 8 bytes for most 
>> CPU:s).
> 
> You should not run into that issue if STRICT_ALIGNMENT is defined.

Well, yes, except that it doesn't check for alignment of ecount_buf. I
mean there is 'if' clause for STRICT_ALIGNMENT that ensures that in, out
and ivec are aligned, but not ecount_buf. And judging from crash report,
it is ecount_buf that is not properly aligned (see last displayed
argument). So that original analysis is sane. It should be noted that it
looks like subroutine in question is called from application directly.
While if called from EVP, i.e. the usual way, the problem never occurs,
because that buffer is properly aligned within EVP_CIPHER_CTX structure.
Resolution will follow later...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4218
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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Kurt Roeckx via RT]

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation 
> strict, but relax the rules on parsing? "Be conservative in what you send, 
> and liberal with what you receive"?

This might be good advice for some things, but ussually not when it
comes to crypto.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Kurt Roeckx]

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation 
> strict, but relax the rules on parsing? "Be conservative in what you send, 
> and liberal with what you receive"?

This might be good advice for some things, but ussually not when it
comes to crypto.


Kurt

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

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Blumenthal, Uri - 0553 - MITLL via RT]

Might I suggest that the right thing in this case would be to keep generation 
strict, but relax the rules on parsing? "Be conservative in what you send, and 
liberal with what you receive"?

Clearly the device manufacturer is at fault here, but the punished party is the 
user - probably not what we should want?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Henson via RT
Sent: Thursday, February 11, 2016 17:27
To: bcri...@gmail.com
Reply To: r...@openssl.org
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to
parse x509 certificate in DER format

On Thu Feb 11 21:38:18 2016, bcri...@gmail.com wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

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=4301
Please log in as guest with password guest if prompted

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


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

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Blumenthal, Uri - 0553 - MITLL]

Might I suggest that the right thing in this case would be to keep generation 
strict, but relax the rules on parsing? "Be conservative in what you send, and 
liberal with what you receive"?

Clearly the device manufacturer is at fault here, but the punished party is the 
user - probably not what we should want?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Henson via RT
Sent: Thursday, February 11, 2016 17:27
To: bcri...@gmail.com
Reply To: r...@openssl.org
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to
parse x509 certificate in DER format

On Thu Feb 11 21:38:18 2016, bcri...@gmail.com wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

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=4301
Please log in as guest with password guest if prompted

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



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 #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

[Andy Polyakov via RT]

Hi,

> I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with 
> the "stvx" assembler instruction in the sha256p8-ppc.s module.  I have built 
> prior version OpenSSL packages on AIX without issue until now (prior was 
> 1.0.1c), and I haven't varied the steps I typically use.  Specifics are:
> 
> AIX: 5200-08

I'm not quite familiar with AIX lingo. What does 5200-08 mean? Is it 5.2?

> ./Configure threads aix64-cc -no-mdc2 -no-idea -no-rc5
> 
> make depend (works ok)
> 
> make (gets the following errors):
> 
> cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  
> -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q64 
> -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -DOPENSSL_BN_ASM_MONT -DSHA1_ASM 
> -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -c -o sha256p8-ppc.o 
> sha256p8-ppc.s
> Assembler:
> sha256p8-ppc.s: line 11: invalid opcode or pseudo-op
> 
> . . . similar diagnostics . . .
> 
> sha256p8-ppc.s: line 767: invalid opcode or pseudo-op
> make: The error code from the last command is 1.

There is ambiguity in the report. First you assert that there is an
issue with stvx instruction, then list lines that refer even to lvx. Is
it possible that your tool-chain can't tolerate *any* vector
instruction, not just stvx and lvx? In such case you probably out of
luck in sense that disabling assembly altogether would be the only
advice from our side. Well, formally speaking one can put an effort into
option to disable vector code in PPC builds, but we are presumably
talking about unsupported platform, unsupported by IBM that is.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229
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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Stephen Henson via RT]

On Thu Feb 11 21:38:18 2016, bcri...@gmail.com wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

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=4301
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] PKCS12_Parse() no longer extract certificate

[Michel]

Hi,

 

I have a test program which is failing using version 1.1 because
PKCS12_Parse() doesn't return the certificate, just the key. No error is
signaled. 

 

I supposed it is not intended. Is it work in progress ?

 

I looks the same with the command line :

with 1.0.2 :

openssl pkcs12 -in Certificate.p12 -clcerts

Enter Import Password:

MAC verified OK

Bag Attributes

localKeyID: 6E D1 .

subject=/CN=PubKeySign Test/C=FR

issuer=/CN=PubKeySign Test/C=FR

-BEGIN CERTIFICATE-

...

-END CERTIFICATE-

Bag Attributes

localKeyID: 6E D1 .

Key Attributes: 

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

-BEGIN ENCRYPTED PRIVATE KEY-

...

-END ENCRYPTED PRIVATE KEY-

 

1.1 : 

c:\OpenSSL_11_dbg\bin\openssl pkcs12 -in Certificate.p12

Enter Import Password:

Bag Attributes

localKeyID: 6E D1 .

Bag Attributes

localKeyID: 6E D1 .

Key Attributes: 

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

-BEGIN ENCRYPTED PRIVATE KEY-

...

-END ENCRYPTED PRIVATE KEY-

 

Regards,

 

Michel

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

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Cristian Berneanu via RT]

The EK certificate is generated and burned into the TPM during
manufacturing. The extraction operation always returns the same certificate.

On Thu, Feb 11, 2016 at 11:16 PM, Stephen Henson via RT 
wrote:

> On Thu Feb 11 07:11:17 2016, bcri...@gmail.com wrote:
> > This is the Endorsement Key certificate extracted from a TPM device.
> >
>
> Does it always do that or is this just an oddity?
>
> 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=4301
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
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] Current Github master fails to compile/link

[Blumenthal, Uri - 0553 - MITLL]

On 2/11/16, 16:16 , "openssl-dev on behalf of Salz, Rich"
 wrote:

>Yes, fixed now.

I confirm the fix. Thanks!


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

[openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Stephen Henson via RT]

On Thu Feb 11 07:11:17 2016, bcri...@gmail.com wrote:
> This is the Endorsement Key certificate extracted from a TPM device.
>

Does it always do that or is this just an oddity?

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=4301
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] Current Github master fails to compile/link

[Salz, Rich]

Yes, fixed now. 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Current Github master fails to compile/link

[Blumenthal, Uri - 0553 - MITLL]

./Configure darwin64-x86_64-cc enable-rfc3779 enable-rc5 enable-md2
enable-deprecated experimental-jpake threads zlib enable-ec_nistp_64_gcc_128
shared --prefix=/Users/ur20980/src/openssl-1.1
--openssldir=/Users/ur20980/src/engines-1.1


…

LD_LIBRARY_PATH=.: clang -DDSO_DLFCN -DHAVE_DLFCN_H
-DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DZLIB -DZLIB_SHARED
-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="/Users/ur20980/src/engines-1.1"
-DENGINESDIR="/Users/ur20980/src/openssl-1.1/lib/engines" -fPIC -fno-common
-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall -O3 -arch x86_64 -dynamiclib
-current_version 1.1 -compatibility_version 1.1 -install_name
/Users/ur20980/src/openssl-1.1/lib/libcrypto.1.1.dylib -o
./libcrypto.1.1.dylib -all_load ./libcrypto.a -L.

Undefined symbols for architecture x86_64:

  "poly1305_blocks", referenced from:

  _poly1305_init in libcrypto.a(poly1305-x86_64.o)

 (maybe you meant: _poly1305_blocks)

  "poly1305_emit", referenced from:

  _poly1305_init in libcrypto.a(poly1305-x86_64.o)

 (maybe you meant: _poly1305_emit)

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see
invocation)

make[4]: *** [link_a.darwin] Error 1

make[3]: *** [do_darwin-shared] Error 2

make[2]: *** [libcrypto.1.1.dylib] Error 2

make[1]: *** [shared] Error 2

make: *** [build_crypto] Error 1

$ 


-- 
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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Dr. Stephen Henson]

On Thu, Feb 11, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

>   ^
> Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
> even without the leading zero byte. See below.
> 
> >>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
> >>contain
> >> leading zeroes. 
> 
> I???m pretty sure this is not correct. It???s been a while since I touched
> ASN.1, but I had quite a bit of experience with it back when.
> 

I should've been a bit clearer. I should have said additional or superfluous
leading zeroes which is the cases here because there is a leading zero and the
MSB of the second octet is also zero. Others have referenced the relevant
sections of the standards that require that.

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

Re: [openssl-dev] [openssl.org #4237] Failed self-tests on AARCH64 (ARM64)

[Andy Polyakov via RT]

Hi,

> $ uname -a
> Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC
> 2015 aarch64 GNU/Linux
> 
> $ make test
> ...
> ../test/recipes/80-test_dane.t  ok
> ../test/recipes/80-test_ocsp.t  ok
> ../test/recipes/80-test_ssl.t . 1/43
> #   Failed test 'test sslv3 with client authentication via BIO pair'
> #   at ../test/recipes/80-test_ssl.t line 345.
> # Looks like you failed 1 test of 27.

Double-check attached patch and report back, please. Cheers.



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

diff --git a/crypto/ec/asm/ecp_nistz256-armv8.pl 
b/crypto/ec/asm/ecp_nistz256-armv8.pl
index 9d1bce1..ce6b69e 100644
--- a/crypto/ec/asm/ecp_nistz256-armv8.pl
+++ b/crypto/ec/asm/ecp_nistz256-armv8.pl
@@ -1289,6 +1289,9 @@ $code.=<<___;
stp $acc0,$acc1,[$rp_real,#$i]
stp $acc2,$acc3,[$rp_real,#$i+16]
 ___
+$code.=<<___   if ($i == 0);
+   adr $bp_real,.Lone_mont-64
+___
 }
 $code.=<<___;
ldp $acc0,$acc1,[$ap_real,#$i]  // in1
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Kurt Roeckx]

See X.690, 8.3.2:
If the contents octets of an integer value encoding consist of more than
one octet, then the bits of the first octet and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE - These rules ensure that an integer value is always encoded
in the smallest possible number of octets.


Kurt

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

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Andy Polyakov via RT]

> I verified the problem on both 1.0.2f and master:
> 
> set LINK=/DEBUG
> perl Configure VC-WIN64A
> ms\do_win64a.bat
> nmake -f ms\nt.make
> 
>  link /nologo /subsystem:console /opt:ref /debug 
> /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp
> LINK : fatal error LNK1181: cannot open input file 'link.obj'
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
> Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d'

Patch is applied. Closing ticket.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Erwann Abalea]

Bonjour,

Le 11 févr. 2016 à 20:25, Blumenthal, Uri - 0553 - MITLL 
mailto:u...@ll.mit.edu>> a écrit :

On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT 
mailto:r...@openssl.org>>
wrote:
On Wed Feb 10 21:59:12 2016, bcri...@gmail.com wrote:
As the error is suggesting it doesn't like the serialNumber in the
certificate.
If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you
get:

13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB
DA
: Error: Integer '00 59 ...' has non-DER encoding.
 ^
Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
even without the leading zero byte. See below.

The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
contain
leading zeroes.

I’m pretty sure this is not correct. It’s been a while since I touched
ASN.1, but I had quite a bit of experience with it back when. SO first of
all, could you please cite your (authoritative) sources stating that an
ASN.1 DER_encoded INTEGER cannot have leading zero. Here’s what others

[openssl-dev] [openssl.org #4279] Re: [openssl.org #3885] [BUGFIX] OpenSSL fails to cross-compile on 32-bit->64-bit

[Andy Polyakov via RT]

> I have an available fix:
> 
> https://github.com/openssl/openssl/pull/597

As per
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fd7dc201d3b9d43972de6a0e659f7ef6421c99cc
problem is addressed in a little bit alternative way. Closing ticket[s].



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4279
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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Blumenthal, Uri - 0553 - MITLL]

>>On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL
>> wrote:
>> 
>> Testing the previous Github version of OpenSSL-1.1 produced encouraging
>> results (notice the leading zero, right where it belongs):
>> 
>> $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
>> ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der
>>&&
>> hexdump -C d.der
>>0:d=0  hl=2 l=   2 prim: INTEGER   :80
>>   02 02 00 80   ||
^^ this is the leading zero

>There's no leading zero in this example.

But there is - “00 80” rather than “80”.

>Don't confuse zero nibbles with zero octets.

Thank you, I don’t. :)


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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Richard Levitte]

Let's put this to rest, shall we?

: ; cat > checkasn1int.sh
#! /bin/sh

CMD="$@"

for x in "3003 02011F" \
 "3003 020180" \
 "3004 0202001F" \
 "3004 02020080"; do
echo Trying sequence $x
echo $x | xxd -r -ps | $CMD
done
: ; sh checkasn1int.sh openssl asn1parse -inform d -i
Trying sequence 3003 02011F
0:d=0  hl=2 l=   3 cons: SEQUENCE  
2:d=1  hl=2 l=   1 prim:  INTEGER   :1F
Trying sequence 3003 020180
0:d=0  hl=2 l=   3 cons: SEQUENCE  
2:d=1  hl=2 l=   1 prim:  INTEGER   :-80
Trying sequence 3004 0202001F
0:d=0  hl=2 l=   4 cons: SEQUENCE  
2:d=1  hl=2 l=   2 prim:  INTEGER   :1F
Trying sequence 3004 02020080
0:d=0  hl=2 l=   4 cons: SEQUENCE  
2:d=1  hl=2 l=   2 prim:  INTEGER   :80
: ; openssl version
OpenSSL 1.0.2f  28 Jan 2016
: ; sh checkasn1int.sh util/shlib_wrap.sh apps/openssl asn1parse -inform d 
-i
Trying sequence 3003 02011F
0:d=0  hl=2 l=   3 cons: SEQUENCE  
2:d=1  hl=2 l=   1 prim:  INTEGER   :1F
Trying sequence 3003 020180
0:d=0  hl=2 l=   3 cons: SEQUENCE  
2:d=1  hl=2 l=   1 prim:  INTEGER   :-80
Trying sequence 3004 0202001F
0:d=0  hl=2 l=   4 cons: SEQUENCE  
2:d=1  hl=2 l=   2 prim:  INTEGER   :BAD INTEGER:[001F]
Trying sequence 3004 02020080
0:d=0  hl=2 l=   4 cons: SEQUENCE  
2:d=1  hl=2 l=   2 prim:  INTEGER   :80
: ; util/shlib_wrap.sh apps/openssl version
OpenSSL 1.1.0-pre3-dev  xx XXX 
: ; 

Cheers,
Richard

In message  on Thu, 11 Feb 2016 19:37:18 +, 
"Blumenthal, Uri - 0553 - MITLL"  said:

uri> On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
uri>  wrote:
uri> 
uri> >If arbitrary leading zero's were allowed in DER, then the encoding
uri> >wouldn't be *distinguished*, i.e., unique.
uri> 
uri> I am NOT talking about “arbitrary” leading zeros. I explicitly state (and
uri> cite the sources, might add the ASN.1 standard itself, and “ASN.1
uri> Complete” by John Larmouth) that a leading zero *is* necessary and
uri> required for a positive integer when its MSB is one (e.g., 0x80). In other
uri> cases it indeed does not belong.
uri> 
uri> >In BER, almost anything goes :)
uri> 
uri> We are *explicitly* and *exclusively* discussing DER. Anything goes for
uri> Bear. :-)
uri> 
uri> P.S. In the integer value provided by Cristian, indeed the MSB was 0 (the
uri> first “valuable” byte was 0x59), so the leading zero byte did not belong.
uri> But I hope OpenSSL-1.1 would properly process 0x02020080.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Salz, Rich]

> Larmouth) that a leading zero *is* necessary and required for a positive
> integer when its MSB is one (e.g., 0x80). In other cases it indeed does not
> belong.

Agreed.  Perhaps I mis-read your note.  Sorry.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Viktor Dukhovni]

> On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> Testing the previous Github version of OpenSSL-1.1 produced encouraging
> results (notice the leading zero, right where it belongs):
> 
> $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
> ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
> hexdump -C d.der
>0:d=0  hl=2 l=   2 prim: INTEGER   :80
>   02 02 00 80   ||
> 0004

There's no leading zero in this example.  Don't confuse zero nibbles
with zero octets.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Blumenthal, Uri - 0553 - MITLL]

Testing the previous Github version of OpenSSL-1.1 produced encouraging
results (notice the leading zero, right where it belongs):

$ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
hexdump -C d.der
0:d=0  hl=2 l=   2 prim: INTEGER   :80
  02 02 00 80   ||
0004
$ dumpasn1 d.der
  0   2: INTEGER 128

0 warnings, 0 errors.
$




P.S. dumpasn1.c doesn’t seem to parse negative integers correctly:

$ x=-128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
hexdump -C d.der
0:d=0  hl=2 l=   1 prim: INTEGER   :-80
  02 01 80  |...|
0003
$ dumpasn1 d.der
  0   1: INTEGER 128
   :   Error: Integer has a negative value.

0 warnings, 1 error.
$ 


-- 
Regards,
Uri Blumenthal





On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
 wrote:

>If arbitrary leading zero's were allowed in DER, then the encoding
>wouldn't be *distinguished*, i.e., unique.
>
>In BER, almost anything goes :)
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


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-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Valerie Anne Fenwick]

Sorry to revive this old thread, I did not see any recent updates.
If there are - please point me that way, and apologies in advance.

I saw a reference to SunOS libc compatibility issues, implying we
never remove functionality. I want to be clear - we do.  We do it
by giving our customers advanced notice, and typically only do
so in a "minor" release (using SunOS version numbering, 5.9, 5.10
and 5.11 were "minor" releases. 5.10.1 (or S10U1) was an update/patch
release).

We give the customers advance notice, and typically continue
to support the feature on the currently released OS and it's updates,
and remove it from the next minor.  For example, all S10 updates
may still support the feature, and it disappeared in S11.

As others have noted, it is impossible to maintain all code forever.
It will create bugs.

I removed the "crypt(1)" command from Solaris 11, and "vi -x / -C" options
as well, because they were based on the ENIGMA rotor. VERY insecure.

We gave notice, told customers they should switch to our
new encrypt(1) command (which had AES available) and made the move.

I like Todd's suggestion (someone else made a similar one, too), but
would take it a step further and prehaps only allow decryption/
verification with these old algorithms when enabled. (if possible)

You can see some crypto related EOF announcements for Solaris here:
http://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.html

Thanks

Valerie

On 11/20/15 02:26 PM, Short, Todd wrote:

While I am all for simplicity, I also think that removing functionality is a 
“bad idea”.

To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive fixes.
2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them and 
rebuild the
library.
Those “who don’t care” (the majority) about the ciphers, should get the 
functionality
that most people care about, basically SSL/TLS connectivity.

--
-Todd Short
// tsh...@akamai.com 
// "One if by land, two if by sea, three if by the Internet."

--
-Todd Short
// tsh...@akamai.com 
// "One if by land, two if by sea, three if by the Internet."


On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
mailto:openssl-dev-boun...@openssl.org> on 
behalf of
bka...@akamai.com > wrote:


On 11/18/2015 07:05 AM, Hubert Kario wrote:

So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
support
both relatively modern TLS with user certificates, preferably the
newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.

That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to make the
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_
they
became obsolete and broken.


There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?


Because it used to be the only real game in town, and *people learned to
rely upon it*.


Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?


No, of course not. But after letting people depend on this “single
cryptographic library” for many years, telling them “too bad” isn’t very
nice.


While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual
implementations.


The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.


I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.


Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:

From the main web page of project:

The OpenSSL Project is a collaborative effort to develop a robust,
commercial-grade, *full-featured*, and Open Source toolkit
implementing the Transport Layer Security (TLS) and Secure Sockets
Layer (SSL) protocols as well as a full-strength *general purpose*
*cryptography library* .

___
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




Valerie
--
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologi

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Blumenthal, Uri - 0553 - MITLL]

On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
 wrote:

>If arbitrary leading zero's were allowed in DER, then the encoding
>wouldn't be *distinguished*, i.e., unique.

I am NOT talking about “arbitrary” leading zeros. I explicitly state (and
cite the sources, might add the ASN.1 standard itself, and “ASN.1
Complete” by John Larmouth) that a leading zero *is* necessary and
required for a positive integer when its MSB is one (e.g., 0x80). In other
cases it indeed does not belong.

>In BER, almost anything goes :)

We are *explicitly* and *exclusively* discussing DER. Anything goes for
Bear. :-)

P.S. In the integer value provided by Cristian, indeed the MSB was 0 (the
first “valuable” byte was 0x59), so the leading zero byte did not belong.
But I hope OpenSSL-1.1 would properly process 0x02020080.


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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Salz, Rich]

If arbitrary leading zero's were allowed in DER, then the encoding wouldn't be 
*distinguished*, i.e., unique.

In BER, almost anything goes :)

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

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

[Blumenthal, Uri - 0553 - MITLL]

>On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT 
>wrote:
>>On Wed Feb 10 21:59:12 2016, bcri...@gmail.com wrote:
>>As the error is suggesting it doesn't like the serialNumber in the
>>certificate.
>> If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you
>> get:
>>
>> 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB
>>DA
>> : Error: Integer '00 59 ...' has non-DER encoding.
  ^
Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
even without the leading zero byte. See below.

>>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
>>contain
>> leading zeroes. 

I’m pretty sure this is not correct. It’s been a while since I touched
ASN.1, but I had quite a bit of experience with it back when. SO first of
all, could you please cite your (authoritative) sources stating that an
ASN.1 DER_encoded INTEGER cannot have leading zero. Here’s what others
 had to say about this:

The private key values are encoded as ASN.1 INTEGERs, which are signed
values
in two's complement format. The leading zero byte is necessary when the
MSB of
the (unsigned) RSA key value is set. Having the MSB set without a 
leading
zero
byte would mean a negative value.


The ASN.1 specs are free and are linked from Wikipedia
.
The relevant section here is in X.690, "8.3 Encoding of an integer 
value”.


In short, the problem is that without that leading zero there is no way to
tell a negative integer from a positive integer.

Here’s how the *current* OSS Nokalva ASN.1 compiler
 DER-encodes integers. First, the ASN.1
spec (had to wrap in a sequence to avoid jostling with the compiler, as I
don’t remember how to write definitions of single primitive types)

World-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
   Tst ::= SEQUENCE {
   value INTEGER (-256..257)
   }
END


And playing with different integer values in the given range:

my-tst Tst ::= 
{ 
   value 127
}


Encodes to 3003 02017F (relevant parts: tag 02, len 01, value 7f)

However this:

my-tst Tst ::= 
{ 
value 128
}


Encodes to 3004 02020080 (integer tag 02, len *02*, and value 00 80) and
for a VERY good reason! If you try to decode the following

3003020180 (what you seem to suggest - the number without the leading
zero) you get:

ASN1STEP: Decoding PDU #1 :

Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 3

value INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
-128

Successfully decoded 5 bytes.
rec1value Tst ::= 
{
value -128
}


Notice that minus.



>>OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is stricter.


I say OpenSSL-1.1 got this wrong, and needs to be fixed.

P.S. Sticking the value of the integer provided provided by Cristian into
OSS ASN.1 DER decoder gave:

 OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.

ASN1STEP: Decoding PDU #1 :
Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 22
D0022E: Integer or enumerated value needlessly long; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
D0023E: Integer or enumerated value too long: 19; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
  value INTEGER: tag = [UNIVERSAL 2] primitive; length = 20
2147483647
S0012E: Decoding of PDU #1 failed with the return code '5'.



Trimming the leading zero from the value (as for *this* particular integer
value that zero is not needed to disambiguate between + and -):

  OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.

ASN1STEP: Decoding PDU #1 :
Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 21
D0023E: Integer or enumerated value too long: 19; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
  value INTEGER: tag = [UNIVERSAL 2] primitive; length = 19
2147483647
S0012E: Decoding of PDU #1 failed with the return code '10'.



The following might also be useful (attempting to encode/decode integer
value 128).

Schema

World-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
  Human ::= INTEGER (0..257)
END

Data: 020180

Decoding:

 OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.


ASN1STEP: Decoding PDU #1 :

D0076S: A negative unsigned integer encountered; check PDU #1 'Human'.
S0012E: Decoding of PDU #1 failed with the return code '2'.


The error is correct: dec

Re: [openssl-dev] Endianess info

[Dmitry Belyavsky]

Dear Rich,

Thank you!
I'll test it during the weekend.

On Thu, Feb 11, 2016 at 9:35 PM, Salz, Rich  wrote:

> Does this patch work for you?
>
> ; git diff
>
> diff --git a/Configure b/Configure
>
> index 3dc6a42..b36bc32 100755
>
> --- a/Configure
>
> +++ b/Configure
>
> @@ -1553,6 +1553,8 @@ foreach (grep /_asm_src$/, keys %target) {
>
>  ($target{$obj} = $target{$src}) =~ s/\.[csS]\b/.o/g;
>
> }
>
>
>
> +$config{lendian} = $config{cflags} =~ /-DL_ENDIAN/ ? 'define' : 'undef';
>
> +
>
> # Write down our configuration where it fits #
>
>
>
> open(OUT,">configdata.pm") || die "unable to create configdata.pm: $!\n";
>
> diff --git a/include/openssl/opensslconf.h.in b/include/openssl/
> opensslconf.h.in
>
> index d9f6429..9dc547f 100644
>
> --- a/include/openssl/opensslconf.h.in
>
> +++ b/include/openssl/opensslconf.h.in
>
> @@ -122,6 +122,8 @@ EOF
>
>
>
> /* Generate 80386 code? */
>
> {- $config{processor} eq "386" ? "#define" : "#undef" -} I386_ONLY
>
> +/* Big or little endian? */
>
> +{- $config{lendian} eq "define" ? "#define" : "#undef" -}
> OPENSSL_LITTLE_ENDIAN
>
>
>
> #undef OPENSSL_UNISTD
>
> #define OPENSSL_UNISTD {- $target{unistd} -}
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> IM: richs...@jabber.at Twitter: RichSalz
>
>
>
> *From:* Dmitry Belyavsky [mailto:beld...@gmail.com]
> *Sent:* Thursday, February 11, 2016 12:45 PM
> *To:* openssl-dev@openssl.org
> *Subject:* Re: [openssl-dev] Endianess info
>
>
>
> Hello Rich,
>
>
>
>
>
>
>
> On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich  wrote:
>
> > Is the endianess information available in any of installed by the 1.1.0
> version *.h files?
> > All the other necessary for building an algorithms-providing engine
> outside of the openssl source tree can be found in the opensslconf.h file.
>
> No, but that's an excellent idea.  Which #define do you need "moved" from
> an existing header file?
>
>
>
> I need the L_ENDIAN #define.
>
>
>
> Thank you!
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Endianess info

[Salz, Rich]

Does this patch work for you?
; git diff
diff --git a/Configure b/Configure
index 3dc6a42..b36bc32 100755
--- a/Configure
+++ b/Configure
@@ -1553,6 +1553,8 @@ foreach (grep /_asm_src$/, keys %target) {
 ($target{$obj} = $target{$src}) =~ s/\.[csS]\b/.o/g;
}

+$config{lendian} = $config{cflags} =~ /-DL_ENDIAN/ ? 'define' : 'undef';
+
# Write down our configuration where it fits #

open(OUT,">configdata.pm") || die "unable to create configdata.pm: $!\n";
diff --git a/include/openssl/opensslconf.h.in b/include/openssl/opensslconf.h.in
index d9f6429..9dc547f 100644
--- a/include/openssl/opensslconf.h.in
+++ b/include/openssl/opensslconf.h.in
@@ -122,6 +122,8 @@ EOF

/* Generate 80386 code? */
{- $config{processor} eq "386" ? "#define" : "#undef" -} I386_ONLY
+/* Big or little endian? */
+{- $config{lendian} eq "define" ? "#define" : "#undef" -} OPENSSL_LITTLE_ENDIAN

#undef OPENSSL_UNISTD
#define OPENSSL_UNISTD {- $target{unistd} -}

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz

From: Dmitry Belyavsky [mailto:beld...@gmail.com]
Sent: Thursday, February 11, 2016 12:45 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Endianess info

Hello Rich,



On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich 
mailto:rs...@akamai.com>> wrote:
> Is the endianess information available in any of installed by the 1.1.0 
> version *.h files?
> All the other necessary for building an algorithms-providing engine outside 
> of the openssl source tree can be found in the opensslconf.h file.

No, but that's an excellent idea.  Which #define do you need "moved" from an 
existing header file?

I need the L_ENDIAN #define.

Thank you!

--
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Endianess info

[Viktor Dukhovni]

> On Feb 11, 2016, at 12:37 PM, Dmitry Belyavsky  wrote:
> 
> Is the endianess information available in any of installed by the 1.1.0 
> version *.h files?
> All the other necessary for building an algorithms-providing engine outside 
> of the openssl source tree can be found in the opensslconf.h file.

Are there any exotic platforms where the same header files might be used
to build executables with either endianness?  If so, the public header
files should not "pin" the endianness, just like they should not "pin"
the machine ABI (32-bit vs. 64-bit, ...).

I don't recall whether any such platforms still exist and are supported.

-- 
Viktor.

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

Re: [openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f

[Viktor Dukhovni]

> On Feb 11, 2016, at 12:30 PM, Salz, Rich  wrote:
> 
> Yes, the order of case labels doesn't matter.  (In fact, it used to be the 
> case that compilers -- back in the stone age, when they generated code on 
> stone tablets -- used to be a little more efficient when you did that.)

I find "default:" first easier to read in some cases, you immediately
know that the default case is handled and how, without having to read
all the other cases and hunt for it further down, especially in large
switches with lots of cases.  I don't always put "default:" first, and
never for any reasons of possible efficiency, but I do it when it seems
more clear and I remember that I find it more clear. :-)

-- 
Viktor.

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

[openssl-dev] [openssl.org #3647] Remove Heartbeat Extension entirely

[Rich Salz via RT]

fixed with 22e3dcb7808bb06cd18c3231e34a5930e796cc48 in master. thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[Dmitry Belyavsky]

Hello Rich,



On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich  wrote:

> > Is the endianess information available in any of installed by the 1.1.0
> version *.h files?
> > All the other necessary for building an algorithms-providing engine
> outside of the openssl source tree can be found in the opensslconf.h file.
>
> No, but that's an excellent idea.  Which #define do you need "moved" from
> an existing header file?
>

I need the L_ENDIAN #define.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4181] Error building openssl with REF_PRINT

[Rich Salz via RT]

fixed in master at commit f3f1cf8444f439c0be9de04bf3821a20d00fd956 thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[Salz, Rich]

> Is the endianess information available in any of installed by the 1.1.0 
> version *.h files?
> All the other necessary for building an algorithms-providing engine outside 
> of the openssl source tree can be found in the opensslconf.h file.

No, but that's an excellent idea.  Which #define do you need "moved" from an 
existing header file?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f

[Dmitry Belyavsky]

Dear Rich,

On Thu, Feb 11, 2016 at 8:30 PM, Salz, Rich  wrote:

> > with leading 'default' label work correctly?
>
> Yes, the order of case labels doesn't matter.  (In fact, it used to be the
> case that compilers -- back in the stone age, when they generated code on
> stone tablets -- used to be a little more efficient when you did that.)
>

Thank you! I was sure from the ancient times that the 'default' label
should be the last one...

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Endianess info

[Dmitry Belyavsky]

Hello OpenSSL Team,

Is the endianess information available in any of installed by the 1.1.0
version *.h files?
All the other necessary for building an algorithms-providing engine outside
of the openssl source tree can be found in the opensslconf.h file.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f

[Salz, Rich]

> with leading 'default' label work correctly?

Yes, the order of case labels doesn't matter.  (In fact, it used to be the case 
that compilers -- back in the stone age, when they generated code on stone 
tablets -- used to be a little more efficient when you did that.)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f

[Dmitry Belyavsky]

Hello all,

Does the code added by the commit 17a723885e8a875fc19d5140f580f80a113ba78f

+switch (EVP_PKEY_id(pk)) {
+default:
+return -1;
+case EVP_PKEY_RSA:
+return SSL_PKEY_RSA_ENC;
+case EVP_PKEY_DSA:
+return SSL_PKEY_DSA_SIGN;

with leading 'default' label work correctly?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3495] Enhance SSL_load_client_CA_file

[Rich Salz via RT]

Thanks for your patience :)

This is checked into master, for part of the next release.
Commit 7823d792d0cad3b44ad5389a8d3381becefe7f44

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3495
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 #4266] OpenSSL-1.1-pre2 cms can not use engine with parameters to sign cms msg

[Stephen Henson via RT]

Now applied as commit 43db7aa2de68e0

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=4266
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 #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded aft

[Salz, Rich via RT]

So now you want to open a PR to fix apps/s_client,server? :)


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2275
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 #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after t

[Rich Salz via RT]

Great, thanks for doing this Joey! Commit 27f172d
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2275
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_INIT_new(): malloc()

[Claus Assmann]

commit 7253fd550c768979ecd3df8f4dbbedd6e9dd76b0

diff --git a/crypto/conf/conf_lib.c b/crypto/conf/conf_lib.c

+/*
+ * These routines call the C malloc/free, to avoid intermixing with
+ * OpenSSL function pointers before the library is initialized.
+ */
+OPENSSL_INIT_SETTINGS *OPENSSL_INIT_new(void)
+{
+OPENSSL_INIT_SETTINGS *ret = malloc(sizeof(*ret));
+
+memset(ret, 0, sizeof(*ret));

If that's a "normal" malloc(), couldn't it return NULL?
Should that be checked?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4266] OpenSSL-1.1-pre2 cms can not use engine with parameters to sign cms msg

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

Any chance these changes to req.c and cms.c will make into 1.1-pre3?

They fix a regression in functionality. req and cms worked in previous versions.
req and cms are not usable in 1.1 with an engine for a smart card.

The "See 4226" should be #4246


On 1/22/2016 7:29 PM, deeng...@gmail.com via RT wrote:
> The inkey parameter of the cms command does not does not accept parameters 
> for an engine to sign the message.
>
> P.S. Also attached are the changes for req.c. to use the key  to hold engine 
> parameters. See  #4226
>
>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 

  Douglas E. Engert  


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4266
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 #4266] OpenSSL-1.1-pre2 cms can not use engine with parameters to sign cms msg

[Douglas E Engert]

Any chance these changes to req.c and cms.c will make into 1.1-pre3?

They fix a regression in functionality. req and cms worked in previous versions.
req and cms are not usable in 1.1 with an engine for a smart card.

The "See 4226" should be #4246


On 1/22/2016 7:29 PM, deeng...@gmail.com via RT wrote:

The inkey parameter of the cms command does not does not accept parameters for 
an engine to sign the message.

P.S. Also attached are the changes for req.c. to use the key  to hold engine 
parameters. See  #4226



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



--

 Douglas E. Engert  

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

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Dannhauer Torben via RT]

Thanks!

-Ursprüngliche Nachricht-
Von: Salz, Rich via RT [mailto:r...@openssl.org] 
Gesendet: Donnerstag, 11. Februar 2016 09:33
An: Dannhauer Torben 
Cc: openssl-dev@openssl.org
Betreff: RE: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in 
Win32 makefiles, easy to fix, solution provided


> What is the status of this bug? Will it be fixed in the next release (1.0.2f
> /1.1.0) ?

yes

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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
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 #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Salz, Rich via RT]

> What is the status of this bug? Will it be fixed in the next release (1.0.2f
> /1.1.0) ?

yes

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
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 #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Dannhauer Torben via RT]

What is the status of this bug? Will it be fixed in the next release (1.0.2f 
/1.1.0) ?

Thanks,
Torben

-Ursprüngliche Nachricht-
Von: Matt Caswell via RT [mailto:r...@openssl.org] 
Gesendet: Mittwoch, 3. Februar 2016 22:48
An: Dannhauer Torben 
Cc: openssl-dev@openssl.org
Betreff: Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in 
Win32 makefiles, easy to fix, solution provided



On 03/02/16 19:43, Salz, Rich via RT wrote:
>> The diff works perfectly on master, but exposed a new bug (bare snprintf).
>> The following patch fixes it.  I can make a PR (or add it to my 
>> existing PR #512) if you'd like.
> 
> Please do as a separate PR.  Thanks.

I think Richard is already on the case, so no need for a PR.

Matt



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

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