[openssl.org #478] make uninstall
hi, I'm using 0.9.7 under Linux 2.4 series. you should add a uninstall rule within Makefile, usefull when have to use different versions of Ossl. make install: to install make uninsal: to remove thx vg __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds
I've checked over the snapshot that was current on or about 14-Jan-2003. It builds OK. In the original 0.9.7.tar.gz there were symbolic links already present in include/openssl, and they are not removed by make clean. In the snapshot the links are not present. Script started on Mon Jan 27 10:15:14 2003 kea gzcat openssl-0.9.7-stable-SNAP-20030114.tar.gz | tar tf - | grep include openssl-0.9.7-stable-SNAP-20030114/VMS/test-includes.com openssl-0.9.7-stable-SNAP-20030114/include/ kea gzcat openssl-0.9.7.tar.gz | tar tf - | grep include openssl-0.9.7/include/ openssl-0.9.7/include/openssl/ openssl-0.9.7/include/openssl/aes.h symbolic link to ../../crypto/aes/aes.h openssl-0.9.7/include/openssl/asn1.h symbolic link to ../../crypto/asn1/asn1.h openssl-0.9.7/include/openssl/asn1_mac.h symbolic link to ../../crypto/asn1/asn1_mac.h openssl-0.9.7/include/openssl/asn1t.h symbolic link to ../../crypto/asn1/asn1t.h openssl-0.9.7/include/openssl/bio.h symbolic link to ../../crypto/bio/bio.h openssl-0.9.7/include/openssl/blowfish.h symbolic link to ../../crypto/bf/blowfish.h openssl-0.9.7/include/openssl/bn.h symbolic link to ../../crypto/bn/bn.h openssl-0.9.7/include/openssl/buffer.h symbolic link to ../../crypto/buffer/buffer.h openssl-0.9.7/include/openssl/cast.h symbolic link to ../../crypto/cast/cast.h openssl-0.9.7/include/openssl/comp.h symbolic link to ../../crypto/comp/comp.h openssl-0.9.7/include/openssl/conf_api.h symbolic link to ../../crypto/conf/conf_api.h openssl-0.9.7/include/openssl/conf.h symbolic link to ../../crypto/conf/conf.h openssl-0.9.7/include/openssl/crypto.h symbolic link to ../../crypto/crypto.h openssl-0.9.7/include/openssl/des.h symbolic link to ../../crypto/des/des.h openssl-0.9.7/include/openssl/des_old.h symbolic link to ../../crypto/des/des_old.h openssl-0.9.7/include/openssl/dh.h symbolic link to ../../crypto/dh/dh.h openssl-0.9.7/include/openssl/dsa.h symbolic link to ../../crypto/dsa/dsa.h openssl-0.9.7/include/openssl/dso.h symbolic link to ../../crypto/dso/dso.h openssl-0.9.7/include/openssl/ebcdic.h symbolic link to ../../crypto/ebcdic.h openssl-0.9.7/include/openssl/ec.h symbolic link to ../../crypto/ec/ec.h openssl-0.9.7/include/openssl/engine.h symbolic link to ../../crypto/engine/engine.h openssl-0.9.7/include/openssl/e_os2.h symbolic link to ../../e_os2.h openssl-0.9.7/include/openssl/err.h symbolic link to ../../crypto/err/err.h openssl-0.9.7/include/openssl/evp.h symbolic link to ../../crypto/evp/evp.h openssl-0.9.7/include/openssl/hmac.h symbolic link to ../../crypto/hmac/hmac.h openssl-0.9.7/include/openssl/idea.h symbolic link to ../../crypto/idea/idea.h openssl-0.9.7/include/openssl/krb5_asn.h symbolic link to ../../crypto/krb5/krb5_asn.h openssl-0.9.7/include/openssl/kssl.h symbolic link to ../../ssl/kssl.h openssl-0.9.7/include/openssl/lhash.h symbolic link to ../../crypto/lhash/lhash.h openssl-0.9.7/include/openssl/md2.h symbolic link to ../../crypto/md2/md2.h openssl-0.9.7/include/openssl/md4.h symbolic link to ../../crypto/md4/md4.h openssl-0.9.7/include/openssl/md5.h symbolic link to ../../crypto/md5/md5.h openssl-0.9.7/include/openssl/mdc2.h symbolic link to ../../crypto/mdc2/mdc2.h openssl-0.9.7/include/openssl/objects.h symbolic link to ../../crypto/objects/objects.h openssl-0.9.7/include/openssl/obj_mac.h symbolic link to ../../crypto/objects/obj_mac.h openssl-0.9.7/include/openssl/ocsp.h symbolic link to ../../crypto/ocsp/ocsp.h openssl-0.9.7/include/openssl/opensslconf.h symbolic link to ../../crypto/opensslconf.h openssl-0.9.7/include/openssl/opensslv.h symbolic link to ../../crypto/opensslv.h openssl-0.9.7/include/openssl/ossl_typ.h symbolic link to ../../crypto/ossl_typ.h openssl-0.9.7/include/openssl/pem2.h symbolic link to ../../crypto/pem/pem2.h openssl-0.9.7/include/openssl/pem.h symbolic link to ../../crypto/pem/pem.h openssl-0.9.7/include/openssl/pkcs12.h symbolic link to ../../crypto/pkcs12/pkcs12.h openssl-0.9.7/include/openssl/pkcs7.h symbolic link to ../../crypto/pkcs7/pkcs7.h openssl-0.9.7/include/openssl/rand.h symbolic link to ../../crypto/rand/rand.h openssl-0.9.7/include/openssl/rc2.h symbolic link to ../../crypto/rc2/rc2.h openssl-0.9.7/include/openssl/rc4.h symbolic link to ../../crypto/rc4/rc4.h openssl-0.9.7/include/openssl/rc5.h symbolic link to ../../crypto/rc5/rc5.h openssl-0.9.7/include/openssl/ripemd.h symbolic link to ../../crypto/ripemd/ripemd.h openssl-0.9.7/include/openssl/rsa.h symbolic link to ../../crypto/rsa/rsa.h openssl-0.9.7/include/openssl/safestack.h symbolic link to ../../crypto/stack/safestack.h openssl-0.9.7/include/openssl/sha.h symbolic link to ../../crypto/sha/sha.h openssl-0.9.7/include/openssl/ssl23.h symbolic link to ../../ssl/ssl23.h openssl-0.9.7/include/openssl/ssl2.h symbolic link to ../../ssl/ssl2.h openssl-0.9.7/include/openssl/ssl3.h symbolic link to ../../ssl/ssl3.h openssl-0.9.7/include/openssl/ssl.h symbolic link to ../../ssl/ssl.h openssl-0.9.7/include/openssl/stack.h symbolic link to
Re: certification path validation suite
Dr. Stephen Henson writes: 3. If there is no reference test suite available, should it be assumed that there exists no tested, and, therefore with high probability no correct, implementation of the certification path validation algorithm which handles the policy mappings and name constraints ? There was some debate about how some options in name constraints should be interpreted in the PKIX mailing lists not long ago. This suggests that correct may be subject to interpretation :-) I've never seen a certificate with either name or policy constraints in the field or indeed privately. Examples would be useful to check out any future OpenSSL support for them. About DPD/DPV: the outcome of this strawpoll http://www.imc.org/ietf-pkix/mail-archive/msg05500.html certainly has implications for this problem. (The immediate implication has been a lot of strawpoll vote message on the pkix mailing list :^) I'm not sure about name constraints options, but there is a recent thread -- December time frame -- about the meaning of the policy extensions. There seem to be a variety of problems here, ranging from how many policy oids can a cert have, to what this extension means in a CA signing cert (does it describe what policy this CA signs? or under what policy this cert itself was signed? Can it mean both c). http://www.imc.org/ietf-pkix/mail-archive/msg05207.html Name constraints, because it was set to critical in the PKIX profile, is probably dead. There is very little support for it in the SSL-using universe: openssl doesn't support it at all, except to reject certs that use it; IE may be doing something useful with it in recent versions; no Netscape-ish related browser that I know of does anything useful with it but at least some Mozilla based ones will reject these certs (probably depends on maturity of NSS). This profile has been around since Jan 1999 and this feature is still not widely available. It's quite easy to create certs with name constraints of various types. iPlanet/Netscape CMS support creating them. I believe Microsoft Certificate Services have templates that support this now. The problem is, they are useless to most of us. I have tried to get some examples of this from the US Fed. bridge PKI members, but this has not proved successful. (Presuming, of course, that they do in fact employ them.) There are many certs in production use with policy extensions; the VeriSign end entity certs should provide many examples. I have been intermittently collecting examples of certificates in order to learn industry best practices (and illuminate areas of PKIX or related profiles that are unclear to me). This was for the benefit of computing Grids, look here: http://caops.es.net/ or here for the data: http://caops.es.net/Documents/GGFV/Certificate_Profile.pdf I think enough data has been collected, and intend to push for some discussion on extensions we need/need to avoid relegate the data to an appendix. If someone wants to contribute to this in some way (discussion, more certificate data c) please feel free to get in touch with me or get involved in gridforum. Thanks, ==mwh Michael Helm ESnet/LBNL __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds
In the original 0.9.7 release there also seems to be some configuration remnants left in the crypto/objects directory -- obj_dat.h; this isn't removed by a make clean. \nick __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #479] support version independent upgrade
Currently, on many Unix platforms I link my application against libssl.so and libcrypto.so. Typically, these are links set to resolve down to the versioned types of these files, like libssl.so.0.9.7 and libcrypto.so.0.9.7. The internal names of these shared objects include the major and minor version so even though I link against the shared objects without the version, such as libssl.so, my application becomes tied to the versioned shared objects at link time, for instance libssl.so.0.9.7. So, when OpenSSL eventually comes out with security upgrades in a new version, like 0.9.8, I will be forced to relink my application against the new openssl version and redistribute it. Ideally, since I linked against the non versioned openssl shared objects, my users should be able to get the new openssl and rebuild its shared objects and run against those without any involvement from me. Since symbollic links are provided on all Unix platforms please remove the major and minor versions from the internal names of libssl.so and libcrypto.so on these platforms to allow users to upgrade version independent shared objects. I have found this condition on solaris (3264 bit), hpux (32 64 bit), sco5, and unixware7. This will involve changes to Makefile.org. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certification path validation suite
On Mon, Jan 27, 2003, Michael Helm wrote: There are many certs in production use with policy extensions; the VeriSign end entity certs should provide many examples. Yes I know about those. Is there any documentation however on what the VeriSign policy extensions actually *mean*. The last time I looked it had a couple of OIDs in there and some noticeNumbers but I couldn't find any descriptions *anywhere* on what the OIDs or numbers meant. 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]
Re: [openssl.org #479] support version independent upgrade
In message [EMAIL PROTECTED] on Mon, 27 Jan 2003 22:40:24 +0100 (MET), via RT [EMAIL PROTECTED] said: rt Currently, on many Unix platforms I link my application against rt libssl.so and libcrypto.so. Typically, these are links set to resolve rt down to the versioned types of these files, like libssl.so.0.9.7 and rt libcrypto.so.0.9.7. The internal names of these shared objects rt include the major and minor version so even though I link against the rt shared objects without the version, such as libssl.so, my application rt becomes tied to the versioned shared objects at link time, for rt instance libssl.so.0.9.7. There's a reason: until OpenSSL 1, we don't guarantee backward binary compatibility. There are technical reasons for this, like the need to make changes to published structures (it may be argued that it shouldn't be needed, but to achieve such flexibility, we either need to hide them (which would require huge changes for everyone) or redo them in such a way that they become rather generic) and other stuff. Because of this, we're forced to do what we currently do with shared libraries. Perhaps you'd prefer that your applications crash mysteriously and in an unrecoverable manner? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #479] support version independent upgrade
In message [EMAIL PROTECTED] on Mon, 27 Jan 2003 22:40:24 +0100 (MET), via RT [EMAIL PROTECTED] said: rt Currently, on many Unix platforms I link my application against rt libssl.so and libcrypto.so. Typically, these are links set to resolve rt down to the versioned types of these files, like libssl.so.0.9.7 and rt libcrypto.so.0.9.7. The internal names of these shared objects rt include the major and minor version so even though I link against the rt shared objects without the version, such as libssl.so, my application rt becomes tied to the versioned shared objects at link time, for rt instance libssl.so.0.9.7. There's a reason: until OpenSSL 1, we don't guarantee backward binary compatibility. There are technical reasons for this, like the need to make changes to published structures (it may be argued that it shouldn't be needed, but to achieve such flexibility, we either need to hide them (which would require huge changes for everyone) or redo them in such a way that they become rather generic) and other stuff. Because of this, we're forced to do what we currently do with shared libraries. Perhaps you'd prefer that your applications crash mysteriously and in an unrecoverable manner? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
