Re: AW: [openssl.org #3312] OpenSSL :: crypto/mem.c without memset() calls?

[David Jacobson]

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 solutions to beware for accessing old memory content.

Leaving aside the problem that just zeroing the memory simply
doesn't work (for a start into that discussion see e.g.
http://bytes.com/topic/c/answers/660296-memset-free), there is
OPENSSL_cleanse which does something similar (actually, it
overwrites the memory with garbage, not just with zeros) in a
way that works. Attempting to be faster at run time, this needs to be
called explicitly, though (and it's called in a lot of places if you look
into the source code).
But it might in fact be a good idea to put that call simply in the
free function and be done with it. With modern processors, the
slowdown is probably hardly nocticeable anyway.

Regards,
Stefan


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Here is a means of using memset so that it can't be optimized out.


#include stdint.h
#include string.h

void *
safe_memset(void *s, int c, size_t n)
{
   if (n  0) {
  volatile unsigned volatile_zero = 0;
  volatile uint8_t *vs = (volatile uint8_t*)s;

  do {
   memset(s, c, n);
  } while (vs[volatile_zero] != (uint8_t)c);
   }

   return s;
}


Since vs points to a volatile, the load in the while clause actually has 
to be done.  That forces the compiler to actually store c into at least 
the byte that is tested, in practice byte zero.  But the fact that the 
index is volatile zero, and since it is volatile it could spontaneously 
change to anything, the compiler has to store c into all bytes.


The key observation is that while you can't pass a volatile to memset 
(you get a warning and the volatile gets stripped away), you can use a 
volatile in a test that could go the wrong way if the memset were elided.


Could you C language lawyers please check this out and make sure I've 
not made a mistake.


Thank you,

--David

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: AW: [openssl.org #3312] OpenSSL :: crypto/mem.c without memset() calls?

[Vladimir Zatsepin]

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 fast as memset(), but gives some guaranties that memory will
be filled correctly.



2014-04-16 8:31 GMT+04:00 David Jacobson dmjacob...@sbcglobal.net:

 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 solutions to beware for accessing old memory content.

 Leaving aside the problem that just zeroing the memory simply
 doesn't work (for a start into that discussion see e.g.
 http://bytes.com/topic/c/answers/660296-memset-free), there is
 OPENSSL_cleanse which does something similar (actually, it
 overwrites the memory with garbage, not just with zeros) in a
 way that works. Attempting to be faster at run time, this needs to be
 called explicitly, though (and it's called in a lot of places if you look
 into the source code).
 But it might in fact be a good idea to put that call simply in the
 free function and be done with it. With modern processors, the
 slowdown is probably hardly nocticeable anyway.

 Regards,
 Stefan


 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

  Here is a means of using memset so that it can't be optimized out.


 #include stdint.h
 #include string.h

 void *
 safe_memset(void *s, int c, size_t n)
 {
if (n  0) {
   volatile unsigned volatile_zero = 0;
   volatile uint8_t *vs = (volatile uint8_t*)s;

   do {
memset(s, c, n);
   } while (vs[volatile_zero] != (uint8_t)c);
}

return s;
 }


 Since vs points to a volatile, the load in the while clause actually has
 to be done.  That forces the compiler to actually store c into at least the
 byte that is tested, in practice byte zero.  But the fact that the index is
 volatile zero, and since it is volatile it could spontaneously change to
 anything, the compiler has to store c into all bytes.

 The key observation is that while you can't pass a volatile to memset (you
 get a warning and the volatile gets stripped away), you can use a volatile
 in a test that could go the wrong way if the memset were elided.

 Could you C language lawyers please check this out and make sure I've not
 made a mistake.

 Thank you,

 --David


 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: AW: [openssl.org #3312] OpenSSL :: crypto/mem.c without memset() calls?

[Peter Waltenberg]

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 problems.I dealt with the tinfoilhattery in our usage by explicitly testing that all sensitive objects freed were in fact cleaned up before release. Since OpenSSL allows you to hook malloc/free calls those tests aren't as difficult to write as it seems.If a compiler we use does ever misbehave, I'll deal with it if and when the tests for 'erasure' fail - and be able to be sure I've 'fixed' the feature.Peter-owner-openssl-...@openssl.org wrote: -To: openssl-dev@openssl.orgFrom: Vladimir Zatsepin Sent by: owner-openssl-...@openssl.orgDate: 04/16/2014 06:06PMSubject: Re: AW: [openssl.org #3312] OpenSSL :: crypto/mem.c without "memset()" calls?Hi,Personally I use this functionvoid* 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 fast as memset(), but gives some guaranties that memory will be filled correctly.2014-04-16 8:31 GMT+04:00 David Jacobson dmjacob...@sbcglobal.net:
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 solutions to beware for accessing old memory content.

Leaving aside the problem that just zeroing the memory simply
doesn't work (for a start into that discussion see e.g.
http://bytes.com/topic/c/answers/660296-memset-free), there is
OPENSSL_cleanse which does something similar (actually, it
overwrites the memory with "garbage", not just with zeros) in a
way that works. Attempting to be faster at run time, this needs to be
called explicitly, though (and it's called in a lot of places if you look
into the source code).
But it might in fact be a good idea to put that call simply in the
free function and be done with it. With modern processors, the
slowdown is probably hardly nocticeable anyway.

Regards,
  Stefan


__
OpenSSL Project http://www.openssl.org
Development Mailing Listopenssl-dev@openssl.org
Automated List Manager  majord...@openssl.org


Here is a means of using memset so that it can't be optimized out.


#include stdint.h
#include string.h

void *
safe_memset(void *s, int c, size_t n)
{
 if (n  0) {
   volatile unsigned volatile_zero = 0;
   volatile uint8_t *vs = (volatile uint8_t*)s;

   do {
 memset(s, c, n);
   } while (vs[volatile_zero] != (uint8_t)c);
 }

 return s;
}


Since vs points to a volatile, the load in the while clause actually has to be done. That forces the compiler to actually store c into at least the byte that is tested, in practice byte zero. But the fact that the index is volatile zero, and since it is volatile it could spontaneously change to anything, the compiler has to store c into all bytes.


The key observation is that while you can't pass a volatile to memset (you get a warning and the volatile gets stripped away), you can use a volatile in a test that could go the wrong way if the memset were elided.


Could you C language lawyers please check this out and make sure I've not made a mistake.

Thank you,

  --David

__
OpenSSL Project http://www.openssl.org
Development Mailing Listopenssl-dev@openssl.org
Automated List Manager  majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3314] BUG - CMS Decrypt returns wrong error message on mismatching private key after Bleichenbachers FIX

[Harakiri via RT]

On Tue, 4/15/14, Stephen Henson via RT r...@openssl.org 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.
 
 
 See the updated documentation for CMS_decrypt for reasons
 why this is
 necessary. If you still think there is a bug then please
 post a follow up.


I dont see this behavior documented here 
http://www.openssl.org/docs/apps/cms.html# (Im talking from the perspective of 
using the command line tool, not API programming)

Parameter -out filename

Should say something like for -decrypt, if the operation fails, random data is 
written to this file - if you wish to use the old behavior use -debug_decrypt 
option

 
 Automated gateways will typically know the recipient's
 certificate so this
 issue shouldn't arise.

Actually this exactly the problem. A decryption gateway at first only has the 
recipients e-mail address to look up a secret key. Using this e-mail adress
a lookup is performed and the secret key is returned. Now the openssl cms CMD 
line is called with that secret key - and there is no useable error anymore
just bad decrypt - this tells me nothing at all. It *could* be that the wrong 
secret key was supplied, it could also be another issue (e.g. outlook doing 
weird encryption things).

Im only talking about using the CMD client here, no direct C API - the only 
possible means i now have is using the 

openssl cms -in mailencrypted.txt -cmsout

dump to grep for recipientInfos and d.issuerAndSerialNumber to figure out all 
the certs to which is messages was encrypted to.

Then i have to take this info and lookup all associated certificates to that 
secret key (can be obviously multiple due renew/expired/revoked etc) and only 
if i can not find the cert it might most likely
be the issue that the message was encrypted to the wrong user/key/cert and the 
current secret key of the user is wrong.

Not only are there so many IFs in that - i cant even do that if i dont have all 
past and current issued certificates of a secret key.

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.

Since the -debug_decrypt is not documented on the CMS page it is most likely 
not supported and will be removed in the near future.

Please reconsider adding useful error information to failed decryption, this 
makes it virtually impossible to debug decryption errors without using the 
-debug_decrypt flag.

Thanks

BTW: While we are at the cms -out param documention, it would be great if 
-verify could cut/remove the signature of a signed messages even if i dont have 
the signers public key (just want to get rid of the signature)


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3309] Bug: Missing critical flag for extended key usage not detected in time-stamp verification

[Stephan Mühlstrasser via RT]

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 setting it to 0 will mean it misses the extension if it is first.

Thanks for identifying the cause.

 I've just added a fix (and to two other cases in the same file). Let me know 
 of
 any problems.

I've applied your suggested fix locally (replaced 0 with -1 in the calls 
to X509_get_ext_by_NID()), and I can confirm that it corrects the problem.

In what OpenSSL version(s) will this fix be included? Will it be 
included in OpenSSL 1.0.2? I could not yet see it in the public Git 
repository.

Thanks
Stephan


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3314] BUG - CMS Decrypt returns wrong error message on mismatching private key after Bleichenbachers FIX

[Stephen Henson via RT]

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 needs to
be able to determine if the RSA decrypt operation has succeeded for a larger
number of carefully crafted messages. The old behaviour would halt and return
an error immediately if RSA decrypt failed for all recipients and continue and
perform a symmetric decrypt operation is at least one RSA decrypt succeeded.
The timing difference between the two is significant and an attacker could
easily distinguish between the two.

In specific cases the attack may not be significant which is why there is a
flag to disable this behaviour. the default is to be safe.

 Since the -debug_decrypt is not documented on the CMS page it is most
 likely not supported and will be removed in the near future.


Compatibility is very important: options are not simply removed in the near
future.

The -debug_decrypt option is currently simply undocumented due to an omission
which I will shortly correct. It will remain supported for the foreseeable
future.

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 #3309] Bug: Missing critical flag for extended key usage not detected in time-stamp verification

[Stephan Mühlstrasser via RT]

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


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3316] Wrong trust chain with new version of openssl

[Satish Kamavaram via RT]

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 order and the device 
is showing the profile as a Verified one , at the time of showing profile 
installation prompt.  Is there a possibility that we will get a fix in next 
version of openssl ?

Command Used:
openssl smime -sign  -signer {pem cert} -inkey {pem cert key}  -certfile {pem 
cert chain} -nodetach  -outform der -in {unsigned mobile config file} -out 
{signed mobile config file}

Thanks
SatishKumaar


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3317] Patch: Avoid out-of-bounds write in SSL_get_shared_ciphers

[Günther Noack via RT]

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_ciphers gets called with an empty
list of ciphers, it will skip the for-loop completely, write buf[-1]='\0',
and return a pointer to uninitialized memory.

I found this with the Clang static analyzer.  (Great tool. :))

Thanks,
Günther

PS: To illustrate,
1449 char *SSL_get_shared_ciphers(const SSL *s,char *buf,int len)
1450 {
1451 char *p;
1452 STACK_OF(SSL_CIPHER) *sk;
1453 SSL_CIPHER *c;
1454 int i;
1455
1456 if ((s-session == NULL) || (s-session-ciphers == NULL) ||
1457 (len  2))
1458 return(NULL);
1459
1460 p=buf;
1461 sk=s-session-ciphers;
1462 for (i=0; isk_SSL_CIPHER_num(sk); i++)   // assume
sk_SSL_CIPHER_num(sk) == 0
1463 {
1464 int n;
1465
1466 c=sk_SSL_CIPHER_value(sk,i);
1467 n=strlen(c-name);
1468 if (n+1  len)
1469 {
1470 if (p != buf)
1471 --p;
1472 *p='\0';
1473 return buf;
1474 }
1475 strcpy(p,c-name);
1476 p+=n;
1477 *(p++)=':';
1478 len-=n+1;
1479 }
1480 p[-1]='\0';  // out of bounds write, returns pointer to
uninitialized memory
1481 return(buf);
1482 }

diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index c6ca137..4720680 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -1442,40 +1442,44 @@ int SSL_set_cipher_list(SSL *s,const char *str)
SSLerr(SSL_F_SSL_SET_CIPHER_LIST, SSL_R_NO_CIPHER_MATCH);
return 0;
}
return 1;
}
 
 /* works well for SSLv2, not so good for SSLv3 */
 char *SSL_get_shared_ciphers(const SSL *s,char *buf,int len)
{
char *p;
STACK_OF(SSL_CIPHER) *sk;
SSL_CIPHER *c;
int i;
 
if ((s-session == NULL) || (s-session-ciphers == NULL) ||
(len  2))
return(NULL);
 
p=buf;
sk=s-session-ciphers;
+
+   if (sk_SSL_CIPHER_num(sk) == 0)
+   return NULL;
+
for (i=0; isk_SSL_CIPHER_num(sk); i++)
{
int n;
 
c=sk_SSL_CIPHER_value(sk,i);
n=strlen(c-name);
if (n+1  len)
{
if (p != buf)
--p;
*p='\0';
return buf;
}
strcpy(p,c-name);
p+=n;
*(p++)=':';
len-=n+1;
}
p[-1]='\0';
return(buf);

Re: [openssl.org #3312] OpenSSL :: crypto/mem.c without memset() calls?

[Joseph Birr-Pixton]

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 heap,
possibly in an exploitable way.

There is no portable way to get the length of a heap block after an
allocation is completed. Most allocator-wrapping layers which need it
extend the allocation by maxalign(sizeof(size_t)) and stash the length
before the allocation, then retrieve it later in free. But this is
really quite expensive - commonly 8 bytes per allocation - and it
ensures that calling code requesting carefully chosen power-of-two
blocks no longer fit into common allocator bucket sizes.

Cheers,
Joe

On 14 April 2014 20:53, Markus Grundmann via RT r...@openssl.org 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 solutions to beware for accessing old memory content.

 ---

 $ diff ../../openssl-1.0.1g/crypto/mem.c mem.c (after my modifications)
 285a286,288
 if (!str) return;
 else memset(str,0,strlen(str));

 293a297,298

 str = NULL;
 324a330
 if (ret  num  0) memset(ret,0,num);
 328a335,342

 /* Check parameters
  */
 if (!str || !file || line = 0)
 {
return NULL;
 }

 330a345
 if (!ret) return NULL;
 391a407,409
 if (!str) return;
 else memset(str,0,strlen(str));

 396a415
 if (!str) return;
 399a419
 str = NULL;


 --
 Best regards,
 Markus

 Better Privacy with PGP encrypted Mail: http://activezone.de/pgp/
 Fingerprint: 58C5 8BAF 6FCE B24F 1881 B5B8 F2A8 E1D0 484B 0054

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3316] Wrong trust chain with new version of openssl

[Stephen Henson via RT]

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 using version 0.9.8k, the chain is
 included in the correct order and the device is showing the profile
 as a Verified one , at the time of showing profile installation
 prompt. Is there a possibility that we will get a fix in next
 version of openssl ?


I'm not sure what you mean by correct order. The order of certificates in a
PKCS#7 structure should not be considered significant and there is additional
information (issuer name and serial number) which should enable a verifier to
locate the appropriate signing certificate.

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

Statically linking libc v loading libc as shared library?

[Ricardo Villegas]

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 statically
linked to libc, eliminating the external dependency on MSVCR*.dll.

Thanks
Ricardo Villegas (_RVX)

PGP key 0x94988332 (just for reference, I currently don't have GPG
installed. (I recently upgraded my HDD.)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

strdup(3) never returns NULL

[Alexander Schrijver]

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 char *str, const char *file, int 
line)
{
char *ret = CRYPTO_malloc(strlen(str)+1, file, line);
 
+   if (ret == NULL) return NULL;
+
strcpy(ret, str);
return ret;
}

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3311] [PATCH] Introduce GOST R 34.11-2012 hash function

[Andrey Kulikov]

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 r...@openssl.org wrote:

 It's been a bit over 2 years since the new Russian cryptography standard
 is out.
 RFCs 6986 and 7091 been out there for a while[1,2]. Other toolkits are
 adding support, e.g. Libgcrypt introduced GOST 34.11-2012 in 1.6.0 [3].

 Keeping in mind that OpenSSL provides GOST reference engine it seems
 natural to revise it in the light of the new standard.

 To summarize the full set of changes for the new standard:
  - New hash function GOST R 34.11-2012 (Stribog) takes place of GOST
 R 34.11-94. After 2018 usage of 34.11-94 is basically prohibited.

  - Digital signature algorithm GOST 34.10-2001 is extended to
 support both 256bit and 512bit keys. The hash function to use is GOST R
 34.11-2012. 256bit version is exactly the same modulo the hashing.

  - 2 new parameter sets (curves) for 512bit GOST 34.10-2012 are
 listed as recommended. Older ones stay as is for 256-bit version.

  - Symmetric cipher stays the same, one new S-box set was defined.

  - Key Exchange (VKO) is the same algorithm but with different hash
 function (HMAC of GOST 34.11-2012).

 This patch adds support for hash algorithm GOST R 34.11-2012 _only_ .
 The source code was initially tested on x86, PowerPC and ARMv4.
 New digests have short names md_gost12_256 and md_gost12_512
 respectively.

 See attached patch or browse it on github:
 https://github.com/openssl/openssl/pull/68

 Next steps towards full support are far less involved and consist mostly
 of minor changes such as adding paramsets and/or removing artificial
 limitations.

 1. GOST R 34.11-2012: Hash Function http://tools.ietf.org/html/rfc6986
 2. GOST R 34.10-2012: Digital Signature Algorithm
 http://tools.ietf.org/html/rfc7091
 3. http://lists.gnupg.org/pipermail/gnupg-announce/2013q4/000336.html

 --
 Dmitry Olshansky

Re: [openssl.org #3308] Re: Return missed NULL-check in CMS_add0_cert back

[Andrey Kulikov via RT]

  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 anyway, as *pcerts can be NULL legitimately, this seems to be not
important.
Sorry for wasting your time. :(

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3310] Can't execute make command

[Andrey Kulikov]

What platform you are using, and what is the config parameters?
Can happens due to accidental editing of source file?

Custom build now available

[Ricardo Villegas]

-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 for modern Windows (requires Windows 2000 or later;
recommended: Windows 7+)

Download it here: http://downloads.rickyv.tk/openssl1.0.1g_win32_nodeps.zip

Includes binaries, header files, import libraries, engines, and default
openssl.cnf file.

This is mostly an experimental build, since the default build is to use the
multi-threaded libc shared library
(i.e. MSVCR*.DLL)

Any feedback when developing apps using this custom build will be
appreciated.
Send feedback to: ric...@rickyv.tk
(Recommendation: digitally signed or encrypted: my public key is available
at keyserver.ubuntu.com)

Built using Visual Studio.NET 2002 (this MAY pose an issue when using the
import libraries;
dynamic linking to the OpenSSL library, at run-time, is recommended.)

_RVX

PGP key: 9DB6C73E (It has changed, please update your keyrings.)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)

iQIcBAEBCgAGBQJTTzeDAAoJELxZO8Gdtsc+ABsQALbXt6xz513Es2/c8Yld4Qx1
O9azxwIOsChk6HK8a4ilmt9qAWPbiZteTuUQnI78RMTJfZVKc2nzSF3lcnyIopuZ
3lvVfA0+HTnQm06Z6tHqtgQQsMeF1nwrQ4dkCxotyRKeBv+JXQY1MZpgKoGUVQWk
pPJGT2Nd84lqBJHJqHWJaN+4Pr5Og1jaPZyuc4gc+LaLrfrm0FyewetEU7yKLO96
xrtUqGpwyWc/fRxAX0VfnjGl6GNyclmSccZekbyRZt2zXfTWImlyZV6/gZFuX+DB
jNsmZqoJoHhf7CnQ4mKkVEN5hwHTAgl74dNwrAMCJogUE9BiastnE7aQQv4aOes2
m16G4ZZOcBfTwY52xwZdFyEH0vZEhzL86ktGOnyrZXx+66zwFNo4JZXbs+TQTx65
MLCeuRIn+a7ZJ0hnJxKgaAXnK+9KswSUhIDmqZSmeHzxzJgD7+xBkC5OvBl/Sjr7
WIqVFO7G3uI6pNhnTlWVPttxsmHSFKnigHSN1mz3z9nft+p1UUxI3yEzRKWPrh8R
yaPCV7B7oEhVijH7SYV0FTywTl+8e4sX+SGRbaq5J5f7yQlcrTwyuiFNbkLqAzaF
HvZX/mgm85g9L/L/irCPBA+AVscOmmc8WB0aMI/zzN3CcRjV1JxdVR5R3G19nhya
xgwYvMhoXzymIZuwokxn
=7v7J
-END PGP SIGNATURE-

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org