[openssl.org #242] man page questions
Hi, there: I installed openssl-0.9.6g on my Soloris machine. I typed in 'man BIO_write' and I got 'No manual entry for BIO_write.' I had to type in 'man BIO_read' to see the man page for BIO_write. And it took me quite a while to figure out BIO_read's right entry for it. I ran into similar problems when I was looking for the man pages for other SSL functions. This is kind of annoying. Any idea on this? Thanks! Lance Zhang __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #240] Build openssl error
I am building openssl0.9.6a in Dynix/ptx4.5.3 server. ./Configure cc /bin/make cc -DMONOLITH -I../include -O -c nseq.c cc -DMONOLITH -I../include -O -c pkcs12.c cc -DMONOLITH -I../include -O -c pkcs8.c cc -DMONOLITH -I../include -O -c spkac.c cc -DMONOLITH -I../include -O -c smime.c cc -DMONOLITH -I../include -O -c rand.c cc -DMONOLITH -I../include -O -c openssl.c rm -f openssl cc -o openssl -DMONOLITH -I../include -O openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhp aram.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand .o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o -L.. -lssl -L.. -l crypto Undefined first referenced symbol in file __bsd_accepts_server.o __bsd_bind s_server.o __bsd_connect s_server.o __bsd_getpeername s_server.o __bsd_getsockname s_server.o __bsd_getsockopts_server.o __bsd_listens_server.o __bsd_recvfrom s_server.o __bsd_recvmsg s_server.o __bsd_sendtos_server.o __bsd_sendmsg s_server.o __bsd_setsockopts_server.o __bsd_sockets_server.o __bsd_socketpairs_server.o __bsd_bindresvport s_server.o __bsd_rcmd s_server.o __bsd_rresvport s_server.o __bsd_shutdown s_server.o gethostbyaddr s_socket.o gethostbyname s_socket.o getservbyname s_socket.o ld: openssl: fatal error: Symbol referencing errors. No output written to openssl *** Error code 1 Make: . Stop. *** Error code 1 Make: . Stop. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #241] MacOS compilation bugs in OpenSSL 0.9.6g
I'm building OpenSSL 0.9.6g on MacOS 9, using the CodeWarrior 8 compiler. I've found three minor compilation problems. In MacSocket.cp & MacSocket.h, the buffer parameter for MacSocket_send is declared "void *" when it should be "const void *". In randfile.c, the macro NO_SYS_TYPES_H is used before openssl/e_os.h is included. For mac builds, NO_SYS_TYPES_H is defined in e_os.h. Perhaps it should be defined instead in the prefix files, or maybe the order of the inclusions in randfile.c is wrong. And finally, idea_lcl.h has, according to the IDE, "inconsistent line endings." Apparently this confuses the compiler as well, because when the macro E_IDEA is expanded, the compiler erroneously leaves in the last three backslashes. Normalizing the line endings allows i_cbc.c to compile. --Lisa Lippincott __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Missing certs, Everyone copies IE cert bug.
On Mon, Aug 19, 2002 at 10:43:00AM +0200, Richard Levitte - VMS Whacker wrote: > [NOTE: whatever I write below is *my* opinion. Period] > > In message <[EMAIL PROTECTED]> on Sun, 18 Aug 2002 21:32:43 -0400, >Tom Zerucha <[EMAIL PROTECTED]> said: > > tz> I don't know what the historic reasons for doing things a particular > tz> way, but I would suggest the following (in order of importance): > tz> > tz> 1. Install the certs by default, > > I'm amazed by this statement. Are you seriously willing to give us > that kind of trust, rather than installing whatever root certs you > need yourself? I'm personally not at all sure I want to be given that > kind of trust; I'm a developper, not a trusted certificate store > care-taker (at least in the OpenSSL arena). The alternative seems to be to let everyone IGNORE CERTIFICATES ENTIRELY. The following SIX applications use OpenSSL and do so in such a way that there is NO security by default: Lynx, Links, Curl, w3m, OmniWeb (commercial MacOSX!), and Wget. Of these, one OpenSource program has a secure mode which requires someone else install the certs. I'll leave it to anyone here to guess which/how to create a truly secure connection. But let me ask an even more stupid question if you don't trust the certs contained in the OpenSSL distribution: Why do you not think there are dozens of bugs, backdoors, intentional hacks, etc? Why shouldn't there be? If no one is checking the code for the certs anyway, and everyone (except maybe Opera - on the Zaurus they got it wrong, but other platforms are right - and Mozilla/Netscape) is ignoring, how do you know the CODE even works even if the certificates are correct? If you can't trust the certs, which you can compare with the cache from Mozilla or another source USING THE COMPILED BINARY TOOLS, why should you trust the source code, much less the binaries? > Unfortunately, we've all been fooled into thinking that our software > distributors should be points of distribution for trusted root > certificates (meaning we implicitely trust Netscape Navigator/ > Communicator, IE and whatnot to be truthful, even though there's no > way in the world the distributors can guarantee that), and most of us > are too lazy to deal with all of that properly. Not quite. When there is a bug, as has just happened with IE, it generally gets publicized and/or noticed and patches are released. Right now, with the IE hole, the third-sigma browsers that normally wouldn't be worth exploiting will get caught up anytime IE is exploited. Get ready for the headline: "OPENSSL BASED BROWSERS LESS SECURE THAN MICROSOFT'S INTERNET EXPLORER". People will be too lazy to read further and Opensource and OpenSSL will get a black eye. > Ultimately, it is YOUR responsability, as a user, to assure the > security of your installation, be it by doing it yourself or by > hiring someone to do it for us. The ultimate responsibility is the user's, but right now I have found at least 7 browsers that are COMPLETELY INSECURE "out of the box". If they said so (by interrupting the user or refusing to work until some override was used), that their use of SSL was only for convienience and not secure, I might be persuaded. There are some cars that have old junk stuffed where the airbag should be. But the airbag light doesn't go on and it looks secure - until you have an accident. If I know there isn't really an airbag there I will drive more carefully until I get it replaced. If you buy a used car, how do YOU, the USER know the airbag is real and not merely some junk stuffing the void?. Someone says it is real. You have to go on the word of the mechanic or dealer. We don't say it was your responsibility because the airbag wasn't real - it is a case of fraud most places (and most people wouldn't buy a car or demand a huge discount if they knew they didn't have a real airbag). Pretend locks that can be opened with any screwdriver would be much cheaper than real ones that require a matching key. Maybe I would use such to discourage burglars, but I would be making an informed choice. Where on the OpenSSL web site does it say that in normal usage that it is completely insecure as used in MOST applications? OpenSSL is sort of a trademark. Those implementing OpenSSL are saying they are using it for the "SECURE socket layer", or for "secure" connections. How is the user supposed to know it is not secure? I can say if they can reach https://www.amazone.com that they should stop using the software immediately. But how do I get that message out? And if it connects, it it a "bug" or a "feature"? OpenSSL is probably considered a "bolt on". The problem is that now it also needs to be filled up and turned on to be secure. It could be made that the effort would be required to drop security. > tz> or if there are nontechnical reasons not to, add something > tz> prominent to the readmes and make process so that the certs > tz> directory will be populated by
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]
[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]
[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 #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 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 #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_
[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 #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]
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]
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]
[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: 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]
