Re: [openssl-dev] OpenSSL 1.0.2f build issue - unresolved external symbol

2016-02-29 Thread Atul Thosar
Any thoughts/pointers?
Including openssl-users group in hope if any one aware of this issue.


--
​BR
,
Atul Thosar


On 29 February 2016 at 00:15, Atul Thosar  wrote:

> Hi All,
> I am building OpenSSL v1.0.2f for Win32 platform, but compilation failed
> w/ following errors. I googled a bit, but could not locate the exact
> cause. Appreciate if anyone could help. Thanks in Advance.
>
> rc /fo"tmp32dll\libeay32.res" /d CRYPTO ms\version32.rc
> link /nologo /subsystem:console /opt:ref /debug /dll
> /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def
> @C:\Users\athosar\AppData\Local\Temp\nm43EB.tmp
> Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp
> cryptlib.obj : error LNK2001: unresolved external symbol _OPENSSL_ia32cap_P
> cryptlib.obj : error LNK2019: unresolved external symbol
> _OPENSSL_ia32_cpuid referenced in function _OPENSSL_cpuid_setup
> md5_dgst.obj : error LNK2019: unresolved external symbol
> _md5_block_asm_data_order referenced in function _MD5_Update
> sha1dgst.obj : error LNK2019: unresolved external symbol
> _sha1_block_data_order referenced in function _SHA1_Update
> sha256.obj : error LNK2019: unresolved external symbol
> _sha256_block_data_order referenced in function _SHA256_Update
> sha512.obj : error LNK2019: unresolved external symbol
> _sha512_block_data_order referenced in function _SHA512_Final
>
> out32dll\libeay32.dll : fatal error LNK1120: 6 unresolved externals
> NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual
> Studio 8\VC\BIN\link.EXE"' : return code '0x460'
> Stop.
>
>
> Build machine configurations are -
>
> OS: Windows 7, 64 bit
> Compiler: Visual Studio 2005
> Active Perl Version: v5.16.3
>
> Initial commands given to configure OpenSSL are -
>
> perl Configure VC-WIN32 no-asm --prefix=
> ms\do_ms
> nmake -f ms\ntdll.mak
>
>
> --
> ​BR,
> Atul Thosar
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #4360] [BUG] OpenSSL-1.0.1 crash on sha1_block_data_order_ssse3 asm

2016-02-29 Thread Hejian via RT
Hi:
we met crash of openssl (varely, 3 times i have seen) on linux x86_64.
openSSL version is  1.0.1r.

The stack is as below:
Program terminated with signal 11, Segmentation fault.
Thread 1 (Thread 0x7f0654871700 (LWP 22383)):
#0 0x7f06a2cdddb8 in sha1_block_data_order_ssse3 ()
from */libcrypto.so.1.0.0
#1 0xca62c1d6ca62c1d6 in ?? ()
#2 0xca62c1d6ca62c1d6 in ?? ()
#3 0xca62c1d6ca62c1d6 in ?? ()

We find the similar issue on https://rt.openssl.org/, the ticket id is 3191 .
Can u help me confirm is it the same issue ?
And where can I get the commit b77b58a398c8b9b4113f3fb6b48e162a3b8d4527 ?

Ths !

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4360
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 #2363] bug: memory allocated by DH_new() may never be free()ed

2016-02-29 Thread Salz, Rich via RT
Roumen, you're right.  Does the leak go away when the cleanup_all_ex_data is 
called?



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2363
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 #2363] bug: memory allocated by DH_new() may never be free()ed

2016-02-29 Thread Salz, Rich
Roumen, you're right.  Does the leak go away when the cleanup_all_ex_data is 
called?


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


Re: [openssl-dev] [openssl.org #2363] bug: memory allocated by DH_new() may never be free()ed

2016-02-29 Thread Roumen Petrov via RT
It is expected DH_free(DH_new()); to leaks memory.  Usually XXX method 
initialize "extra data".

Sample code is without code that clear library, at least 
CRYPTO_cleanup_all_ex_data is missing.

Roumen



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2363
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 #4359] Duplicate n2l, etc., macros

2016-02-29 Thread Salz, Rich via RT
>From discussion in GH 664 with Rob Percival.  The issue of repeatd macros came 
>up.


Thanks. I've just looked at merging all of the various definitions of those 
macros and it's not pretty - not all of the definitions match. There's a bug in 
some of the definitions in ssl_locl.h ('c' is not bracketed) and some of the 
defintions in idea_lcl.h appear to have blatantly dishonest comments above them:
/* NOTE - c is not incremented as per n2l */
#define n2ln(c,l1,l2,n) { \
c+=n; \
...



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4359
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] req command crashes using config file containing passwords

2016-02-29 Thread Michel
Hi Viktor,

With your patch applied, I can confirm that the 'req' command now run just
fine.

Thanks,

Michel.
 
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de
Viktor Dukhovni
Envoyé : lundi 29 février 2016 19:00
À : openssl-dev@openssl.org
Objet : Re: [openssl-dev] req command crashes using config file containing
passwords

On Mon, Feb 29, 2016 at 03:51:02PM +0100, Michel wrote:

> They are failing when calling the 'req' command with a configure script
> containing input_password/output password :

Please try the patch below:

-- 
Viktor.

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


[openssl-dev] [openssl.org #4358] Problems in ocsp.1ssl

2016-02-29 Thread e...@thyrsus.com via RT
This is automatically generated email about markup problems in a man
page for which you appear to be responsible.  If you are not the right
person or list, please tell me so I can correct my database.

See http://catb.org/~esr/doclifter/bugs.html for details on how and
why these patches were generated.  Feel free to email me with any
questions.  Note: These patches do not change the modification date of
any manual page.  You may wish to do that by hand.

I apologize if this message seems spammy or impersonal. The volume of
markup bugs I am tracking is over five hundred - there is no real
alternative to generating bugmail from a database and template.

--
 Eric S. Raymond

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

Problems with ocsp.1ssl:

Unbalanced group in command synopis. You probably forgot
to open or close a [ ] or { } group properly.

--- ocsp.1ssl-unpatched 2016-02-29 12:48:13.618729272 -0500
+++ ocsp.1ssl   2016-02-29 12:50:05.234488918 -0500
@@ -165,7 +165,7 @@
 [\fB\-path\fR]
 [\fB\-CApath dir\fR]
 [\fB\-CAfile file\fR]
-[\fB\-no_alt_chains\fR]]
+[\fB\-no_alt_chains\fR]
 [\fB\-VAfile file\fR]
 [\fB\-validity_period n\fR]
 [\fB\-status_age n\fR]
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] req command crashes using config file containing passwords

2016-02-29 Thread Viktor Dukhovni
On Mon, Feb 29, 2016 at 03:51:02PM +0100, Michel wrote:

> They are failing when calling the 'req' command with a configure script
> containing input_password/output password :

Please try the patch below:

-- 
Viktor.

diff --git a/apps/req.c b/apps/req.c
index 693acc2..b128fa8 100644
--- a/apps/req.c
+++ b/apps/req.c
@@ -198,7 +198,9 @@ int req_main(int argc, char **argv)
 char *extensions = NULL, *infile = NULL;
 char *outfile = NULL, *keyfile = NULL, *inrand = NULL;
 char *keyalgstr = NULL, *p, *prog, *passargin = NULL, *passargout = NULL;
-char *passin = NULL, *passout = NULL, *req_exts = NULL, *subj = NULL;
+char *passin = NULL, *passout = NULL;
+char *nofree_passin = NULL, *nofree_passout = NULL;
+char *req_exts = NULL, *subj = NULL;
 char *template = default_config_file, *keyout = NULL;
 const char *keyalg = NULL;
 OPTION_CHOICE o;
@@ -436,15 +438,17 @@ int req_main(int argc, char **argv)
 }
 }
 
-if (!passin) {
-passin = NCONF_get_string(req_conf, SECTION, "input_password");
-if (!passin)
+if (passin == NULL) {
+passin = nofree_passin =
+NCONF_get_string(req_conf, SECTION, "input_password");
+if (passin == NULL)
 ERR_clear_error();
 }
 
-if (!passout) {
-passout = NCONF_get_string(req_conf, SECTION, "output_password");
-if (!passout)
+if (passout == NULL) {
+passout = nofree_passout =
+NCONF_get_string(req_conf, SECTION, "output_password");
+if (passout == NULL)
 ERR_clear_error();
 }
 
@@ -862,8 +866,10 @@ int req_main(int argc, char **argv)
 X509_REQ_free(req);
 X509_free(x509ss);
 ASN1_INTEGER_free(serial);
-OPENSSL_free(passin);
-OPENSSL_free(passout);
+if (passin != nofree_passin)
+OPENSSL_free(passin);
+if (passout != nofree_passout)
+OPENSSL_free(passout);
 OBJ_cleanup();
 return (ret);
 }
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] req command crashes using config file containing passwords

2016-02-29 Thread Michel
Hi,

 

I have some tests scripts that were working well with 1.0.2 and are crashing
using v1.1 (Windows 7).

 

They are failing when calling the 'req' command with a configure script
containing input_password/output password :

 

openssl req -new -batch -key RootCA.key -out RootCA.csr -config RootCA.cnf 

 

"Access violation reading location . "(when freeing output password)

 

here under the call stack :

openssl.exe!CheckBytes(unsigned char * pb, unsigned char bCheck, unsigned
int nSize) Line 1696   C++

openssl.exe!_free_dbg_nolock(void * pUserData, int nBlockUse) Line 1300
C++

openssl.exe!_free_dbg(void * pUserData, int nBlockUse) Line 1265 C++

openssl.exe!free(void * pUserData) Line 49  C++

openssl.exe!CRYPTO_free(void * str, const char * file, int line) Line 226
C

openssl.exe!req_main(int argc, char * * argv) Line 866C

openssl.exe!do_cmd(lhash_st_FUNCTION * prog, int argc, char * * argv) Line
620C

openssl.exe!main(int argc, char * * argv) Line 324  C

 

Let me know if I can help more.

 

Regards,

 

Michel.

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


[openssl-dev] [openssl.org #4357] NIST SP800-56A co-factor ECDH KATs

2016-02-29 Thread Billy Brumley via RT
Didn't see any co-factor ECDH tests, so here's a PR:

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

KATs parsed from here:

http://csrc.nist.gov/groups/STM/cavp/documents/components/ecccdhtestvectors.zip

BBB


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4357
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] Ubsec and Chil engines

2016-02-29 Thread David Woodhouse
On Sat, 2016-02-20 at 12:40 -0800, Sander Temme wrote:
> However, I’m intrigued by the notion of a PKCS#11 Engine in OpenSSL:
> it’s a standard (an OASIS standard now); it’s fairly fully featured;
> everyone in the industry supports it including Thales; and you can
> build a program that calls it without needing a vendor SDK, because
> there are standard headers and a well defined way to get to the entry
> points.  If we can come up with a way to pick a PKCS#11 slot and log
> into it that makes sense (e.g. not by poking PINs into a system wide
> config file etc.) then I think we’d have a winner.

OK, let's explore that. Let's assume, purely for the sake of this
discussion, that we ditch the engine from OpenSSL 1.1 and go *purely*
with a solution based around the existing engine_pkcs11.

From your point of view, what problems are there with that scenario?

You talk about "a way to pick a PKCS#11 slot and log into it"... that's
basically handled by RFC7512, isn't it? The PKCS#11 URI gives us a
standard way to specify not only the slot but also the object therein.
It *also* allows a pin-value attribute to be encoded within the URI if
you want to do that.

If you don't want to encode the PIN, it can be requested at runtime via
a UI_METHOD that you provide. I see the Chil engine also supports an
alternative callback function... does that really provide any more
functionality than your own UI_METHOD does? We could potentially add
that... if we must.

Are there any (other) gaps in required functionality?

Note that engine_pkcs11 doesn't currently support the ?module-path=
query attribute. The code flow of the engine doesn't make that trivial,
since we initialise the engine (and load the provider module) first and
only *later* do we get given a URI to deal with. It's not beyond the
wit of man to fix that though, if we need to.

We *haven't* needed to care about it so far, though. General-purpose
builds (such as building packages for Linux distributions) tend to just
use p11-kit-proxy.so as the default module. That just makes us obey the
*system* configuration for which PKCS#11 modules should be visible to
which applications. And special-purpose use cases can specify a module
in advance when loading the engine. Anyone migrating code which
explicitly uses the Chil engine to engine_pkcs11 would be able to
specify the appropriate module path when loading the engine.

For sanely maintained Linux distributions at least, I want to get to a
point where *any* application which can take certs/keys from a file,
should *also* accept a PKCS#11 URI in place of a file name and should
just work. The Fedora packaging guidelines already say that this SHOULD
be the case, FWIW.

> What I would like to see though is for such a PKCS#11 Engine to be
> part of OpenSSL proper,

Yeah yeah, but not for 1.1. Some of us are hoping to fix that for 1.2
(and not necessarily as an ENGINE but more by having PKCS#11 support
properly integrated). We have agreement from copyright-holders of most
of the existing engine (and libp11, where most of the *functionality*
lies) to relicense it and include it in OpenSSL.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



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


Re: [openssl-dev] MSVC 2015 internal compiler error

2016-02-29 Thread Matt Caswell


On 24/02/16 16:48, Gisle Vanem wrote:
> Matt Caswell wrote:
> 
>> The complete patch is attached. This is currently going through review,
>> and solves the link issue.
> 
> That brought MSVC-2015 back on track. Thanks!
> 

This has now been committed, so hopefully this should work again now.

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