[openssl.org #2234] PATCH to fix broken c_rehash's $openssl derivation
Greetings,
I have identified several problems in the way OpenSSL 1.0.0's c_rehash works.
This breaks on any nonstandard configuration, in that:
- c_rehash POSTFIXES $dir/bin to the PATH, when it should prefix it. ($dir
inherits $openssldir from Configure)
- c_rehash should use $prefix/bin, not $openssldir/bin (comment ditto)
This causes several issues:
- If THE RIGHT VERSION OF openssl isn't already in PATH
or unless openssl is (uncommon!) overridden to $prefix/bin, c_rehash will be
unable to identify the proper openssl executable and abort.
- If multiple versions of OpenSSL are installed in parallel, for instance,
0.9.8X under /usr and OpenSSL 1.0.0 under /opt/openssl-1.0.0, c_rehash will
grab the wrong version of openssl and thus the wrong hash algorithm, making
OpenSSL unable to find its certificates.
This has already caused bogus bug reports:
https://developer.berlios.de/bugs/?func=detailbugbug_id=17073group_id=1824
The attached patch fixes these OpenSSL issues:
- It adds a line my $prefix; to tools/c_rehash.in
- It uses the line to derive the path component
- It PREPENDS this to the existing path
- It AVOIDS adding a path separator if $ENV{PATH} happens to be empty
- It teaches Configure to replace my $prefix as it regenerates c_rehash from
the .in file.
The patch applies to OpenSSL 1.0.0 on - I guess - all platforms, and possibly
earlier versions too. Please check earlier versions and adopt where needed.
Thank you.
--
Matthias Andree
diff -up ./Configure.orig ./Configure
--- ./Configure.orig2010-01-19 22:40:54.0 +0100
+++ ./Configure 2010-04-12 18:24:47.0 +0200
@@ -1789,11 +1789,11 @@ EOF
(system $make_command.$make_targets) == 0 or exit $?
if $make_targets ne ;
if ( $perl =~ m...@^/@) {
- dofile(tools/c_rehash,$perl,'^#!/', '#!%s','^my \$dir;$', 'my
$dir = ' . $openssldir . ';');
+ dofile(tools/c_rehash,$perl,'^#!/', '#!%s','^my \$dir;$', 'my
$dir = ' . $openssldir . ';', '^my \$prefix;$', 'my $prefix = ' . $prefix .
';');
dofile(apps/CA.pl,$perl,'^#!/', '#!%s');
} else {
# No path for Perl known ...
- dofile(tools/c_rehash,'/usr/local/bin/perl','^#!/', '#!%s','^my
\$dir;$', 'my $dir = ' . $openssldir . ';');
+ dofile(tools/c_rehash,'/usr/local/bin/perl','^#!/', '#!%s','^my
\$dir;$', 'my $dir = ' . $openssldir . ';', '^my \$prefix;$', 'my $prefix =
' . $prefix . ';');
dofile(apps/CA.pl,'/usr/local/bin/perl','^#!/', '#!%s');
}
if ($depflags ne $default_depflags !$make_depend) {
diff -up ./tools/c_rehash.in.orig ./tools/c_rehash.in
--- ./tools/c_rehash.in.orig2009-04-22 18:50:42.0 +0200
+++ ./tools/c_rehash.in 2010-04-12 18:23:39.0 +0200
@@ -7,6 +7,7 @@
my $openssl;
my $dir;
+my $prefix;
if(defined $ENV{OPENSSL}) {
$openssl = $ENV{OPENSSL};
@@ -24,7 +25,7 @@ if (defined(Cwd::getcwd)) {
}
my $path_delim = ($pwd =~ /^[a-z]\:/i) ? ';' : ':'; # DOS/Win32 or Unix
delimiter?
-$ENV{PATH} .= $path_delim$dir/bin;
+$ENV{PATH} = $prefix/bin . ($ENV{PATH} ? $path_delim . $ENV{PATH} : ); #
prefix our path
if(! -x $openssl) {
my $found = 0;
STORE question
Where can I get program example using ENGINE as STORE? Valery Blazhnov __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.0a-dev on VMS
Hello,
I have checked both the 1.0.0 and 0.9.8 20100414 snapshots and it look
much-much better.
Thank you very much Richard and Steven.
I got almost clean compile in both branches
On OPENSSL-098-STABLE-SNAP-20100414 got the following informational message and
a warning.
bss_dgram.c
if (timeleft.tv_sec 0)
^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression
timeleft.tv_sec is being compared with a relational op
erator to a constant whose value is not greater than zero. This might not be
what you intended.
at line number 220 in file
USRDSK:[ZAY.WORK.OPENSSL-098-STABLE-SNAP-20100414.CRYPTO.BIO]BSS_DGRAM.C;1
---
d1_both.c
item = pqueue_find(s-d1-buffered_messages, seq64be);
.^
%CC-W-CVTDIFTYPES, In this statement, seq64be of type pointer to unsigned
char, is being converted to unsigned lon
g long.
at line number 623 in file
USRDSK:[ZAY.WORK.OPENSSL-098-STABLE-SNAP-20100414.SSL]D1_BOTH.C;1
item = pitem_new(seq64be, frag);
.^
%CC-W-CVTDIFTYPES, In this statement, seq64be of type pointer to unsigned
char, is being converted to unsigned lon
g long.
at line number 679 in file
USRDSK:[ZAY.WORK.OPENSSL-098-STABLE-SNAP-20100414.SSL]D1_BOTH.C;1
%LIBRAR-W-COMCOD, compilation warnings in module D1_BOTH file
USRDSK:[ZAY.WORK.OPENSSL-098-STABLE-SNAP-20100414.IA64.OB
J.SSL]D1_BOTH.OBJ;1
-
On OPENSSL-100-STABLE-SNAP-20100414 got just the informational message. No harm
to keep it... but it improves the code if we fix it.
bss_dgram.c
if (timeleft.tv_sec 0)
^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression
timeleft.tv_sec is being compared with a relational op
erator to a constant whose value is not greater than zero. This might not be
what you intended.
at line number 226 in file
USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.CRYPTO.BIO]BSS_DGRAM.C;1
-
From other side the tests went fine as well, except that the SSLROOT
environment variable is not set correctly from the TESTS.COM causeing the
following error:
Testing key generation with NIST Binary-Curve B-571 ok
cat
2071080376:error:02001006:system library:fopen:no such device or
address:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100
414.CRYPTO.BIO]BSS_FILE.C;1:126:fopen('SSLROOT:[00]openssl.cnf','r')
2071080376:error:2006D002:BIO routines:BIO_new_file:system
lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.CRYPTO
.BIO]BSS_FILE.C;1:131:
2071080376:error:0E078002:configuration file routines:DEF_LOAD:system
lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-2010
0414.CRYPTO.CONF]CONF_DEF.C;1:199:
2071080376:error:02001006:system library:fopen:no such device or
address:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100
414.CRYPTO.BIO]BSS_FILE.C;1:126:fopen('SSLROOT:[00]openssl.cnf','r')
2071080376:error:2006D002:BIO routines:BIO_new_file:system
lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.CRYPTO
.BIO]BSS_FILE.C;1:131:
2071080376:error:0E078002:configuration file routines:DEF_LOAD:system
lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-2010
0414.CRYPTO.CONF]CONF_DEF.C;1:199:
%BACKUP-E-OPENIN, error opening
USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.TEST]P.TXT-CLEAR;1 as input
-RMS-E-FNF, file not found
...by using a more conventional approach SSLROOT is set correctly and ALL test
PASS happily :)
I have used the following patch in order to make it work.
TITAN2_ZAY $ diff .testtests.com;1 .testtests.com;5
File USRDSK:ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.TESTTESTS.COM;1
15 $ sslroot = f$parse(sys$disk:[-.apps];syntax_only) -
].;+ .]
16 $ define /translation_attributes = concealed sslroot 'sslroot'
**
File USRDSK:ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.TESTTESTS.COM;5
15 $ set default '__here'
16 $ set default [-.apps]
17 $ sslroot = f$parse( f$environment( default), , , ,
no_conceal)
18 $ sslroot = sslroot - ][ - .00 - ].; + .]
19 $ define /translation_attributes = concealed sslroot 'sslroot'
---
Unfortunately, the install (install.com) do not work at all.
The install directory structure is created, but, except for the include
directory, they are not populated.
Regards,
Z
-Original Message-
From: Dr. Stephen Henson [mailto:st...@openssl.org]
Sent: den 13 april 2010 17:03
To: openssl-dev@openssl.org
Cc: s...@antinode.info
Subject: Re: OpenSSL 1.0.0a-dev on VMS
On Tue, Apr 13, 2010, Richard Levitte wrote:
Steven
Re: [openssl.org #2233] [BUG] Checkin #19560 causes an DTLS bug
In my opinion the patch is also not necessary, because dtls1_buffer_message() requires a pointer to some 64 bit data to be used as the priority for the queue. However, s-s3-rrec.seq_num already is a pointer, since it is an array. Using (s-s3-rrec.seq_num) usually returns the same value, i.e. the pointer to the first value of the array, but I'm not sure if that's always the case. Regards, Robin On Apr 14, 2010, at 2:20 AM, Stephen Henson via RT wrote: Patch has already been reverted. Presumably the 0.9.8 one (Checkin #19561) is OK? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2230] [PATCH] DTLS reassembly
This patch appears to be broken on OpenSSL 0.9.8 it gives warnings: d1_both.c: In function ‘dtls1_reassemble_fragment’: d1_both.c:623: error: passing argument 2 of ‘pqueue_find’ makes integer from pointer without a cast ../include/openssl/pqueue.h:89: note: expected ‘long unsigned int’ but argument is of type ‘unsigned char *’ d1_both.c:679: error: passing argument 1 of ‘pitem_new’ makes integer from pointer without a cast ../include/openssl/pqueue.h:80: note: expected ‘long unsigned int’ but argument is of Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2230] [PATCH] DTLS reassembly
On Apr 14, 2010, at 2:20 PM, Stephen Henson via RT wrote:
This patch appears to be broken on OpenSSL 0.9.8 it gives warnings:
d1_both.c: In function ‘dtls1_reassemble_fragment’:
d1_both.c:623: error: passing argument 2 of ‘pqueue_find’ makes integer
from pointer without a cast
../include/openssl/pqueue.h:89: note: expected ‘long unsigned int’ but
argument is of type ‘unsigned char *’
d1_both.c:679: error: passing argument 1 of ‘pitem_new’ makes integer
from pointer without a cast
../include/openssl/pqueue.h:80: note: expected ‘long unsigned int’ but
argument is of
Sorry, my bad. I forgot the different pqueue priorities in 0.9.8...
Here is a patch to fix that.
Regards,
Robin
--- ssl/d1_both.c 14 Apr 2010 00:41:25 - 1.4.2.27
+++ ssl/d1_both.c 14 Apr 2010 12:48:59 -
@@ -599,7 +599,7 @@
hm_fragment *frag = NULL;
pitem *item = NULL;
int i = -1, is_complete;
- unsigned char seq64be[8];
+ PQ_64BIT seq64;
unsigned long frag_len = msg_hdr-frag_len, max_len;
if ((msg_hdr-frag_off+frag_len) msg_hdr-msg_len)
@@ -617,10 +617,10 @@
goto err;
/* Try to find item in queue */
- memset(seq64be,0,sizeof(seq64be));
- seq64be[6] = (unsigned char) (msg_hdr-seq8);
- seq64be[7] = (unsigned char) msg_hdr-seq;
- item = pqueue_find(s-d1-buffered_messages, seq64be);
+ pq_64bit_init(seq64);
+ pq_64bit_assign_word(seq64, msg_hdr-seq);
+ item = pqueue_find(s-d1-buffered_messages, seq64);
+ pq_64bit_free(seq64);
if (item == NULL)
{
@@ -672,11 +672,11 @@
if (item == NULL)
{
- memset(seq64be,0,sizeof(seq64be));
- seq64be[6] = (unsigned char)(msg_hdr-seq8);
- seq64be[7] = (unsigned char)(msg_hdr-seq);
+ pq_64bit_init(seq64);
+ pq_64bit_assign_word(seq64, msg_hdr-seq);
+ item = pitem_new(seq64, frag);
+ pq_64bit_free(seq64);
- item = pitem_new(seq64be, frag);
if (item == NULL)
{
goto err;
dtls-reassembly-bug-bug-0.9.8.patch
Description: Binary data
[openssl.org #2233] [BUG] Checkin #19560 causes an DTLS bug
[seggelm...@fh-muenster.de - Wed Apr 14 12:08:30 2010]: In my opinion the patch is also not necessary, because dtls1_buffer_message() requires a pointer to some 64 bit data to be used as the priority for the queue. However, s-s3-rrec.seq_num already is a pointer, since it is an array. Using (s-s3- rrec.seq_num) usually returns the same value, i.e. the pointer to the first value of the array, but I'm not sure if that's always the case. Err it is of type PQ_64BIT in 0.9.8 and not an array. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: question regarding crypto\bio\bio_lib.c and num_read
I think, it could be a bug, not yet noted by others because never used num_read. Regards, M.M. Ray Satiro schrieb: Both BIO_write() and BIO_puts() increment num_write on success. But BIO_gets() by all appearances does not increment num_read, only BIO_read() does. I don't see why that omission in BIO_gets() would be intentional. Any thoughts? Thanks, Jay __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2233] [BUG] Checkin #19560 causes an DTLS bug
On 14.04.2010, at 15:35, Stephen Henson via RT wrote: [seggelm...@fh-muenster.de - Wed Apr 14 12:08:30 2010]: In my opinion the patch is also not necessary, because dtls1_buffer_message() requires a pointer to some 64 bit data to be used as the priority for the queue. However, s-s3-rrec.seq_num already is a pointer, since it is an array. Using (s-s3- rrec.seq_num) usually returns the same value, i.e. the pointer to the first value of the array, but I'm not sure if that's always the case. Err it is of type PQ_64BIT in 0.9.8 and not an array. Yes, but the dtls1_buffer_message() function uses a PQ_64BIT pointer to pass a PQ_64BIT struct, which is accessed directly. However, passed is just the pointer to the array which holds the sequence number. This is not very elegant but seems to work. The patch recently submitted only changed s-s3-rrec.seq_num to (s-s3-rrec.seq_num) when passing it to the buffering function. Since seq_num is an array and therefore interpreted as a pointer to the first element this was ok. It was simply used as if it were a pointer to an PQ_64BIT struct. Changing it to (s-s3-rrec.seq_num) only results in passing the very same pointer to the buffering function. This is because the compiler also interprets this as a pointer to the first element of the array. However, I don't know if this is the case with every compiler because we didn't find this construct in the C specification, i.e. referencing an array pointer. I expected it to be the pointer to the pointer to the first element of the a rray, which it is not for some reason. So I still recommend not to change it and revert the patch for 0.9.8 as well to be sure it keeps working or change it to create a real PQ_64BIT struct which is then passed to the buffering function. Regards, Robin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2233] [BUG] Checkin #19560 causes an DTLS bug
[seggelm...@fh-muenster.de - Wed Apr 14 18:03:15 2010]: Yes, but the dtls1_buffer_message() function uses a PQ_64BIT pointer to pass a PQ_64BIT struct, which is accessed directly. However, passed is just the pointer to the array which holds the sequence number. This is not very elegant but seems to work. The patch recently submitted only changed s-s3-rrec.seq_num to (s-s3- rrec.seq_num) when passing it to the buffering function. Since seq_num is an array and therefore interpreted as a pointer to the first element this was ok. It was simply used as if it were a pointer to an PQ_64BIT struct. Changing it to (s-s3- rrec.seq_num) only results in passing the very same pointer to the buffering function. This is because the compiler also interprets this as a pointer to the first element of the array. However, I don't know if this is the case with every compiler because we didn't find this construct in the C specification, i.e. referencing an array pointer. I expected it to be the pointer to the pointer to the first element of the array, which it is not for some reason. So I still recommend not to change it and revert the patch for 0.9.8 as well to be sure it keeps working or change it to create a real PQ_64BIT struct which is then passed to the buffering function. As I said the 1.0.0 change has been reverted and I'm referring only to the 0.9.8 patch. The original 0.9.8 patch was made because it broke the VMS compile. If you revert it in 0.9.8 you get this warning under Unix: gcc -I../crypto -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED -m64 -DL_ENDIAN -DTERMIO -DCONF_DEBUG -DDEBUG_SAFESTACK -g -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -c -o d1_pkt.o d1_pkt.c cc1: warnings being treated as errors d1_pkt.c: In function ‘dtls1_get_record’: d1_pkt.c:628: error: passing argument 3 of ‘dtls1_buffer_record’ makes pointer from integer without a cast d1_pkt.c:168: note: expected ‘long unsigned int *’ but argument is of type ‘long unsigned int’ d1_pkt.c: In function ‘dtls1_read_bytes’: d1_pkt.c:768: error: passing argument 3 of ‘dtls1_buffer_record’ makes pointer from integer without a cast d1_pkt.c:168: note: expected ‘long unsigned int *’ but argument is of type ‘long unsigned int’ make[1]: *** [d1_pkt.o] Error 1 make[1]: Leaving directory `/home/steve/src/ossl8/ssl' make: *** [build_ssl] Error 1 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2235] Resolved: Minor fix to crypto/ts/Makefile
According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0a-dev on VMS
From: Dr. Stephen Henson st...@openssl.org Please check the 0.9.8 snapshots too. Perhaps when I work up more courage. If there are any minor issues which someone VMS illiterate (i.e. me) can understand I'll fix them. I'm still wondering why this symlink is in apps: md4.c - ../crypto/md4/md4.c Formerly, it was supplied in the source kit. Now it appears to be generated. Does anyone use it? The top VMS builder (makevms.com) dutifully makes a copy, but I don't see it used anywhere in the VMS builders. More VMS-specific: makevms.com: I'm sure that there was some excellent reason to move the generated header files (BUILDINF.H, OPENSSLCONF.H) from their old location, [.arch.CRYPTO], to the new one, [.crypto._arch] (where arch is ALPHA, IA64, or VAX), but it wasn't obvious to me. I thought that using the old, sequestered [.arch...] tree made sense, and had the advantage of making clean-up simpler. This change, by the way is what hosed the installation procedure ([.crypto]install.com), which wasn't notified of the change: [...] Installing CRYPTO files. [...] %COPY-E-OPENIN, error opening ALP$DKA100:[UTILITY.SOURCE.OPENSSL.OPENSSL-1^.0^.0 -STABLE-SNAP-20100414.ALPHA.CRYPTO]OPENSSLCONF.H; as input -RMS-E-DNF, directory not found -SYSTEM-W-NOSUCHFILE, no such file [...] (Oh, _now_ I see. This (annoying) change would allow the deletion of a few lines of DCL in [.crypto]install.com. But they weren't deleted.) --- crypto/install.com_orig 2010-01-29 06:03:46 -0600 +++ crypto/install.com 2010-04-14 17:45:21 -0500 @@ -120,12 +120,12 @@ $ THEN $COPY 'tmp' WRK_SSLINCLUDE: /LOG $ ELSE -$IF D .EQS. _''ARCH' -$THEN -$ COPY [-.'ARCH'.CRYPTO]'tmp' WRK_SSLINCLUDE: /LOG -$ELSE +$!!! IF D .EQS. _''ARCH' +$!!! THEN +$!!! COPY [-.'ARCH'.CRYPTO]'tmp' WRK_SSLINCLUDE: /LOG +$!!! ELSE $ COPY [.'D']'tmp' WRK_SSLINCLUDE: /LOG -$ENDIF +$!!! ENDIF $ ENDIF $ SET FILE/PROT=WORLD:RE WRK_SSLINCLUDE:'tmp' $ GOTO LOOP_SDIRS Not, in my opinion, a good trade, even when done correctly. Steven M. Schweda s...@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0a-dev on VMS (v. HP-UX ia64)
If there are any minor issues which someone VMS illiterate (i.e. me) can understand I'll fix them. By the way, speaking of non-VMS stuff, in case anyone cares, ... dyi # uname -a HP-UX dyi B.11.31 U ia64 4235313755 unlimited-user license dyi # gcc --version gcc (GCC) 4.3.3 [...] [...] gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -mlp64 -O3 -DB_ENDIAN -D_REENTRANT -DOPENSSL_EXPERIMENTAL_JPAKE -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -E asm/md5-ia64.S | \ /usr/bin/perl -ne 's/;\s+/;\n/g; print;' md5-ia64.s gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -mlp64 -O3 -DB_ENDIAN -D_REENTRANT -DOPENSSL_EXPERIMENTAL_JPAKE -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -c -o md5-ia64.o md5-ia64.s asm/md5-ia64.S: Assembler messages: asm/md5-ia64.S:1041: Warning: `md5digestBlock1' was not specified with previous .proc asm/md5-ia64.S:1041: Warning: `md5_digest_block1' should be an operand to this .endp asm/md5-ia64.S:1164: Warning: `md5digestBlock2' was not specified with previous .proc asm/md5-ia64.S:1164: Warning: `md5_digest_block2' should be an operand to this .endp asm/md5-ia64.S:1287: Warning: `md5digestBlock3' was not specified with previous .proc asm/md5-ia64.S:1287: Warning: `md5_digest_block3' should be an operand to this .endp [...] Only warnings, but they might be easy to remove (unless some other assembler would complain). Steven M. Schweda s...@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Information wanted on OpenSSL cipher alias HIGH, MEDIUM and LOW.
Hi All, I wanted to know when we use ALL:!SSLv2:!EXPORT:!LOW:!MEDIUM:!DH to select the ciphers how do OpenSSL understands what are ciphers are available under LOW and MEDIUM. Ssleay.txt documents names LOW,MEDIUM and HIGH as aliases. Please can someone provide me more information on this? Thanks in advance Jayalakshmi. smime.p7s Description: S/MIME cryptographic signature
PEM reads entire file before failing
I've noticed when calling PEM_read_bio_X509() on a bogus file it has to read *the entire file* before it fails and returns NULL, whereas other functions like d2i_PKCS7_bio and d2i_PKCS12_bio() fail after reading just a small amount. Can we fix the PEM functions to fail sooner? Why can't they tell after reading the first line that it doesn't start with -BEGIN? Or after each line why can't it tell that it's not valid base64 data? I'm writing a function that detects the cert type automatically by calling various OpenSSL read functions like the ones I've mentioned above, and it can be very slow to return not a cert on large non-cert files. Thanks, Phillip
