-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have built a version of OpenSSL 1.0.1g for Windows with:
- - no external dependencies (statically linked libc, multi-threaded, no
MSVCR*.DLL)
- - buffer-overflow protection
- - DTLS heartbeat support (use at your own risk)
- - misc. optimisations
What platform you are using, and what is the config parameters?
Can happens due to accidental editing of source file?
> > Well...
> > With this check 'make test' fails with:
> >
> > CMS => PKCS#7 compatibility tests
> > signed content DER format, RSA key: generation error
> > make[1]: *** [test_cms] Error 1
> >
> >
> Can't reproduce that here. Anyone else seeing this?
I saw it on Debian 7 x64, gcc 4.7.2
But an
Hello Dmitry,
Thanks a lot for your commitment!
It would be good idea to add test cases for new functionality as well.
On 14 April 2014 23:52, Dmitry Olshansky via RT wrote:
> It's been a bit over 2 years since the new Russian cryptography standard
> is out.
> RFCs 6986 and 7091 been out the
For some reason people are sharing a lot to OpenSSL code these days and I
noticed this in on of these files. I tried to match the coding style.
diff --git a/crypto/mem.c b/crypto/mem.c
index f7984fa..b2d47d7 100644
--- a/crypto/mem.c
+++ b/crypto/mem.c
@@ -327,6 +327,8 @@ char *CRYPTO_strdup(const
Hi all,
Would there be any problem with creating apps linked to OpenSSL if the
library was compiled with libc statically as opposed to a shared object?
The default build on Windows specifies using libc as a shared object (i.e.
using msvcr70.dll). I was thinking of distributing OpenSSL as statical
On Wed Apr 16 19:37:20 2014, satis...@mportal.com wrote:
> Hi ,
>
> When the iOS WiFi Profile is signed using new openSSL 1.0.1 version,
> it specifies the certificate chain in reverse order causing the
> device not to recognize the certificate chain and show "Not
> Verified". However, when we sign
This patch is incorrect. You cannot hope to get the length of an
arbitrary heap block using strlen.
A lot of the time you might get 'lucky' and this memset will be short
and therefore just ineffective at zeroing the to-be-freed block.
Sometimes you'll be unlucky and you will completely trash your
Hello,
the attached patch fixes an out-of-bounds write in SSL_get_shared_ciphers.
According to Bodo Moeller, the bug should not be critical because the
function never gets called with an empty list, but it may still be nice to
have that check in place.
Without the patch, when SSL_get_shared_ciph
Hi ,
When the iOS WiFi Profile is signed using new openSSL 1.0.1 version, it
specifies the certificate chain in reverse order causing the device not to
recognize the certificate chain and show "Not Verified". However, when we sign
using version 0.9.8k, the chain is included in the correct orde
Am 15.04.14 20:00, schrieb Stephen Henson via RT:
> I've just added a fix (and to two other cases in the same file). Let me know
> of
> any problems.
The commit now showed up in the public Git repository, so I'm all set now.
Best Regards
Stephan
On Wed Apr 16 10:55:57 2014, harakiri...@yahoo.com wrote:
>
> In this case the bleichenbacher attack does not even apply to
> encryption/decryption gateways if they work per user/recipient
> basis so the change makes no sense.
>
In general the attack is very real. To perform the attack an attacker
Am 15.04.14 20:00, schrieb Stephen Henson via RT:
> The cause was that the lastpost parameter was set to 0 instead of -1. The
> purpose of lastpos is to find multiple extensions of the same time so you can
> continue from the last found position or -1 to start from the beginning.
> Erroneously sett
On Tue, 4/15/14, Stephen Henson via RT wrote:
>> decrypting messages. Otherwise update the documentation
- that
> > under no circumenstances the
CMS_R_NO_MATCHING_RECIPIENT is ever
> > returned - you might as well remove it from any header
file.
>
In fact, it doesn't. The memset() function called has to be unknown to the compiler (i.e. not builtin) and in another module, but even there, the linker could optimize it out. And yes, there have been linkers 'capable' of optimizing that call out. Personally, I blame OS/2 for most of these problem
Hi,
Personally I use this function
void* secure_memset(void *ptr, unsigned char c, size_t size)
{
unsigned char *tmp = (unsigned char *) ptr;
if(!tmp)
return NULL;
while(size > 0)
{
*tmp++ = c;
size--;
}
return ptr;
}
It is not too fa
On 4/15/14 10:33 AM, stefan.n...@t-online.de wrote:
Hi,
I have "checked" the current source code of 'crpyto/mem.c' and I'm a
little bit suprised that no memset()-calls are made before the free_*()
functions are entered. I think a "zeroing" of the previous used memory
is a good solut
17 matches
Mail list logo