Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On Thu, Jul 03, 2014 at 11:35:15PM +0200, Kurt Roeckx wrote:
On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf F?rster via RT wrote:
I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
and 96, or ?:
The line before that:
dp=d;
l2c(v0,dp);--- Uninitialized variable: d
l2c(v1,dp);--- Uninitialized variable: d
while (l--)
{
if (n == 0)
{
DES_encrypt1(ti,schedule,DES_ENCRYPT);
dp=d;
t=ti[0]; l2c(t,dp);
t=ti[1]; l2c(t,dp);
save++;
}
*(out++)= *(in++)^d[n];--- Uninitialized variable: d
n=(n+1)0x07;
}
d is uninitialized, but it's being written to, not read from,
so I don't see a problem with this.
What?
So l2c is:
#define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
*((c)++)=(unsigned char)(((l) 8L)0xff), \
*((c)++)=(unsigned char)(((l)16L)0xff), \
*((c)++)=(unsigned char)(((l)24L)0xff))
It reads v0 and v1 and writes to d (dp). d being uninitialized
shouldn't be an issue. Or am I missing something?
Yes, c (which is d) is both incremented and dereferenced.
-Otto
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On Fri, Jul 04, 2014 at 08:21:15AM +0200, Otto Moerbeek wrote:
On Thu, Jul 03, 2014 at 11:35:15PM +0200, Kurt Roeckx wrote:
On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf F?rster via RT wrote:
I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
and 96, or ?:
The line before that:
dp=d;
l2c(v0,dp);--- Uninitialized variable: d
l2c(v1,dp);--- Uninitialized variable: d
while (l--)
{
if (n == 0)
{
DES_encrypt1(ti,schedule,DES_ENCRYPT);
dp=d;
t=ti[0]; l2c(t,dp);
t=ti[1]; l2c(t,dp);
save++;
}
*(out++)= *(in++)^d[n];--- Uninitialized variable: d
n=(n+1)0x07;
}
d is uninitialized, but it's being written to, not read from,
so I don't see a problem with this.
What?
So l2c is:
#define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
*((c)++)=(unsigned char)(((l) 8L)0xff), \
*((c)++)=(unsigned char)(((l)16L)0xff), \
*((c)++)=(unsigned char)(((l)24L)0xff))
It reads v0 and v1 and writes to d (dp). d being uninitialized
shouldn't be an issue. Or am I missing something?
Yes, c (which is d) is both incremented and dereferenced.
So we have:
DES_cblock d;
which as far as I know really is:
unsigned char d[8];
and:
register unsigned char *dp=d;
*((dp)++) = foo;
d is a valid pointer, but the content it points to is
uninitialized. We end up writing to d[0], d[1], ..., d[7]. I
don't see us reading it, nor do I see a problem with it.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2770] updated cryptodev fix
From fa47376f4c3e03b18ccd52df53d8c5041155d4ed Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos n...@gnutls.org
Date: Fri, 4 Jul 2014 07:31:25 +0200
Subject: [PATCH] cryptodev: Fix issue with signature generation
That patch also enables support for SHA2 hashes, and
removes support for hashes that were never supported by
cryptodev.
---
crypto/engine/eng_cryptodev.c | 192 ++
1 file changed, 140 insertions(+), 52 deletions(-)
diff --git a/crypto/engine/eng_cryptodev.c b/crypto/engine/eng_cryptodev.c
index 568e131..a1c39e5 100644
--- a/crypto/engine/eng_cryptodev.c
+++ b/crypto/engine/eng_cryptodev.c
@@ -2,6 +2,7 @@
* Copyright (c) 2002 Bob Beck b...@openbsd.org
* Copyright (c) 2002 Theo de Raadt
* Copyright (c) 2002 Markus Friedl
+ * Copyright (c) 2012 Nikos Mavrogiannopoulos
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -74,8 +75,6 @@ struct dev_crypto_state {
int d_fd;
#ifdef USE_CRYPTODEV_DIGESTS
- char dummy_mac_key[HASH_MAX_LEN];
-
unsigned char digest_res[HASH_MAX_LEN];
char *mac_data;
int mac_len;
@@ -162,15 +161,21 @@ static struct {
static struct {
int id;
int nid;
- int keylen;
+ int digestlen;
} digests[] = {
+#if 0
+/* HMAC is not supported */
{ CRYPTO_MD5_HMAC, NID_hmacWithMD5, 16},
{ CRYPTO_SHA1_HMAC, NID_hmacWithSHA1, 20},
- { CRYPTO_RIPEMD160_HMAC, NID_ripemd160, 16/*?*/},
- { CRYPTO_MD5_KPDK, NID_undef, 0},
- { CRYPTO_SHA1_KPDK, NID_undef, 0},
+ { CRYPTO_SHA2_256_HMAC, NID_hmacWithSHA256, 32},
+ { CRYPTO_SHA2_384_HMAC, NID_hmacWithSHA384, 48},
+ { CRYPTO_SHA2_512_HMAC, NID_hmacWithSHA512, 64},
+#endif
{ CRYPTO_MD5, NID_md5, 16},
{ CRYPTO_SHA1, NID_sha1, 20},
+ { CRYPTO_SHA2_256, NID_sha256, 32},
+ { CRYPTO_SHA2_384, NID_sha384, 48},
+ { CRYPTO_SHA2_512, NID_sha512, 64},
{ 0,NID_undef, 0},
};
#endif
@@ -248,13 +253,14 @@ get_cryptodev_ciphers(const int **cnids)
static int nids[CRYPTO_ALGORITHM_MAX];
struct session_op sess;
int fd, i, count = 0;
+ unsigned char fake_key[CRYPTO_CIPHER_MAX_KEY_LEN];
if ((fd = get_dev_crypto()) 0) {
*cnids = NULL;
return (0);
}
memset(sess, 0, sizeof(sess));
- sess.key = (caddr_t)123456789abcdefghijklmno;
+ sess.key = (void*)fake_key;
for (i = 0; ciphers[i].id count CRYPTO_ALGORITHM_MAX; i++) {
if (ciphers[i].nid == NID_undef)
@@ -286,6 +292,7 @@ static int
get_cryptodev_digests(const int **cnids)
{
static int nids[CRYPTO_ALGORITHM_MAX];
+ unsigned char fake_key[CRYPTO_CIPHER_MAX_KEY_LEN];
struct session_op sess;
int fd, i, count = 0;
@@ -294,12 +301,12 @@ get_cryptodev_digests(const int **cnids)
return (0);
}
memset(sess, 0, sizeof(sess));
- sess.mackey = (caddr_t)123456789abcdefghijklmno;
+ sess.mackey = fake_key;
for (i = 0; digests[i].id count CRYPTO_ALGORITHM_MAX; i++) {
if (digests[i].nid == NID_undef)
continue;
sess.mac = digests[i].id;
- sess.mackeylen = digests[i].keylen;
+ sess.mackeylen = 8;
sess.cipher = 0;
if (ioctl(fd, CIOCGSESSION, sess) != -1
ioctl(fd, CIOCFSESSION, sess.ses) != -1)
@@ -387,14 +394,14 @@ cryptodev_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
cryp.ses = sess-ses;
cryp.flags = 0;
cryp.len = inl;
- cryp.src = (caddr_t) in;
- cryp.dst = (caddr_t) out;
+ cryp.src = (void*) in;
+ cryp.dst = (void*) out;
cryp.mac = 0;
cryp.op = ctx-encrypt ? COP_ENCRYPT : COP_DECRYPT;
if (ctx-cipher-iv_len) {
- cryp.iv = (caddr_t) ctx-iv;
+ cryp.iv = (void*) ctx-iv;
if (!ctx-encrypt) {
iiv = in + inl - ctx-cipher-iv_len;
memcpy(save_iv, iiv, ctx-cipher-iv_len);
@@ -445,7 +452,7 @@ cryptodev_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
if ((state-d_fd = get_dev_crypto()) 0)
return (0);
- sess-key = (caddr_t)key;
+ sess-key = (void*)key;
sess-keylen = ctx-key_len;
sess-cipher = cipher;
@@ -715,18 +722,6 @@ digest_nid_to_cryptodev(int nid)
}
-static int
-digest_key_length(int nid)
-{
- int i;
-
- for (i = 0; digests[i].id; i++)
- if (digests[i].nid == nid)
- return digests[i].keylen;
- return (0);
-}
-
-
static int cryptodev_digest_init(EVP_MD_CTX *ctx)
{
struct dev_crypto_state *state = ctx-md_data;
@@ -737,7 +732,6 @@ static int cryptodev_digest_init(EVP_MD_CTX *ctx)
printf(cryptodev_digest_init: Can't get digest \n);
return (0);
}
-
memset(state, 0, sizeof(struct dev_crypto_state));
if ((state-d_fd = get_dev_crypto()) 0) {
@@ -745,8 +739,8 @@ static int cryptodev_digest_init(EVP_MD_CTX *ctx)
return (0);
}
- sess-mackey = state-dummy_mac_key;
- sess-mackeylen = digest_key_length(ctx-digest-type);
+ sess-mackey = NULL;
+ sess-mackeylen = 0;
sess-mac = digest;
if (ioctl(state-d_fd, CIOCGSESSION, sess) 0) {
@@ -762,8 +756,8 @@ static int cryptodev_digest_init(EVP_MD_CTX *ctx)
static int cryptodev_digest_update(EVP_MD_CTX *ctx, const void *data,
size_t count)
{
- struct crypt_op cryp;
struct
Re: [openssl.org #3415] Bug report: Uninitialized memory reads reported by valgrind for ECDSA signatures
On Čt, 2014-07-03 at 23:47 +0200, Matt Caswell via RT wrote: I've put together a fix (see below), but not pushed it because I was working on the assumption that if you had PURIFY defined then you wouldn't care about constant time operation. I've since been told that possibly some distros define PURIFY in their production builds. Anyone know of an example where this is used in a production build? We use -DPURIFY in regular openssl packages in Red Hat Enterprise Linux and Fedora. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Website Contribution
Hi; I'm a big fan of static pages. They cache easily. They can run from a local disk. What are your thoughts on Doxygen? Allan -- misspelled on my iDevice ; +1-424-242-2668 On Jul 3, 2014, at 11:55, Michael \Croydon\ K. g...@rvapps.org wrote: Of course WML is just a tool which generates in the end the HTML, CSS and JS output. And we need a dynamic generation in the background. Pure HTML + CSS is pure pain and a lot worse than the current state. Means a no-go. But WML is a bit outdated and does very likely stopping people from sending patches/commit. So in my opinion there are basically two options: 1. Modernize just the front-end and keep WML. Create a nicer design without images, don't use inline css ... 2. Replace WML with something better AND modernize the front-end. In this case I suggesting strongly PHP. When Im looking into the web repo I'm sure the porting to PHP is going very fast since the website itself is very static right now. This should also make it easier to maintain the content in the long-run. I would prefer to refactoring the website completely. But no matter what, to bring a bit more life into it, GitHub can help. -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If there's genuine interest in modernising the OpenSSL website with HTML CSS instead of wml I'd be willing to code something up. I can't promise to work particularly quickly, but if there's a desire to generate a new website design I'm certainly willing to chuck a decent amount of time into making that happen. I could always make it a Github project and that way folks could just chip in where they wanted to. On copyright grounds we'd probably need permission from Steve H or Steve M to do that on Github, given that we'd be touching the OpenSSL 'brand' and such. Dominyk Sent from Thunderbird for OS X. My PGP public key is automatically attached to this email. On 29/06/2014 04:01, Salz, Rich wrote: The website is written using a tool called wml. It would be great if someone wanted to make it more modern and properly use things like CSS. Then it might make sense to put it into a github repository. Want to volunteer? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��IϮ��r�m (���Z+�7�zZ)���1���x ��h���W^��^��%�� -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTsF6LAAoJEIclJNuddDJspRgP/0YX6PEHy6oczGtnyaWJYtH8 FRsGE8HA2lZroNEPfTQxJTr+vBsMNf3+rofM2k5BGAkQwhpil/bEW32vzGR/KzZm cr9giZntzLcF+GKIgl7pftJeWUu3F/IVHHdgiMQgjNSgLh7LTRxiQb+s1l4XJHCN 7FSwqASD0Bs4UGRJi955F2NyPmjJ1OkBLDzeoLLrOfc/ez221asy/Aa2YWDRJb78 0gKF8X9sOfChb/Uc4/xnq9imof1X5hfrA6ohRHLiFw9dKKf7Mq44EvgzMAyWjqYC vGURh+vEvQi6v3jvbs7soZPQ43Vm8qdNy8rfPtX5kCQAR+liPLuI/tNVcIqLGhYD LWaOejmqo1wYE7UPfBvxYKuIJFHliFSTCtmfcvbyj4KTLP4jh5B/bipI2ckR3aIb KoaH0mmDi3sAq7P6IRjs4HWHAXbN9trb/t55ocyFKxc8RY1gtdPy6hQghU6RnOx8 MdKe/Y1kpTjFx8e4rroUsU83xciXn73MIeGwsgewisEOKmES9CokXWF+CgFGsAdF J/IB9uNhoy5o3+g73aMDZzH00EjUA84W9/q62OKmB+WC9dXWYSjO+DiQAxhBOOlF w+nT6nft2rHSeKhaWIOwVm+HEPkxp807vuD3htLgykhSOEDV0DKYTtUNm9ZYkErM 2KL4PydPD0WkamgBj4MC =wrlC -END PGP SIGNATURE- __ 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 #3429] PATCH: Update to X509_check_host documentation
Viktor graciously took the time to explain some of the finer details of the new name matching API (see http://www.mail-archive.com/openssl-users@openssl.org/msg74281.html). The discussion was helpful to me, and would likely be helpful to others. The patch incorporates Viktor's comments, and includes a description and examples of the default matching behavior for X509_check_host(). It also improves flow by breaking the first large paragraph on into two separate prargraphs. The patch also adds a NOTES sections for three topics that did not appear to belong in the description body. The notes section states policies are not applied with the new functions, and extended error information is not available. Finally two additional cross references were added for SSL_get_peer_certificate and X509_verify_cert. * diff --git a/doc/crypto/X509_check_host.pod b/doc/crypto/X509_check_host.pod index 113861d..cfbbe82 100644 --- a/doc/crypto/X509_check_host.pod +++ b/doc/crypto/X509_check_host.pod @@ -18,25 +18,29 @@ X509_check_host, X509_check_email, X509_check_ip, X509_check =head1 DESCRIPTION -The certificate matching functions are intended to be called to check -if a certificate matches a given host name, email address, or IP -address. The validity of the certificate and its trust level has to -be checked by other means. +The certificate matching functions are used to check if a certificate +matches a given host name, email address, or IP address. The +validity of the certificate and its trust level has to be checked by +other means. X509_check_host() checks if the certificate matches the specified -host name, which must be encoded in the preferred name syntax -described in section 3.5 of RFC 1034. Per section 6.4.2 of RFC 6125, -Bname values representing international domain names must be given -in A-label form. The Bnamelen argument must be the number of -characters in the name string or zero in which case the length is -calculated with strlen(name). When Bname starts with a dot (e.g -.example.com), it will be matched by a certificate valid for any -sub-domain of Bname, (see also BX509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS -below). Applications are strongly advised to use -X509_VERIFY_PARAM_set1_host() in preference to explicitly calling -LX509_check_host(3), hostname checks are out of scope with the -DANE-EE(3) certificate usage, and the internal check will be -suppressed as appropriate when DANE support is added to OpenSSL. +host name, which can be supplied in the Common Name (CN) or Subject +Alternate Name (SAN). By default, wildcards are supported and they +match only in the left-most label; but they may match part of that +label with an explicit prefix or suffix. For example, by default, a +host name of www.example.com would match *.example.com, +w*.example.com or *w.example.com. The host name must be encoded +in the preferred name syntax described in section 3.5 of RFC 1034. +The default behavior can be changed with the flags discussed below. + +In accordance with section 6.4.2 of RFC 6125, Bname values +representing international domain names must be given in A-label +form. The Bnamelen argument must be the number of characters +in the name string or zero in which case the length is calculated +with strlen(name). If Bname starts with a dot (e.g .example.com), +then it will be matched by a certificate valid for any sub-domain +of Bname, (see also BX509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS +below). X509_check_email() checks if the certificate matches the specified email address. Only the mailbox syntax of RFC 822 is supported, @@ -105,6 +109,24 @@ and -1 for an internal error: typically a memory allocation X509_check_ip_asc() can also return -2 if the IP address string is malformed. +=head1 NOTES + +Applications are encouraged to use X509_VERIFY_PARAM_set1_host() +rather than explicitly calling LX509_check_host(3). Host name +checks are out of scope with the DANE-EE(3) certificate usage, +and the internal checks will be suppressed as appropriate when +DANE support is added to OpenSSL. + +The certificate matching functions do Bnot use policies when evaluating +certificates. Policies are the responsibility of the calling application. +For example, X509_check_host() does not fail Iif the certificate is +declared as Extended Validation by the issuer but includes a wildcard +domain name. + +There is no way to determine the reason for the failure if the certificate +matching functions fail. That is, there is no extended error information +provided to the caller. + =head1 SEE ALSO LSSL_get_verify_result(3)|SSL_get_verify_result(3), @@ -112,7 +134,9 @@ LX509_VERIFY_PARAM_set1_host(3)|X509_VERIFY_PARAM_set1_host LX509_VERIFY_PARAM_add1_host(3)|X509_VERIFY_PARAM_add1_host(3), LX509_VERIFY_PARAM_set1_email(3)|X509_VERIFY_PARAM_set1_email(3), LX509_VERIFY_PARAM_set1_ip(3)|X509_VERIFY_PARAM_set1_ip(3), -LX509_VERIFY_PARAM_set1_ipasc(3)|X509_VERIFY_PARAM_set1_ipasc(3)
[openssl.org #3430] ssltest fails when using -DTEMP_GOST_TLS
Hi, when I compile using the -DTEMP_GOST_TLS flag and the enable-GOST flag openssl compiles succesfully. The ssltest fails however. This happens on the current (04-07-2014) master branch, as well as the current (04-07-2014) OpenSSL_1_0_2-stable branch (the only branches I have tested so far with this issue), on a linux-elf platform as well as mingw64 (Windows). Output during ssltest: Testing GOST-GOST94 Available compression methods: NONE ERROR in CLIENT 1075452872:error:140830B5:SSL routines:ssl3_client_hello:no ciphers available:s3_clnt.c:863: SSLv3, cipher (NONE) (NONE) 1 handshakes of 256 bytes done Failed GOST-GOST94 It fails ssltest on GOST-MD5 as well: $./ssltest -cipher GOST-MD5 Available compression methods: NONE ERROR in CLIENT 3076066056:error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available:s23_clnt.c:522: TLSv1.2, cipher (NONE) (NONE) 1 handshakes of 256 bytes done The GOST ciphers show up in the cipher list, but with 'unknown' fields. $ openssl ciphers -v -l 'ALL' |grep -i gost GOST-GOST94 SSLv3 Kx=RSA Au=RSA Enc=unknown Mac=unknown GOST-MD5SSLv3 Kx=RSA Au=RSA Enc=unknown Mac=MD5 The GOST engine itself loads without errors: $ openssl engine gost - -t -c (gost) Reference implementation of GOST engine [gost89, gost89-cnt, md_gost94, gost-mac, gost94, gost2001, gost-mac] [ available ] CRYPT_PARAMS: OID of default GOST 28147-89 parameters (input flags): STRING Am I doing something wrong here, is this expected behaviour, or is the GOST (SSL/TLS) implementation currently broken ? Thanks, Peter Mosmans __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3431] typo (?) in crypto/sha/asm/sha512-x86_64.pl
Hi,
As of 04-07-2014, the latest version of crypto/sha/asm/sha512-x86_64.pl
(commit 29be3f6411) in the master branch shows the following at line 2309:
$code.=___ if ($SZ==4 $shext);
Seeing that the variable $shext doesn't exist, but $shaext does, this
might be a typo.
Please find a (micro)patch attached to change this line to the following:
$code.=___ if ($SZ==4 $shaext);
Cheers,
Peter Mosmans
diff --git a/crypto/sha/asm/sha512-x86_64.pl b/crypto/sha/asm/sha512-x86_64.pl
index 9941da9..eef5f3f 100755
--- a/crypto/sha/asm/sha512-x86_64.pl
+++ b/crypto/sha/asm/sha512-x86_64.pl
@@ -2306,7 +2306,7 @@ $code.=___;
.rva.LSEH_end_$func
.rva.LSEH_info_$func
___
-$code.=___ if ($SZ==4 $shext);
+$code.=___ if ($SZ==4 $shaext);
.rva.LSEH_begin_${func}_shaext
.rva.LSEH_end_${func}_shaext
.rva.LSEH_info_${func}_shaext
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote:
On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
and 96, or ?:
The line before that:
dp=d;
l2c(v0,dp);--- Uninitialized variable: d
l2c(v1,dp);--- Uninitialized variable: d
while (l--)
{
if (n == 0)
{
DES_encrypt1(ti,schedule,DES_ENCRYPT);
dp=d;
t=ti[0]; l2c(t,dp);
t=ti[1]; l2c(t,dp);
save++;
}
*(out++)= *(in++)^d[n];--- Uninitialized variable: d
n=(n+1)0x07;
}
d is uninitialized, but it's being written to, not read from,
so I don't see a problem with this.
What?
So l2c is:
#define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
*((c)++)=(unsigned char)(((l) 8L)0xff), \
*((c)++)=(unsigned char)(((l)16L)0xff), \
*((c)++)=(unsigned char)(((l)24L)0xff))
It reads v0 and v1 and writes to d (dp). d being uninitialized
shouldn't be an issue. Or am I missing something?
It writes to *d, surely? Which means d uninitialised is very much an issue, no?
However, now I've read the code (it'd help if people posted enough
snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
array, so the diagnosis is basically incorrect. And therefore I agree
with you, not a problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
It'd be nice, btw, if someone would report the bug to cppcheck.
On 4 July 2014 10:15, Ben Laurie b...@links.org wrote:
On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote:
On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
and 96, or ?:
The line before that:
dp=d;
l2c(v0,dp);--- Uninitialized variable: d
l2c(v1,dp);--- Uninitialized variable: d
while (l--)
{
if (n == 0)
{
DES_encrypt1(ti,schedule,DES_ENCRYPT);
dp=d;
t=ti[0]; l2c(t,dp);
t=ti[1]; l2c(t,dp);
save++;
}
*(out++)= *(in++)^d[n];--- Uninitialized variable: d
n=(n+1)0x07;
}
d is uninitialized, but it's being written to, not read from,
so I don't see a problem with this.
What?
So l2c is:
#define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
*((c)++)=(unsigned char)(((l) 8L)0xff), \
*((c)++)=(unsigned char)(((l)16L)0xff), \
*((c)++)=(unsigned char)(((l)24L)0xff))
It reads v0 and v1 and writes to d (dp). d being uninitialized
shouldn't be an issue. Or am I missing something?
It writes to *d, surely? Which means d uninitialised is very much an issue,
no?
However, now I've read the code (it'd help if people posted enough
snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
array, so the diagnosis is basically incorrect. And therefore I agree
with you, not a problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
- Original Message - From: Wilfried Klaebe w+...@chaos.in-kiel.de To: openssl-dev@openssl.org Sent: Thursday, 3 July, 2014 11:42:08 PM Subject: Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions Am Thu, Jul 03, 2014 at 07:20:46PM +0200 schrieb Kurt Roeckx: On Thu, Jul 03, 2014 at 08:08:52AM -0400, Hubert Kario wrote: - Original Message - From: Benny Baumann be...@geshi.org To: openbsd-t...@openbsd.org, openssl-dev@openssl.org Sent: Wednesday, 2 July, 2014 8:49:18 PM Subject: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions Hi folks, I know the following patches will cause a controversy just like the issues they resolve caused me and several other people headaches when debugging them. But first things first. The attached patches (intentionally) do the following two things: 1. Adjust the limit for maximum allowed size of a received public key to be increased from 516 bytes (just barely enough for 4 KBit RSA public keys) up to 8200 bytes (enough for 64KBit RSA keys with some minor margin) 2. Remove the crippling of the DH/DSA routines for working with at most 10kBit parameters. Current general recommendation is that if you require more than 128 bit security you shouldn't be using RSA or DHE in the first place but use ECC. You'd need someone signing your ECC certificates though. There are generally trusted CAs that have 4k keys? I haven't seen one. There certainly isn't one in the Mozilla trust store. on the other hand, I see 5 384 bit ECC roots... I also saw few websites in the wild that were using them, so they are using them for signing I won't even mention the whole issue of actually configuring TLS for more than 128 bit security... I've had a request in Debian about this too for someone using a 16384 bit key. Some two people using a 8192 and a 8200 bit CAcert signed RSA certificate. One of them me and the other one the author and submitter of these patches. If the root that performs signing (CAcert) is using 4096 bit RSA key and you're using DHE or ECDHE you won't gain anything from going over 4096 bit for the server certificate... The weakest link will be the CA key one way or another. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Preventing the next Heartbleed
Interesting paper by David Wheeler: http://www.dwheeler.com/essays/heartbleed.html. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On Fri, Jul 04, 2014 at 08:38:23AM +0200, Kurt Roeckx wrote:
On Fri, Jul 04, 2014 at 08:21:15AM +0200, Otto Moerbeek wrote:
On Thu, Jul 03, 2014 at 11:35:15PM +0200, Kurt Roeckx wrote:
On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf F?rster via RT wrote:
I think cppcheck is right here in void DES_ofb64_encrypt(), line 84,
85
and 96, or ?:
The line before that:
dp=d;
l2c(v0,dp);--- Uninitialized variable: d
l2c(v1,dp);--- Uninitialized variable: d
while (l--)
{
if (n == 0)
{
DES_encrypt1(ti,schedule,DES_ENCRYPT);
dp=d;
t=ti[0]; l2c(t,dp);
t=ti[1]; l2c(t,dp);
save++;
}
*(out++)= *(in++)^d[n];--- Uninitialized variable: d
n=(n+1)0x07;
}
d is uninitialized, but it's being written to, not read from,
so I don't see a problem with this.
What?
So l2c is:
#define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
*((c)++)=(unsigned char)(((l) 8L)0xff), \
*((c)++)=(unsigned char)(((l)16L)0xff), \
*((c)++)=(unsigned char)(((l)24L)0xff))
It reads v0 and v1 and writes to d (dp). d being uninitialized
shouldn't be an issue. Or am I missing something?
Yes, c (which is d) is both incremented and dereferenced.
So we have:
DES_cblock d;
which as far as I know really is:
unsigned char d[8];
and:
register unsigned char *dp=d;
*((dp)++) = foo;
d is a valid pointer, but the content it points to is
uninitialized. We end up writing to d[0], d[1], ..., d[7]. I
don't see us reading it, nor do I see a problem with it.
Kurt
OK, but then d *is* initialized. It would cause less confusion if
you'd make a difference between d and *d in your comments.
-Otto
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3432]
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3430] ssltest fails when using -DTEMP_GOST_TLS
when I compile using the -DTEMP_GOST_TLS flag What the reason to do it? GOST TLS (at least that one what works) do not require this to be defined.
Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Kurt, Am 04.07.2014 00:41, schrieb Kurt Roeckx: On Thu, Jul 03, 2014 at 11:42:08PM +0200, Wilfried Klaebe wrote: Am Thu, Jul 03, 2014 at 07:20:46PM +0200 schrieb Kurt Roeckx: On Thu, Jul 03, 2014 at 08:08:52AM -0400, Hubert Kario wrote: - Original Message - From: Benny Baumann be...@geshi.org To: openbsd-t...@openbsd.org, openssl-dev@openssl.org Sent: Wednesday, 2 July, 2014 8:49:18 PM Subject: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions Hi folks, I know the following patches will cause a controversy just like the issues they resolve caused me and several other people headaches when debugging them. But first things first. The attached patches (intentionally) do the following two things: 1. Adjust the limit for maximum allowed size of a received public key to be increased from 516 bytes (just barely enough for 4 KBit RSA public keys) up to 8200 bytes (enough for 64KBit RSA keys with some minor margin) 2. Remove the crippling of the DH/DSA routines for working with at most 10kBit parameters. Current general recommendation is that if you require more than 128 bit security you shouldn't be using RSA or DHE in the first place but use ECC. You'd need someone signing your ECC certificates though. There are CAs doing ECC certificates. I see about 100 that trace back to the mozilla certificate store. They might not be popular, but it does exist and is being used. Sure. But still people are free to choose their CA for other parameters. Also people ARE using 8192 RSA certificates in the wild and with server certificates this is no problem. Currently things break horrible with client certificates of this size - for NO good reason. Just generating 16k DH params takes inordinate amount of time. With 4096 bit DH parameters I'm getting less than 20 key exchanges a second with a fast i7 CPU. I'd hazard a guess that with 16k DH you'll be able to do less than 1 key exchange a second. That's a very neat way to DoS your server. That's why Benny suggested making the limit configurable instead of flatly raising it. But the patch just raises the limit to something I think you shouldn't consider using. If you read my first mail you /might/ have found a paragraph stating that I'm well open for discussion given one of two things is honored with the choosen solution: 1. Either do a fix limit at 65536 Bit (as it's now) 2. OR do a dynamic limit with a default at the next level above the currently wide used size (8192 Bit) With the first option I offered a limit as low as 16384 Bit which unfortunately due to it's implementation affects all public keys transmitted to the server. Not fixing this means having inconsistent behaviour between RSA and DSA when both offer similar strength - DSA being limited at 10k while RSA breaking at 4k. By adjusting the limit you could get this to at least be consistently breaking at 16k regardless of whether you use RSA or DSA. Unfortunately adjusting DSA also involves adjusting DH, because the limit is implemented *in*the*bignum*library* - one of the worst places to do so. That's why I said DSA/DH is crippled: You just might want to allow arbitrary sizes for keys in the offline case and limit things in the online case - if you are at arguing with the performance part of things. According to the NIST recommendations (http://www.keylength.com/en/4/), 16384 bit would be close to the 15360 bit if you want to reach the 256 bit level. But there currently is no way to reach the 256 level with TLS as far as I know. The best you can currently do is 192 bit, which The most you can get is 192 Bit using SHA384 based ciphers with either RSA, DSA or EC curve P-571. would be a 7680 assymetric key. So I think that anything above 8192 bit doesn't make any sense at the moment. Granted. 8k is the max I currently use and what I have seen in the wild - but 8192 bit IS being used to a point where it starts to matter. Considering that #319 is unresolved for nearly 12 years now, and part 1 of this patch would at least mitigate that one for quite some time into the future, could the OpenSSL Project please apply at least that one really soon now, please? It got applied 12 years ago? Just not to the limit you want now. Nope. It was fixed in 2004 earliest if I read the comments in that ticket correctly. And even then it took them TWO YEARs two change one number holding everyone back Wouldn't it be better to be proactive here and be one step ahead by allowing 8192 Bit certificates if people really want to use them (and I WANT to use them). The current limit is breaking software and thus it IS a bug. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -BEGIN
Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions
- Original Message - From: Benny Baumann be...@geshi.org To: openssl-dev@openssl.org Sent: Friday, July 4, 2014 10:28:07 AM Subject: Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 03.07.2014 14:08, schrieb Hubert Kario: I won't even mention the whole issue of actually configuring TLS for more than 128 bit security... The most difficult thing in getting the configuration above 128 bit was less to generate appropriate key material, but to figure out in which ways the cipher suite setup API breaks - having GnuTLS less broken in this regard than OpenSSL. (Valid for recent versions of GnuTLS) SECURE256:-CIPHER-ALL:+COMP-DEFLATE:-MAC-ALL:!MD5:!ANON-DH:-3DES-CBC:-CAMELLIA-256-CBC:!CAMELLIA-128-CBC:-AES-256-CBC:!AES-128-CBC:+VERS-TLS1.2:+VERS-TLS1.1:+AEAD:+SHA512:+SHA384:+SHA256:+AES-256-GCM:+SHA1:+VERS-TLS1.0:-DHE-RSA:-RSA:+DHE-RSA:+DHE-DSS:+RSA:+SRP:+CAMELLIA-256-CBC:+AES-256-CBC:-VERS-SSL3.0:%SERVER_PRECEDENCE Not to mention that SECURE_256_ still contains 192 bit ciphers. sorry, but with TLS 1.0 security level of 192 bit or higher is impossible, please read the RFCs to understand why. Used cipher suites is just one step in at least 5 step process and it's actually one of the simplest. in short: You are ramping just two or three dials up to 11 in a system in which _all_ the elements need to be above your target level of security. Giving the option to set them to 11 makes other users vulnerable to DoS attacks. This makes the change really questionable. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On 07/04/2014 11:17 AM, Ben Laurie wrote:
It'd be nice, btw, if someone would report the bug to cppcheck.
http://5.150.254.56:443/trac-cppcheck/ticket/5970#ticket
Thx
On 4 July 2014 10:15, Ben Laurie b...@links.org wrote:
On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote:
On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
and 96, or ?:
The line before that:
dp=d;
l2c(v0,dp);--- Uninitialized variable: d
l2c(v1,dp);--- Uninitialized variable: d
while (l--)
{
if (n == 0)
{
DES_encrypt1(ti,schedule,DES_ENCRYPT);
dp=d;
t=ti[0]; l2c(t,dp);
t=ti[1]; l2c(t,dp);
save++;
}
*(out++)= *(in++)^d[n];--- Uninitialized variable: d
n=(n+1)0x07;
}
d is uninitialized, but it's being written to, not read from,
so I don't see a problem with this.
What?
So l2c is:
#define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
*((c)++)=(unsigned char)(((l) 8L)0xff), \
*((c)++)=(unsigned char)(((l)16L)0xff), \
*((c)++)=(unsigned char)(((l)24L)0xff))
It reads v0 and v1 and writes to d (dp). d being uninitialized
shouldn't be an issue. Or am I missing something?
It writes to *d, surely? Which means d uninitialised is very much an issue,
no?
However, now I've read the code (it'd help if people posted enough
snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
array, so the diagnosis is basically incorrect. And therefore I agree
with you, not a problem.
--
Toralf
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Website Contribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jekyll Sass are another two strong candidates IMO. Dom Sent from Thunderbird for OS X. My PGP public key is automatically attached to this email. On 03/07/2014 20:38, Allan Clark wrote: Hi; I'm a big fan of static pages. They cache easily. They can run from a local disk. What are your thoughts on Doxygen? Allan -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTtvlAAAoJEIclJNuddDJs+HAP/0z7lG1kiQheJhzkJu0O79fH 8U8H9AuDiYDnfSEqh1lKHUMF/lIdPUvk5Kcjntd1fOVNZiQ/0pUQP32VMuMmCGYv b9/qlXdJKTe/odxraAf2Zs/YK1sVqMWHpBvKwHMgfG0SW0r87FCYLd5R8j3nnCke xjxPA5ZsqXEB752I7pozSV34ymQqsI64a6Q2fyV8QP8QKkFuCQNKULMY+sTV/yL0 DVs6xjrUNf0NRepA4YFdhaue79UZHQqO0inoFZlGw/0jNBDcD++BpoBvvK2Jf2pZ w2y+U89bvOz9JjoyiHpiVDozJV9UasgqnOpvnkL0yppuav06wLs5kvSLEAnmETIq Ejt9sqfoVno9HGDl/gposmpBgmfR7r0Gvd8AhMQ6T7XH2TxKiHhmP6eveKL0kQx1 +GciscstHgQsbhHrBUhs/TWs9dmLbAiGAOBmLcZApECIoHVIrfHaLw3rupbHr6w0 N71j9ayRWvjIPbGQqfAjwFjENvldqlmnMYaDFDsG9rvcSj4IY730TXmbZhgt3Rm8 V2tL2zvg1lAChjpjJYg6KXoPp8v3/Hu968xuAaNgP4iVr1QaFA8a3qlfUYFM9y7j 8cuWmwco3INFjpwGodfXm1FHh+q7Ohei3RxLT52Mu4e5pcPvMwFCQ/DtiPSyJE40 WRFlPZw5msQLxiAmrbxf =GBPc -END PGP SIGNATURE- 0x9D74326C.asc Description: application/pgp-keys 0x9D74326C.asc.sig Description: Binary data
Re: [openssl.org #3433] ESXi 4.1 SSL Patch
On Fri, Jul 04, 2014 at 08:31:41PM +0200, Robin Kohler via RT wrote: Hi together I have an issue with the openssl version 0.9.8y. I would like to update the actually version 0.9.8y to 0.9.8.za, but I can't find any patches for an ESXi 4.1 Host. I installed a vmware patch, but the issue was not fixed. I read that the openssl version 0.9.8y is the last one for ESXi 4.1. Is that correct? So it's my understanding that vmware's ESXi includes openssl. I assume you can't actually compile and install openssl on it. So I think there is little we can do to help you and I think you should contact vmware about this instead. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On 4 July 2014 15:20, Toralf Förster toralf.foers...@gmx.de wrote:
On 07/04/2014 11:17 AM, Ben Laurie wrote:
It'd be nice, btw, if someone would report the bug to cppcheck.
http://5.150.254.56:443/trac-cppcheck/ticket/5970#ticket
Thanks.
Thx
On 4 July 2014 10:15, Ben Laurie b...@links.org wrote:
On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote:
On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org wrote:
On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
and 96, or ?:
The line before that:
dp=d;
l2c(v0,dp);--- Uninitialized variable: d
l2c(v1,dp);--- Uninitialized variable: d
while (l--)
{
if (n == 0)
{
DES_encrypt1(ti,schedule,DES_ENCRYPT);
dp=d;
t=ti[0]; l2c(t,dp);
t=ti[1]; l2c(t,dp);
save++;
}
*(out++)= *(in++)^d[n];--- Uninitialized variable: d
n=(n+1)0x07;
}
d is uninitialized, but it's being written to, not read from,
so I don't see a problem with this.
What?
So l2c is:
#define l2c(l,c)(*((c)++)=(unsigned char)(((l))0xff), \
*((c)++)=(unsigned char)(((l) 8L)0xff), \
*((c)++)=(unsigned char)(((l)16L)0xff), \
*((c)++)=(unsigned char)(((l)24L)0xff))
It reads v0 and v1 and writes to d (dp). d being uninitialized
shouldn't be an issue. Or am I missing something?
It writes to *d, surely? Which means d uninitialised is very much an issue,
no?
However, now I've read the code (it'd help if people posted enough
snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
array, so the diagnosis is basically incorrect. And therefore I agree
with you, not a problem.
--
Toralf
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3429] AutoReply: PATCH: Update to X509_check_host documentation
On Fri, Jul 04, 2014 at 10:50:47PM +0200, noloa...@gmail.com via RT wrote: Updated text for the patch based on Viktor's reply to JW and JB on the list. The updted text includes the a statement that its not possible to determine which named matched (this may be added in the future); and the two-label rule could make an application vulnerable to attacks on ccTLDs like *.co.uk (the two-label rule stops attacks on gTLDs like *.com). Should it mention publicsuffix.org? Or should we use that list? Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3429] AutoReply: PATCH: Update to X509_check_host documentation
On Sat, Jul 05, 2014 at 12:17:13AM +0200, Kurt Roeckx wrote: On Fri, Jul 04, 2014 at 10:50:47PM +0200, noloa...@gmail.com via RT wrote: Updated text for the patch based on Viktor's reply to JW and JB on the list. The updated text includes the a statement that its not possible to determine which named matched (this may be added in the future); and the two-label rule could make an application vulnerable to attacks on ccTLDs like *.co.uk (the two-label rule stops attacks on gTLDs like *.com). Should it mention publicsuffix.org? Or should we use that list? No and no. That responsibility lies with the issuing CA. The two label heuristic is not intended to be a robust generic-wildcard detection mechanism. The resposibility for correct issuance of wildcard certificates is on the CA. I will update the API to return the matched name from the certificate (via an additional char ** argument). -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3434] [PATCH] Add support for key wrapping mode with padding - RFC 5649
On Fri, Jul 04, 2014 at 08:33:36PM +0200, Petr Spacek via RT wrote: I tried to fully describe purpose and implementation directly in the code comments. This is no substitute for documentation. This patchset introduces new libcrypto API elements, which need to be documented. Please squash any commits whose separation does not substantially simplify review. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
