dep/
Does anyone want to keep the dep/ directory and its contents? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [patch] 56bit cipher handling patch Version B.03
Lutz Jaenicke [EMAIL PROTECTED]: [...] This patch enhances the SSL/TLS cipher mechanism to correctly handle the TLS 56bit ciphers. Without this patch the 56bit ciphers can be enabled, but the sorting is wrong (visible in client mode, since the first cipher the client lists and that is available on the server will be used). It also enhances the the cipher-list commands by a sorting by strength-bits (as of version B.02) and it fixes a bug in the cipher-command parser (possible endless loop) (as of version B.03). Are the any comments one this patch? Should we apply it in existing form? (I haven't yet carefully read the complete patch myself, so these questions are directed to myself as well :-) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [patch] 56bit cipher handling patch Version B.03
Bodo Moeller wrote: Lutz Jaenicke [EMAIL PROTECTED]: [...] This patch enhances the SSL/TLS cipher mechanism to correctly handle the TLS 56bit ciphers. Without this patch the 56bit ciphers can be enabled, but the sorting is wrong (visible in client mode, since the first cipher the client lists and that is available on the server will be used). It also enhances the the cipher-list commands by a sorting by strength-bits (as of version B.02) and it fixes a bug in the cipher-command parser (possible endless loop) (as of version B.03). Are the any comments one this patch? Should we apply it in existing form? (I haven't yet carefully read the complete patch myself, so these questions are directed to myself as well :-) I've reviewed earlier versions and I'm essentially happy with it in principle. I think the best way to review it in detail is to apply it and run it! Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Converting certificate in Netscape's cert7.db to PEM format
Dr Stephen Henson wrote: Antonio Lam wrote: Hi: I am trying to write a SSL enabled client program with certificated based authentication. My server is a Netscape Messaging Server and they have the cert7.db and key3.db to store all there certificates and keys. I am able to create both server certificate and client certificate, both are store in a Netscape way: in cert7.db and key3.db file Does anyone know whether there is a way to convert a certificate and key in cert7.db and key3.db to PEM format? I need the PEM format certificate to implement a program with Perl's SSLeay library, since the "use_certificate_file function only take the PEM format... Please let me know if you have the answer. Are the certificates visible if you use key3.db and cert7.db from Netscape? If so you can try exporting to a PKCS#12 file. Yes, I can export it to PKCS#12 file. Can I used the "pkcs12" utility from openSSL to convert it to pem format? Just like this: openssl pkcs12 -nocerts -in file.p12 -out cert.pem openssl pkcs12 -nokeys -in file.p12 -out key.pem thanks, Antonio Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development 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]
Re: Mac junk?
ulf Is it really necessary to have 320k + 50k files in a printable ulf encoding in the Mac directory?? As Roy pointed out, none-source code MacOS files have (let's call it) a fork structure and therefore *has to* be encoded in either case. There is a binary format, but then the files will be 280k+42k (or something) at the cost that people might and probably will get into a trouble unpacking 'em whenever some program (e.g. cvs for mac:-) gets wrong idea and applies \n to \r or even worse iso-8859-x to macos encoding conversion. The printable format (.hqx) is in turn resistant to that kind of screw-ups, it occupies as much space in gzipped distribution as the binary format and some programs (e.g. SUNtar for MacOS) handle 'em transparently. Yes, one can pack-n-compress those two files together, then binhex the archive and get down to about 100k, but it won't save you space in the final .tar.gz distribution and will only add a level of complexity to the unpacking procedure. Well, I suppose nobody gives a damn about the latter anyway, huh:-) But back to the question. Is it *really* necessary? The files are (as Roy already inexplicitely mentioned) Metrowerk's alternative to Makefiles and an applescript creating (equivalent to) symbolic links in ./include/openssl. I reckon it's as necessary as to have the MacOS catalog. As alternative we can detach the whole catalog from the cvs and put it on the web, say at http://www.openssl.org/related/MacOS or something, and simply offer people to download the MacOS-specific stuff separately. Shall we take a vote? Cheers. Andy. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
