Re: IMPORTANT: please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz
On Fri, Feb 14, 2003 at 06:08:34PM +0100, Bodo Moeller wrote: Please test snapshot openssl-0.9.7-stable-SNAP-20030214.tar.gz (or later), which will be available today around 8 p.m. GMT at URL: ftp://ftp.openssl.org/snapshot;type=d . We plan to release version 0.9.7a soon (next week if all goes well). OpenSSL 0.9.7a will be a bugfix release based on 0.9.7; thus there will be no beta releases. The snapshot should solve most problems that have been reported to [EMAIL PROTECTED]; please test it to help us avoid unforeseen problems with the new release. `make test' completed for openssl-0.9.7-stable-SNAP-20030216 on FreeBSD 5.0-CURRENT i386, alpha, and sparc64. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[PATCH] Parallel make
Parallel make, eg. make -j 7 fails now. This patch correct it. -- Witold Filipczyk [EMAIL PROTECTED] --- openssl-0.9.7.old/crypto/Makefile.ssl Fri Dec 20 15:28:45 2002 +++ openssl-0.9.7/crypto/Makefile.ssl Sun Feb 16 20:02:43 2003 @@ -50,7 +50,7 @@ top: @(cd ..; $(MAKE) DIRS=$(DIR) all) -all: buildinf.h lib subdirs shared +all: shared buildinf.h: ../Makefile.ssl ( echo #ifndef MK1MF_BUILD; \ @@ -96,7 +96,7 @@ $(RANLIB) $(LIB) || echo Never mind. @touch lib -shared: +shared: buildinf.h lib subdirs if [ -n $(SHARED_LIBS) ]; then \ (cd ..; $(MAKE) $(SHARED_LIB)); \ fi --- openssl-0.9.7.old/ssl/Makefile.ssl Thu Dec 19 22:10:20 2002 +++ openssl-0.9.7/ssl/Makefile.ssl Sun Feb 16 20:03:13 2003 @@ -55,14 +55,14 @@ top: (cd ..; $(MAKE) DIRS=$(DIR) all) -all: lib shared +all: shared lib: $(LIBOBJ) $(AR) $(LIB) $(LIBOBJ) $(RANLIB) $(LIB) || echo Never mind. @touch lib -shared: +shared: lib if [ -n $(SHARED_LIBS) ]; then \ (cd ..; $(MAKE) $(SHARED_LIB)); \ fi
[openssl.org #512] make OpenSSl-0.9.6a
I get this message when I try to compile OpenSSL-0.9.6a with the command make: # make making all in crypto... cc -I. -I.. -I../include -DOPENSSL_SYSNAME_ULTRASPARC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DMD5_ASM -c cryptlib.c /usr/ucb/cc: language optional software package not installed *** Error code 1 make: Fatal error: Command failed for target `cryptlib.o' Current working directory /progs/local/openssl-0.9.7/crypto *** Error code 1 make: Fatal error: Command failed for target `sub_all' Do I need to install a language package? Stian Guttormsen EDB-Teamco Driftskonsulent Telecom Drift Unix Mobil tlf: 22772827 / mob: 91888785/ fax: 22090492 email: [EMAIL PROTECTED] smail: Boks 399, Økern 0513 Oslo www.edb.teamco.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #513] [PATCH] Parallel make
Parallel make, eg. make -j 7 fails now. This patch correct it. -- Witold Filipczyk [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #510] bug at compilation
Fix committed. It will appear in OpenSSL 0.9.7a and on. This ticket is now resolved. [[EMAIL PROTECTED] - Tue Feb 18 12:29:43 2003]: Hello ! I'm trying to compile OpenSSL on a Windows 2000 server with Borland C++ Builder 5 using nasm. With the OpenSSL 0.9.7 stable snapshot 20030216, compilation stopped with the following error code : bcc32 -otmp32\md2test.obj -Iinc32 -Itmp32 -DWIN32_LEAN_AND_MEAN -q -w-au s -w-par -w-inl -c -tWC -tWM -DOPENSSL_SYSNAME_WIN32 -DL_ENDIAN -DDSO_WIN32 -D_s tricmp=stricmp -O2 -ff -fp -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_NO_KRB5 -c .\crypto\md2\md2test.c .\crypto\md2\md2test.c: Warning W8066 .\crypto\md2\md2test.c 128: Unreachable code in function main ilink32 -ap -Tpe -x -Gn tmp32\md2test.obj c0x32.obj, out32\md2test.exe,, out32\ssleay32.lib out32\libeay32.lib cw32mt.lib import32.lib Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Fatal: Unable to open file 'C0X32.OBJ' ** error 2 ** deleting out32\md2test.exe How can I fix it ? Thanks. Olivier Marché Observatoire de la Vie Etudiante - Infocentre Université de Provence - Aix-Marseille 1 tél : 04 91 10 62 37 - fax : 04 91 10 61 20 -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[ANNOUNCE] OpenSSL 0.9.7a and 0.9.6i released
-BEGIN PGP SIGNED MESSAGE- OpenSSL version 0.9.7a and 0.9.6i released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.7a of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release and incorporates at least 11 changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES. We also release 0.9.6i, which contains the same security bugfix as 0.9.7a and a few more small bugfixes compared to 0.9.6h. The most significant changes are: o Security: Important security related bugfixes. [0.9.7a and 0.9.6i] o Enhanced compatibility with MIT Kerberos. [0.9.7a] o Can be built without the ENGINE framework. [0.9.7a] o IA32 assembler enhancements. [0.9.7a] o Support for new platforms: FreeBSD/IA64 and FreeBSD/Sparc64. [0.9.7a] o Configuration: the no-err option now works properly. [0.9.7a] o SSL/TLS: now handles manual certificate chain building. [0.9.7a] o SSL/TLS: certain session ID malfunctions corrected. [0.9.7a] We consider OpenSSL 0.9.7a to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.7a is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ For those who want or have to stay with the 0.9.6 series of OpenSSL, we strongly recommend that you upgrade to OpenSSL 0.9.6i as soon as possible. It's available in the same location as 0.9.7a. The distribution file name is: o openssl-0.9.7a.tar.gz [normal] MD5 checksum: a0d3203ecf10989fdc61c784ae82e531 o openssl-0.9.6i.tar.gz [normal] MD5 checksum: 9c4db437c17e0b6412c5e4645b6fcf5c o openssl-engine-0.9.6i.tar.gz [engine] MD5 checksum: c9adc0596c630b31b999eba32fc0a6b3 The checksums were calculated using the following command: openssl md5 openssl-0.9.7a.tar.gz openssl md5 openssl-0.9.6i.tar.gz openssl md5 openssl-engine-0.9.6i.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakov Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Lutz JänickeUlf Möller -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQEVAwUBPlOJmPTy7ZjgbSyxAQHG4Qf+K6vX8kk9msYI3iD6zK3BSXzMFO0pCVNN 8OkUW7wsmAnoSRuT89jGTom0fmIi1eiQcOFUf1krlk7btJ4KRVEok/G2ooa4qOmq MU+4djKgM/LDlqzAbDfN7cEbWGPJeP4polPTgOBYqexBdwoTvJuX9m4LRgvK2enW BsJjqdsmsLqWlMmixpKsMHNXXyYqs8SGhdSR7SQlbCVNu6QabWi21NbKCvyJzhEq 5Bn9mUej60GHOdTNpRGwqWxBCvl/kAPnOP4ffj5mbQL+R9VYCeCy3BsjDmLdmDt9 xqxdXBxPqu/S1OnSnsTQeMk70o3qX0F6lgqhNUt6FtHynbxoAGAPcw== =KOdL -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #509]
Hello (a beginner using linux+ssl) I tried to install the latest version of openssl (openssl-0.9.7.tar.gz) under Suse Linux 7.2 but it makes no results. The make and make install command doesn´t work. Then I tried with the version 9.6h.tar.gz and the make and make install runs. The only problem I had is that i received an error messages like this: make[2]: Leaving directory `/var/tmp/openssl-0.9.6h/crypto/rand' making all in crypto/err... make[2]: Entering directory `/var/tmp/openssl-0.9.6h/crypto/err' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/var/tmp/openssl-0.9.6h/crypto/err' making all in crypto/objects... make[2]: Entering directory `/var/tmp/openssl-0.9.6h/crypto/objects' /usr/local/bin/perl objects.pl objects.txt obj_mac.num obj_mac.h make[2]: /usr/local/bin/perl: Command not found make[2]: *** [obj_mac.h] Error 127 make[2]: Leaving directory `/var/tmp/openssl-0.9.6h/crypto/objects' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/var/tmp/openssl-0.9.6h/crypto' make: *** [sub_all] Error 1 What I understand is that openssl is looking for archive perl, under the the directory /usr/local/bin/ ..but in my computer the archive perl is located at /usr/bin/. My question is ..What I can do ..so that ..when I run the make install ..it looks for the perl archive in /usr//bin/ and not in /usr/local/bin If you have other solution please let me know... Thanks a lot __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #511] BUG: crypto/ec/ec_key.c:EC_KEY_dup()
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #512] make OpenSSl-0.9.6a
This is not an OpenSSL bug; you should install gcc, and possibly remove /usr/ucb from the PATH. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #514] Bug in OpenSSL????
Hi, on AIX (64bit) I noticed a major problem with non-blocking sockets. Methods SSL_connect(), SSL_read() and SSL_write() should return SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete their tasks but the socket couldn't handle all the work. But instead, the methods return SSL_ERROR_SYSCALL when the underlying socket gave errno=EWOULDBLOCK or errno=EAGAIN (means: the application should retry with these functions if it has not been completed, yet) from their respective functions (read() and write()). For these specific system error numbers, the SSL functions should return SSL_ERROR_WANT_* return codes, shouldn't they? Regards Ralph Schuster PS: However, on AIX 4.2 and earlier, this didn't seem to be a problem. Funny, isn't it? (But these versions are not supported by IBM anymore!) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #512] make OpenSSl-0.9.6a
Thanks. I have already done that and it resolved the problem. SG -Original Message- From: Bodo Moeller via RT [mailto:[EMAIL PROTECTED]] Sent: 19. februar 2003 17:33 To: Guttormsen Stian Cc: [EMAIL PROTECTED] Subject: [openssl.org #512] make OpenSSl-0.9.6a This is not an OpenSSL bug; you should install gcc, and possibly remove /usr/ucb from the PATH. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Inconsistent behavior of ECPublicKey_{set,get}_octet_string()?
On Wed, Feb 19, 2003, Eric Cronin wrote:
I am trying to find the analogue of the {i2d,d2i}_{DSA,RSA}PublicKey
functions for ECDSA EC_KEY's. As best I can tell,
i2dECPKParameters+ECPublicKey_get_octet_string and
d2iECPKParameters+ECPublicKey_set_octet_string are the way to do the
encoding/decoding of just the public portions of an EC_KEY. However,
unlike all the other encoding routines in OpenSSL,
ECPublicKey_{set,get}_octet_string() does not advance the supplied
buffer after copying the key to it.
Instead, if *in is non-NULL, it remains pointing to the start of the
copied key after the function returns (In every other encoding routine
I've used *in is advanced to point to the byte after the just encoded
data).
Although the key specific RSAPublicKey and RSAPrivateKey functions follow a
written standard (PKCS#1) the DSAPublicKey and DSAPrivateKey ones AFAIK do
not: they were made up for SSLeay and we're now stuck with them.
Rather than make up a new format that would be incompatible with everything
else I'd prefer it that we didn't have any equivalents at all for newer
algorithms.
The preferred technique for handling all types of public keys is the
{i2d,d2i}_PUBKEY functions and EVP_PKEY. These use the standard certificate
format for public keys. This isn't algorithm specific and there are various
standards that define the formats used.
There are key specific key types such as {i2d,d2i}_RSA_PUBKEY. These just call
the PUBKEY type and insert or extract the algorithm specific key, throwing an
error if the key isn't of the expected type.
The EC equivalents are d2i_EC_PUBKEY and i2d_EC_PUBKEY.
Similarly PKCS#8 is the preferred private key format.
Is there a reason these functions deviates from the normal OpenSSL
behavior? It was hard enough to figure out the unwritten rules of when
the input buffer does and does not get advanced to begin with, and now
if some functions adhere to it and some don't...
A lot more of that stuff is documented since 0.9.7 but not all the EC stuff:
its very new.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Inconsistent behavior of ECPublicKey_{set,get}_octet_string()?
Eric Cronin wrote:
I am trying to find the analogue of the {i2d,d2i}_{DSA,RSA}PublicKey
functions for ECDSA EC_KEY's.
May I ask why ? For X9.62 you don't need them (, or do
you mean a X509 SubjectPublicKeyInfo object ?).
As best I can tell,
i2dECPKParameters+ECPublicKey_get_octet_string and
d2iECPKParameters+ECPublicKey_set_octet_string are the way to do the
encoding/decoding of just the public portions of an EC_KEY. However,
unlike all the other encoding routines in OpenSSL,
ECPublicKey_{set,get}_octet_string() does not advance the supplied
buffer after copying the key to it.
The ECPublicKey_{set|get}_octet_string() functions should simply return
(or set) the public key as an octet string (as the name suggest). They have
nothing to do with ASN1 DER encoding = no i2d or d2i prefix.
Note: the ec public key in the X509 SubjectPublicKeyInfo object is not
DER encoded (the most significant bit of the public key (encoded
as an octet string) becomes the most significant bit of the bit string).
Instead, if *in is non-NULL, it remains pointing to the start of the
copied key after the function returns (In every other encoding routine
I've used *in is advanced to point to the byte after the just encoded
data).
ECPublicKey_{set|get}_octet_string() are *not* DER de/encoding routines.
Is there a reason these functions deviates from the normal OpenSSL
behavior? It was hard enough to figure out the unwritten rules of when
the input buffer does and does not get advanced to begin with, and now
if some functions adhere to it and some don't...
Sorry, perhaps I should add some comments in the corresponding
code section ...
Regards,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Inconsistent behavior of ECPublicKey_{set,get}_octet_string()?
On Wednesday, February 19, 2003, at 02:48 PM, Nils Larsch wrote:
Eric Cronin wrote:
I am trying to find the analogue of the {i2d,d2i}_{DSA,RSA}PublicKey
functions for ECDSA EC_KEY's.
May I ask why ? For X9.62 you don't need them (, or do
you mean a X509 SubjectPublicKeyInfo object ?).
I'm working on an implementation of forward-secure signature
algorithms, whose keys can sometimes contain multiple RSA/DSA/ECDSA/etc
keys. I haven't tackled the best way to PKCS encode these
forward-secure keys yet, so in the meantime I have just been using a
simple obj1_size||obj1_blob||obj2_size||obj2_blob||... encoding, using
i2d_DSAPublicKey and the like when I needed to dump out an OpenSSL key.
I will probably switch to putting the raw keys into an EVP_PKEY for
the encoding as Steve suggested, but my original goal was just to use
the simplest encoding possible since the code will all be removed once
a real encoding is decided upon.
As best I can tell,
i2dECPKParameters+ECPublicKey_get_octet_string and
d2iECPKParameters+ECPublicKey_set_octet_string are the way to do the
encoding/decoding of just the public portions of an EC_KEY. However,
unlike all the other encoding routines in OpenSSL,
ECPublicKey_{set,get}_octet_string() does not advance the supplied
buffer after copying the key to it.
The ECPublicKey_{set|get}_octet_string() functions should simply return
(or set) the public key as an octet string (as the name suggest). They
have
nothing to do with ASN1 DER encoding = no i2d or d2i prefix.
Note: the ec public key in the X509 SubjectPublicKeyInfo object is not
DER encoded (the most significant bit of the public key (encoded
as an octet string) becomes the most significant bit of the bit
string).
OK, maybe encoding is the wrong term to have used. What I meant is
that all the other (OpenSSL internal datastructure) - (char * buffer)
functions I can think of have the side effect of advancing the output
buffer's pointer after copying the data (unless it allocated the
buffer, in which case it doesn't)... The ECPublicKey_{set,get} ones,
while having that same common function signature, do not. Maybe this
is just i2d/d2i functions vs. all other functions of this nature, in
which case I've unfairly singled out ECPublicKey_{set,get}/
I'm not saying that advancing the buffer pointer is the best design
(personally I think side effects like that just to save the caller from
a simple += are bad), but it would at least be nice if all of OpenSSL's
foo_convert(object * foo, char **out) had the same behavior regarding
if (!out), if (out !*out) and if (out *out) and similarly for the
conversion back to in internal datastructure.
Thanks,
Eric
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Inconsistent behavior of ECPublicKey_{set,get}_octet_string()?
Eric Cronin wrote:
...
I'm working on an implementation of forward-secure signature
algorithms, whose keys can sometimes contain multiple RSA/DSA/ECDSA/etc
keys. I haven't tackled the best way to PKCS encode these
forward-secure keys yet, so in the meantime I have just been using a
simple obj1_size||obj1_blob||obj2_size||obj2_blob||... encoding, using
i2d_DSAPublicKey and the like when I needed to dump out an OpenSSL key.
I will probably switch to putting the raw keys into an EVP_PKEY for
the encoding as Steve suggested, but my original goal was just to use
the simplest encoding possible since the code will all be removed once
a real encoding is decided upon.
I think you should use, as Steve suggested, the X509 DER encoded
SubjectPublicKeyInfo object because a simple EC public key
(without parameters) isn't really useful.
...
The ECPublicKey_{set|get}_octet_string() functions should simply return
(or set) the public key as an octet string (as the name suggest). They
have
nothing to do with ASN1 DER encoding = no i2d or d2i prefix.
Note: the ec public key in the X509 SubjectPublicKeyInfo object is not
DER encoded (the most significant bit of the public key (encoded
as an octet string) becomes the most significant bit of the bit
string).
OK, maybe encoding is the wrong term to have used. What I meant is
that all the other (OpenSSL internal datastructure) - (char * buffer)
functions I can think of have the side effect of advancing the output
buffer's pointer after copying the data (unless it allocated the
buffer, in which case it doesn't)... The ECPublicKey_{set,get} ones,
while having that same common function signature, do not. Maybe this
is just i2d/d2i functions vs. all other functions of this nature, in
which case I've unfairly singled out ECPublicKey_{set,get}/
I'm not saying that advancing the buffer pointer is the best design
I guess the reason for this was to simplify the OpenSSL ASN1 macros/
functions (you can call the corresponding de- encode functions in a
row, without taking care of the pointer).
(personally I think side effects like that just to save the caller from
a simple += are bad), but it would at least be nice if all of OpenSSL's
foo_convert(object * foo, char **out) had the same behavior regarding
if (!out), if (out !*out) and if (out *out) and similarly for the
conversion back to in internal datastructure.
Ack = I will think about it ...
Regards,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #511] BUG: crypto/ec/ec_key.c:EC_KEY_dup()
Bodo Moeller via RT [EMAIL PROTECTED]: [nothing] RT has cut off the message, which said that the fix will be in the next snapshot (which should be the latest snapshot by now). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Inconsistent behavior of ECPublicKey_{set,get}_octet_string()?
On Wed, Feb 19, 2003, Nils Larsch wrote: I guess the reason for this was to simplify the OpenSSL ASN1 macros/ functions (you can call the corresponding de- encode functions in a row, without taking care of the pointer). It was indeed for that purpose. When the old ASN1 code built encoders and decoders by stringing together d2i and i2d functions it avoided having to bloat the code even further by incrementing a pointer after every single call. It doesn't matter as much now because encoders and decoders aren't written like that with the new ASN1 code (though a couple of pathological cases remain) but I suppose were stuck with that behaviour in case anything relies on it. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
