The only critical bit here is opinion replacing analysis.
As you said so yourself, and I quote: When both an application and a
library ([...]) both initialize and register their own threading functions,
bad things happen and the application can crash.)
Indeed. Spot on, I'd say.
That is /exactly/
patch attached, of course.
Even in UNIX County, ioctl(FIONBIO) isn't everywhere. Let alone abroad.
Since the days of yore OpenSSL has implicitly known this as there exists a
BIO_socket_nbio() but since it was far from complete the more or less
complete #ifdef portability hacks litter the
The CRLF and paths bit is most probably due to the fact that I do my
diff/merge/dev work on Win32/64 boxes mostly - that's where all my toolkit
sits anyway; hadn't realized your patch was that picky. When I do it on a
*nix box, I always run 'patch -l' which doesn't complain; when code looks a
real
patch file attached.
Subitems:
- {
+#if 0 /* [i_a] ERROR: some intrinsic memcpy() ops can copy DOWN, thus
corrupting the data here */
memcpy((unsigned char *)ctx-tmp,
(unsigned char *)(ctx-tmp[jj]),i-jj);
+#else
+
Side note:
You may want to ignore the 'const' in the prototype for now; we have an
in-house copy of OpenSSL which is quite severely const-ified and
size_t-ified.
--- h:\prj\1original\openssl\openssl\crypto\x509\x509_cmp.c2010-01-12
19:29:33.0 +-0200
+++
Bug Fix:
See attached diff.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
Changelog says:
Changes between 0.9.6a and 0.9.6b [9 Jul 2001]
[...]
*) In crypto/bio/bf_buff.c, increase DEFAULT_BUFFER_SIZE to 4096
(previously it was 1024).
[Bodo Moeller]
However, the corresponding .pod hasn't been updated yet.
.pod fix/patch attached.
Also note that the
The callback calls BIO_printf(); it's return value is properly propagated
but is not checked in the error chain dumper func; when the errors are
streamed through any BIO which fails, such failure hence remains undetected
and the BIO is being hammered instead of aborting the error dump. Different
fix attached.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--
fix
fix attached.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--
fix
ssl\s3_clnt.c:
since the hash length lands in 'md_len' and the entire hash
would/should/might be used as the IV...
What do the protocol wizards have to say about this?
--- h:\prj\1original\openssl\openssl\ssl\s3_clnt.c2010-02-28
02:24:04.0 +-0200
+++
ssl3_read() does indirect, while ssl3_write does not.
Doesn't seem intentional to me, on the contrary.
Tick choice:
[ ] Correct reasoning fix?
[ ] Dead wrong, buster!
just in case: patch attached
--- h:\prj\1original\openssl\openssl\ssl\s3_lib.c2009-11-19
02:34:54.0 +-0200
+++
Was doing another merge and while doing so had a look at the differences
between my local copy and CVS HEAD of yesterday (2010/04/29) and one of 'em
was odd as it used 'inl' while counting 'chunk'.
This is the patch for
#define BLOCK_CIPHER_func_cfb(cname, cprefix, cbits, kstruct, ksched) \
On Thu, Apr 29, 2010 at 12:31 AM, Ger Hobbelt g...@hobbelt.com wrote:
And for those that like this to be
like this to be -- liking this to
:-(
On Thu, Apr 29, 2010 at 12:31 AM, Ger Hobbelt g...@hobbelt.com wrote:
And for those that like this to be like this to be -- liking this to:-(
Steve,
In answer to your question:
On Wed, Apr 28, 2010 at 3:19 PM, Stephen Henson via RT r...@openssl.orgwrote:
Note that it is also possible to add -Zi on the command line to
Configure for non-debug builds to avoid needing to modify OpenSSL of the
generated Makefile.
Is anyone aware of
On Fri, Nov 27, 2009 at 10:31 AM, Nick via RT r...@openssl.org wrote:
As you understand now, troubles in key generation. It's time to dip into
sources.
Most probably troubles in correct usage of APIs. Read on.
Cipher context initialization (and simultaneous key definition) perform in
call
Sorry for late reply; been under the weather lately, healthwise, so
this is my first 'on-line' experience in a while ;-)
As far as the brain is operational again... I'd say the quickest way
to fix this is to wrap the __try/__except chunk in a compiler-specific
preproc check a la:
#if
Bumped and fed to RT as this bugger doesn't seem to have a ticket #
while the fix is available, and I just got an enquiry about this and
whether did it make it into the latest. (Nope, it did not. Yet?)
See also the dev@ mail trail at the subject line time shown below
for how it got to this.
Resolved. Thanks for all your hard work on OpenSSL!
Ger
On Mon, Apr 13, 2009 at 1:40 PM, Stephen Henson via RT r...@openssl.org wrote:
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
--
Met
patchfile included.
1)
Adds documentation (--help) to mkerr.pl; very handy for the folks who
like to use this nice tool within and without OpenSSL (e.g. me ;-) ).
2)
The patch also fixes the error number assignment, now _really_
starting at 100 (as hinted at in other sections of OpenSSL
1)
shut up GCC (and other compilers) about implicit definition of
printf() by including the headerfile delivering its prototype as well
in the generated code: stdlib.h
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:
1)
shut up GCC (and other compilers) about implicit definition of
printf() by including the headerfile delivering its prototype as well
in the generated code: stdlib.h
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:
Error result code check in ./crypto/x509/x509_vfy.c: error return
value can be negative.
(My personal lesson from this: don't wait to see if one of the Top
Dogs bother asking 'hm, shouldn't this change as well?' - I waited for
the O.G., then forgot. And now I'm still not 110% sure if I saw
Simple stuff, but best to get this out of the way finally.
Patch file included, of course.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile:
Kim's fix as diff for CA.sh for when anyone wants to incorporate this
in 0.9.9 CVS HEAD
On Tue, Feb 24, 2009 at 9:46 PM, Nguyen, Kim via RT r...@openssl.org wrote:
The CA.sh script in 0.9.8j is missing the -extensions v3_ca flag. This
doesn't seem to be a problem in CA.pl
In comparision,
As originally posted to users@ by Victor Duchovni @ 2009/02/11
Attached is this as a patch file against todays 0.9.9 CVS HEAD; patch
includes assert() -- OPENSSL_assert() fixes as well.
On Wed, Feb 11, 2009 at 10:41 AM, Ger Hobbelt g...@hobbelt.com wrote:
Good find! This is indeed wrong
patch attached: return value was not checked, causing havoc later
along the line (under particular memory conditions).
diff produced inspected against latest 0.9.9 CVS HEAD.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:
The bugfix core in the attached diff are these bits:
@@ -351,6 +361,8 @@
fvalue = va_arg(args, LDOUBLE);
else
fvalue = va_arg(args, double);
+fmtfp(sbuffer, buffer, currlen, maxlen,
+ fvalue, min, max,
On Wed, Mar 11, 2009 at 1:49 PM, Vladimir Kotal vladimir.ko...@sun.com wrote:
Hello,
In case the openssl verify command is not able to process input file, it
reports the usage even if the usage is perfectly okay:
$ openssl verify -CAfile /local/Saved/SMI_SSL_CA-chain.pem cert.cer
Error
L.S.,
please have a look at crypto/des/xcbc_enc.c: function
void DES_xcbc_encrypt(...)
in 0.9.9 CVS HEAD
at line 165 the loop reads:
for (l-=8; l0; l-=8)
shouldn't this read as:
for (l-=8; l=0; l-=8)
as happens for all other cbc loops out there (not only in
wrong statistic (read instead of write) is updated when calling BIO_nwrite().
The fix:
--- \\Debbie\ger\prj\1original\openssl\openssl\crypto\bio\bss_bio.c
2003-08-06
11:36:25.0 +-0100
+++ \\Debbie\ger\prj\3actual\openssl\crypto\bio\bss_bio.c 2008-12-24
22:35:22.0
On Thu, Dec 25, 2008 at 11:25 PM, Richard Levitte via RT r...@openssl.org
wrote:
Patch applied. Thanks.
You're welcome.
Just saw it pop up on CVS. That was fast! :-)
Cheers,
Ger
--
Richard Levitte
levi...@openssl.org
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
The corresponding DECLARE_... statements are in pcy_int.h and x509v3.h
respectively BTW.
--- \\Debbie\ger\prj\1original\openssl\openssl\crypto\x509v3\pcy_lib.c
2008-11-12
20:36:05.0 +-0100
+++ \\Debbie\ger\prj\3actual\openssl\crypto\x509v3\pcy_lib.c2008-11-12
22:12:48.0
When the malloc() fails, the original code would still try to access
the (invalid) pointer.
--- \\Debbie\ger\prj\1original\openssl\openssl\crypto\dsa\dsa_asn1.c
2008-11-12
20:36:01.0 +-0100
+++ \\Debbie\ger\prj\3actual\openssl\crypto\dsa\dsa_asn1.c 2008-11-12
21:29:50.0
VERSION: todays CVS for 0.9.9 (bleeding edge)
ISSUE:
first assert() included an unknown variable called 'counter'.
--- \\Debbie\ger\prj\1original\openssl\openssl\crypto\camellia\cmll_ctr.c
2008-11-01
20:08:48.0 +-0100
+++ \\Debbie\ger\prj\3actual\openssl\crypto\camellia\cmll_ctr.c
VERSION: todays' CVS 0.9.9 (bleeding edge)
ISSUE: a function (padlock_rand_bytes) with int parameter, which
function pointer prototype requires size_t (which is different size on
several platforms).
Patch to correct this:
--- \\Debbie\ger\prj\1original\openssl\openssl\engines\e_padlock.c
size_t issues + assert--OPENSSL_assert:
--- \\Debbie\ger\prj\1original\openssl\openssl\crypto\bn\bn_asm.c
2005-10-22
21:20:06.0 +-0100
+++ \\Debbie\ger\prj\3actual\openssl\crypto\bn\bn_asm.c 2008-11-01
23:10:36.0 +-0100
@@ -66,16 +70,17 @@
#include cryptlib.h
#include
And exactly the same for AES:
--- \\Debbie\ger\prj\1original\openssl\openssl\crypto\aes\aes_ctr.c
2008-11-01
20:25:22.0 +-0100
+++ \\Debbie\ger\prj\3actual\openssl\crypto\aes\aes_ctr.c 2008-11-01
22:53:56.0 +-0100
@@ -117,16 +123,16 @@
unsigned char
Has been resolved in todays CVS by Ben Laurie. Thanks!
On Sun, Nov 2, 2008 at 9:13 PM, The default queue via RT [EMAIL PROTECTED]
wrote:
Greetings,
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
Re: cannot compile camelia
Fixed in todays CVS by Dr. S. Hanson. (this and the others were filed
yesterday, but only made it through rt@ a few hours ago. Sorry.)
On Sun, Nov 2, 2008 at 9:13 PM, The default queue via RT [EMAIL PROTECTED]
wrote:
Greetings,
This message has been automatically generated in response to
40 matches
Mail list logo
