Re: [openssl.org #85] 0.9.7 prototype constification problems
On Mon, Jun 17, 2002 at 07:02:45PM +0100, Ben Laurie wrote: Avery Pennarun via RT wrote: On Mon, Jun 17, 2002 at 11:19:31AM +0200, Bodo Moeller wrote: Good question, but this problem does not appear to apply to C, and anyway it only makes *existing* code uglier -- for new code, the modified API makes more sense (the encoded data can be in 'const unsigned char' arrays all the time). If you don't want #ifdefs and casts throughout your code, please consider hiding this in wrapper functions. Hmm, okay, I'm not really convinced, but now that I see it doesn't cause C programs to not compile, I think it's okay to accept the small number of openssl-using C++ programs that will need changes because of this. Hmm, well, I'm not, because all right-thinking projects have a zero-warnings policy. OpenSSL included. The old API is not perfect when the data is located in a 'const' array, the new API is not perfect when the data is located in a non-'const' array. C++ code can be written to match either the old or the new API; with the wrong API, you can have either zero warnings or zero casts, not both. As those functions are not really supposed to modify the data, the 'const' variant appears to be the right one. -- 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]
[openssl.org #102] Problem: aes_locl.h on Windows
I have totally removed that '#ifdef' condition, now we include string.h on all systems (which is what we do in most other header files anyway, so this cannot break anything unless it is broken elsewhere too). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
djgpp patches
Thanks a lot to Doug Kaufmann for the MSDOS patches for djgpp. But one thing I don't understand. In ./crypto/bn/bn_mul.c: #if defined(OPENSSL_NO_ASM) || !(defined(__i386) || defined(__i386__)) || \ defined(__DJGPP__) /* Assembler implementation exists only for x86 */ I haven't studied the Makefiles, but surely djgpp target should use the assembly version in bn-586.pl? Otherwise, simpy defining OPENSSL_NO_ASM for djgpp should be enough. Gisle V. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #104] Make fails with undefined reference
On Mon, Jun 17, 2002 at 07:43:18PM +0200, [EMAIL PROTECTED] via RT wrote: redhat linux never upgraded libraries are rpm's glibc-2.1.92-14 and glibc-devel-2.1.92-14. it's redhat 7.0. I think sysconf is unistd.h. Some other headers are in /usr/i386-glibc21-linux/include, and since I'm not much of a programmer I don't know if they're important or not I dc. i don't even know if that's really old enough to upgrade. anyhow, i don't think it was in an archive of the mailing list, so that's why I posted it. I added it to the Request Tracker, as on standard platforms ./config should detect enough of the settings that compilation should succeed. I consider Redhat Linux to be kind of standard enough. Does anybody know the resolution of this problem? 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: cvs commit: openssl/crypto/evp c_all.c evp.h
Lutz Jaenicke schrieb:
On Sat, Jun 15, 2002 at 01:01:08AM +0200, Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Fri, 14 Jun 2002
20:59:59 +0200 (MET DST), [EMAIL PROTECTED] said:
jaenicke diff -u -r1.7.8.1 -r1.7.8.2
jaenicke --- c_all.c 2002/02/23 02:09:25 1.7.8.1
jaenicke +++ c_all.c 2002/06/14 18:59:53 1.7.8.2
jaenicke @@ -61,6 +61,7 @@
jaenicke#include openssl/evp.h
jaenicke
jaenicke#undef OpenSSL_add_all_algorithms
jaenicke +void OpenSSL_add_all_algorithms(void);
jaenicke
jaenickevoid OpenSSL_add_all_algorithms(void)
jaenicke {
Please explain why you need to declare that function just before you
define it. I can't see how that makes sense...
This was done by Goetz's patch. I have also seen gcc complain about functions
without prototype just when they where defined.
Building OpenSSL with debug (at least on linux)
will generate build lines like
gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -DOPENSSL_NO_KRB5
-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -ggdb
-g2 -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations
-Werror -c -o hw_ncipher.o hw_ncipher.c
and the -Wmissing-declarations with the -Werror will
terminate the build process on not declared functions.
They have to either be declared or static...
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
smime.p7s
Description: S/MIME Cryptographic Signature
Re: cvs commit: openssl/crypto/evp c_all.c evp.h
On Tue, Jun 18, 2002 at 01:38:45PM +0200, Götz Babin-Ebell wrote: Building OpenSSL with debug (at least on linux) will generate build lines like gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -DOPENSSL_NO_KRB5 -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -ggdb -g2 -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations -Werror -c -o hw_ncipher.o hw_ncipher.c and the -Wmissing-declarations with the -Werror will terminate the build process on not declared functions. They have to either be declared or static... The problem should now be solved in 0.9.7-beta2, did you try? 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 #85] 0.9.7 prototype constification problems
Bodo Moeller wrote: On Mon, Jun 17, 2002 at 07:02:45PM +0100, Ben Laurie wrote: Avery Pennarun via RT wrote: On Mon, Jun 17, 2002 at 11:19:31AM +0200, Bodo Moeller wrote: Good question, but this problem does not appear to apply to C, and anyway it only makes *existing* code uglier -- for new code, the modified API makes more sense (the encoded data can be in 'const unsigned char' arrays all the time). If you don't want #ifdefs and casts throughout your code, please consider hiding this in wrapper functions. Hmm, okay, I'm not really convinced, but now that I see it doesn't cause C programs to not compile, I think it's okay to accept the small number of openssl-using C++ programs that will need changes because of this. Hmm, well, I'm not, because all right-thinking projects have a zero-warnings policy. OpenSSL included. The old API is not perfect when the data is located in a 'const' array, the new API is not perfect when the data is located in a non-'const' array. C++ code can be written to match either the old or the new API; with the wrong API, you can have either zero warnings or zero casts, not both. As those functions are not really supposed to modify the data, the 'const' variant appears to be the right one. Fair enough. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #105] Problem build 0.9.7 SNAP with ./Configure debug
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #98] Re: OpenSSL engine ctrl: handling of strings
Lutz Jaenicke schrieb:
On Sat, Jun 15, 2002 at 07:38:40PM -0400, Geoff Thorpe wrote:
On Fri, 14 Jun 2002, [ISO-8859-15] Götz Babin-Ebell wrote:
In the ..._ctrl()-Function of the engines a passed string
is only referenced and not copyed.
This is bad if the buffer with the passed data is overwritten...
[snip]
Could you please;
(a) put this into the bug-tracker,
I have already bounced the report into the request tracker when I read it.
(It was assigned ticket #98.)
(b) use -u context diffs so they're easier to follow
That's indeed true.
Sorry for that. (Please see attachment)
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
diff -u -r openssl-0.9.7-stable-SNAP-20020618/crypto/engine/eng_dyn.c
openssl-0.9.7-stable-SNAP-20020618_new/crypto/engine/eng_dyn.c
--- openssl-0.9.7-stable-SNAP-20020618/crypto/engine/eng_dyn.c Thu Nov 22 11:08:49
2001
+++ openssl-0.9.7-stable-SNAP-20020618_new/crypto/engine/eng_dyn.c Tue Jun 18
+14:08:05 2002
-157,6 +157,10
dynamic_data_ctx *ctx = (dynamic_data_ctx *)ptr;
if(ctx-dynamic_dso)
DSO_free(ctx-dynamic_dso);
+if (ctx-DYNAMIC_LIBNAME)
+ OPENSSL_free((void*)(ctx-DYNAMIC_LIBNAME));
+if (ctx-engine_id)
+ OPENSSL_free((void*)(ctx-engine_id));
OPENSSL_free(ctx);
}
}
-169,7 +173,7
{
dynamic_data_ctx *c;
c = OPENSSL_malloc(sizeof(dynamic_data_ctx));
- if(!ctx)
+ if(!c)
{
ENGINEerr(ENGINE_F_SET_DATA_CTX,ERR_R_MALLOC_FAILURE);
return 0;
-310,8 +314,13
/* a NULL 'p' or a string of zero-length is the same thing */
if(p (strlen((const char *)p) 1))
p = NULL;
- ctx-DYNAMIC_LIBNAME = (const char *)p;
- return 1;
+if (ctx-DYNAMIC_LIBNAME)
+ OPENSSL_free((void*)(ctx-DYNAMIC_LIBNAME));
+if (p)
+ ctx-DYNAMIC_LIBNAME = BUF_strdup(p);
+else
+ ctx-DYNAMIC_LIBNAME = NULL;
+return ctx-DYNAMIC_LIBNAME != NULL ? 1 : 0;
case DYNAMIC_CMD_NO_VCHECK:
ctx-no_vcheck = ((i == 0) ? 0 : 1);
return 1;
-319,8 +328,13
/* a NULL 'p' or a string of zero-length is the same thing */
if(p (strlen((const char *)p) 1))
p = NULL;
- ctx-engine_id = (const char *)p;
- return 1;
+if (ctx-engine_id)
+ OPENSSL_free((void*)(ctx-engine_id));
+if (p)
+ ctx-engine_id = BUF_strdup(p);
+else
+ ctx-engine_id = NULL;
+return ctx-engine_id != NULL ? 1 : 0;
case DYNAMIC_CMD_LIST_ADD:
if((i 0) || (i 2))
{
diff -u -r openssl-0.9.7-stable-SNAP-20020618/crypto/engine/hw_4758_cca.c
openssl-0.9.7-stable-SNAP-20020618_new/crypto/engine/hw_4758_cca.c
--- openssl-0.9.7-stable-SNAP-20020618/crypto/engine/hw_4758_cca.c Wed May 22
10:03:17 2002
+++ openssl-0.9.7-stable-SNAP-20020618_new/crypto/engine/hw_4758_cca.c Tue Jun 18
+14:08:28 2002
-124,8 +124,27
/* static variables */
/*--*/
-static const char def_CCA4758_LIB_NAME[] = CCA_LIB_NAME;
-static const char *CCA4758_LIB_NAME = def_CCA4758_LIB_NAME;
+static const char *CCA4758_LIB_NAME = NULL;
+static const char *get_CCA4758_LIB_NAME()
+{
+ if (CCA4758_LIB_NAME)
+ return CCA4758_LIB_NAME;
+ else
+ return CCA_LIB_NAME;
+}
+static void free_CCA4758_LIB_NAME()
+{
+ if (CCA4758_LIB_NAME)
+ OPENSSL_free((char*)CCA4758_LIB_NAME);
+ CCA4758_LIB_NAME = NULL;
+}
+static long set_CCA4758_LIB_NAME(const char *newName)
+{
+ if (CCA4758_LIB_NAME)
+ OPENSSL_free((char*)CCA4758_LIB_NAME);
+ return (CCA4758_LIB_NAME = BUF_strdup(newName)) != NULL ? 1 : 0;
+}
+
#ifndef OPENSSL_NO_RSA
static const char* n_keyRecordRead = CSNDKRR;
static const char* n_digitalSignatureGenerate = CSNDDSG;
-232,6 +251,7
static int ibm_4758_cca_destroy(ENGINE *e)
{
ERR_unload_CCA4758_strings();
+free_CCA4758_LIB_NAME();
return 1;
}
-243,7 +263,7
goto err;
}
- dso = DSO_load(NULL, CCA4758_LIB_NAME , NULL, 0);
+ dso = DSO_load(NULL, get_CCA4758_LIB_NAME() , NULL, 0);
if(!dso)
{
CCA4758err(CCA4758_F_IBM_4758_CCA_INIT,CCA4758_R_DSO_FAILURE);
-299,7 +319,8
static int ibm_4758_cca_finish(ENGINE *e)
{
- if(dso)
+ free_CCA4758_LIB_NAME();
+ if(!dso)
{
CCA4758err(CCA4758_F_IBM_4758_CCA_FINISH
Re: djgpp patches
On Tue, 18 Jun 2002, Gisle Vanem wrote:
Thanks a lot to Doug Kaufmann for the MSDOS patches for djgpp. But one thing I don't
understand. In ./crypto/bn/bn_mul.c:
#if defined(OPENSSL_NO_ASM) || !(defined(__i386) || defined(__i386__)) || \
defined(__DJGPP__) /* Assembler implementation exists only for x86 */
I haven't studied the Makefiles, but surely djgpp target should use the assembly
version
in bn-586.pl? Otherwise, simpy defining OPENSSL_NO_ASM for djgpp should be enough.
You can make DJGPP use the assembly routines by changing Configure
values for DJGPP to show ${x86_out_asm} in the eighth field of
config-string. Then the build will fail bacause of the TYPE and SIZE
macros. I suspect it will work with these defined to null as in the
recent patch I submitted for Cygwin [openssl.org #76]. I haven't had
a chance to check this yet. Before doing this routinely for DJGPP, we
should probably verify that there are no instructions that won't work
on a 386 processor. Otherwise tha code won't be portable to many of
the low-powered machines (i.e. 386 and 486 processors) that run DOS.
I was worried that the name bn-586.pl might imply instructions
requiring at least a 586 processor.
Doug
__
Doug Kaufman
Internet: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Building Shared library on QNX for Openssl 9.6d
Hello Prashant, Tuesday, June 18, 2002, 12:21:58 AM, you wrote: PK Hello Group, PK How can I configure OpenSsl to build shared library (.so) on QNX 6 PK Operating PK System. Have you tried ./config shared -- Best regards, Henrimailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #107] pb installing OpenSSL 0.9.7 beta2 on W2000
Hi I have difficulties to install Openssl 0.9.7 beta2 on a W2000 platform (for VC++ without using assembly) the ntdll.mak generated by the do_ms command seems erroneous : some lines are broken : SSL OBJ=$(OBJ_D)\ssl.obj \ CRYPTO OBJ=$(OBJ_D)\crypto.obj \ (instead of SSLOBJ=... I suppose) and all the paragraph wich copy include files seems wrong, with command like : $(INCL_D)\cryptlib.h: $(SRC_D)\\cryptlib.h $(CP) $(SRC_D)\\cryptlib.h $(INCL_D)\cryptlib.h (I suppose that some directory is missing in $(SRC_D)\?\cryptlib.h) Regards Francois __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: djgpp patches
On Tue, 18 Jun 2002, Doug Kaufman wrote: a chance to check this yet. Before doing this routinely for DJGPP, we should probably verify that there are no instructions that won't work on a 386 processor. Otherwise tha code won't be portable to many of the low-powered machines (i.e. 386 and 486 processors) that run DOS. I was worried that the name bn-586.pl might imply instructions requiring at least a 586 processor. I think it's just optimised for a Pentium. Not that Pentium instructions are used. Gisle V. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #108] Need Help
Hello there, I have dowloaded an openssl-0.9.6D and openssl-engine-0.9.6D. However, I am having a problem using this program. What do I need to do in order to be able to convert a certificate from a . PFX file to a .PEM file ? or where can I get some documentation on how to use this program ? I am currently using a windows 2000 workstation. Thank you. Tonny __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #108] Need Help
The handling of PKCS12 et al is explained in Steve Henson's excellent FAQ: http://www.drh-consultancy.demon.co.uk/pkcs12faq.html Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #98] OpenSSL engine ctrl: handling of strings
Hi there, OK, finally got round to taking a look at this ticket [#98] - apologies for the delay on my part. [[EMAIL PROTECTED] - Fri Jun 14 21:37:50 2002]: There is a possible problem with the string param handling of ENGINE_ctrl(): (At least I will get a problem...) In the ..._ctrl()-Function of the engines a passed string is only referenced and not copyed. This is bad if the buffer with the passed data is overwritten... Since in the BIO interface passed string params are copied to an internal (allocated) buffer (at least in the modules I checked...), the ENGINE -interface should act the same way. I'm not sure I understand how this can be a generic problem. If an ENGINE implementation intends to store passed strings, ie. for use after the ENGINE_ctrl() command in question has returned, then it should surely be making a local copy? There are two points that leap to mind; (1) Only the ENGINE implementor knows if he/she only needs the string value during the ctrl() call or whether he/she intends to use the string value at a later time - so he/she should be deciding whether a copy is required or not. (2) If a copy was to be made by the framework for passing to the ENGINE's ctrl() handler, where would it be stored? Moreover, when/how would it be cleaned up? Then again, perhaps I haven't fully understood the problem you see. Please illustrate the potential if I have and I'll take a closer look. NB: My inability to grok the problem isn't helped by the fact that I can't read that diff format, perhaps that makes me a fake hacker? :-) Could you please resubmit the patch in diff -u form if you still think I need to examine it in fine detail. Regards, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #11] Fw: trustway pkcs11 engine for openssl
Hi there, Just a couple of thoughts on this ticket [#11].. [[EMAIL PROTECTED] - Thu May 30 17:39:08 2002]: Richard Levitte via RT [EMAIL PROTECTED] writes: 1. could this engine be considered a general PKCS#11 engine, or are there specific ties to Trustway. I'd prefer to see a general PKCS#11 engine. This engine is a general PKCS#11 engine. I tested it first with the PKCS#11 library developped by Lutz Behnke (libgpkcs11.so) and its software token (libceay_tok.so). It is possible to make a general PKCS#11 engine and just put specific ties, if any, for multiple hardwares. In Trustway case, the only specific tie is the name of PKCS#11 library to load and some controls added when loading it. Our code depends on gpkcs11 include files (cryptoki.h, pkcs11.h, ...); it is possible to add them to our patch. It would be great to have a generic pkcs#11 ENGINE going into the base openssl source, certainly moreso than having a new one added for each particular implementation/token type. W.r.t. requiring different controls, well yes - that's the whole point of having string-based controls for ENGINEs, it lets the user/admin get any kind of settings through to any kind of ENGINE without OpenSSL having to understand it all. With Steve's recent work on (auto)configuration through openssl.cnf, arbitrary controls can be specified for loading/configuring ENGINEs on initialisation. For a generic pkcs11 ENGINE, one of these controls of course would identify the library/driver/token/location of the corresponding device. 2. Those extra functions in the RSA method, are they really needed? I understand that they provide a lot of automagic things, but then it should be added in the ENGINE framework as something that would be potentially available for any hardware (that supports that extra functionality). Also, when it comes to loading keys, the current modus operandi is to explicitely use the ENGINE key loading functions rather than having some implicit functionality going on. The reason is that we'd prefer not to surprise the users too much. The Bull Trustway CC2000 isn't only a cryptographic accelerator card, it is a high level security hardware providing key generation and storage in secure memory. That's why we can't use ENGINE key loading functions. Yes those extra functions are really needed when using this kind of hardware. I'm not convinced - the nCipher support in OpenSSL works fine with their HSM keys. As for adding key generation and/or key-loading changes to *generic* parts of OpenSSL - I would much prefer we keep that issue orthogonal to the ENGINE implementations for now. Adding/changing ENGINEs is a localised process with virtually zero regression risk. Meddling with generic code risks affecting oodles of apps and users who don't even care about ENGINEs, hardware, etc. And yes I agree, they don't know what they're missing out on, but nonetheless we need to treat ENGINE development differently to how we approach changing non-ENGINE APIs. Anyhow - right now it makes sense for hardware key-generation to be handled by external hardware-specific utilities. The possible configuration requirements for arbitrary hardware is too vague to define in general terms, for now at least, and people using hardware need to have hardware-specific drivers and support software anyhow - so why not put hardware-specific key-gen utils in there with that? NB: That's not to say that some of the other points aren't important - I agree completely that it would be useful for RSA classes (ie. ENGINE implementations of RSA_METHOD) to have their own key-gen callback. For one thing, this would make it possible to have hardware-generated (and perhaps hardware-protected too) keys used as ephemeral/temporary keys in SSL/TLS cipher-suites. However that would immediately require that the ENGINE knows how to generate generic keys because you cannot possibly ask the admin to enter a smart-card and/or PIN when an in-progress SSL handshake needs an ephemeral key ... general hardware key generation could require anything the manufacturer manages to dream up; biometrics, smart cards, PINs, luck, and other equally useful tools of the trade (no cynicism, of course:-). Could you possibly resubmit a non-intrusive version of your pkcs11 engine implementation (ie. without changing other openssl code) and I'll look at integrating it. That at least will give us a base of code in the CVS snapshots for us and everyone else to work from. Perhaps a bit further down the line, we could look at opening up a independant ticket and discussion about changes to the OpenSSL APIs (extending RSA_METHOD, etc), but I don't think they need affect PKCS11 support for now. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated
[openssl.org #86] Bug in RSA_check_key
Hi there, I've taken ownership of this ticket (#86) for now, but I don't think it'll last long. IMHO, this bug is not a bug. If you look at the implementation of RSA_check_key() you'll realise that this function is designed to test an RSA key structure - not just the essential key elements (n,e,d) but all the performance-enhancing extras too; the primes and the CRT bits. This function is not useful on public keys nor is it useful on HSM keys, for obvious reasons. Why are you calling this function when using a hardware key? If you want to provide a convincing argument for why an alternative key check function might be useful, we could perhaps look at supplementing the API insteal. Eg. are you looking for something like; RSA_check_public_key()? Right now I can't see the current behaviour of RSA_check_key() as representing a bug. It may not be intuitive, but I'm reluctant to change the behaviour of the existing API function (breaking compatibility) for that reason alone. I have changed the status of this ticket to 'stalled', but will refrain from closing it for now. OTOH: if you agree with my interpretation, please let me know and I'll close this. Regards, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #86] Bug in RSA_check_key
This sounds like the same old problem with passing an RSA public key to this function and getting a segv, which seems to bite new users quite often. Can this function be fixed to do a sanity check on the key before proceeding? I assume it's the same with a hardware key. If a user ends up with an RSA key (public, private, or HSM), how are they to know whether they can safey call this function? Do they need intimate enough knowledge of the RSA structure to check if d is NULL, or check some flag to determine if it's a hardware key? Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_read behavior
Now that openssl sends a empty record as part of the known IV attack fix, I noticed that SSL_read returns -1 if the only record available is one without a body (our setup uses mem BIOs). Is this behavior desirable? It seems to me that returning 0 would make more sense. Also, if this is the way things should be, is the right way to check that everything is ok when receiving a -1 to call BIO_should_retry on the read bio? /Sam __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
