Re: [openssl.org #97] About 0.9.6a(b) and des_encrypt1()

On Wed, 8 Aug 2001, [iso-8859-1] Götz Babin-Ebell wrote: Richard Levitte - VMS Whacker wrote: Hmm, it feels like it's really time for a rename (basically, change des to DES in all names, and thereby follow the convention used everywhere else in OpenSSL), or this becomes an impossible

[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

[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

[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

[openssl.org #98] OpenSSL engine ctrl: handling of strings

Hi, [snip] 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

[openssl.org #25] [patch] SSL.cert_store

Hi Doug (and anyone else following this ticket) [[EMAIL PROTECTED] - Tue May 7 21:46:52 2002]: [snip] i saw references to a STATUS file in the mail archives that ralf was working on this, but doesn't seem to have happened yet. the simple patch below implements the required functions to

[openssl.org #86] Bug in RSA_check_key

Just attaching a little more state to this ticket ... [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. I don't call RSA_check_key for a hardware key, I call it for my CA private

[openssl.org #59] 0.9.7 EVP manual pages incomplete

G'day, [levitte - Thu Jul 18 20:55:58 2002]: I just did a tentative addition of history. Please check it and complete it if needed. Yup the history stuff looks great, thanks Richard. However I'm not sure who understands the EVP behavioural changes well enough to comment/document them

[openssl.org #86] Bug in RSA_check_key

OK, I'm going to close this ticket down now as we have at least solved the bug, albeit that it was a bit of a short-cut ... we documented the existing behaviour rather than changing it :-) If anyone feels strongly that this is not resolved until RSA_check_key() is modified to use a new

[openssl.org #156] Bugs in doc/crypto/{DH,DSA,RSA}_set_method.pod and doc/crypto/{dh,dsa,rsa}.pod

I'm taking a look at this now ... please hold off on reverting back to 0.9.6 (non-engine) versions of the docs until I get my head around it again (I haven't looked at this stuff for a while) ... Cheers, Geoff -- Geoff Thorpe, RT/openssl.org

[openssl.org #212] SSL_CTX_flush_sessions() must be called before SSL_CTX_free().

[[EMAIL PROTECTED] - Mon Aug 12 13:15:25 2002]: It looks to me like SSL_CTX_flush_sessions() must be always called just before SSL_CTX_free() if session caching callback functions are installed. There appears to be a bug in SSL_CTX_free(): ...

[openssl.org #311] Memory leak in session caching?

I've committed a fix for this that the requestor has tested, so I'm closing the ticket as well. -- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL

[openssl.org #156] Bugs in doc/crypto/{DH,DSA,RSA}_set_method.pod and doc/crypto/{dh,dsa,rsa}.pod

I committed fixes for all this stuff quite some time ago but forgot to close the ticket ... -- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL

[openssl.org #25] [patch] SSL.cert_store

Well, I've had no reply from Doug MacEachern about this ticket. Without it being resubmitted with a CC to the American icon of legal common sense (the BXA), I can't really (read: won't) touch it. If anyone's got any better ideas (or lives next door to Doug), please let me know. Cheers, Geoff

[openssl.org #59] 0.9.7 EVP manual pages incomplete

I'm closing this ticket now. Things seem to be in order - if not, someone should open a new ticket with specific pointers to what it is they feel is wrong/missing. Steve-H also took a quick glance at the man pages and didn't see anything amiss. --

[openssl.org #401] Bug in openssl-0.9.7-stable install_docs (head3)

I am still trying to figure out whether the base pod version we support can be bumped to support 4 levels of header rather than 2. In the mean time, I've replaced the =head3 tags in the 0.9.7-stable branch with I.. tags. I will leave this ticket open, and attempt to rebadge it with a 0.9.8

[openssl.org #475] [Fwd: patch to 0.9.7 -performacne]

As mentioned in ticket 489 (which is now closed), this ticket was not forgotten, it is waiting on the patch being submitted with a copy to the appropriate US agencies. For the patch itself, I'm not sure about the location (or necessity) of _method_mod_n initialisation you've inserted - but I'll

[openssl.org #475] [Fwd: patch to 0.9.7 -performacne]

[[EMAIL PROTECTED] - Tue Feb 4 18:36:33 2003]: Attached is my patch to openssl 0.9.7. This message is CC'ed to the appropriate US gov't parties. OK. Thanks David for sorting out the US obligations, and for bringing the missing _method_mod_n initialisation to our attention. I've attached an

[openssl.org #276] How to get session id for external session cache in openssl

[jaenicke - Tue Sep 10 08:58:13 2002]: --snip-- I have thus bounced your mail into the request tracker, such that a suitable API will be added. (just dredging through some older tickets ...) I've attached an ultra-simple suggestion (the attached diff probably won't propogate to openssl-dev

[openssl.org #276] How to get session id for external session cache in openssl

[geoff - Wed Feb 5 01:37:55 2003]: --snip-- request tracker). Anyway, does this seem to do what's required? Damn, let's try that again ... the diff *is* now attached to the RT ticket. -- Geoff Thorpe, RT/openssl.org __

[openssl.org #475] [Fwd: patch to 0.9.7 -performacne]

[geoff - Tue Feb 4 22:57:06 2003]: Thanks again. I'll let this patch linger for a day or two in case anyone wants to sanity-check first. Vini, vidi, VIMi. (I diffed, I lingered, I committed - more or less). 0.9.7 is going to have a patch-level release soon so I've confined this change to

[openssl.org #276] How to get session id for external session cache in openssl

I've committed the patch I wrote for this a while ago, as there have been no complaints. It's in CVS now and should be available in snapshots leading up to 0.9.8. Ticket resolved. -- Geoff Thorpe, RT/openssl.org __ OpenSSL

[openssl.org #507] NULL _mod_exp functions can cause crash when verifying DSA with ubsec

Hi there, (1) While testing I found that verification of certain signed documents crashed OpenSSL. The problem appears to be that hw_ubsec.c:ubsec_dsa_verify() calls p_UBSEC_dsa_verify_ioctl() and if this call fails then the code tries using software crypto, indirectly calling

[openssl.org #507] NULL _mod_exp functions can cause crash when verifying DSA with ubsec

[geoff - Sat Feb 15 21:48:27 2003]: The problem is nonetheless still there, and I am looking at it. OK, I've taken a further look - and some of the issues this problem have raised apply to other code too (eg. RSA and DH for sure, perhaps others). The fact that these METHOD's have protected

[openssl.org #507] NULL _mod_exp functions can cause crash when verifying DSA with ubsec

[guest - Fri Feb 21 02:43:59 2003]: The patch works, the app no longer crashes while verifying the DSA signature that it crashed on before. OK, I've edited the patch to remove some sludge and be a little clearer in places. It's now committed to the head of CVS and should be visible in the

[openssl.org #689] ENGINE fallback to software

Audit the ENGINE implementations to eliminate transparent behaviour that is not requested by the application (ENGINE_ctrl()) or the user (conf or environment variables). This mainly covers fallback to software. -- Geoff Thorpe, RT/openssl.org

[openssl.org #668] [PATCH] Fall back to software if nCipher hardware fails

Hi there, The patch reads OK and I was about to take a closer look when I realised that it's for 0.9.7. Rereading your original submission, you did note this but I must have glazed over at the time. 0.9.7 is a stable release branch so we're not making feature/functional changes there except

[openssl.org #1668] [PATCH] Fix for engine cache logic reversal

Nice analysis Ian and John, thanks for digging in to this. I agree with what you've determined, though I think there was a missing 'uptodate' line from the code too. I'm attaching a diff that matches yours but has this extra line. Can you please confirm that this still gives you the behaviour

[openssl.org #695] [PATCH] DSO: dlfcn support for MacOS X

hmm ... RT has a weird bug that added an empty comment whilst changing ticket status. Please ignore it. [EMAIL PROTECTED] - Wed Sep 24 07:48:10 2003]: Anyway, here's a patch for MacOS X, the patch for dso_dlfcn.c could be implemented in other ways also. There would be no need for ifdef's

[openssl.org #695] [PATCH] DSO: dlfcn support for MacOS X

sigh I (stupidly) wrote: [snip] are building for a platform that does this (in which case the secondary test without the underscore is presumably useless - and worth using an #else clause to eliminate it perhaps??), or (ii) implement a distinct [snip] Of course you already

[openssl.org #855] Major memory leak in OpenSSL using threads

Thanks for the update. You mentioned off-RT that there might have been some other problem with session caching? Contrary to what I said at the time, I'm closing this ticket (for the sake of clarity). Please feel free to open another if you hit other problems.

[openssl.org #867] [PATCH] Bignum exponent in RSA_generate_key_ex (instead of long)

Can you please resubmit the patch as an attachment rather than inlining it? The patch gets word-wrapped otherwise and is unusable. -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project

[openssl.org #874] [Fwd: Bug#243509: openssl: genrsa get crasy with small key size]

[I'd forgotten to send this to RT] OK, I took a look and the problem does not appear to be BN_generate_prime_ex() but the fact that, for small modulus sizes, the generated primes are always identical and the rsa keygen keeps looping in the hope that it eventually gets something unique. I've

[openssl.org #668] [PATCH] Fall back to software if nCipher hardware fails

Could you please adapt the patch for the head of CVS (nightly snapshots can be found on the ftp server) and resubmit? If this is not possible, let me know and perhaps I'll find a moment to have a poke at it. NB: in 0.9.8-dev, the engine implementations are to be found in ./engines/ rather

[openssl.org #695] [PATCH] DSO: dlfcn support for MacOS X

Antti, Any news on an update for your patch? Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL

[openssl.org #867] [PATCH] Bignum exponent in RSA_generate_key_ex (instead of long)

[geoff - Thu Apr 1 18:13:51 2004]: Can you please resubmit the patch as an attachment rather than inlining it? The patch gets word-wrapped otherwise and is unusable. Jelte, Any news on this? If you could update the request tracker ticket with a clean (non-wrapped) copy of your patch, I'd

[openssl.org #867] [PATCH] Bignum exponent in RSA_generate_key_ex (instead of long)

Looks mostly ok. It's missing a RSA_METHOD change and has a redundant BN_new() (memory leak), but nothing major. I'll tidy it up and commit it in a sec, thanks. -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project

[openssl.org #889] [PATCH] Support for VIA PadLock ACE (fwd)

[EMAIL PROTECTED] - Fri Jun 4 11:13:39 2004]: I have written new engine module for VIA PadLock ACE. http://www.logix.cz/michal/devel/padlock/#openssl This is quite cool. However to proceed, you'd need to port the engine to the head of CVS, which has the engines relocated from

[openssl.org #889] [PATCH] Support for VIA PadLock ACE (fwd)

OK, attached is a patch against CVS mainline. For me it works in both static and shared versions. Cool, I'll try to take a look in the next few days. I didn't get it, sorry. Should I make the Padlock support always static as is the cryptodev? The PadLock is available on new VIA Nehemiah

[openssl.org #889] [PATCH] Support for VIA PadLock ACE (fwd)

Hi, Getting back to this as I just finished an updated version of the PadLock engine with support for AES192, AES256 and RNG. For now it is only for 0.9.7 (see http://www.logix.cz/michal/devel/padlock/#openssl) and before porting it to CVS I want to clarify how... Thanks for the update,

[openssl.org #889] [PATCH] Support for VIA PadLock ACE (fwd)

[EMAIL PROTECTED] - Fri Jul 9 01:06:08 2004]: I finally decided to make the engine equal to other engines and build as a shared library. My next step will be extending the OpenSSL_config() (if necessary) to allow fine-grained loading of specified engines for apps that support it. But this

[openssl.org #889] [PATCH] Support for VIA PadLock ACE (fwd)

[EMAIL PROTECTED] - Sat Jul 10 01:26:23 2004]: AFAIK this way of checking for CPUID is 386-safe as well. Cool, thanks for the update. I've just sent a post to openssl-devel to ask for some assistance verifying the detection code under 386/486 systems. If I can get some confirmation back about

[openssl.org #926]

Sorry for the delay, this ticket slipped through the net, and Nils Larsch recently brought it to my attention. Vadim Fedukovich wrote: [snip] I'm particular interested exactly why it is believed that gcd(p-1,e)==1 and gcd(q-1,e)==1 (according to comments in the source). [snip] The gcd()

[openssl.org #697] bn-top related bug fixes

[EMAIL PROTECTED] - Thu Sep 25 11:37:20 2003]: as requested by Nil Larschs, i'm sending this diff to [EMAIL PROTECTED] For a discussion of these bugs and fixes, see the thread http://www.mail-archive.com/openssl-dev@openssl.org/msg16241.html Yup, in fact the bignum audit propsed in that

[openssl.org #956] engine code in ECDSA and ECDH

[EMAIL PROTECTED] - Thu Oct 21 08:19:52 2004]: please try a recent snapshot So it looks like this issue was resolved (I haven't checked, but Nils is a trustworthy sort :-). I'm closing the ticket. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org

[openssl.org #695] [PATCH] DSO: dlfcn support for MacOS X

I contacted the original submitter and he said there is unlikely to be any value in this line of enquiry now. He asked me to close the ticket and I'm happy to oblige. -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project

[openssl.org #2608] bug report: segfault from base64 decoding

David (thanks!) re-raised this ticket with the following details. (I am also attaching his 'base64-bug.txt' file.) Our UC-KLEE tool found a buffer overflow in OpenSSL's base64 decoder that results in a negative length passed to memcpy. This is likely exploitable, depending on where PEM-encoded

[openssl.org #2608] bug report: segfault from base64 decoding

I'm attaching a patch that I think is the right fix, but would appreciate feedback from people who understand evp/b64 better than me. It passes make test, and ceases to dump-core with David's sample input (also attached to this ticket). BTW, this patch seems to apply to all branches as far back