[openssl.org #373] Fw: is SSL_CTX_new() thread safe (on win32) ?
submiting as a bug (read the whole email ...)
Louis Solomon
www.SteelBytes.com
- Original Message -
From: Louis Solomon [SteelBytes] [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, December 01, 2002 2:10 PM
Subject: Re: is SSL_CTX_new() thread safe (on win32) ?
ok,
here's the cause I think ...
SSL_CTX_new(...)
{
...
ssl_create_cipher_list(...)
...
}
static int init_ciphers=1;
ssl_create_cipher_list(...)
{
...
if (init_ciphers) load_ciphers();
...
ssl_cipher_get_disabled()
...
}
load_ciphers()
{
init_ciphers = 0;
... // mark_1
init ssl_cipher_methods[]
...
}
ssl_cipher_get_disabled()
{
...
use ssl_cipher_methods[] // mark_2
...
}
consider this:
thread_1 calls SSL_CTX_new() and reaches mark_1
a context switch happens (thread_1 stalls, and thread_2 becomes
active)
thread_2 calls SSL_CTX_new() and reaches mark_2
thread_2 will be trying to read from ssl_cipher_methods which is
uninitialised !!
any one care to fix the 0.9.7 beta ? (or 0.9.6g)
Louis Solomon
www.SteelBytes.com
- Original Message -
From: Louis Solomon [SteelBytes] [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 30, 2002 10:30 PM
Subject: Re: is SSL_CTX_new() thread safe (on win32) ?
I just tested with 0.9.7 beta 4, and it still happens.
any ideas ?
Louis Solomon
www.SteelBytes.com
- Original Message -
From: Louis Solomon [SteelBytes] [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 26, 2002 4:10 PM
Subject: Re: is SSL_CTX_new() thread safe (on win32) ?
whoops :-) there was a typo in the url, it should be
http://www.steelbytes.com/temp/openssl_bug_test.zip
Louis Solomon
www.SteelBytes.com
- Original Message -
From: Louis Solomon [SteelBytes] [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 25, 2002 12:29 PM
Subject: is SSL_CTX_new() thread safe (on win32) ?
When running this test program I wrote, I _sometimes_ get
an error return by SSL_CTX_new(). The error msg is:
SSL routines:SSL_CTX_new:library has no ciphers
Louis Solomon
[EMAIL PROTECTED]
source and binaries of test program avail from:
http://www.steeelbytes.com/temp/openssl_bug_test.zip
openssl versions tested with:
0.9.6g compiled by me (src from openssl.org)
0.9.6g binaries from bsdftpd-ssl.sc.ru
0.9.6d binaries from mod-ssl.org
test enviroment:
winxp pro sp1
dual P3 733Mhz + 768MB ram
compiler:
visual studio .net
pseudo code:
main_thread()
{
init ssl (dyanmically linked with LoadLibrary and
GetProcAddress)
success = 0;
create a heap of worker threads
wait for work threads
clean up ssl
if (success!=num_threads)
show error
else
show success
}
worker_thread()
{
ssl_meth = SSLv23_method();
ssl_ctx = SSL_CTX_new(ssl_meth);
if (ssl_ctx!=NULL)
{
SSL_CTX_free(ssl_ctx);
success++;
}
else
{
log ssl error to debug output
}
}
__
OpenSSL Project
http://www.openssl.org
User Support Mailing List
[EMAIL PROTECTED]
Automated List Manager
[EMAIL PROTECTED]
__
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]
Re: OpenSSL and compression using ZLIB
(Note this approach keeps compression code in BIOs without duplicating it in ssl/, so applications can use the BIOs independantly too. Also, new compression methods are easier to add - eg. define a libbzip2-based BIO and add a new compression id+hook in the SSL/TLS code). I agree with this. I´ve been several years using ZLIB to compress big files mixing ZLIB code with pkcs7 code in OpenSSL, and a ZBIO would be very useful. I think there is a lot of messages in OpenSSL user-list asking for something similar to this to handle big files, so I think all that people would also benefit of this zBIO. Also, OpenSSL is a big sized library now, so if separate ZLIB code must be in libeay32.dll ans ssleay32.dll a lot of applications (in windows specially) would be greater, and with Java around the cost of downloading binaries and the size of executables must be carefully watched. I´m aware I´m talking as a user here, and this is a developers list... Pablo J. Royo __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Trying to understand bn_div_words()
levitte bn_div_words(0xC383,0x838B4B53,0x8000) Hmm, a call like that gave me an aruthmetic error on Linux... According to bc 0xC383838B4B53 / 0x8000 = 0x18707. The result is 33 bits or in other words the operation *overflows*. According to IA-32 manual overflow is indicated with the #DE (divide error) rather than with the CF flag which is why it dumps the core. This behaviour does not constitute a bug as BN_div makes sure the condition is never met. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #201] OpenSSL 0.9.6e failing make test
Hello again Lutz,
On Friday, November 29, 2002 at 1:20:25 PM +0100, Lutz Jänicke via RT wrote:
On Fri, Nov 29, 2002 at 12:59:29PM +0100, Alain Guibert via RT wrote:
- with 0.9.6g:
installing man3/SSL_write.3
/usr/bin/pod2man: Invalid man page - 1st pod line is not NAME in SSL_write.pod
make: *** [install_docs] Error 29
Hmm. Seems your version of pod2man has some problems, that were not
detected. util/pod2mantest has been improved since the release of
0.9.6g. The version of pod2man.pl shipping with OpenSSL should
definitely work.
Tried OpenSSL 0.9.7 beta4 and it seems to work. Both make test and
make install passes. Great! Thanks. I'll confirm with 0.9.7 when it's
released, but please feel free to close the bug.
Installing manpages gives:
| /usr/bin/pod2man: Invalid man page - 1st pod line is not NAME in pod2mantest.pod
| pod2man does not work properly ('BasicTest' failed). Looking for another pod2man ...
| /usr/bin/pod2man: Invalid man page - 1st pod line is not NAME in pod2mantest.pod
| /usr/bin/pod2man does not work properly ('BasicTest' failed). Looking for another
|pod2man ...
| No working pod2man found. Consider installing a new version.
| As a workaround, we'll use a bundled old copy of pod2man.pl.
| installing man1/CA.pl.1
| installing man1/asn1parse.1
[and so on]
There is just an alert at some point:
| installing man3/engine.3
| ../../util/pod2man.pl: Unrecognized pod directive in paragraph 34 of engine.pod:
|head3
| ../../util/pod2man.pl: Unrecognized pod directive in paragraph 39 of engine.pod:
|head3
| ../../util/pod2man.pl: Unrecognized pod directive in paragraph 59 of engine.pod:
|head3
| ../../util/pod2man.pl: Unrecognized pod directive in paragraph 62 of engine.pod:
|head3
| ../../util/pod2man.pl: Unrecognized pod directive in paragraph 69 of engine.pod:
|head3
| ../../util/pod2man.pl: Unrecognized pod directive in paragraph 73 of engine.pod:
|head3
But the installation continues, and man engine is there after.
Bye!Alain.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Trying to understand bn_div_words()
In message [EMAIL PROTECTED] on Mon, 02 Dec 2002 10:51:30 +0100, Andy Polyakov [EMAIL PROTECTED] said: appro levitte bn_div_words(0xC383,0x838B4B53,0x8000) appro appro Hmm, a call like that gave me an aruthmetic error on Linux... appro appro According to bc 0xC383838B4B53 / 0x8000 = 0x18707. The appro result is 33 bits or in other words the operation *overflows*. According appro to IA-32 manual overflow is indicated with the #DE (divide error) appro rather than with the CF flag which is why it dumps the core. This appro behaviour does not constitute a bug as BN_div makes sure the condition appro is never met. Yeah, and I discovered a small bug late last night, as well as the fact that bn_div_words() is supposed to return on error (or at least if the divisor is 0). I'm slowly getting there, there's currently another problem going on, and I think it might have to do with dropping the lowest bit of the divisor when that one gets diveded by two (because of some quirks with EDIV)... -- 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 #201] OpenSSL 0.9.6e failing make test
On Mon, Dec 02, 2002 at 10:55:26AM +0100, Alain Guibert via RT wrote: There is just an alert at some point: | installing man3/engine.3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 34 of engine.pod: head3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 39 of engine.pod: head3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 59 of engine.pod: head3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 62 of engine.pod: head3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 69 of engine.pod: head3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 73 of engine.pod: head3 But the installation continues, and man engine is there after. Hmm. According to http://www.perldoc.com/perl5.6/pod/perlpod.html there only exist =head1 and =head2, so the complaint is correct :-) Geoff??? 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]
Re: [openssl.org #201] OpenSSL 0.9.6e failing make test
On December 2, 2002 05:53 am, Lutz Jaenicke via RT wrote: On Mon, Dec 02, 2002 at 10:55:26AM +0100, Alain Guibert via RT wrote: There is just an alert at some point: | installing man3/engine.3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 34 | of engine.pod: head3 ../../util/pod2man.pl: Unrecognized pod | directive in paragraph 39 of engine.pod: head3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 59 | of engine.pod: head3 ../../util/pod2man.pl: Unrecognized pod | directive in paragraph 62 of engine.pod: head3 | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 69 | of engine.pod: head3 ../../util/pod2man.pl: Unrecognized pod | directive in paragraph 73 of engine.pod: head3 But the installation continues, and man engine is there after. Hmm. According to http://www.perldoc.com/perl5.6/pod/perlpod.html there only exist =head1 and =head2, so the complaint is correct :-) Geoff??? Hmm, bollocks. I can't confess to having studied the perlpod documentation on this - I merely wondered if I could get away with a third level of header nesting and it just worked on my installation (ie. I got no warnings/errors and the resulting man-page rendered fine). Is this a limitation in (some versions of) 'pod2man' or is it a safety measure because of limitations in (some versions of) 'man'? It seems a shame to have to ditch something that works if it's a limitation in the version of the conversion tool being used. Lutz, you are the doc-god, what do you think we should do? I'm obviously the first to want a third level of header nesting, but I may not be the last ... Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ The bastards have beaten off rationalism for now, but haven't eliminated our capacity for reason - to do that they'd have to make us forget how to both think and fear at the same time. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
authorityKeyIdentifier
Hi, I read the discussion about the authorityKeyIdentifier and the problems with Microsoft. So I used my contacts, packaged the problem and now it looks for me like Microsoft also interprets the extension in the correct way. The problem is now where do you find the bug or problem? I forward two mails from Microsoft in some minutes. They were really friendly and fast. So if you find a bug in their code then you can contact these guys. Best regards Michael -- --- Michael Bell Email (private): [EMAIL PROTECTED] Rechenzentrum - Datacenter Email: [EMAIL PROTECTED] Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482 Unter den Linden 6 Fax: +49 (0)30-2093 2959 10099 Berlin Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[Fwd: RE: RFC 3280 and smartcardlogin]
This is the second answer and there are no doubts. They use the same interpretation of the standard like OpenSSL. So if you find a situation where Microsoft's software uses another interpretation then you should feel free to contact these guys directly or refer Microsoft's support to them. Best regards Michael Original Message Subject: RE: RFC 3280 and smartcardlogin Date: Mon, 2 Dec 2002 10:16:25 -0800 From: Laudon Williams [EMAIL PROTECTED] To: Glenn Pittaway [EMAIL PROTECTED],Michael Bell [EMAIL PROTECTED],David Cross [EMAIL PROTECTED] This is a common misunderstanding of the standard. Problem is this... SKI based on a hash of Public Key - Root: No AKI SKI is unique hash of the public key in this certificate Intermediary: AKI is exact duplicate of the Root's SKI. This should never be computed. It is an exact copy. SKI is unique has of the public key in this certificate End Entity: AKI is exact duplicate of the Root's SKI. This should never be computed. It is an exact copy. SKI is unique has of the public key in this certificate - The RFC recommends, but does not require a specific algorithm for generating the SKI. AKI based on Authority name and Serial Number - Root: Serial # - 12345 Issuer - Root CA Subject - Root CA No AKI No SKI Intermediary: Serial # - 54321 Issuer - Root CA Subject - Int CA AKI - NULL, Root CA, 12345 SKI - Whatever... End Entity: Serial # - 67890 Issuer - Int CA Subject - Whoever AKI - NULL, Root CA, 54321 (this refers to the Issuer and Serial number in the Intermediary CA) SKI - whatever... - The AKI does not refer to the Toot certificate. It refers to the Issuer and Serial number in the intermediary CA. -Laudon -Original Message- From: Glenn Pittaway Sent: Monday, December 02, 2002 8:25 AM To: 'Michael Bell'; Laudon Williams; David Cross Laudon/David, Can either of you comment? Glenn -Original Message- From: Michael Bell [mailto:[EMAIL PROTECTED]] Sent: Friday, November 29, 2002 3:29 AM To: Glenn Pittaway Subject: RFC 3280 and smartcardlogin Dear Mr. Pittaway, we tested the Microsoft smartcard login successfully with a Citrix Metaframe Server. This is also possible with a third party CA. The problems starts if we use a CA-hierarchy. The software tries to validate the complete certificate chain what is really good. We afraid that there is a problem in the extension interpretation of the validation code. It expects in the authorityKeyIdentifier in the field authorityCertIssuer (see RFC 3280) at every time the issuer of the certificate but this is only correct for selfsigned CA-certificates. If you use a hierarchy which is higher than one then the authorityCertIssuer is the issuer of the CA-cert and not the subject of the CA-cert. The problem is that PKIX and some laws in Europe require the use of this extension and Microsoft is the only vendor who interprets RFC 3280 in this way. So we cannot simply remove the extension from the certificates. The result is that we cannot create hierarchies with Microsft smartcardlogin or we have to build only flat hierarchies (means there is no hierarchy). My question is now who can I contact at Microsoft to get a statement about this problem and does Microsoft see the problem as a bug or as is because a patch would break too many clients? Best regards Michael Bell -- --- Michael Bell Email (private): [EMAIL PROTECTED] Rechenzentrum - Datacenter Email: [EMAIL PROTECTED] Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482 Unter den Linden 6 Fax: +49 (0)30-2093 2959 10099 Berlin Germany -- --- Michael Bell Email (private): [EMAIL PROTECTED] Rechenzentrum - Datacenter Email: [EMAIL PROTECTED] Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482 Unter den Linden 6 Fax: +49 (0)30-2093 2959 10099 Berlin Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[Fwd: RE: RFC 3280 and smartcardlogin]
This was the first answer from Microsoft. Perhaps my description was not
really perfect.
Michael
Original Message
Subject: RE: RFC 3280 and smartcardlogin
Date: Mon, 2 Dec 2002 08:55:13 -0800
From: David Cross [EMAIL PROTECTED]
To: Glenn Pittaway [EMAIL PROTECTED],Michael Bell
[EMAIL PROTECTED],Laudon Williams
[EMAIL PROTECTED]
I am slightly confused on the problem you are encountering. The AKI
matches the SKI in the issuer certificate and we validate that on our
clients and servers. There is no standard way (only recommendations) on
how to generate theat value - the only requirement is that they match.
You should never be re-calculating the AKI and SKI values - you should
always perform a binary comparison. If we changed our current
algorithm, this could break hundreds of millions of clients. Relevant
abstract:
4.2.1.1 Authority Key Identifier
The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used to
sign a certificate. This extension is used where an issuer has
multiple signing keys (either due to multiple concurrent key pairs or
due to changeover). The identification MAY be based on either the
key identifier (the subject key identifier in the issuer's
certificate) or on the issuer name and serial number.
The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction. There is one exception;
where a CA distributes its public key in the form of a self-signed
certificate, the authority key identifier MAY be omitted. The
signature on a self-signed certificate is generated with the private
key associated with the certificate's subject public key. (This
proves that the issuer possesses both the public and private keys.)
In this case, the subject and authority key identifiers would be
identical, but only the subject key identifier is needed for
certification path building.
The value of the keyIdentifier field SHOULD be derived from the
public key used to verify the certificate's signature or a method
that generates unique values. Two common methods for generating key
identifiers from the public key, and one common method for generating
unique values, are described in section 4.2.1.2. Where a key
identifier has not been previously established, this specification
RECOMMENDS use of one of these methods for generating keyIdentifiers.
Where a key identifier has been previously established, the CA SHOULD
use the previously established identifier.
This profile RECOMMENDS support for the key identifier method by all
certificate users.
This extension MUST NOT be marked critical.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNamesOPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
David B. Cross
Program Manager
Windows Security
-Original Message-
From: Glenn Pittaway
Sent: Monday, December 02, 2002 8:25 AM
To: Michael Bell; Laudon Williams; David Cross
Subject: RE: RFC 3280 and smartcardlogin
Laudon/David,
Can either of you comment?
Glenn
-Original Message-
From: Michael Bell [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 29, 2002 3:29 AM
To: Glenn Pittaway
Subject: RFC 3280 and smartcardlogin
Dear Mr. Pittaway,
we tested the Microsoft smartcard login successfully with a Citrix
Metaframe Server. This is also possible with a third party CA. The
problems starts if we use a CA-hierarchy. The software tries to validate
the complete certificate chain what is really good.
We afraid that there is a problem in the extension interpretation of the
validation code. It expects in the authorityKeyIdentifier in the field
authorityCertIssuer (see RFC 3280) at every time the issuer of the
certificate but this is only correct for selfsigned CA-certificates. If
you use a hierarchy which is higher than one then the
authorityCertIssuer is the issuer of the CA-cert and not the subject of
the CA-cert.
The problem is that PKIX and some laws in Europe require the use of this
extension and Microsoft is the only vendor who interprets RFC 3280 in
this way. So we cannot simply remove the extension from the
certificates. The result is that we cannot create hierarchies with
Microsft smartcardlogin or we have to build only flat hierarchies (means
there is no hierarchy).
My question is now who can I contact at Microsoft to get a statement
about this problem and does Microsoft see the problem as a bug or as is
because a patch would break too many clients?
Best regards
Michael Bell
--
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
Ah, that is a good point in the case where we saw this, the source bio was a bio_s_mem, i.e. a memory bio, so it was not doing r text-mode eol translation. In other instances we do use the r mode with file bios, and I guess that might explain why we never saw it happen in those functions... although it could also be that we never had a line of text that was exactly 1022 characters long. :) In any case, I don't believe that memory bios can be set to text-mode... can they? --Peter Lincroft --- Richard Levitte via RT [EMAIL PROTECTED] wrote: A couple of questions: - which type of source BIO did you use when this happened? - if it was a text file, was it opened in binary mode? In case it was a text file opened in binary mode, do you get a better behavior if it's opened in text mode? You see, in text mode, CRLF is supposed to be converted to LF, and hopefully *before* the length of the buffer is checked... [[EMAIL PROTECTED] - Fri Nov 22 10:27:16 2002]: OS: Windows, but I think it is a cross-platform bug. Version: 0.9.6g In the following function which is called from PKCS7_sign, if the source text contains a line of text which is exactly a mutiple of MAX_SMLEN-2 characters long and has a CRLF line ending, then the gets call will return a buffer which ends with just a CR, and then on the next call a line that contains just an LF, which will result in two CRLF pairs being put into the output. -- Richard Levitte __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign
In message [EMAIL PROTECTED] on Mon, 2 Dec 2002 22:30:20 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Ah, that is a good point in the case where we saw rt this, the source bio was a bio_s_mem, i.e. a memory rt bio, so it was not doing r text-mode eol rt translation. In other instances we do use the r rt mode with file bios, and I guess that might explain rt why we never saw it happen in those functions... rt although it could also be that we never had a line of rt text that was exactly 1022 characters long. :) rt rt In any case, I don't believe that memory bios can be rt set to text-mode... can they? No they can't. However, if CRLF are showing up in them, it means you have put it in there some way, perhaps from transfering a file in binary mode to it? Text mode vs. binary mode is tricky business... -- 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 #356] Bug in CRLF translation in PKCS7_sign
In message [EMAIL PROTECTED] on Mon, 2 Dec 2002 22:30:20 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Ah, that is a good point in the case where we saw rt this, the source bio was a bio_s_mem, i.e. a memory rt bio, so it was not doing r text-mode eol rt translation. In other instances we do use the r rt mode with file bios, and I guess that might explain rt why we never saw it happen in those functions... rt although it could also be that we never had a line of rt text that was exactly 1022 characters long. :) rt rt In any case, I don't believe that memory bios can be rt set to text-mode... can they? No they can't. However, if CRLF are showing up in them, it means you have put it in there some way, perhaps from transfering a file in binary mode to it? Text mode vs. binary mode is tricky business... -- 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: [PATCH] Windows CE (against openssl-0.9.7-stable-SNAP-20021201)
Sure. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS Whacker Sent: Tuesday, 3 December 2002 9:12 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] Windows CE (against openssl-0.9.7-stable-SNAP-20021201) In message [EMAIL PROTECTED] on Tue, 3 Dec 2002 02:38:33 +1100, Steven Reddie [EMAIL PROTECTED] said: smr I've made some changes to wcecompat to support other Windows CE platforms, smr the necessary changes to OpenSSL are attached. I've also included smr cryptlib.h in several files so that the OPENSSL_cleanse prototype is smr declared. Without it I am getting compiler failures, and it's probably a smr general Win32 problem. Thanks for catching that. However, I'm surprised that you didn't include openssl/crypto.h, which is what I encouraged (admitedly in a not very outspoken way...). Mind if I change that? -- 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #371] undeclared MAXHOSTNAMELEN in ssltest.c (097snap)
Defining USE_SOCKETS before e_os.h is included probably helps :-). This ticket is now resolved. [jaenicke - Sun Dec 1 19:02:13 2002]: [[EMAIL PROTECTED] - Sat Nov 30 23:00:17 2002]: Building OpenSSL 0.9.7 beta4 and snap 20021129 on RedHat 8.0 (gcc 3.2 glibc 2.3) configured with 'no-asm shared --with-krb5-flavor=MIT' make fail with undeclared MAXHOSTNAMELEN in ssltest.c (line 693). After adding #include asm/param.h build ok and pass all tests Hmm. asm/param.h seems to be Linux'ish to me. I just checked my HP-UX 10.20 box and it seems, that sys/param.h would be the way to go. On Linux this will include asm/param.h via linux/param.h. Could you please try? Hmm. Having this said, e_os.h already seems to include sys/param.h, doesn't it??? Best regards, Lutz -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Status of 0.9.6h?
What is the status of the 0.9.6h defect release? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
