Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.

[Billy Brumley]

> Thanks! Verify attached diff.

Without looking too closely at the asm, at least the output now looks OK to me:

Input point: P
ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d
5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a
d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499
after ecp_nistz256_point_add(A, P, P)
52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39
61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d
b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b
after ecp_nistz256_point_double(B, P)
52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39
61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d
b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b

I will say that I don't understand how ecp_nistz256_point_add_affine
does not have these conditions. Maybe that's a question for the
original authors.

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

Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.

[Andy Polyakov via RT]

Hi,

Thanks! Verify attached diff.


diff --git a/crypto/ec/asm/ecp_nistz256-x86_64.pl b/crypto/ec/asm/ecp_nistz256-x86_64.pl
index c2621c2..824d7b5 100755
--- a/crypto/ec/asm/ecp_nistz256-x86_64.pl
+++ b/crypto/ec/asm/ecp_nistz256-x86_64.pl
@@ -2044,6 +2044,7 @@ $code.=<<___;
 	push	%r15
 	sub	\$32*5+8, %rsp
 
+.Lpoint_double_shortcut$x:
 	movdqu	0x00($a_ptr), %xmm0		# copy	*(P256_POINT *)$a_ptr.x
 	mov	$a_ptr, $b_ptr			# backup copy
 	movdqu	0x10($a_ptr), %xmm1
@@ -2334,6 +2335,7 @@ $code.=<<___;
 	 mov	0x40+8*1($b_ptr), $acc6
 	 mov	0x40+8*2($b_ptr), $acc7
 	 mov	0x40+8*3($b_ptr), $acc0
+	movq	$b_ptr, %xmm1
 
 	lea	0x40-$bias($b_ptr), $a_ptr
 	lea	$Z1sqr(%rsp), $r_ptr		# Z1^2
@@ -2389,7 +2391,7 @@ $code.=<<___;
 	test	$acc0, $acc0
 	jnz	.Ladd_proceed$x			# (in1infty || in2infty)?
 	test	$acc1, $acc1
-	jz	.Ladd_proceed$x			# is_equal(S1,S2)?
+	jz	.Ladd_double$x			# is_equal(S1,S2)?
 
 	movq	%xmm0, $r_ptr			# restore $r_ptr
 	pxor	%xmm0, %xmm0
@@ -2402,6 +2404,13 @@ $code.=<<___;
 	jmp	.Ladd_done$x
 
 .align	32
+.Ladd_double$x:
+	movq	%xmm1, $a_ptr			# restore $a_ptr
+	movq	%xmm0, $r_ptr			# restore $r_ptr
+	add	\$`32*(18-5)`, %rsp		# difference in frame sizes
+	jmp	.Lpoint_double_shortcut$x
+
+.align	32
 .Ladd_proceed$x:
 	`_for_sqr("$R(%rsp)", "$src0")`
 	lea	$Rsqr(%rsp), $r_ptr		# R^2
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.

[Billy Brumley via RT]

> Thanks! Verify attached diff.

Without looking too closely at the asm, at least the output now looks OK to me:

Input point: P
ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d
5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a
d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499
after ecp_nistz256_point_add(A, P, P)
52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39
61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d
b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b
after ecp_nistz256_point_double(B, P)
52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39
61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d
b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b

I will say that I don't understand how ecp_nistz256_point_add_affine
does not have these conditions. Maybe that's a question for the
original authors.

BBB


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

Re: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td"

[Andy Polyakov via RT]

>> The SecurityPolicy.pdf claims that HP-UX 11i IA64 is a Supported
>> Configuration; how can this claim be made when the code does nto even
>> compile correctly?
> 
> The FIPS module compiles correctly but there is the duplicated symbol issue
> when you use the FIPS capable OpenSSL.
> 
> Although we can't change the FIPS module symbols without a change letter you
> can change the symbols on the OpenSSL side. So if you change them to (say)
> ossl_AES_Te and ossl_AES_Td and make sure the non-FIPS capable OpenSSL still
> compiles it should work.

Presumably simpler option should be to remove .global AES_T[ed]#
directives in crypto/aes/asm/aes-ia64.S (see attached). I don't have
possibility to actually verify it on HP-UX, but at least Linux linker
output look proper (can't execute either, only look at binaries).


diff --git a/crypto/aes/asm/aes-ia64.S b/crypto/aes/asm/aes-ia64.S
index 7f6c4c3..0018e02 100644
--- a/crypto/aes/asm/aes-ia64.S
+++ b/crypto/aes/asm/aes-ia64.S
@@ -791,7 +791,6 @@ AES_decrypt:
 
 // leave it in .text segment...
 .align	64
-.global	AES_Te#
 .type	AES_Te#,@object
 AES_Te:	data4	0xc66363a5,0xc66363a5, 0xf87c7c84,0xf87c7c84
 	data4	0xee99,0xee99, 0xf67b7b8d,0xf67b7b8d
@@ -957,7 +956,6 @@ AES_Te:	data4	0xc66363a5,0xc66363a5, 0xf87c7c84,0xf87c7c84
 .size	AES_Te#,2048+256	// HP-UX assembler fails to ".-AES_Te#"
 
 .align	64
-.global	AES_Td#
 .type	AES_Td#,@object
 AES_Td:	data4	0x51f4a750,0x51f4a750, 0x7e416553,0x7e416553
 	data4	0x1a17a4c3,0x1a17a4c3, 0x3a275e96,0x3a275e96
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3252] OpenSSL v1.0.1f issue: decryption failed or bad record mac:s3_pkt.c:484

[Hubert Kario via RT]

On Tuesday 02 February 2016 21:25:13 Rich Salz via RT wrote:
> Sorry we didn't get to this sooner. We're only taking security fixes
> for 1.0.1 now.
> Is this still an issue? (Hubert?)

courtapps.utcourts.gov:443 is down and myrta.com:443 doesn't show the 
problem any more

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

Re: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td"

[Tom Francis via RT]

Use an older version of OpenSSL for your FIPS-enabled OpenSSL?  Yes, it might 
have security problems, but it you’re using the FIPS module!  It’s got worse 
security problems, so you shouldn’t worry. :)

I can say for sure the FIPS 2.0 module compiled and worked at the time the 
Security Policy was approved for HP-UX on IA64 and PA-RISC, in both 32- and 
64-bit flavors.  But it was pretty picky about the link editor and compiler.

Two other issues to be aware of (and maybe fixing this will let the more recent 
versions of OpenSSL work):

1) HP’s link editor is very brittle. You should be sure you’re using the proper 
patch level for it.  I no longer have access to the box I was building on, and 
I’m not sure what the status of the box that was sent for testing is, so I 
can’t check the patch-level for the link editor.  Take a look at the dates in 
the Security Policy, it was the patch that came out about a month (or less?) 
prior to the submission of the FIPS 2.0 module for approval.  The previous 
patch wouldn’t link anything except the HP-UX kernel, so it was released 
outside the normal schedule (and the next patch broke it again, the patch after 
that was OK, but I never tried that one with building the FIPS module or 
FIPS-enabled OpenSSL).

2) You’re definitely using a newer version of the compiler; A.06.25 was the 
current version when the FIPS stuff was approved; depending on your auditors, 
you may need to be using that one.  Especially since the prior versions 
wouldn’t compile the FIPS module correctly, I wouldn’t be surprised if newer 
ones are incapable, too.


TOM

> On Feb 2, 2016, at 6:38 PM, Stuart Kemp via RT  wrote:
> 
> The SecurityPolicy.pdf claims that HP-UX 11i IA64 is a Supported 
> Configuration; how can this claim be made when the code does nto even compile 
> correctly?
> 
> From: Rich Salz via RT [r...@openssl.org]
> Sent: Tuesday, February 02, 2016 4:23 PM
> To: Stuart Kemp
> Cc: openssl-dev@openssl.org
> Subject: [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate 
> Symbol "AES_Te" and "AES_Td"
> 
> If you sneeze on the FIPS code, you need a new CMVP change letter.
> Setting realistic expectations, there are no plans at this time for any FIPS
> work.
> --
> Rich Salz, OpenSSL dev team; rs...@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] Rgd. CVE-2015-3197 fix test verification !!

[Hubert Kario]

On Wednesday 03 February 2016 07:22:05 Hareesh D wrote:
> Can someone please tell me how to verify the fix done for
> 
> CVE-2015-3197. I want to test 1.0.1r version for this issue.
> 
> From the issue description I'm not able to understand what exactly
> client and server doing.
> 
> Please tell me what packet client has to send or else please provide
> me the packet capture of the issue.
> 
> Please help. Thanks !!


I have "published" a reproducer but it is a bit hairy - you will need 
development versions of few python modules, but nothing too crazy. You 
will also need Python 2.6, 3.2 or later.

The relevant libraries are tlslite-ng, tlsfuzzer and python-ecdsa.

To start, download tlsfuzzer and switch to branch with new code:

git clone https://github.com/tomato42/tlsfuzzer
cd tlsfuzzer
git checkout ssl2

Then get the crypto library, switch to its development branch and make 
it available to the tlsfuzzer:

git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
git checkout sslv2
popd
ln -s .tlslite-ng/tlslite tlslite

Then get the dependency of the crypto library:

git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa

Note: In future checking out the development branches will not be 
necessary (the lines with `git checkout` can be skipped).

The relevant test to check if SSLv2 is completely disabled and client 
can't force a connection is
scripts/test-sslv2-force-cipher.py
It will test if the server rejects the SSLv2 style client hello by 
either closing the connection or sending an alert and closing a 
connection.

To run it use the following command:

PYTHONPATH=. python scripts/test-sslv2-force-cipher.py -h hostname \
-p port-number

For example:

PYTHONPATH=. python scripts/test-sslv2-force-cipher.py -h localhost\
-p 4433


All tests returning "OK" and the summary being:

Test end
successful: 21
failed: 0

means that the server is most likely NOT vulnerable.

Any error in form of 

Unexpected message from peer: Handshake(43)

(or any other number) and an exit value of non-zero means that the 
server IS vulnerable.
-- 
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

Re: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td"

[Andy Polyakov via RT]

> Use an older version of OpenSSL for your FIPS-enabled OpenSSL?

For this specific problem it wouldn't help. I mean even older versions
should/would exhibit same problem. And renaming symbols or removing
.global directives (in whatever OpenSSL version being linked with FIPS
module, not FIPS module) would have to be performed for all of them. The
reason for why the problem in question (and similar) slip through is
that FIPS module validation procedure, exhausting as it is, does not
involve linking with "big" OpenSSL. As result one risks to remain
oblivious of them on rare platforms such as one in question till it
becomes too late. But luckily enough one can modify "big" OpenSSL to
accommodate such mishaps. Renaming symbols as general method or
case-specific workarounds like removing .global directives in this case
is the way to go.

> Yes,
> it might have security problems, but it you’re using the FIPS module!
> It’s got worse security problems, so you shouldn’t worry. :)
> 
> I can say for sure the FIPS 2.0 module compiled and worked at the
> time the Security Policy was approved for HP-UX on IA64 and PA-RISC,
> in both 32- and 64-bit flavors. But it was pretty picky about the
> link editor and compiler.
> 
> Two other issues to be aware of (and maybe fixing this will let the
> more recent versions of OpenSSL work):
> 
> 1) HP’s link editor is very brittle. You should be sure you’re using
> the proper patch level for it.  I no longer have access to the box I
> was building on, and I’m not sure what the status of the box that was
> sent for testing is, so I can’t check the patch-level for the link
> editor.  Take a look at the dates in the Security Policy, it was the
> patch that came out about a month (or less?) prior to the submission
> of the FIPS 2.0 module for approval.  The previous patch wouldn’t
> link anything except the HP-UX kernel, so it was released outside the
> normal schedule (and the next patch broke it again, the patch after
> that was OK, but I never tried that one with building the FIPS module
> or FIPS-enabled OpenSSL).
> 
> 2) You’re definitely using a newer version of the compiler; A.06.25
> was the current version when the FIPS stuff was approved; depending
> on your auditors, you may need to be using that one.  Especially
> since the prior versions wouldn’t compile the FIPS module correctly,
> I wouldn’t be surprised if newer ones are incapable, too.

Seconded.


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

[openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?

[Rich Salz via RT]

There were some openssl DTLS bugs that MAtt found and fixed, and the last word
in this ticket was that there were Asterisk bugs causing memory corruption.
Closing ticket.

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

[openssl-dev] Fwd: CVE-2014-8730 TLS CBC Incorrect Padding Abuse Vulnerability

[Shyamal Bhowmik]

Hello,

I am using OpenSSL 1.0.1i 6 Aug 2014 version...

Following is my understanding of the issue:

This is an implementation specific issue and there is no general patch
available. The vulnerability depends on how the padding bytes in TLS data
are handled in CBC mode and is more specific to TLS v1.0. If the padding
bytes in the TLS data received, are handled in the same way as SSLv3 i.e.
they are ignored then this issue can arise. If the TLS data padding bytes
are handled as per standard i.e. every byte in the padding data should be
filled with the total padding length value, then this vulnerability does
not occur.

I have tested this with a TLS v1.0 browser connecting to my server, and the
code flow and debug statements show that during decryption of cipher,
function tls1_cbc_remove_padding() in file libssl/ssl/s3_cbc.c is invoked
which handles padding data. This function checks for validity of every pad
byte value with the last pad byte which holds the total pad length and
returns success or failure as per the validation.
In file libssl/ssl/s3_pkt.c, function ssl3_get_record is called to decrypt
the cipher. Below is a code snippet of this function:

/* decrypt in place in 'rr->input' */
rr->data=rr->input;
enc_err = s->method->ssl3_enc->enc(s,0); // Calls TLS decrypt function
i.e. invoke tls1_enc function in file t1_enc.c that calls
tls1_cbc_remove_padding
/* enc_err is:
 * 0: (in non-constant time) if the record is publically invalid.
 * 1: if the padding is valid
 * -1: if the padding is invalid */
if (enc_err == 0)
{
al=SSL_AD_DECRYPTION_FAILED;
SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_BLOCK_CIPHER_PAD_IS_WRONG);
goto f_err;
}

As seen from above, error is thrown only for 0 return value and -1 return
value is not handled. So if i change the code  if (enc_err == 0)  to  if
(enc_err <= 0) will solve my problem?
There was no specific way to reproduce this issue and it was seen very
sporadically.

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

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

[Rich Salz via RT]

Re-opening it. It would be good to decide soon if we should do this.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #636] Example in man page for BIO_new_bio_pair incorrect?

[Rich Salz via RT]

I've had this ticket open in my list for a long time. I am reluctantly closing
it now. It would be great if someone had a simple testcase or doc fix against
current releases.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

Re: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels

[Daniel Kahn Gillmor via RT]

On Tue 2016-02-02 14:08:18 -0500, Rich Salz via RT wrote:
> any chance you can refresh your 1.0.2 patch? I'm interested in being able to
> accept the common names but not changing the output for compatibility..

I am too :)

it looks like it was already merged, though, as
0ec6898c67aeddc3c414f3cc1af2275d81329c20.

0 dkg@alice:~$ openssl version
OpenSSL 1.0.2f  28 Jan 2016
0 dkg@alice:~$ openssl ciphers -v DHE-DSS-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
0 dkg@alice:~$ openssl ciphers -v EDH-DSS-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
0 dkg@alice:~$ 

do you think there are pieces that aren't yet merged?  have you tried
using the common names with 1.0.2 and they don't work?

  --dkg


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

Re: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE

[Viktor Dukhovni]

> On Feb 3, 2016, at 4:18 PM, Daniel Kahn Gillmor via RT  
> wrote:
> 
> if the cert at the top of the chain is self-signed, it's entirely
> reasonable to say that the expiration date is meaningful.  For example,
> I could distribute a certificate for a root authority which i intend to
> only be useful for 2 years.

That's expressly not the case here, as the certificate is not even self-issued,
let alone self-signed.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE

[Viktor Dukhovni via RT]

> On Feb 3, 2016, at 4:18 PM, Daniel Kahn Gillmor via RT  
> wrote:
> 
> if the cert at the top of the chain is self-signed, it's entirely
> reasonable to say that the expiration date is meaningful.  For example,
> I could distribute a certificate for a root authority which i intend to
> only be useful for 2 years.

That's expressly not the case here, as the certificate is not even self-issued,
let alone self-signed.

-- 
Viktor.


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

[openssl-dev] [openssl.org #4287] Option -attime for "openssl ts -verify"

[Broda, Frank via RT]

On 2016-02-02 15:56, Stephen Henson via RT [r...@openssl.org] wrote:
> IMHO a better way to handle this is to make "ts" handle general verify options
> the same way that ocsp, verify, cms, s_client and s_server do then you get
> -attime support automatically.

Your argument seems valid to me. I'll try, but it will take me some days.

Frank


___
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

[Matt Caswell]

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

___
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

[Matt Caswell via RT]

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


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

Re: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels

[Salz, Rich via RT]

> do you think there are pieces that aren't yet merged?  have you tried using
> the common names with 1.0.2 and they don't work?

Nope, I was just reading through all the tickets to do some basic triage.

I will close this one.  Thanks !


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

[openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels

[Rich Salz via RT]

0ec6898c67aeddc3c414f3cc1af2275d81329c20

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

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

Re: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels

[Salz, Rich]

> do you think there are pieces that aren't yet merged?  have you tried using
> the common names with 1.0.2 and they don't work?

Nope, I was just reading through all the tickets to do some basic triage.

I will close this one.  Thanks !

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

Re: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE

[Daniel Kahn Gillmor via RT]

On Mon 2016-02-01 18:46:20 -0500, Viktor Dukhovni wrote:
> On Mon, Feb 01, 2016 at 11:38:49PM +, Alex Rousskov via RT wrote:
>
>> On 02/01/2016 02:32 PM, openssl-dev@openssl.org via RT wrote:
>> 
>> > Please be more explicit about what errors you feel were not reported.
>> 
>> One specific error mentioned during the previous discussion was "expired
>> certificate". This was ~four years ago, so my recollection may be
>> faulty, but I believe that was _not_ the only hidden error.
>
> Expiration makes no sense for a certificate at the top of the chain,
> it has no issuer, so the date is unsigned and meaningless.

if the cert at the top of the chain is self-signed, it's entirely
reasonable to say that the expiration date is meaningful.  For example,
I could distribute a certificate for a root authority which i intend to
only be useful for 2 years.

How else should i indicate to the end user that the cert should be be
considered unusable after that time?

the fact that a root cert is *not* expired is maybe not too meaningful.
But if it *is* limited in time, then we should take it at its word and
not rely on it after that point, in the same way that if the root cert
is limited via nameConstraints, we should take it at its word and not
rely on it for names outside the bounds of what it declares itself valid
for.

 --dkg


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

[openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der()

[Stephen Henson via RT]

On Fri Jan 29 19:14:50 2016, h...@symas.com wrote:
>
> Just to be clear - in our use case we already know the length. But if
> the
> function you're proposing is returning only a success/error code, then
> the
> function should probably also provide the length as a return
> parameter, for
> more general users.

I've added a new function:

int X509_NAME_get0_der(const unsigned char **pder, size_t *pderlen,
X509_NAME *nm)

Let me know if that suits your needs.

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 #4274] OpenSSL 1.1 X509_NAME_der()

[Howard Chu via RT]

Stephen Henson via RT wrote:
> On Fri Jan 29 19:14:50 2016, h...@symas.com wrote:
>>
>> Just to be clear - in our use case we already know the length. But if
>> the
>> function you're proposing is returning only a success/error code, then
>> the
>> function should probably also provide the length as a return
>> parameter, for
>> more general users.
>
> I've added a new function:
>
> int X509_NAME_get0_der(const unsigned char **pder, size_t *pderlen,
> X509_NAME *nm)
>
> Let me know if that suits your needs.

Thanks, yes, works fine. I saw your commit and merged our support for it 
already. 
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=6bb6d5e3c6269589f5e64805bd849174d62bd3ea

-- 
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


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

[openssl-dev] [openssl.org #1915] Bug Report : Abort when race condition occurs in ERR_get_state

[Rich Salz via RT]

We're cleaning up the threads stuff, see GitHub PR 451.
Thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

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

[Dannhauer Torben via RT]

This bug affects 1.0.2.f and supposedly also 1.1.0 alpha, I reported it already 
3 years (!!) ago as Bug #2928 for OpenSSL 1.0.1c, but it was closed yesterday 
since 1.0.1 development is finished.

Please find attached the Bug description again for OpenSSL 1.0.2f. I provide 
already a solution, so please apply the bug fix to trunk, 1.0.2 and 1.1.0 
branches

The bug is not obvious since only few people use the MSBuild System in this 
extend. However, it is clearly defined by MS how it's build system works and 
thus why OpenSSL building fails in certain conditions.



-- BUG DESCRIPTION (Copied and updated from Bug #2928) --

Dear OpenSSL Team,

I recently tried to build OpenSSL with Visual Studio and I discovered a very 
annoying but easy to fix bug:

In the makefile created by Perl, the linker binary name is assigned to a 
variable named LINK. This variable $(LINK) is called to execute the linker call.
This causes a serious collision with the MS Visual Studio build system which 
also relies on a variable named LINK:

In Visual Studio, the compiler is called cl.exe and the linker is called 
link.exe.
On invocation, they append the command line arguments to the environment 
variable identical to their name (if they exist). This allows to define 
"global" linker or compiler flags which are not part of the makefile.
On the backside this also implies that a makefile must not use internal 
variable names identical to the build systems env-vars "LINK" and "CL".

This error was observed with MS VS 2013 Update 5 but applies to older Visual 
Studios as well.



## Example with the CURRENT (WRONG) status #
Build Environment (Visual Studio Command line):
SET LINK=

Makefile of OpenSSL
SET LINK=link.exe
SET LINKER_ARGS=

The resulting linker call triggered by the makefile script is then:
$(LINK) $(LINKER_ARGS)
Which is extended by the MSVC build system to (because MSVC adds the content of 
the variable LINK after the linker command)
$(LINK) $(LINK) $(LINKER_ARGS)
and finally stripped to:
link.exe link.exe 


This is a double invocation of link.exe which causes link to try linking 
itself, which of course fails.



### CORRECTED Example #
Build Environment (Visual Studio Command line):
SET LINK=

Makefile:
SET LINKER_BIN=link.exe
SET LINKER_ARGS=

The call should be:
$(LINKER_BIN) $(LINKER_ARGS)
Which would be extended by the MSVC build system to
$(LINKER_BIN) $(LINK) $(LINKER_ARGS)
and finally be stripped to:
link.exe  

==>This would be correct and working



 How to solve it: #


- Never use the variables named LINK and CL inside the makefiles or their 
generator scripts.

- Please call the binary variables different, e.g. LINKER_BIN and COMPILER_BIN

- Adapt your build scripts to generate such corrected makefiles


Thank you for your help

Kind regards,
Torben Dannhauer

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

[openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug

[HM via RT]

Hey,

i’m writing to let you know, that the HMAC_Init_ex() function returns a random 
int whenever i use it.
This is in contrast to the documentation, that says “1 for success, 0 for an 
error”.

I’m running OS X 10.11.3 and OpenSSL 1.0.206


Best of wishes,

-- 
Mikk Rätsep
Developer

m...@high-mobility.com  
+372 51 54 052

HIGH MOBILITY  berlin . tallinn . high-mobility.com 

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

[openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der()

[Stephen Henson via RT]

OK thanks for the update, ticket resolved.

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 #4284] Bug in nistz256 assembly code.

[Jun Sun via RT]

Hi Billy,
Thank you very much for verify the bug!

The reason ecp_nistz256_point_add_affine is not affected is that this function 
is only used when a scalar is multiplying the generator point G. In this case, 
a big pre-computed table is used with a 7 bit window size for all fixed window 
positions (that is why the table has 37x64 entries and you do not see a point 
doubling function called there). So at the point when 
ecp_nistz256_point_add_affine is called, p.p is holding the accumulated 
previous window scalar data (lower bits of scalar) by G, and t.a is holding the 
current window scalar value by G, they will never meet each other. So inside 
ecp_nistz256_point_add_affine, no logic to check for doubling.


Jun Sun


From: Billy Brumley via RT 
Sent: February 3, 2016 6:05 AM
To: Jun Sun
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.

> Thanks! Verify attached diff.

Without looking too closely at the asm, at least the output now looks OK to me:

Input point: P
ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d
5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a
d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499
after ecp_nistz256_point_add(A, P, P)
52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39
61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d
b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b
after ecp_nistz256_point_double(B, P)
52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39
61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d
b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b

I will say that I don't understand how ecp_nistz256_point_add_affine
does not have these conditions. Maybe that's a question for the
original authors.

BBB


This email and any attachments are for the sole use of the intended recipients 
and may be privileged or confidential. Any distribution, printing or other use 
by anyone else is prohibited. If you are not an intended recipient, please 
contact the sender immediately, and permanently delete this email and 
attachments.

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

Re: [openssl-dev] [openssl.org #3155] Bug report: S/MIME base64 decoding fails on files that have 76 base64 characters per line

[Jeroen Pluimers via RT]

Hi Rich,

Wow, thanks for reminding me about that.

I know how hard it is to prioritise efforts, especially on open source
projects, so I am really glad there is a fix meaning a workaround for these
files isn't needed any more.

Keep up the good work!

Regards,



Groet,
--
Jeroen W. Pluimers - specialist in .NET, Win32, SQL, Visual Studio & Delphi
tel: +31 20 610 8322
fax: +31 20 610 8323
GSM: +31 654 385 135
mailto:jer...@pluimers.com
Pluimers Software Ontwikkeling BV, Amsterdam, Trade-register 34152606
http://wiert.me ; http://jwpluimers.myplaxo.com/

On Mon, Feb 1, 2016 at 8:52 PM, Rich Salz via RT  wrote:

> We believe this is fixed, please re-open the ticket if not.
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>

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

Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.

[Jun Sun]

Hi Billy,
Thank you very much for verify the bug!

The reason ecp_nistz256_point_add_affine is not affected is that this function 
is only used when a scalar is multiplying the generator point G. In this case, 
a big pre-computed table is used with a 7 bit window size for all fixed window 
positions (that is why the table has 37x64 entries and you do not see a point 
doubling function called there). So at the point when 
ecp_nistz256_point_add_affine is called, p.p is holding the accumulated 
previous window scalar data (lower bits of scalar) by G, and t.a is holding the 
current window scalar value by G, they will never meet each other. So inside 
ecp_nistz256_point_add_affine, no logic to check for doubling.


Jun Sun


From: Billy Brumley via RT 
Sent: February 3, 2016 6:05 AM
To: Jun Sun
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.

> Thanks! Verify attached diff.

Without looking too closely at the asm, at least the output now looks OK to me:

Input point: P
ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d
5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a
d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499
after ecp_nistz256_point_add(A, P, P)
52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39
61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d
b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b
after ecp_nistz256_point_double(B, P)
52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39
61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d
b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b

I will say that I don't understand how ecp_nistz256_point_add_affine
does not have these conditions. Maybe that's a question for the
original authors.

BBB


This email and any attachments are for the sole use of the intended recipients 
and may be privileged or confidential. Any distribution, printing or other use 
by anyone else is prohibited. If you are not an intended recipient, please 
contact the sender immediately, and permanently delete this email and 
attachments.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1979] Add uClibc support

[Rich Salz via RT]

This might be interesting to support, but unfortunately nobody looked at the
bug in years and the build process has changed a great deal. If you could
re-integrate this against what's in master, we'd look at it. If that's too much
work, I understand. We don't have/use this particular run-time environment.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3557] -nameopt utf8 behaviour in openssl 1.0.1i

[Stephen Henson via RT]

Duplicate of ticket #2397 which is now resolved.

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 #3964] Fix OPENSSL_NO_STDIO build

[Rich Salz via RT]

So guys, sorry for dropping the ball. Where are we on this now?
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #2248] CVS HEAD: bug in evp_locl.h - wrong number of bytes/bits passed to encrypt routine in loop

[Rich Salz via RT]

Seems that code had been rewritten/removed; closing ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #2237] Building Openssl on OpenVMS using "extended parse-style"

[Rich Salz via RT]

all fixed in master with the perl-based test framework.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #2752] objects.txt - update of extended key usage

[Rich Salz via RT]

I'm going to add these:
id-kp 21 : secureShellClient : SSH Client
id-kp 22 : secureShellServer : SSH Server
I also found 22-26 from RFC 6495. Any others?

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

Anyone interested in looking at this and porting it to master?
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
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

[Joey Yandle via RT]

> In the makefile created by Perl, the linker binary name is assigned to a 
> variable named LINK. This variable $(LINK) is called to execute the linker 
> call.
> This causes a serious collision with the MS Visual Studio build system which 
> also relies on a variable named LINK:

Are you invoking msbuild.exe to build openssl?  The supported build 
instructions use nmake.exe directly on the generated makefiles.

What is your build invocation?

cheers,

Joey


___
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

[Joey Yandle]

In the makefile created by Perl, the linker binary name is assigned to a 
variable named LINK. This variable $(LINK) is called to execute the linker call.
This causes a serious collision with the MS Visual Studio build system which 
also relies on a variable named LINK:


Are you invoking msbuild.exe to build openssl?  The supported build 
instructions use nmake.exe directly on the generated makefiles.


What is your build invocation?

cheers,

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

Re: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug

[Salz, Rich via RT]

> I’m running OS X 10.11.3 and OpenSSL 1.0.206

I cannot reproduce this.  Did you build from source, or is that a 
vendor-provided version?  The ".206" isn't part of our release naming.  Did you 
mean 1.0.2f?  Do you have a sample program to show the error?


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

[openssl-dev] [openssl.org #3369] 1.0.1g / Windows / patch - missing ZLIB define in cms_lcl.h

[Rich Salz via RT]

old release, reason for change never justified/explained, closing the ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Rich Salz via RT]

our plan for async work is here: https://github.com/openssl/openssl/pull/451

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

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

[openssl-dev] [openssl.org #3778] [PATCH] change RSA modulus length to 2048 in all examples for req

[Rich Salz via RT]

This was done before, forgot to close this ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #4066] bug: openssl clean up crash

[Rich Salz via RT]

No information to reproduce.

Please open a new ticket if still an issue.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
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

[Joey Yandle]

Anyone interested in looking at this and porting it to master?


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

___
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

[Joey Yandle via RT]

> Anyone interested in looking at this and porting it to master?

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


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

[openssl-dev] [openssl.org #3019] [PATCH] avoid null pointer dereference in ubsec_dh_generate_key()

[Rich Salz via RT]

someone already fixed this in 1.0.2
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3527] [PATCH] OpenSSL doesn't build as a DLL on Windows

[Rich Salz via RT]

we fixed this by being better about public/private DLL ordinals.
please re-open ticket if still an issue. thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3537] Bug in TS_check_status_info() and misleading comments

[Rich Salz via RT]

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

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

[openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

[Rich Salz via RT]

I think this is a duplicate.

We're still not implementing Camellia-GCM :)

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

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

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny]

Rich,

Thank you for response.

There is quite a lengthy discussion on that github PR. Is there any TL;DR
version of it?

That PR's diff doesn't really look similar to changes proposed here, as I
was mostly curious about splitting the state maching to allow deferring
things until the required data (RSA-encrypted pre-master) will be available.

I will be more than happy to revive this patch if it sounds interesting to
you. Please let me know.

Thank you,
Fedor.

On Thu, Feb 4, 2016 at 1:15 AM, Rich Salz via RT  wrote:

> our plan for async work is here:
> https://github.com/openssl/openssl/pull/451
>
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Fedor Indutny via RT]

Rich,

Thank you for response.

There is quite a lengthy discussion on that github PR. Is there any TL;DR
version of it?

That PR's diff doesn't really look similar to changes proposed here, as I
was mostly curious about splitting the state maching to allow deferring
things until the required data (RSA-encrypted pre-master) will be available.

I will be more than happy to revive this patch if it sounds interesting to
you. Please let me know.

Thank you,
Fedor.

On Thu, Feb 4, 2016 at 1:15 AM, Rich Salz via RT  wrote:

> our plan for async work is here:
> https://github.com/openssl/openssl/pull/451
>
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>

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

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Salz, Rich via RT]

It’s late and my response was incomplete.
The other part has already landed in master, and that's the "async engine" 
support.


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

[openssl-dev] [openssl.org #3080] Android NEON and CFLAGS options

[Rich Salz via RT]

As discussed in the ticket: you can add the flags on your own if needed;
they're not necessary.
Closing ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Rich Salz via RT]

We're not taking on these new Camellia ciphers for now.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3839] [BUG][PATCH] Compilation error when building with EVP_CHECK_DES_KEY

[Rich Salz via RT]

we removed the feature from master.
if it's necessary for 1.0.2 please re-open the ticket and we'll take the patch.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #2551] [PATCH] All platforms: Option to disable sending renegotiation_info extension.

[Rich Salz via RT]

no longer an issue.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #2752] objects.txt - update of extended key usage

[Rich Salz via RT]

pushed a bunch of new eku's to master.
please open a new ticket (or a PR for objectds.txt) if there are OID's you want
to see added.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #2673] Bug report: OpenSSL Memory leak in B64 encode

[Rich Salz via RT]

An OpenSSL cleanup call (such as clean_ex_data) must be called before existing,
else internal data will be kept around.

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

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

[openssl-dev] [openssl.org #3077] rbuf_freelist and wbuf_freelist corrupted.

[Rich Salz via RT]

We still doubt it is an openssl defect. if you can recreate this on a current
release, please open a new ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #2999] Incomplete fix to remove SSL3_RECORD->orig_len

[Rich Salz via RT]

0.9.8? :) since been fixed.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3145] openssl auto install to /usr/local/lib64

[Rich Salz via RT]

no longer an issue, explicitly set the install tree during config.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3084] openssl-1.0.1e: Configure lacks disable of SSLV2 and Compression by default

[Rich Salz via RT]

Fixed in 1.0.2 and 1.1
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3082] [PATCH] Filter listed protocols from help options based on compile settings

[Rich Salz via RT]

kinda fixed in 1.0.2 and really fixed in 1.1
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #4098] Pull request

[Rich Salz via RT]

we'll be doing the work in https://github.com/openssl/openssl/pull/451
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #4091] Openssl make depends gives errors when no-md5 is specified

[Rich Salz via RT]

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

___
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

[Joey Yandle]

Anyone interested in looking at this and porting it to master?


Looks pretty easy, I'll do it.

___
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

[Joey Yandle via RT]

> Anyone interested in looking at this and porting it to master?

Looks pretty easy, I'll do it.


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

[openssl-dev] [openssl.org #2584] ssltest -test_cipherlist bug incorrectly skipping ciphers

[Rich Salz via RT]

Fixed in the next release (master branch; 1.1)
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #2654] [PATCH] support LDFLAGS in Makefiles

[Rich Salz via RT]

Sorry, nobody looked at this in years.
It's too late for 1.0.1, it might be fixed in 1.0.2, and it's definiltey fixed
in master.
Closing ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3003] Enhancement Request - RFC6698 (DANE) TLSA Support

[Rich Salz via RT]

currently in master, planned for 1.1 scheculed for april 2017
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3058] support for intel compiler on Windows

[Rich Salz via RT]

correct, intel compiler not supported. (as I'm sure you figured out, since you
opened this ticket years ago)
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3050] x509 PEM certificate input parsing bug

[Rich Salz via RT]

the base64 decoding routines were rewritten to be more flexible in the 1.1
release.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3083] [PATCH] Adds sanity checking to malloc()/calloc()/alloca() calls in OpenSSL 1.0.1c

[Rich Salz via RT]

we are much better about checking return values now.
if (when, really) you find more cases where it's not checked in current
releases, please open a new ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3096] OpenSSL 1.0.1e: valgrind errors with -DPURIFY set

[Rich Salz via RT]

We think this is a false positive, please try to recreate against current
releases and open a new ticket if still an issue.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3085] config on *nix does not reject incorrect arguments

[Rich Salz via RT]

Fixed in the next release.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #3098] Enhancement - Validation of country code

[Rich Salz via RT]

Sorry, but I doubt we will do this. Being able to create lowercase CC's is
useful for testing.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

Re: [openssl-dev] [openssl.org #3050] x509 PEM certificate input parsing bug

[Casey McGinty via RT]

Thanks for the follow up, and thanks for all your work on such a critical
tool!

Casey McGinty

On Wed, Feb 3, 2016, 7:56 PM Rich Salz via RT  wrote:

> the base64 decoding routines were rewritten to be more flexible in the 1.1
> release.
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>

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

Re: [openssl-dev] [openssl.org #3699] openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2

[Andy Polyakov via RT]

>> Sorry, we can't touch the FIPS code any more without sponsorship.
> 
> Though if this is still a problem a workaround is to rename the symbols on the
> OpenSSL side outside the FIPS code.

Another possibility is to add .weak directives to sparccpuid.S so that
linker can tolerate multiple symbols.


diff --git a/crypto/sparccpuid.S b/crypto/sparccpuid.S
index 7b12ec2..51ba441 100644
--- a/crypto/sparccpuid.S
+++ b/crypto/sparccpuid.S
@@ -429,6 +429,7 @@ OPENSSL_cleanse:
 .size	OPENSSL_cleanse,.-OPENSSL_cleanse
 
 .global	_sparcv9_vis1_instrument_bus
+.weak	_sparcv9_vis1_instrument_bus
 .align	8
 _sparcv9_vis1_instrument_bus:
 	mov	%o1,%o3	! save cnt
@@ -467,6 +468,7 @@ _sparcv9_vis1_instrument_bus:
 .size	_sparcv9_vis1_instrument_bus,.-_sparcv9_vis1_instrument_bus
 
 .global	_sparcv9_vis1_instrument_bus2
+.weak	_sparcv9_vis1_instrument_bus2
 .align	8
 _sparcv9_vis1_instrument_bus2:
 	mov	%o1,%o3	! save cnt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Fwd: CVE-2014-8730 TLS CBC Incorrect Padding Abuse Vulnerability

[Kurt Roeckx]

On Wed, Feb 03, 2016 at 05:11:34PM +0530, Shyamal Bhowmik wrote:
> 
> /* enc_err is:
>  * 0: (in non-constant time) if the record is publically invalid.
>  * 1: if the padding is valid
>  * -1: if the padding is invalid */
> if (enc_err == 0)
> {
> al=SSL_AD_DECRYPTION_FAILED;
> SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_BLOCK_CIPHER_PAD_IS_WRONG);
> goto f_err;
> }
> 
> As seen from above, error is thrown only for 0 return value and -1 return
> value is not handled. So if i change the code  if (enc_err == 0)  to  if
> (enc_err <= 0) will solve my problem?

If you change that to <= 0 you will introduce a security problem
by leaking timing information.  There is an other check for < 0
below.

> There was no specific way to reproduce this issue and it was seen very
> sporadically.

I'm not sure what you're trying to fix, but if you're getting
padding it's also possible that you actually received a padding
error.

This also doesn't seem to have anything to do with CVE-2014-8730
which we weren't vulnerable to, as you actually explained
yourself.


Kurt

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

[openssl-dev] [openssl.org #3234] [bug] openssl defaults to using tls compression

[Emilia Käsper via RT]

1.1.0 now defaults to no compression: dc5744cb78da6f2bcafeeefe22c604a51b52dfc5.

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

[openssl-dev] [crypto engine]: API users try to find separate external library for new engine

[Catalin Vasile]

I'm trying to make a new crypto engine.

Any application that tries to use my custom OpenSSL library that includes my 
engine gives me an error trying to find an external library for my new engine 
(it tries to locate /usr/lib/libhwrng.so,  where hwrng is my engine), although 
if I run a "grep -R 'hwrng' . " in the install folder it finds references in 
the libcrypto.so .

I have done a "grep -R 'cryptodev' ." and it is referenced the same amount of 
times and in the same files.
What could I be missing that cryptodev is loaded "naturally" (it knows it's 
inside libcrypto.so), but engine hwrng is seen as being something totally 
external?


Cata
 


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

[openssl-dev] [openssl.org #4148] PCKS1 type 1 Padding check error

[Emilia Käsper via RT]

Resolved in ba2de73b185016e0a98e62f75b368ab6ae673919 for master (1.1.0). This
isn't really a bug so we won't be backporting to stable branches, though.

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

Re: [openssl-dev] [crypto engine]: API users try to find separate external library for new engine

[Alexander Gostrer]

Hi Cata,

We solved this problem in our project:
https://github.com/AtmelCSO/cryptoauth-openssl-engine
I may be wrong but I think it was done using "export LD_LIBRARY_PATH=". Try it. If it will not work then you dig into our engine.

Regards,
Alex Gostrer

On Wed, Feb 3, 2016 at 9:00 AM, Catalin Vasile  wrote:

>
>
> I'm trying to make a new crypto engine.
>
> Any application that tries to use my custom OpenSSL library that includes
> my engine gives me an error trying to find an external library for my new
> engine (it tries to locate /usr/lib/libhwrng.so,  where hwrng is my
> engine), although if I run a "grep -R 'hwrng' . " in the install folder it
> finds references in the libcrypto.so .
>
> I have done a "grep -R 'cryptodev' ." and it is referenced the same amount
> of times and in the same files.
> What could I be missing that cryptodev is loaded "naturally" (it knows
> it's inside libcrypto.so), but engine hwrng is seen as being something
> totally external?
>
>
> Cata
>
>
>
> ___
> 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 #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Torben Dannhauer via RT]

Zitat von Andy Polyakov via RT :

> On 02/03/16 17:15, Joey Yandle via RT wrote:
>>> In the makefile created by Perl, the linker binary name is assigned to a
>>> variable named LINK. This variable $(LINK) is called to execute the
>>> linker call.
>>> This causes a serious collision with the MS Visual Studio build system
>>> which also relies on a variable named LINK:
>>
>> Are you invoking msbuild.exe to build openssl?  The supported build
>> instructions use nmake.exe directly on the generated makefiles.
>>
>> What is your build invocation?
>
> That was my initial reaction too. The problem description sounds like as
> if something else is being talked about. Indeed, it refers to SET
> LINK=link.exe (there is not *SET* LINK in generated makefile), and you
> can't help wondering how would such problem go unnoticed for such long
> time. But as it turns out... Consider
>
> FOO=bar
>
> all:
>   echo %%FOO%%
>
> If passed to nmake, it prints "%FOO%" as long as there is no environment
> variable named FOO. But as soon as you assign FOO variable prior
> invoking nmake it prints "bar" irregardless[!] FOO's original value.
> LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables
> that can be used to specify kind of site-specific defaults. I find it
> hard to imagine how LINK would be useful in general case, i.e. as
> something that would be applicable to *all* linked binaries, but I
> suppose one can't deny the option to do so. Out of curiosity what's
> yours? And verify attached diff and report back.



Hi, thanks for feedback,

I use nmake as described in the instructions.

Indeed, as I discovered and reported the bug 3 years ago, my first  
question was how such a problem was undiscovered for so a long time.  
At least now we are talking about it and agree we should fix it.

Technical details:

The env variable LINK is only evaluated by link.exe if it is set in  
the commandline (e.g. as required for compiling WinXP compatible  
binaries with VS 2012 and newer: setting another subsystem version)
Since WinXP compiling is more than only setting linker flags, we  
simulate it by setting instead a empty LINK variable- the key aspect  
is that the COMMANDLINE has a set LINK variable , then the LINK  
variable is evaluated by link.exe and the error occurs. This happens  
because the OpenSSL makefile uses a also variable named LINK.

To reproduce the error, open visual studio x64 commandline and enter:

Set link=""
perl Configure VC-WIN64A --prefix=c:\tmp_open_ssl_x64
ms\do_win64a
nmake -f "ms\ntdll.mak"

-> wait and see the linker step failing..

The provided patch is exactly what I did the last 3 years manually in  
the ntdll.mak makefile before starting the compilation.

I would be very glad to see it marger into trunk.

regards,
Torben


PS.: The full story to compile WinXP compatible binaries on  
commandline in VS2012 and newer is this:

--- x86 -

@set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE%
@set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH%
@set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB%
@set CL=/D_USING_V110_SDK71_;%CL%

@set LINK=/SUBSYSTEM:CONSOLE,5.01 /MANIFEST %LINK%

@echo Switched to XP target x86



--- x64 (WinXp x64 is quite rare)

@set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE%
@set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH%
@set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB%
@set CL=/D_USING_V110_SDK71_;%CL%

@set LINK=/SUBSYSTEM:CONSOLE,5.02 /MANIFEST %LINK%

@echo Switched to XP target x64





___
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

[Joey Yandle 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'


___
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

[Joey Yandle]

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'


___
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

[Torben Dannhauer via RT]

 

Zitat von Andy Polyakov via RT <  r...@openssl.org>:

 

> On 02/03/16 17:15, Joey Yandle via RT wrote:

>>> In the makefile created by Perl, the linker binary name is assigned 

>>> to a variable named LINK. This variable $(LINK) is called to execute 

>>> the linker call.

>>> This causes a serious collision with the MS Visual Studio build 

>>> system which also relies on a variable named LINK:

>> 

>> Are you invoking msbuild.exe to build openssl?  The supported build 

>> instructions use nmake.exe directly on the generated makefiles.

>> 

>> What is your build invocation?

> 

> That was my initial reaction too. The problem description sounds like 

> as if something else is being talked about. Indeed, it refers to SET 

> LINK=link.exe (there is not *SET* LINK in generated makefile), and you 

> can't help wondering how would such problem go unnoticed for such long 

> time. But as it turns out... Consider

> 

> FOO=bar

> 

> all:

> echo %%FOO%%

> 

> If passed to nmake, it prints "%FOO%" as long as there is no 

> environment variable named FOO. But as soon as you assign FOO variable 

> prior invoking nmake it prints "bar" irregardless[!] FOO's original value.

> LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables 

> that can be used to specify kind of site-specific defaults. I find it 

> hard to imagine how LINK would be useful in general case, i.e. as 

> something that would be applicable to *all* linked binaries, but I 

> suppose one can't deny the option to do so. Out of curiosity what's 

> yours? And verify attached diff and report back.

 

 

 

Hi, thanks for feedback,

 

I use nmake as described in the instructions.

 

Indeed, as I discovered and reported the bug 3 years ago, my first question
was how such a problem was undiscovered for so a long time.  

At least now we are talking about it and agree we should fix it.

 

Technical details:

 

The env variable LINK is only evaluated by link.exe if it is set in the
commandline (e.g. as required for compiling WinXP compatible binaries with
VS 2012 and newer: setting another subsystem version) Since WinXP compiling
is more than only setting linker flags, we simulate it by setting instead a
empty LINK variable- the key aspect is that the COMMANDLINE has a set LINK
variable , then the LINK variable is evaluated by link.exe and the error
occurs. This happens because the OpenSSL makefile uses a also variable named
LINK.

 

To reproduce the error, open visual studio x64 commandline and enter:

 

Set link=""

perl Configure VC-WIN64A --prefix=c:\tmp_open_ssl_x64 ms\do_win64a nmake -f
"ms\ntdll.mak"

 

-> wait and see the linker step failing..

 

The provided patch is exactly what I did the last 3 years manually in the
ntdll.mak makefile before starting the compilation.

 

I would be very glad to see it marger into trunk.

 

regards,

Torben

 

 

PS.: The full story to compile WinXP compatible binaries on commandline in
VS2012 and newer is this:

 

--- x86 -

 

@set INCLUDE=%ProgramFiles(x86)%\Microsoft
SDKs\Windows\7.1A\Include;%INCLUDE%

@set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set
LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB% @set
CL=/D_USING_V110_SDK71_;%CL%

 

@set LINK=/SUBSYSTEM:CONSOLE,5.01 /MANIFEST %LINK%

 

@echo Switched to XP target x86

 

 

 

--- x64 (WinXp x64 is quite rare)

 

@set INCLUDE=%ProgramFiles(x86)%\Microsoft
SDKs\Windows\7.1A\Include;%INCLUDE%

@set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set
LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB% @set
CL=/D_USING_V110_SDK71_;%CL%

 

@set LINK=/SUBSYSTEM:CONSOLE,5.02 /MANIFEST %LINK%

 

@echo Switched to XP target x64

 

 

 


___
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

[Joey Yandle]

And verify attached diff and report back.


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.


diff --git a/test/ssltest.c b/test/ssltest.c
index 5d6700e..9cd2a53 100644
--- a/test/ssltest.c
+++ b/test/ssltest.c
@@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int 
family, long count,

 if (BIO_do_accept(acpt) <= 0)
 goto err;

-snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt));
+BIO_snprintf(addr_str, sizeof(addr_str), ":%s", 
BIO_get_accept_port(acpt));


 client = BIO_new_connect(addr_str);
 BIO_set_conn_ip_family(client, family);

___
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

[Joey Yandle via RT]

> And verify attached diff and report back.

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.

diff --git a/test/ssltest.c b/test/ssltest.c
index 5d6700e..9cd2a53 100644
--- a/test/ssltest.c
+++ b/test/ssltest.c
@@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int 
family, long count,
  if (BIO_do_accept(acpt) <= 0)
  goto err;

-snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt));
+BIO_snprintf(addr_str, sizeof(addr_str), ":%s", 
BIO_get_accept_port(acpt));

  client = BIO_new_connect(addr_str);
  BIO_set_conn_ip_family(client, family);


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

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


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

[openssl-dev] [openssl.org #1683] OPENSSL_NO_{RSA, DSA, DH} defines not honored

[Rich Salz via RT]

For 1.1 we did a cleanup pass that should have fixed all of these.
Please open a new ticket if there are still issues.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [openssl.org #1876] cross compilation patch from TANDBERG

[Rich Salz via RT]

This is patch is for 0.9.8
The current releases have much better cross-compile support.
Please open a new ticket if this is still an issue.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl-dev] [crypto engine]: API users try to find separate external library for new engine

[Catalin Vasile]

I'm trying to make a new crypto engine.


Any application that tries to use my custom OpenSSL library that includes my 
engine gives me an error trying to find an external library for my new engine 
(it tries to locate /usr/lib/libhwrng.so, where hwrng is my engine), although 
if I run a "grep -R 'hwrng' . " in the install folder it finds references in 
the libcrypto.so .


I have done a "grep -R 'cryptodev' ." and it is referenced the same amount of 
times and in the same files.

What could I be missing that cryptodev is loaded "naturally" (it knows it's 
inside libcrypto.so), but engine hwrng is seen as being something totally 
external?


Cata
___
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]

On 02/03/16 17:15, Joey Yandle via RT wrote:
>> In the makefile created by Perl, the linker binary name is assigned to a 
>> variable named LINK. This variable $(LINK) is called to execute the linker 
>> call.
>> This causes a serious collision with the MS Visual Studio build system which 
>> also relies on a variable named LINK:
> 
> Are you invoking msbuild.exe to build openssl?  The supported build 
> instructions use nmake.exe directly on the generated makefiles.
> 
> What is your build invocation?

That was my initial reaction too. The problem description sounds like as
if something else is being talked about. Indeed, it refers to SET
LINK=link.exe (there is not *SET* LINK in generated makefile), and you
can't help wondering how would such problem go unnoticed for such long
time. But as it turns out... Consider

FOO=bar

all:
echo %%FOO%%

If passed to nmake, it prints "%FOO%" as long as there is no environment
variable named FOO. But as soon as you assign FOO variable prior
invoking nmake it prints "bar" irregardless[!] FOO's original value.
LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables
that can be used to specify kind of site-specific defaults. I find it
hard to imagine how LINK would be useful in general case, i.e. as
something that would be applicable to *all* linked binaries, but I
suppose one can't deny the option to do so. Out of curiosity what's
yours? And verify attached diff and report back.



diff --git a/util/mk1mf.pl b/util/mk1mf.pl
index f9eeea8..506d491 100755
--- a/util/mk1mf.pl
+++ b/util/mk1mf.pl
@@ -646,7 +646,7 @@ EX_LIBS=$ex_libs
 # The OpenSSL directory
 SRC_D=$src_dir
 
-LINK=$link
+LINK_CMD=$link
 LFLAGS=$lflags
 RSC=$rsc
 FIPSLINK=\$(PERL) util${o}fipslink.pl
diff --git a/util/pl/BC-32.pl b/util/pl/BC-32.pl
index 36ad682..364c4d4 100644
--- a/util/pl/BC-32.pl
+++ b/util/pl/BC-32.pl
@@ -142,7 +142,7 @@ ___
 		{
 		local($ex)=($target =~ /O_SSL/)?' $(L_CRYPTO)':'';
 		$ex.=' ws2_32.lib gdi32.lib';
-		$ret.="\t\$(LINK) \$(MLFLAGS) $efile$target /def:ms/${Name}.def @<<\n  \$(SHLIB_EX_OBJ) $objs $ex\n<<\n";
+		$ret.="\t\$(LINK_CMD) \$(MLFLAGS) $efile$target /def:ms/${Name}.def @<<\n  \$(SHLIB_EX_OBJ) $objs $ex\n<<\n";
 		}
 	$ret.="\n";
 	return($ret);
@@ -156,7 +156,7 @@ sub do_link_rule
 	$file =~ s/\//$o/g if $o ne '/';
 	$n=($target);
 	$ret.="$target: $files $dep_libs\n";
-	$ret.="\t\$(LINK) \$(LFLAGS) $files \$(APP_EX_OBJ), $target,, $libs\n\n";
+	$ret.="\t\$(LINK_CMD) \$(LFLAGS) $files \$(APP_EX_OBJ), $target,, $libs\n\n";
 	return($ret);
 	}
 
diff --git a/util/pl/Mingw32.pl b/util/pl/Mingw32.pl
index fe3fb27..55c85f6 100644
--- a/util/pl/Mingw32.pl
+++ b/util/pl/Mingw32.pl
@@ -98,7 +98,7 @@ sub do_link_rule
 	$file =~ s/\//$o/g if $o ne '/';
 	$n=($target);
 	$ret.="$target: $files $dep_libs\n";
-	$ret.="\t\$(LINK) ${efile}$target \$(LFLAGS) $files $libs\n\n";
+	$ret.="\t\$(LINK_CMD) ${efile}$target \$(LFLAGS) $files $libs\n\n";
 	return($ret);
 	}
 1;
diff --git a/util/pl/OS2-EMX.pl b/util/pl/OS2-EMX.pl
index 28cd116..92a332e 100644
--- a/util/pl/OS2-EMX.pl
+++ b/util/pl/OS2-EMX.pl
@@ -99,7 +99,7 @@ sub do_lib_rule
 		{
 		local($ex)=($target =~ /O_SSL/)?' $(L_CRYPTO)':'';
 		$ex.=' -lsocket';
-		$ret.="\t\$(LINK) \$(SHLIB_CFLAGS) \$(MLFLAGS) $efile$target \$(SHLIB_EX_OBJ) \$(${Name}OBJ) $ex os2/${Name}.def\n";
+		$ret.="\t\$(LINK_CMD) \$(SHLIB_CFLAGS) \$(MLFLAGS) $efile$target \$(SHLIB_EX_OBJ) \$(${Name}OBJ) $ex os2/${Name}.def\n";
 		$ret.="\temximp -o $out_def/$name.a os2/${Name}.def\n";
 		$ret.="\temximp -o $out_def/$name.lib os2/${Name}.def\n\n";
 		}
@@ -113,7 +113,7 @@ sub do_link_rule
 	$file =~ s/\//$o/g if $o ne '/';
 	$n=($target);
 	$ret.="$target: $files $dep_libs\n";
-	$ret.="\t\$(LINK) ${efile}$target \$(CFLAG) \$(LFLAGS) $files $libs\n\n";
+	$ret.="\t\$(LINK_CMD) ${efile}$target \$(CFLAG) \$(LFLAGS) $files $libs\n\n";
 	return($ret);
 	}
 
diff --git a/util/pl/VC-32.pl b/util/pl/VC-32.pl
index 73160e9..258b694 100644
--- a/util/pl/VC-32.pl
+++ b/util/pl/VC-32.pl
@@ -361,7 +361,7 @@ sub do_lib_rule
  		if ($fips && $target =~ /O_CRYPTO/)
 			{
 			$ret.="$target: $objs \$(PREMAIN_DSO_EXE)";
-			$ret.="\n\tSET FIPS_LINK=\$(LINK)\n";
+			$ret.="\n\tSET FIPS_LINK=\$(LINK_CMD)\n";
 			$ret.="\tSET FIPS_CC=\$(CC)\n";
 			$ret.="\tSET FIPS_CC_ARGS=/Fo\$(OBJ_D)${o}fips_premain.obj \$(SHLIB_CFLAGS) -c\n";
 			$ret.="\tSET PREMAIN_DSO_EXE=\$(PREMAIN_DSO_EXE)\n";
@@ -375,7 +375,7 @@ sub do_lib_rule
 		else
 			{
 			$ret.="$target: $objs";
-			$ret.="\n\t\$(LINK) \$(MLFLAGS) $efile$target $name @<<\n  \$(SHLIB_EX_OBJ) $objs $ex \$(EX_LIBS)\n<<\n";
+			$ret.="\n\t\$(LINK_CMD) \$(MLFLAGS) $efile$target $name @<<\n  \$(SHLIB_EX_OBJ) $objs $ex \$(EX_LIBS)\n<<\n";
 			}
 
 		$ret.="\tIF EXIST \$@.manifest mt -nologo -manifest \$@.manifest -outputresource:\$@;2\n\n";
@@ -393,13 +393,13 @@ sub do_link_rule
 	$ret.="$target: $files $dep_libs\n";
 	if ($standalone == 1)
 		{
-		$ret.="  \$(LINK) \$(LFLAGS) $efile$target @<<\n\t";
+		$ret.=" 

Re: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug

[HM via RT]

I built it using cocoapods, the OpenSSL headers show 1.0.2f.
I’ll try to make some sample program tomorrow.


> On 3 veebr 2016, at 18:27, Salz, Rich via RT  wrote:
> 
>> I’m running OS X 10.11.3 and OpenSSL 1.0.206
> 
> I cannot reproduce this.  Did you build from source, or is that a 
> vendor-provided version?  The ".206" isn't part of our release naming.  Did 
> you mean 1.0.2f?  Do you have a sample program to show the error?
> 
> 


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

[openssl-dev] [openssl.org #1995] Man pages for the "rsa" utility should clearly state what output formats are used

[Rich Salz via RT]

everything is now the standard format, except where noted.
if i'm wrong, please re-open the ticket and give specifics so we can fix it.
thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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