Re: [openssl.org #2128] PKCS12_PBE_add is a noop but maybe it should add the algorithms?
On Tue, Dec 15, 2009 at 10:18 AM, Tomas Mraz via RT r...@openssl.org wrote: If you call just SSL_library_init() and PKCS12_PBE_add some pkcs12 files will not be loadable and moreover the openssl will crash due to missing checks for ciphers not found. I've reported the crash in a separate report. Perhaps the PKCS12_PBE_add should add the algorithms which are not added in the SSL_library_init() call but which are used in the static PBE algorithms table? It looks like this behaviorwith PKCS12_PBE_add() changed in this commit: (date: 2006-05-15 20:34:35 +0300; author: steve; state: Exp; lines: +0 -2; commitid: AaVb4NIRWO7LR8xr;) | crypto/evp/c_allc.c:1.12, CHANGES:1.1316, crypto/pkcs12/p12_crpt.c:1.20, | crypto/evp/evp_pbe.c:1.21, crypto/evp/p5_crpt.c:1.21 ` Change builting PBE to use static table. Add entries for HMAC and MD5, GOST. Neither the commit log nor the CHANGES file entry state clearly that this removed some ciphers from being registered with PKCS12_PBE_add() call. As far as PKCS#12 files are concerned, the disappearance of EVP_rc2_40_cbc() is especially unfortunate. Was this removed on purpose, i.e., was it understood that this will require changes in applications that do not register all ciphers by default? I used to call SSL_library_init() (i.e., add SSL ciphers/digests) and PKCS12_PBE_add() (to get whatever else would be needed for PKCS#12 files), but that does not work anymore with OpenSSL 1.0.0-beta4. For now, I'm adding EVP_add_cipher(EVP_rc2_40_cbc()) call to get the behavior closer to what it used to be. While there is a note saying that typical applications will call OpenSSL_add_all_algorithms() (which would avoid this issue), it could be worth documenting the difference in behavior between 0.9.8 and 1.0.0 more explicitly as far as PKCS12_PBE_add() is concerned. - Jouni __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2135] [patch] fix few LIBDIR refs in engines/
openssl-1.0.0-beta4 and the openssl-1.0.0-stable branch are still using
/lib/ instead of /$(LIBDIR)/ in a few places.
-mike
Index: engines/Makefile
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/engines/Makefile,v
retrieving revision 1.23.2.4
diff -u -p -r1.23.2.4 Makefile
--- engines/Makefile 10 Nov 2009 01:52:52 - 1.23.2.4
+++ engines/Makefile 11 Jan 2010 02:48:32 -
@@ -107,7 +107,7 @@ install:
@[ -n $(INSTALLTOP) ] # should be set by top Makefile...
@if [ -n $(SHARED_LIBS) ]; then \
set -e; \
- $(PERL) $(TOP)/util/mkdir-p.pl $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines; \
+ $(PERL) $(TOP)/util/mkdir-p.pl $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines; \
for l in $(LIBNAMES); do \
( echo installing $$l; \
pfx=lib; \
Index: engines/ccgost/Makefile
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/engines/ccgost/Makefile,v
retrieving revision 1.9.2.1
diff -u -p -r1.9.2.1 Makefile
--- engines/ccgost/Makefile 2 Apr 2009 15:04:01 - 1.9.2.1
+++ engines/ccgost/Makefile 11 Jan 2010 02:48:33 -
@@ -53,13 +53,13 @@ install:
*DSO_WIN32*) sfx=eay32.dll; pfx=;; \
*) sfx=.bad;; \
esac; \
- cp $${pfx}$(LIBNAME)$$sfx $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx.new; \
+ cp $${pfx}$(LIBNAME)$$sfx $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx.new; \
else \
sfx=.so; \
- cp cyg$(LIBNAME).dll $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx.new; \
+ cp cyg$(LIBNAME).dll $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx.new; \
fi; \
- chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx.new; \
- mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx; \
+ chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx.new; \
+ mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx; \
fi
links:
Re: [openssl.org #2135] [patch] fix few LIBDIR refs in engines/
On Sunday 10 January 2010 21:53:03 Mike Frysinger wrote: openssl-1.0.0-beta4 and the openssl-1.0.0-stable branch are still using /lib/ instead of /$(LIBDIR)/ in a few places. there is also a missing ref in the top level Makefile.org -mike Index: Makefile.org === RCS file: /usr/local/src/openssl/CVSROOT/openssl/Makefile.org,v retrieving revision 1.295.2.8 diff -u -p -r1.295.2.8 Makefile.org --- Makefile.org 15 Oct 2009 23:44:11 - 1.295.2.8 +++ Makefile.org 11 Jan 2010 03:01:02 - @@ -551,7 +551,7 @@ install_sw: fi; \ done; \ ( here=`pwd`; \ - cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \ + cd $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR); \ $(MAKE) -f $$here/Makefile HERE=$$here link-shared ); \ if [ $(INSTALLTOP) != /usr ]; then \ echo 'OpenSSL shared libraries have been installed in:'; \ signature.asc Description: PGP signature
[openssl.org #2136] Add display of old-style (MD5) subject/issuer hash to x509 command
This is an enhancement request that addresses an incompatibility
introduced with the new SHA1-based hashing of the subject/issuer name
defined in openssl 1.0.0. The necessary patches based on openssl
1.0.0-beta4 are attached.
Reason for the request:
The change forces sites, that distribute information, e.g. links, based
on the subject/issuer hash to sites using either 0.9.x or 1.x.x versions
of openssl, to install both of these versions in order to be able to
generate and display the hashes required for the 2 versions.
Since the basic functions required for the generation of both hash types
are anyhow present in openssl version 1.0.0+ only the integration of the
old-style (MD5 based) hash in the x509 command as an additional display
option for both the subject and the issuer hash is missing. The attached
patches for apps/x509.c and crypto/x509/x509_cmp.c provide the necessary
additions.
Please add the requested feature to the final 1.0.0 release.
Best regards
Willy Weisz
--
---
Willy Weisz
European Centre for Parallel Computing at Vienna (VCPC)
Computational Science Center
Nordbergstrasse 15/C312
A-1090 Wien
Tel: (+43 1) 4277 - 39424 Fax: (+43 1) 4277 - 9394
Mobile: +43 699 10109546e-mail: we...@vcpc.univie.ac.a
--- apps/x509.c.orig2009-10-18 16:42:26.0 +0200
+++ apps/x509.c 2010-01-10 01:20:45.0 +0100
@@ -99,7 +99,13 @@
-passin arg - private key password source\n,
-serial - print serial number value\n,
-subject_hash - print subject hash value\n,
+#ifndef OPENSSL_NO_MD5
+ -subject_hash_old - print old-style (MD5) subject hash value\n,
+#endif
-issuer_hash- print issuer hash value\n,
+#ifndef OPENSSL_NO_MD5
+ -issuer_hash_old- print old-style (MD5) issuer hash value\n,
+#endif
-hash - synonym for -subject_hash\n,
-subject- print subject DN\n,
-issuer - print issuer DN\n,
@@ -179,6 +185,9 @@
int text=0,serial=0,subject=0,issuer=0,startdate=0,enddate=0;
int next_serial=0;
int subject_hash=0,issuer_hash=0,ocspid=0;
+#ifndef OPENSSL_NO_MD5
+ int subject_hash_old=0,issuer_hash_old=0;
+#endif
int noout=0,sign_flag=0,CA_flag=0,CA_createserial=0,email=0;
int ocsp_uri=0;
int trustout=0,clrtrust=0,clrreject=0,aliasout=0,clrext=0;
@@ -397,8 +406,16 @@
else if (strcmp(*argv,-hash) == 0
|| strcmp(*argv,-subject_hash) == 0)
subject_hash= ++num;
+#ifndef OPENSSL_NO_MD5
+ else if (strcmp(*argv,-subject_hash_old) == 0)
+ subject_hash_old= ++num;
+#endif
else if (strcmp(*argv,-issuer_hash) == 0)
issuer_hash= ++num;
+#ifndef OPENSSL_NO_MD5
+ else if (strcmp(*argv,-issuer_hash_old) == 0)
+ issuer_hash_old= ++num;
+#endif
else if (strcmp(*argv,-subject) == 0)
subject= ++num;
else if (strcmp(*argv,-issuer) == 0)
@@ -759,10 +776,22 @@
{
BIO_printf(STDout,%08lx\n,X509_subject_name_hash(x));
}
+#ifndef OPENSSL_NO_MD5
+ else if (subject_hash_old == i)
+ {
+
BIO_printf(STDout,%08lx\n,X509_subject_name_hash_old(x));
+ }
+#endif
else if (issuer_hash == i)
{
BIO_printf(STDout,%08lx\n,X509_issuer_name_hash(x));
}
+#ifndef OPENSSL_NO_MD5
+ else if (issuer_hash_old == i)
+ {
+
BIO_printf(STDout,%08lx\n,X509_issuer_name_hash_old(x));
+ }
+#endif
else if (pprint == i)
{
X509_PURPOSE *ptmp;
--- crypto/x509/x509_cmp.c.orig 2009-05-30 20:10:59.0 +0200
+++ crypto/x509/x509_cmp.c 2010-01-10 01:21:45.0 +0100
@@ -133,6 +133,13 @@
return(X509_NAME_hash(x-cert_info-issuer));
}
+#ifndef OPENSSL_NO_MD5
+unsigned long X509_issuer_name_hash_old(X509 *x)
+ {
+ return(X509_NAME_hash_old(x-cert_info-issuer));
+ }
+#endif
+
X509_NAME *X509_get_subject_name(X509 *a)
{
return(a-cert_info-subject);
@@ -148,6 +155,13 @@
return(X509_NAME_hash(x-cert_info-subject));
}
+#ifndef OPENSSL_NO_MD5
+unsigned long X509_subject_name_hash_old(X509 *x)
+ {
+ return(X509_NAME_hash_old(x-cert_info-subject));
+ }
+#endif
+
#ifndef OPENSSL_NO_SHA
/* Compare two certificates: they must be identical for
* this to work. NB: Although cmp operations are
Re: Get root certificates from System Store of Windows
(2010/01/10 23:23), Shahin Khorasani wrote:
try this
(snip)
Thanks, it works.
So I request X509_STORE_set_default_paths call this.
When this is merge, both Unix user and Windows user can use
the system's default root certificates.
I should file this to Request Tracker as a bug? (even if this is feature
request)
Backgrounds:
We maintain a wrapper library of OpenSSL, openssl lib for Ruby.
And we also maintain https library, which depends on openssl.
So when the https library want to verify certificates of web server,
On Unix, we can use X509_STORE_set_default_paths, then users can verify.
But on Windows cannot now.
This patch allow Windows users to verify certificates easily.
Thanks,
this needs to link Crypt32.dll
Index: crypto/x509/x509_d2.c
===
RCS file: /v/openssl/cvs/openssl/crypto/x509/x509_d2.c,v
retrieving revision 1.7
diff -u -p -r1.7 x509_d2.c
--- crypto/x509/x509_d2.c 19 Feb 2001 16:02:21 - 1.7
+++ crypto/x509/x509_d2.c 11 Jan 2010 11:25:57 -
@@ -62,6 +62,34 @@
#include openssl/x509.h
#ifndef OPENSSL_NO_STDIO
+
+#if defined(_WIN32_WINNT) _WIN32_WINNT = 0x0500
+#include Wincrypt.h
+void X509_STORE_load_windows_systemstore(X509_STORE *ctx)
+ {
+ HCERTSTORE hStore;
+ PCCERT_CONTEXT pContext = NULL;
+ X509 *x509;
+
+ hStore = CertOpenSystemStore(0, ROOT);
+ if(!hStore) return;
+
+ while (pContext = CertEnumCertificatesInStore(hStore, pContext))
+ {
+ x509 = NULL;
+ x509 = d2i_X509(NULL, pContext-pbCertEncoded,
pContext-cbCertEncoded);
+ if (x509)
+ {
+ X509_STORE_add_cert(store, x509);
+ X509_free(x509);
+ }
+ }
+
+ CertFreeCertificateContext(pContext);
+ CertCloseStore(hStore, 0);
+}
+#endif
+
int X509_STORE_set_default_paths(X509_STORE *ctx)
{
X509_LOOKUP *lookup;
@@ -77,6 +105,10 @@ int X509_STORE_set_default_paths(X509_ST
/* clear any errors */
ERR_clear_error();
+#if defined(_WIN32_WINNT) _WIN32_WINNT = 0x0500
+ X509_STORE_load_windows_systemstore(X509_STORE *ctx)
+#endif
+
return(1);
}
--
NARUSE, Yui nar...@airemix.jp
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[PATCH] Change needed for -DPURIFY builds.
Any further thoughts on this patch? I'd love to get these -DPURIFY builds working properly. --Kevin crypto/rand/randfile.c : @@ -102,6 +102,14 @@ if (file == NULL) return(0); +#ifdef PURIFY +/* struct stat has padding and unused fields that may not be + * initialized in the call to stat(). We need to clear the entire + * structure before calling RAND_add() to avoid complaints from + * applications such as Valgrind. + */ +memset(sb, 0, sizeof(sb)); +#endif if (stat(file,sb) 0) return(0); RAND_add(sb,sizeof(sb),0.0); if (bytes == 0) return(ret); From: Kevin Regan Sent: Friday, January 08, 2010 11:01 AM To: Kevin Regan; 'openssl-dev@openssl.org' Subject: RE: RE: Change needed for -DPURIFY builds. I also wanted to mention that the -DPURIFY flag should not weaken the PRNG (you should be able to run a production system with -DPURIFY). It should only be used to remove uninitialized data that may (or may not) add some entropy to the PRNG. I believe that my patch handles this correctly. --Kevin From: Kevin Regan Sent: Friday, January 08, 2010 10:53 AM To: 'openssl-dev@openssl.org' Subject: RE: Change needed for -DPURIFY builds. You're missing the point -- your comment is the height of irony, in a way. Use a suppression to make Valgrind shut up. /r$ I think you misunderstand his issue. His issue is not valgrind reports a spurious error/warning. His issue is -DPURIFY does not do what I think it's supposed to do. Perhaps my recollection is incorrect, but my recollection was that -DPURIFY was supposed to make OpenSSL not process uninitialized data with code precisely like that suggested here, accepting that there might be some reduction in the amount of entropy that OpenSSL gets in exchange for having only one switch to flip. The -DPURIFY flag is used precisely this way in other projects, shutting off all manner of 'optimizations' that interfere with tools like Purify, Valgrind, and others. DS This is correct. Here is the relevant entry in the OpenSSL FAQ (#14): http://www.openssl.org/support/faq.html#PROG14 The -PURIFY flag is meant to remove additions to the PRNG that would cause trouble for applications such as Purify and Valgrind. The issue that I pointed out is a location where the -DPURIFY flag was missed. It shouldn't be controversial. This is exactly what the flag is meant for. My change simply make the FAQ statement correct by fixing a bug. As for suppressions, it isn't possible in this case. The unintialized data taints all users of the openssl random number generator (directly or indirectly). This causes problems throughout the code. You would need dozens or hundreds of suppressions, none of which actually mention the RAND_add function (so, I guess it is possible, but prohibitively expensive). As a reference, here are the other two PURIFY entries in the code: crypto/rand/randfile.c: #ifdef PURIFY RAND_add(buf,i,(double)i); #else /* even if n != i, use the full array */ RAND_add(buf,n,(double)i); #endif crypto/rand/md_rand.c: MD_Update(m,local_md,MD_DIGEST_LENGTH); MD_Update(m,(unsigned char *)(md_c[0]),sizeof(md_c)); #ifndef PURIFY MD_Update(m,buf,j); /* purify complains */ #endif --Kevin p.s. Here, again, is the patch I am suggestion: crypto/rand/randfile.c : @@ -102,6 +102,14 @@ if (file == NULL) return(0); +#ifdef PURIFY +/* struct stat has padding and unused fields that may not be + * initialized in the call to stat(). We need to clear the entire + * structure before calling RAND_add() to avoid complaints from + * applications such as Valgrind. + */ +memset(sb, 0, sizeof(sb)); +#endif if (stat(file,sb) 0) return(0); RAND_add(sb,sizeof(sb),0.0); if (bytes == 0) return(ret);
Re: [PATCH] Change needed for -DPURIFY builds.
On Mon, Jan 11, 2010, Kevin Regan wrote: Any further thoughts on this patch? I'd love to get these -DPURIFY builds working properly. Please send the patch to the request tracker. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Get root certificates from System Store of Windows
On Mon, Jan 11, 2010, NARUSE, Yui wrote: (2010/01/10 23:23), Shahin Khorasani wrote: try this (snip) Thanks, it works. So I request X509_STORE_set_default_paths call this. When this is merge, both Unix user and Windows user can use the system's default root certificates. I should file this to Request Tracker as a bug? (even if this is feature request) Some CryptoAPI handling code already exists in the CryptoAPI ENGINE and I'd suggest that a ctrl for that would be the best place to put it. There are some debug options already that can dump a whole store to standard output. However some additional code would be needed because that just adds the whole store without any purpose setting code. This could cause security issues if for example client certificate authorities are used for server signing for example. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [PATCH] Change needed for -DPURIFY builds.
Hi Dr. Henson, I noticed instructions in the README to send the patch to the openssl-dev mailing list. Where can I find this request tracker? Thanks, Kevin -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Monday, January 11, 2010 4:35 PM To: openssl-dev@openssl.org Subject: Re: [PATCH] Change needed for -DPURIFY builds. On Mon, Jan 11, 2010, Kevin Regan wrote: Any further thoughts on this patch? I'd love to get these -DPURIFY builds working properly. Please send the patch to the request tracker. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Change needed for -DPURIFY builds.
On Mon, Jan 11, 2010, Kevin Regan wrote: Hi Dr. Henson, I noticed instructions in the README to send the patch to the openssl-dev mailing list. Where can I find this request tracker? Sending it to rt-b...@openssl.org will result in it appearing in the request tracker. More details at: http://www.openssl.org/support/rt.html Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
