Re: How to submit a patch?
On Tue, Aug 20, 2002 at 05:06:30PM -0400, joe hartford wrote: I have a patch for OpenSSL that I'd like to submit. Should I just post it on this list, or is there a better way to do it? Please send it to [EMAIL PROTECTED] or [EMAIL PROTECTED] (both addresses end up in the same request tracker). You submission will be archived and receive a ticket number to be tracked. See also: http://www.openssl.org/support/rt2.html Also, my patch is based off of the OpenSSL cvs repository, not a specific release. Is this acceptable? Yes. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #235] Bug in cryptlib.c
Is this the correct list to post bug reports to?
There is a bug in cryptlib.c when using app locks. It is in both 0.9.6c and 0.9.7
beta 3. In
0.9.7 beta3 CRYPTO_NUM_LOCKS is 31. When requesting an app lock this code gets called:
int CRYPTO_get_new_lockid(char *name)
{
char *str;
int i;
...
i=sk_push(app_locks,str);
if (!i)
OPENSSL_free(str);
else
i+=CRYPTO_NUM_LOCKS; /* gap of one :-) */
return(i);
}
which returns 32 for the new app lock. Note that, as the comment says, there is a gap
of one;
there is no lock numbered 31. Now when you try to access the name of that new lock,
32, this code
is called:
const char *CRYPTO_get_lock_name(int type)
{
if (type 0)
return(dynamic);
else if (type CRYPTO_NUM_LOCKS)
return(lock_names[type]);
else if (type-CRYPTO_NUM_LOCKS = sk_num(app_locks))
return(ERROR);
else
return(sk_value(app_locks,type-CRYPTO_NUM_LOCKS));
}
However since type-CRYPTO_NUM_LOCKS is 1 and that is = the number of app locks, 1,
you get
ERROR instead of the lock's name.
This can be fixed by not having the gap, or by compensating for the gap. I don't know
what the
original intention was in having the gap so I'm not sure what the best way to fix it
is.
Tim
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL using a TRNG
Michael, thanks for you suggestion. - Original Message - From: Michael Sierchio [EMAIL PROTECTED] Sent: Tuesday, August 20, 2002 21:16 Leif Kremkow wrote: I'm looking for some guidance. I'd like to change the OpenSSL library to be able to use a TRNG for all random numbers, not just to seed the PRNG. There are no such devices which produce adequate quantities of random material for a server with reasonable load. Most have a variable max bitrate which seldom exceeds 12k-16k bits/s. I have reason to believe, that for my intended use, it will do fine. Could you, or somebody else who is familiar with that part of the source, tell me where I should add a new RAND_METHOD section (md_rand.c?) or should I just add a new file. If more people agree with you, once I have a working piece of code (which may under perform), then obviously nobody will be interested in a patch. Until then, I would appreciate your help in finding my way around the source. Kind regards,, Leif Kremkow __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL using a TRNG
Michael Sierchio wrote: Leif Kremkow wrote: I'm looking for some guidance. I'd like to change the OpenSSL library to be able to use a TRNG for all random numbers, not just to seed the PRNG. There are no such devices which produce adequate quantities of random material for a server with reasonable load. Most have a variable max bitrate which seldom exceeds 12k-16k bits/s. Wow - and what application needs more than this bitrate? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #236] a bug in OBJ_txt2obj function?
Dear OpenSSL Team,
Our company is the market leader on X509 certificate issuance in
Hungary. For some functions we use OpenSSL products and we have found a
problem in the recently issued OpenSSL versions that we would like to
share.
Source file: obj_dat.c
Function name: OBJ_txt2obj
Version: 0.6.9g
...
/* Work out size of content octets */
i=a2d_ASN1_OBJECT(NULL,0,s,-1);
if (i = 0) {
/* Clear the error */
ERR_get_error();
return NULL;
}
/* Work out total size */
j = ASN1_object_size(0,i,V_ASN1_OBJECT);
if((buf=(unsigned char *)OPENSSL_malloc(j)) == NULL) return NULL;
p = buf;
/* Write out tag+length */
ASN1_put_object(p,0,i,V_ASN1_OBJECT,V_ASN1_UNIVERSAL);
/* Write out contents */
a2d_ASN1_OBJECT(p,i,s,-1);
p=buf;
op=d2i_ASN1_OBJECT(NULL,p,i); -- this should be
op=d2i_ASN1_OBJECT(NULL,p,j);
...
In the code snippet above the i variable contains the length of the
object content while the j variable contains the whole asn1 structure
length. So I assume in the d2i_ASN1_OBJECT fuction call the j
variable should be given instead of the i one as in the other d2i...
kinda functions. This length parameter is used for buffer size checking
later in the ASN1_get_object function:
Source file: asn1_lib.c
Function name: ASN1_get_object
Version: 0.6.9g
...
if (*plength (omax - (p - *pp)))
{
ASN1err(ASN1_F_ASN1_GET_OBJECT,ASN1_R_TOO_LONG);
/* Set this so that even if things are not long enough
* the values are set correctly */
ret|=0x80;
}
...
Here the omax variable contains the value given to the
d2i_ASN1_OBJECT last parameter while plength is the length read from
the der coding. The p - *pp is the header length so if the omax
contains the object content length instead of the total (header +
content) length the comparison fails and NULL is returned instead of
the ASN1 OBJECT requested. Examining earlier OpenSSL versions we
discovered that this few lines of the comparison code is commented out
so this was not a problem until OpenSSL 0.6.9d.
Please confirm that our assumptions are right and give me information on
how the problem can be resolved.
Thank you for your help.
Best regards,
László Cséplõ,
Henrik Schalamonek
NetLock Ltd.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #238] Solaris 2 shared libraries are built incorrectly with gcc
When configuring OpenSSL 0.9.6g for solaris-sparcv8-gcc/solaris-x86-gcc shared, the way the shared libcrypto.so and libssl.so are built is wrong: * gcc is invoked with gcc -G, but unfortunately this doesn't suffice to trigger shared library generation. Instead, gcc creates a cross of a dynamic executable and a shared object, as can be seen with gcc -v: crt1.o is linked in, which leads to an unresolved reference to main: ldd -d libcrypto.so reports symbol not found: main (./libcrypto.so.0) The correct way to build shared libraries with gcc on (almost?) any platform is to use gcc -shared instead. Unfortunately, this adds another problem with gcc 3.x releases: gcc -shared adds a dynamic dependency on the shared libgcc_s.so, so in order for libcrypto.so and libssl.so to be self-contained, one needs to add a runpath pointing to the directory where libgcc_s.so is installed, e.g. with -R/vol/gnu/lib (i.e. gcc's libdir) on Solaris 2 or -rpath /vol/gnu/lib on IRIX 6 and Tru64 UNIX. Here's the solaris8-x86-gcc test report for reference: OpenSSL self-test report: OpenSSL version: 0.9.6g Last change: [In 0.9.6g-engine release:]... Options: --prefix=/vol/openssl --openssldir=/vol/openssl/share shared OS (uname): SunOS arenal 5.8 Generic_111920-01 i86pc i386 OS (config): i86pc-whatever-solaris2 Target (default): solaris-x86-cc Target: solaris-x86-gcc Compiler: Configured with: /vol/gnu/src/gcc/gcc-3.1-branch-dist/configur e --prefix=/vol/gnu --with-local-prefix=/vol/gnu --disable-nls Thread model: posix gcc version 3.1 Test passed. Rainer __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #237] [PATCH] Support for Subject Directory Attributes
The following patch provides basic support for Subject Directory
Attributes, which are defined in the x509 spec (RFC 2459), but are
currently unsupported by OpenSSL. In this patch, Subject Directory
Attributes are parsed like Authority Information Access.
An OID for Corestreet Credential Validation has also been added to
provide support for Dr. Silvio Micali's certificate validation mechanism.
The follow diff is relative to the 8/15/02 snapshot.
Index: crypto/objects/obj_dat.h
===
RCS file:
/home/jhartford/projects/openssl/cvs/openssl/crypto/objects/obj_dat.h,v
retrieving revision 1.62
diff -c -b -r1.62 obj_dat.h
*** crypto/objects/obj_dat.h2002/08/02 12:28:33 1.62
--- crypto/objects/obj_dat.h2002/08/19 19:44:30
***
*** 62,73
* [including the GNU Public Licence.]
*/
! #define NUM_NID 716
! #define NUM_SN 711
! #define NUM_LN 711
! #define NUM_OBJ 685
! static unsigned char lvalues[4849]={
0x00,/* [ 0] OBJ_undef */
0x2A,0x86,0x48,0x86,0xF7,0x0D, /* [ 1] OBJ_rsadsi */
0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01, /* [ 7] OBJ_pkcs */
--- 62,73
* [including the GNU Public Licence.]
*/
! #define NUM_NID 718
! #define NUM_SN 713
! #define NUM_LN 713
! #define NUM_OBJ 687
! static unsigned char lvalues[4860]={
0x00,/* [ 0] OBJ_undef */
0x2A,0x86,0x48,0x86,0xF7,0x0D, /* [ 1] OBJ_rsadsi */
0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01, /* [ 7] OBJ_pkcs */
***
*** 753,758
--- 753,760
0x67,0x2B,0x0D,0x04,0x0A,/* [4833]
OBJ_wap_wsg_idm_ecid_wtls10 */
0x67,0x2B,0x0D,0x04,0x0B,/* [4838]
OBJ_wap_wsg_idm_ecid_wtls11 */
0x67,0x2B,0x0D,0x04,0x0C,/* [4843]
OBJ_wap_wsg_idm_ecid_wtls12 */
+ 0x55,0x1D,0x09, /* [4848]
OBJ_subject_directory_attribute */
+ 0x2B,0x06,0x01,0x04,0x01,0xE0,0x35,0x01, /* [4851] OBJ_corestreet */
};
static ASN1_OBJECT nid_objs[NUM_NID]={
***
*** 1873,1878
--- 1875,1884
NID_wap_wsg_idm_ecid_wtls11,5,(lvalues[4838]),0},
{wap-wsg-idm-ecid-wtls12,wap-wsg-idm-ecid-wtls12,
NID_wap_wsg_idm_ecid_wtls12,5,(lvalues[4843]),0},
+ {subjectDirectoryAttribute,Subject Directory Attribute,
+ NID_subject_directory_attribute,3,(lvalues[4848]),0},
+ {corestreet,Corestreet Credential Validation,NID_corestreet,8,
+ (lvalues[4851]),0},
};
static ASN1_OBJECT *sn_objs[NUM_SN]={
***
*** 2054,2059
--- 2060,2066
(nid_objs[130]),/* clientAuth */
(nid_objs[131]),/* codeSigning */
(nid_objs[50]),/* contentType */
+ (nid_objs[717]),/* corestreet */
(nid_objs[53]),/* countersignature */
(nid_objs[153]),/* crlBag */
(nid_objs[103]),/* crlDistributionPoints */
***
*** 2555,2560
--- 2562,2568
(nid_objs[496]),/* singleLevelQuality */
(nid_objs[387]),/* snmpv2 */
(nid_objs[85]),/* subjectAltName */
+ (nid_objs[716]),/* subjectDirectoryAttribute */
(nid_objs[398]),/* subjectInfoAccess */
(nid_objs[82]),/* subjectKeyIdentifier */
(nid_objs[498]),/* subtreeMaximumQuality */
***
*** 2598,2603
--- 2606,2612
(nid_objs[285]),/* Biometric Info */
(nid_objs[179]),/* CA Issuers */
(nid_objs[131]),/* Code Signing */
+ (nid_objs[717]),/* Corestreet Credential Validation */
(nid_objs[382]),/* Directory */
(nid_objs[392]),/* Domain */
(nid_objs[132]),/* E-mail Protection */
***
*** 2662,2667
--- 2671,2677
(nid_objs[386]),/* Security */
(nid_objs[394]),/* Selected Attribute Types */
(nid_objs[143]),/* Strong Extranet ID */
+ (nid_objs[716]),/* Subject Directory Attribute */
(nid_objs[398]),/* Subject Information Access */
(nid_objs[130]),/* TLS Web Client Authentication */
(nid_objs[129]),/* TLS Web Server Authentication */
***
*** 3309,3316
(nid_objs[434]),/* OBJ_data 0 9 */
(nid_objs[181]),/* OBJ_iso 1 */
(nid_objs[182]),/* OBJ_member_body 1 2 */
- (nid_objs[379]),/* OBJ_org 1 3 */
(nid_objs[527]),/* OBJ_identified_organization 1 3 */
(nid_objs[393]),/* OBJ_joint_iso_ccitt 2 */
(nid_objs[11]),/* OBJ_X500 2 5 */
(nid_objs[380]),/* OBJ_dod 1 3 6 */
--- 3319,3326
(nid_objs[434]),/* OBJ_data 0 9 */
(nid_objs[181]),/* OBJ_iso 1 */
(nid_objs[182]),/* OBJ_member_body 1 2 */
(nid_objs[527]),/* OBJ_identified_organization 1 3 */
+ (nid_objs[379]),/* OBJ_org 1 3 */
(nid_objs[393]),/* OBJ_joint_iso_ccitt 2 */
(nid_objs[11]),/* OBJ_X500 2 5 */
(nid_objs[380]),/*
[openssl.org #239] Solaris 2/Intel shared libssl/libcrypto contain text relocations
Trying to build OpenSSL 0.9.6g on Solaris 8/Intel with a fixed solaris-x86-gcc shared configuration and a proper invokation of gcc (using -shared instead of gcc -G as explained in a previous report) fails since the assembler sources used contain text relocations. The link step fails with errors like this: + gcc -shared -G -o libcrypto.so.0.9.6 -h libcrypto.so.0 -z allextract libcrypto.a -L. +-z defs -lsocket -lnsl -ldl -lc Text relocation remains referenced against symbol offset in file unknown 0x22d2 libcrypto.a(dx86-sol.o) and many more. This lets building libcrypto.so fail. Unfortunately, it is not even possible to turn off the -z text implied with -shared with a subsequent -z textoff, since the linker complains: ld: fatal: option -ztextoff and -ztext are incompatible ld: fatal: Flags processing errors Anyway, shared libraries with remaining text relocations are not really useful since they are not sharable, greatly diminishing their utility. So perlasm and the various x86 assembler implementations should be fixed to produce proper PIC code if shared libraries are to be produced. The affected files during the Solaris 8/Intel compilation were crypto/bf/asm/bx86-sol.o crypto/cast/asm/cx86-sol.o crypto/des/asm/dx86-sol.o crypto/des/asm/yx86-sol.o crypto/md5/asm/mx86-sol.o crypto/rc4/asm/rx86-sol.o crypto/sha/asm/sx86-sol.o For the record, here's the test report: OpenSSL self-test report: OpenSSL version: 0.9.6g Last change: [In 0.9.6g-engine release:]... Options: --prefix=/vol/openssl --openssldir=/vol/openssl/share shared OS (uname): SunOS arenal 5.8 Generic_111920-01 i86pc i386 OS (config): i86pc-whatever-solaris2 Target (default): solaris-x86-cc Target: solaris-x86-gcc Compiler: Configured with: /vol/gnu/src/gcc/gcc-3.1-branch-dist/configur e --prefix=/vol/gnu --with-local-prefix=/vol/gnu --disable-nls Thread model: posix gcc version 3.1 Test passed. Rainer __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #236] a bug in OBJ_txt2obj function?
[[EMAIL PROTECTED] - Wed Aug 21 22:14:01 2002]: Dear OpenSSL Team, Our company is the market leader on X509 certificate issuance in Hungary. For some functions we use OpenSSL products and we have found a problem in the recently issued OpenSSL versions that we would like to share. op=d2i_ASN1_OBJECT(NULL,p,i); -- this should be op=d2i_ASN1_OBJECT(NULL,p,j); ... In the code snippet above the i variable contains the length of the object content while the j variable contains the whole asn1 structure length. So I assume in the d2i_ASN1_OBJECT fuction call the j variable should be given instead of the i one as in the other d2i... kinda functions. This length parameter is used for buffer size checking later in the ASN1_get_object function: Yes that's correct. This bug has always been present but the old ASN1_get_object could read past the end of the supplied buffer so it wasn't caught until now. A fix has already been checked into the 0.9.6-stable branch. It is also possible to work around this bug by using the OBJ_create and OBJ_nid2obj functions instead. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #237] [PATCH] Support for Subject Directory Attributes
[[EMAIL PROTECTED] - Wed Aug 21 22:21:34 2002]: The following patch provides basic support for Subject Directory Attributes, which are defined in the x509 spec (RFC 2459), but are currently unsupported by OpenSSL. In this patch, Subject Directory Attributes are parsed like Authority Information Access. An OID for Corestreet Credential Validation has also been added to provide support for Dr. Silvio Micali's certificate validation mechanism. The follow diff is relative to the 8/15/02 snapshot. Do you have an example of a certificate containing this extension, that is one not generated by OpenSSL? There are a number of areas of this patch which I'm not sure about, the ASN1 code doesn't seem to match the description in RFC2459 and the extension of GENERAL_NAME for example. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: PKCS#11 engines revisited]
On Tue, Aug 20, 2002, Matthias Loepfe wrote: Hi I just want to give you some background information why AdNovum has choosen the let's call it the 'interceptor-way' of implementing the PKCS#11 functionality. We are working in an environment where the main purpose of the hardware security modules (HSM) is not crypto acceleration but secure storage of private keys and trust ankers. And in may situations we have more than one (different) device active. For example one for user authentication (removable chipcard) and the other one for server/sevice authentication. The problem with the ENGINE aproach is, that if you load and register an engine for let's say RSA, the ALL RSA operations are directed to this engine. That's not what we expect. We ONLY want the RSA operations bound to the objects (keys, certs) stored on the HSM, be executed on it. Under the cover we also create an ENGINE but we do not register it, but simply use it for the key objects. That only happens if the appropriate ENGINE calls state that that ENGINE provides the default implementation. It doesn't have to. Our second goal was to implement a solution which was a plug replacement for a 'normal' OpenSSL. That means there is NO need to modify any application to use PKCS#11 instead of file based keys and certs. We 'mangled' all the necessary parameters into one string (like an URL). There are some problems with that approach if a fully featured PKCS#11 ENGINE is to be written at some point and with some planned OpenSSL extensions. Such an ENGINE might be able to supply the default implementation for some algorithms. A pretty good match for an ENGINE in PKCS#11 terms is a library and slot combination. Then an application might be able to use (say) slot #0 of library foo-pkcs11 for default RSA. This can be handled with the ctrl mechanism of OpenSSL 0.9.7, which isn't in previous versions. The config file stuff can also be used to allow existing applications to work with little or no modification. In this context a PKCS#11 ENGINE would be a kind of 'virtual' enging which would behave like the 0.9.7 dynamic ENGINE. An application (possibly via the config file mechanism) would load the PKCS#11 ENGINE, send it some ctrls which would say which file and slot to use and its new name. So what it might say is 'use slot #0 or library foo-pkcs11 and call it bar'. Any references to 'bar' after that would be routed to the slot and library combination. Under this scheme the key name would just map to CKA_NAME. Support for file based keys can be handled by some minor modifcation to OpenSSLs PEM handler. This might involve a special key with appropriate header ENGINE KEY perhaps? This special key format would have various bits of info in it. Minimally this might just be an ENGINE and key name and possibly some ctrls. We'd also have a utility to create the files (options to 'engine' perhaps?). When OpenSSL encountered such a key it would load the ENGINE referenced, optionally perform the ctrls on it then call ENGINE_load_private_key returning the EVP_PKEY structure to the application. This would all go on under the hood and the application should largely be able to handle this kind of key in the same way as an ordinary key. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
