[openssl-dev] Problem with Commit 3fd181a8b5b85a1f7383e82438da494a08f7d843, Remove an option related to a deprecated flag.

2017-02-17 Thread John Hughes 
This commit removes the cms and smime "-nooldmime" option on the grounds 
that the flags they use "CMS_NOOLDMIMETYPE" and "PKCS7_NOOLDMIMETYPE" 
are not used in the pkcs7/cms code.


But those flags *are* used.

In include/openssl/pkcs7.h we have:

# define PKCS7_NOOLDMIMETYPE 0x400

And in include/openssl/cms.h:

# define CMS_NOOLDMIMETYPE   0x400

And include/openssl/smime.h

# define SMIME_OLDMIME   0x400

And, in crypto/pkcs7/pk7mime.c:

int SMIME_write_PKCS7(BIO *bio, PKCS7 *p7, BIO *data, int flags)
{
...
flags ^= SMIME_OLDMIME;

return SMIME_write_ASN1(bio, (ASN1_VALUE *)p7, data, flags,
ctype_nid, NID_undef, mdalgs,
ASN1_ITEM_rptr(PKCS7));

And, finally in crypto/asn1/asn_mime.c:

int SMIME_write_ASN1(BIO *bio, ASN1_VALUE *val, BIO *data, int flags,
 int ctype_nid, int econt_nid,
 STACK_OF(X509_ALGOR) *mdalgs, const ASN1_ITEM *it)
{
...
if (flags & SMIME_OLDMIME)
mime_prefix = "application/x-pkcs7-";
else
mime_prefix = "application/pkcs7-";


That is to say the effect of setting the flag CMS_NOOLDMIMETYPE or 
PKCS7_NOOLDMIMETYPE is to *unset* the flag SMIME_OLDMIME in calls to 
SMIME_write_ASN1, and so tell SMIME_write_ASN1 to write new-style mime 
headers "application/pkcs7-" instead of the horrid old 
"application/x-pkcs7-".


TL; DR -- the flags "CMS_NOOLDMIMETYPE" and "PKCS7_NOOLDMIMETYPE" *are* 
used, and shouldn't be deprecated.



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3454] remove OPENSSL_SYS_WIN constraint for EC_GFp_nistp224_method()

2016-06-13 Thread Rich Salz via RT 
fixed in master with commit b4b576d thanks!

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3454
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3100] [patch] remove some useless code in BN_uadd

2016-06-13 Thread Andy Polyakov via RT 
bn_add.c was modernized in
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7d6284057b66458f6c99bd65ba67377d63411090
and suggested modifications were "accumulated". Case is being dismissed.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3100
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] remove defines that access X.509 store

2016-04-23 Thread Roumen Petrov 

Hi,

Please find attached file 
"0004-remove-defines-X509_STORE_set_verify_.-as-context-is.patch" with a 
patch that removes two defines that access X.509 store members directly.


As the X509_STORE is opaque build of source that use those defines fail.

Regards,
Roumen
>From 32b59c4406581d9e0418ba9b61a1abe2044468ff Mon Sep 17 00:00:00 2001
From: Roumen Petrov <open...@roumenpetrov.info>
Date: Sat, 16 Apr 2016 19:10:19 +0300
Subject: [PATCH 4/4] remove defines X509_STORE_set_verify_... as context is
 now opaque

---
 include/openssl/x509_vfy.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/openssl/x509_vfy.h b/include/openssl/x509_vfy.h
index 4bf27e9..fa186a0 100644
--- a/include/openssl/x509_vfy.h
+++ b/include/openssl/x509_vfy.h
@@ -104,9 +104,6 @@ DEFINE_STACK_OF(X509_VERIFY_PARAM)
 
 int X509_STORE_set_depth(X509_STORE *store, int depth);
 
-# define X509_STORE_set_verify_cb_func(ctx,func) ((ctx)->verify_cb=(func))
-# define X509_STORE_set_verify_func(ctx,func)((ctx)->verify=(func))
-
 void X509_STORE_CTX_set_depth(X509_STORE_CTX *ctx, int depth);
 
 # define X509_STORE_CTX_set_app_data(ctx,data) \
-- 
1.8.4

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4408] [PATCH] Remove last traces of CRYPTO_dynlock for non-compatibility build

2016-03-12 Thread Rich Salz via RT 
fied; matt removed the dynlock reference.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4408
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4408] [PATCH] Remove last traces of CRYPTO_dynlock for non-compatibility build

2016-03-10 Thread David Woodhouse via RT 
Commit 2e52e7df5 ("Remove the old threading API") left a dummy definition
of the CRYPTO_dynlock for compatibility, if OPENSSL_API_COMPAT < 1.1.0.

However, there's still a DEFINE_STACK_OF(CRYPTO_dynlock) in cryptlib.h
which isn't so masked, and breaks the build if you disable the API
compatibility. Assuming that's supposed to be present too for the same
reason, wrap it in a similar #ifdef.
---
 crypto/include/internal/cryptlib.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/include/internal/cryptlib.h 
b/crypto/include/internal/cryptlib.h
index a97e20b..18d205e 100644
--- a/crypto/include/internal/cryptlib.h
+++ b/crypto/include/internal/cryptlib.h
@@ -82,7 +82,9 @@ typedef struct ex_callback_st EX_CALLBACK;
 
 DEFINE_STACK_OF(EX_CALLBACK)
 
+# if OPENSSL_API_COMPAT < 0x1010L
 DEFINE_STACK_OF(CRYPTO_dynlock)
+# endif
 
 typedef struct app_mem_info_st APP_INFO;
 DEFINE_LHASH_OF(APP_INFO);
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4408
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3700] [PATCH] remove CRYPTO_strdup, switch callers to BUF_strdup

2016-03-02 Thread Rich Salz via RT 
addressed in upcoming 1.1 release.
we went for consistency with OPENSLS_strdup, etc
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3700
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3647] Remove Heartbeat Extension entirely

2016-02-11 Thread Rich Salz via RT 
fixed with 22e3dcb7808bb06cd18c3231e34a5930e796cc48 in master. thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3647
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4297] [PATCH] remove double initialization of cryptodev engine

2016-02-08 Thread Cristian Stoica via RT 
From: Cristian Stoica 

cryptodev engine is initialized together with the other engines in
ENGINE_load_builtin_engines. The initialization done through
OpenSSL_add_all_algorithms is redundant.

Signed-off-by: Cristian Stoica 
---
 crypto/engine/eng_all.c | 12 
 crypto/engine/engine.h  |  4 
 crypto/evp/c_all.c  |  5 -
 util/libeay.num |  2 +-
 4 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/crypto/engine/eng_all.c b/crypto/engine/eng_all.c
index 48ad0d2..a198c5f 100644
--- a/crypto/engine/eng_all.c
+++ b/crypto/engine/eng_all.c
@@ -122,15 +122,3 @@ void ENGINE_load_builtin_engines(void)
 #endif
 ENGINE_register_all_complete();
 }
-
-#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-void ENGINE_setup_bsd_cryptodev(void)
-{
-static int bsd_cryptodev_default_loaded = 0;
-if (!bsd_cryptodev_default_loaded) {
-ENGINE_load_cryptodev();
-ENGINE_register_all_complete();
-}
-bsd_cryptodev_default_loaded = 1;
-}
-#endif
diff --git a/crypto/engine/engine.h b/crypto/engine/engine.h
index bd7b591..020d912 100644
--- a/crypto/engine/engine.h
+++ b/crypto/engine/engine.h
@@ -857,10 +857,6 @@ typedef int (*dynamic_bind_engine) (ENGINE *e, const char 
*id,
  */
 void *ENGINE_get_static_state(void);
 
-# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-void ENGINE_setup_bsd_cryptodev(void);
-# endif
-
 /* BEGIN ERROR CODES */
 /*
  * The following lines are auto generated by the script mkerr.pl. Any changes
diff --git a/crypto/evp/c_all.c b/crypto/evp/c_all.c
index a3ed00d..719e34d 100644
--- a/crypto/evp/c_all.c
+++ b/crypto/evp/c_all.c
@@ -82,9 +82,4 @@ void OPENSSL_add_all_algorithms_noconf(void)
 OPENSSL_cpuid_setup();
 OpenSSL_add_all_ciphers();
 OpenSSL_add_all_digests();
-#ifndef OPENSSL_NO_ENGINE
-# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-ENGINE_setup_bsd_cryptodev();
-# endif
-#endif
 }
diff --git a/util/libeay.num b/util/libeay.num
index 7f7487d..f4a72ec 100755
--- a/util/libeay.num
+++ b/util/libeay.num
@@ -2803,7 +2803,7 @@ BIO_indent  3242  
EXIST::FUNCTION:
 BUF_strlcpy 3243   EXIST::FUNCTION:
 OpenSSLDie  3244   EXIST::FUNCTION:
 OPENSSL_cleanse 3245   EXIST::FUNCTION:
-ENGINE_setup_bsd_cryptodev  3246   
EXIST:__FreeBSD__:FUNCTION:ENGINE
+ENGINE_setup_bsd_cryptodev  3246   NOEXIST::FUNCTION:
 ERR_release_err_state_table 3247   EXIST::FUNCTION:LHASH
 EVP_aes_128_cfb83248   EXIST::FUNCTION:AES
 FIPS_corrupt_rsa3249   NOEXIST::FUNCTION:
-- 
2.7.0


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4297
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2999] Incomplete fix to remove SSL3_RECORD->orig_len

2016-02-03 Thread Rich Salz via RT 
0.9.8? :) since been fixed.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4078] remove MDC2 support (1.1 dev branch)

2016-02-02 Thread Emilia Käsper via RT 
This was rejected by the team.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2016-01-17 Thread Salz, Rich 

> What about to remove declaration of FIPS_mode and FIPS_mode_set?
> Those functions could be used by external packages at configure time to
> detect that fips is not supported at all.
> Note 1.0.0 does not declare both functions.

For various reasons, the team wants them there.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2016-01-17 Thread Salz, Rich via RT 

> What about to remove declaration of FIPS_mode and FIPS_mode_set?
> Those functions could be used by external packages at configure time to
> detect that fips is not supported at all.
> Note 1.0.0 does not declare both functions.

For various reasons, the team wants them there.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2016-01-16 Thread Alessandro Ghedini via RT 
This has been (partially) fixed, so it can probably be closed.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2016-01-16 Thread Rich Salz via RT 
we did everything we want to do, closing this.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

2016-01-15 Thread Richard Levitte 
In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25 +0100, 
Rainer Jung <rainer.j...@kippdata.de> said:

rainer.jung> Hi,
rainer.jung> 
rainer.jung> the list of downloadable files on http://openssl.org/source/ 
contains
rainer.jung> pre1 *and* pre2 files for 1.1. Furthermore pre1 is listed above
rainer.jung> pre2. IMHO pre2 is what people should test and pre1 is no longer
rainer.jung> entitled to be listed on that page. So I suggest to remove pre1 
from
rainer.jung> the list.

You're entirely correct.  I'm going in and fixing now.

rainer.jung> I don't know how this list is maintained, if auto-generated or
rainer.jung> manually. It seems the web git is not public.

Our release script should have dealt with it, but it's possible we've
failed to adapt it the pre-release format files.  I'll have a look
later.

rainer.jung> In addition one could wish to put the preferred major version 
(1.0.2?)
rainer.jung> first in the list. Despite the version explanations in front of the
rainer.jung> list, it would help people to choose the right one. But of course 
what
rainer.jung> is preferred might change over time and is harder to automate with
rainer.jung> scripting.

Food for thought.  Not promising anything, but will certainly look
into it.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

2016-01-15 Thread Blumenthal, Uri - 0553 - MITLL 
On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte"
 wrote:

>In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25
>+0100, Rainer Jung  said:
>
>rainer.jung> In addition one could wish to put the preferred major
>version (1.0.2?)
>rainer.jung> first in the list. Despite the version explanations in front
>of the
>rainer.jung> list, it would help people to choose the right one. But of
>course what
>rainer.jung> is preferred might change over time and is harder to
>automate with
>rainer.jung> scripting.
>
>Food for thought.  Not promising anything, but will certainly look
>into it.

Another option is to have a “latest” symlink in that directory pointing to
the current/latest file to pick, updated as a new release appears on the
server…


smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

2016-01-15 Thread Rainer Jung 

Hi,

the list of downloadable files on http://openssl.org/source/ contains 
pre1 *and* pre2 files for 1.1. Furthermore pre1 is listed above pre2. 
IMHO pre2 is what people should test and pre1 is no longer entitled to 
be listed on that page. So I suggest to remove pre1 from the list.


I don't know how this list is maintained, if auto-generated or manually. 
It seems the web git is not public.


In addition one could wish to put the preferred major version (1.0.2?) 
first in the list. Despite the version explanations in front of the 
list, it would help people to choose the right one. But of course what 
is preferred might change over time and is harder to automate with 
scripting.


Thanks and regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

2016-01-15 Thread Richard Levitte 
In message  on Fri, 15 Jan 2016 18:38:32 +, 
"Blumenthal, Uri - 0553 - MITLL"  said:

uri> On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte"
uri>  wrote:
uri> 
uri> >In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25
uri> >+0100, Rainer Jung  said:
uri> >
uri> >rainer.jung> In addition one could wish to put the preferred major
uri> >version (1.0.2?)
uri> >rainer.jung> first in the list. Despite the version explanations in front
uri> >of the
uri> >rainer.jung> list, it would help people to choose the right one. But of
uri> >course what
uri> >rainer.jung> is preferred might change over time and is harder to
uri> >automate with
uri> >rainer.jung> scripting.
uri> >
uri> >Food for thought.  Not promising anything, but will certainly look
uri> >into it.
uri> 
uri> Another option is to have a “latest” symlink in that directory pointing to
uri> the current/latest file to pick, updated as a new release appears on the
uri> server…

We used to have that before we remade the site (for the better, all
things considered)...  it seems that got lost in the process.  I'll
look into it.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4117] [PATCH] Remove useless locking code

2016-01-12 Thread Rich Salz via RT 
commit done awhile ago.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4195] remove duplicates in util/libeay.num

2015-12-23 Thread Kurt Roeckx via RT 
On Tue, Dec 22, 2015 at 09:03:56AM +, Roumen Petrov via RT wrote:
> Hello,
> 
> After remove of some global variables in export file left double 

Patch applied.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4195] remove duplicates in util/libeay.num

2015-12-22 Thread Roumen Petrov via RT 
Hello,

After remove of some global variables in export file left double 
information for non existent functions.

For instance before:
X509_CERT_PAIR_it   3534 
EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
X509_CERT_PAIR_it   3534 
EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:

current:
X509_CERT_PAIR_it   35341_1_0 NOEXIST::FUNCTION:
X509_CERT_PAIR_it   35341_1_0 NOEXIST::FUNCTION:

Proposed patch removes duplicates.


Regards,
Roumen Petrov




>From 992be79410a3c909f4b1d2f492423aaf2c8a8454 Mon Sep 17 00:00:00 2001
From: Roumen Petrov <open...@roumenpetrov.info>
Date: Sat, 21 Mar 2015 15:29:25 +0200
Subject: [PATCH 2/2] remove duplicates in util/libeay.num

---
 util/libeay.num | 13 -
 1 file changed, 13 deletions(-)

diff --git a/util/libeay.num b/util/libeay.num
index e9a678b..bce6ca0 100755
--- a/util/libeay.num
+++ b/util/libeay.num
@@ -1951,7 +1951,6 @@ ENGINE_unregister_ciphers   2528	1_1_0	EXIST::FUNCTION:ENGINE
 ENGINE_get_ciphers  2529	1_1_0	EXIST::FUNCTION:ENGINE
 d2i_OCSP_BASICRESP  2530	1_1_0	EXIST::FUNCTION:
 KRB5_CHECKSUM_it2531	1_1_0	NOEXIST::FUNCTION:
-KRB5_CHECKSUM_it2531	1_1_0	NOEXIST::FUNCTION:
 EC_POINT_add2532	1_1_0	EXIST::FUNCTION:EC
 ASN1_item_ex_i2d2533	1_1_0	EXIST::FUNCTION:
 OCSP_CERTID_it  2534	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
@@ -1983,7 +1982,6 @@ X509_CRL_it 2555	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION
 X509_CRL_it 2555	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
 OCSP_BASICRESP_add_ext  2556	1_1_0	EXIST::FUNCTION:
 KRB5_ENCKEY_it  2557	1_1_0	NOEXIST::FUNCTION:
-KRB5_ENCKEY_it  2557	1_1_0	NOEXIST::FUNCTION:
 UI_method_set_closer2558	1_1_0	EXIST::FUNCTION:
 X509_STORE_set_purpose  2559	1_1_0	EXIST::FUNCTION:
 i2d_ASN1_GENERALSTRING  2560	1_1_0	EXIST::FUNCTION:
@@ -2193,7 +2191,6 @@ X509_ATTRIBUTE_it   2732	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:
 OCSP_ONEREQ_get_ext_by_NID  2733	1_1_0	EXIST::FUNCTION:
 PKCS12_decrypt_skey 2734	1_1_0	EXIST::FUNCTION:
 KRB5_AUTHENT_it 2735	1_1_0	NOEXIST::FUNCTION:
-KRB5_AUTHENT_it 2735	1_1_0	NOEXIST::FUNCTION:
 UI_dup_error_string 2736	1_1_0	EXIST::FUNCTION:
 RSAPublicKey_it 2737	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:RSA
 RSAPublicKey_it 2737	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:RSA
@@ -2211,7 +2208,6 @@ HMAC_CTX_reset  2747	1_1_0	EXIST::FUNCTION:
 ENGINE_get_digest   2748	1_1_0	EXIST::FUNCTION:ENGINE
 OCSP_RESPONSE_print 2749	1_1_0	EXIST::FUNCTION:
 KRB5_TKTBODY_it 2750	1_1_0	NOEXIST::FUNCTION:
-KRB5_TKTBODY_it 2750	1_1_0	NOEXIST::FUNCTION:
 ACCESS_DESCRIPTION_it   2751	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
 ACCESS_DESCRIPTION_it   2751	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
 PKCS7_ISSUER_AND_SERIAL_it  2752	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
@@ -2266,7 +2262,6 @@ ASN1_tag2bit2788	1_1_0	EXIST::FUNCTION:
 UI_method_set_flusher   2789	1_1_0	EXIST::FUNCTION:
 X509_ocspid_print   2790	1_1_0	EXIST::FUNCTION:
 KRB5_ENCDATA_it 2791	1_1_0	NOEXIST::FUNCTION:
-KRB5_ENCDATA_it 2791	1_1_0	NOEXIST::FUNCTION:
 ENGINE_get_load_pubkey_function 2792	1_1_0	EXIST::FUNCTION:ENGINE
 UI_add_user_data2793	1_1_0	EXIST::FUNCTION:
 OCSP_REQUEST_delete_ext 2794	1_1_0	EXIST::FUNCTION:
@@ -2485,7 +2480,6 @@ OCSP_url_svcloc_new 2973	1_1_0	EXIST::FUNCTION:
 ASN1_template_free  2974	1_1_0	NOEXIST::FUNCTION:
 OCSP_SINGLERESP_add_ext 2975	1_1_0	EXIST::FUNCTION:
 KRB5_AUTHENTBODY_it 2976	1_1_0	NOEXIST::FUNCTION:
-KRB5_AUTHENTBODY_it 2976	1_1_0	NOEXIST::FUNCTION:
 X509_supported_extension2977	1_1_0	EXIST::FUNCTION:
 i2d_KRB5_AUTHDATA   2978	1_1_0	NOEXIST::FUNCTION:
 UI_method_get_opener2979	1_1_0	EXIST::FUNCTION:
@@ -2587,13 +2581,11 @@ asn1_do_lock3059	1_1_0	NOEXIST::FUNCTION:
 PKCS7_ATTR_VERIFY_it3060	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
 PKCS7_ATTR_VERIFY_it3060	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
 KRB5_APREQBODY_it   3061	1_1_0	NOEXIST::FUNCTION:
-KRB5_APR

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2015-11-13 Thread Salz, Rich 

> So, does the above mean that my patch is not going to be merged?

No.  It will be.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2015-11-11 Thread Alessandro Ghedini 
On Sat, Oct 31, 2015 at 08:34:33am -0400, Steve Marquess wrote:
> On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote:
> > Hi,
> > 
> > I don't know what your intentions are with FIPS support in master, ...
> 
> We would like to continue to provide a FIPS validated module for the 1.1
> (and subsequent) releases. Unfortunately the current module ("OpenSSL
> FIPS Object Module 2.0") designed for compatibility with the 1.0
> releases won't be compatible with 1.1. That means we need to obtain a
> new validation for a new module, an endeavor fraught with many
> difficulties (none of them technical).
> 
> I do expect the stars will align for that eventually, as they have for
> the five previous open source based validations. In the interim, since
> the FIPS module is shaped almost entirely by policy and metaphysical
> considerations, we should not include any incomplete FIPS specific code
> in 1.1 -- code that even if complete in some speculative sense would
> also be unusable absent a matching FIPS 140-2 validation.

So, does the above mean that my patch is not going to be merged?

Cheers


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2015-10-31 Thread Steve Marquess 
On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote:
> Hi,
> 
> I don't know what your intentions are with FIPS support in master, ...

We would like to continue to provide a FIPS validated module for the 1.1
(and subsequent) releases. Unfortunately the current module ("OpenSSL
FIPS Object Module 2.0") designed for compatibility with the 1.0
releases won't be compatible with 1.1. That means we need to obtain a
new validation for a new module, an endeavor fraught with many
difficulties (none of them technical).

I do expect the stars will align for that eventually, as they have for
the five previous open source based validations. In the interim, since
the FIPS module is shaped almost entirely by policy and metaphysical
considerations, we should not include any incomplete FIPS specific code
in 1.1 -- code that even if complete in some speculative sense would
also be unusable absent a matching FIPS 140-2 validation.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2015-10-31 Thread Alessandro Ghedini via RT 
Hi,

I don't know what your intentions are with FIPS support in master, but after
the removal of most if the fips/ code, several bits and pieces of now broken
code have remained in the codebase. IMO it'd be better to just remove it for
now.

See the following GitHub pull request:
https://github.com/openssl/openssl/pull/449

Cheers

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2015-10-31 Thread Richard Levitte 
Can't recall previous discussions on this, but would it be possible to have a 
FIPS engine? 

Cheers 
Richard 

Steve Marquess  skrev: (31 oktober 2015 13:34:33 CET)
>On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote:
>> Hi,
>> 
>> I don't know what your intentions are with FIPS support in master,
>...
>
>We would like to continue to provide a FIPS validated module for the
>1.1
>(and subsequent) releases. Unfortunately the current module ("OpenSSL
>FIPS Object Module 2.0") designed for compatibility with the 1.0
>releases won't be compatible with 1.1. That means we need to obtain a
>new validation for a new module, an endeavor fraught with many
>difficulties (none of them technical).
>
>I do expect the stars will align for that eventually, as they have for
>the five previous open source based validations. In the interim, since
>the FIPS module is shaped almost entirely by policy and metaphysical
>considerations, we should not include any incomplete FIPS specific code
>in 1.1 -- code that even if complete in some speculative sense would
>also be unusable absent a matching FIPS 140-2 validation.
>
>-Steve M.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4117] [PATCH] Remove useless locking code

2015-10-31 Thread Alessandro Ghedini via RT 
Hi,

in commit 070c233 I didn't notice that the CRYPTO_w_lock()/CRYPTO_w_unlock()
calls are now useless, so I made a patch to fix that.

See the following GitHub pull request:
https://github.com/openssl/openssl/pull/454

Cheers

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2015-10-31 Thread Richard Levitte 


On October 31, 2015 2:09:50 PM GMT+01:00, Steve Marquess  
wrote:
>On 10/31/2015 09:01 AM, Richard Levitte wrote:
>> Can't recall previous discussions on this, but would it be possible
>to have a FIPS engine? 
>
>Of a sort, yes. I'll let Steve Henson speak to the details, but it is
>his hope (and mine) that FIPS module support for 1.1 and beyond would
>be
>modular so the FIPS module and OpenSSL releases would no longer be so
>tightly coupled.
>
>-Steve M.

I'm most certainly interested in such an effort. 
-- 
levi...@openssl.org 
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code

2015-10-31 Thread Steve Marquess 
On 10/31/2015 09:01 AM, Richard Levitte wrote:
> Can't recall previous discussions on this, but would it be possible to have a 
> FIPS engine? 

Of a sort, yes. I'll let Steve Henson speak to the details, but it is
his hope (and mine) that FIPS module support for 1.1 and beyond would be
modular so the FIPS module and OpenSSL releases would no longer be so
tightly coupled.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4078] remove MDC2 support (1.1 dev branch)

2015-10-08 Thread Emilia Käsper via RT 
Tracking ticket - if anyone has any concerns, please voice them now.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4019] [PATCH] dgst.pod: Remove redundant documentation of -hmac

2015-08-24 Thread Markus Rinne via RT 
Option -hmac was documented twice.

The issue was reported here:

https://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=3930
---
 doc/apps/dgst.pod | 5 -
 1 file changed, 5 deletions(-)

diff --git a/doc/apps/dgst.pod b/doc/apps/dgst.pod
index 236e1b7..b156097 100644
--- a/doc/apps/dgst.pod
+++ b/doc/apps/dgst.pod
@@ -13,7 +13,6 @@ Bopenssl Bdgst
 [B-hex]
 [B-binary]
 [B-r]
-[B-hmac arg]
 [B-non-fips-allow]
 [B-out filename]
 [B-sign filename]
@@ -64,10 +63,6 @@ output the digest or signature in binary form.
 
 output the digest in the coreutils format used by programs like Bsha1sum.
 
-=item B-hmac arg
-
-set the HMAC key to arg.
-
 =item B-non-fips-allow
 
 Allow use of non FIPS digest when in FIPS mode.  This has no effect when not in
-- 
1.8.4

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4019] [PATCH] dgst.pod: Remove redundant documentation of -hmac

2015-08-24 Thread Michel 


 Message d'origine 
De : Markus Rinne via RT r...@openssl.org 
Date :24/08/2015  17:42  (GMT+01:00) 
A :  
Cc : openssl-dev@openssl.org 
Objet : [openssl-dev] [openssl.org #4019] [PATCH] dgst.pod: Remove
redundant documentation of -hmac 

Option -hmac was documented twice.

The issue was reported here:

https://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=3930
---
doc/apps/dgst.pod | 5 -
1 file changed, 5 deletions(-)

diff --git a/doc/apps/dgst.pod b/doc/apps/dgst.pod
index 236e1b7..b156097 100644
--- a/doc/apps/dgst.pod
+++ b/doc/apps/dgst.pod
@@ -13,7 +13,6 @@ Bopenssl Bdgst
[B-hex]
[B-binary]
[B-r]
-[B-hmac arg]
[B-non-fips-allow]
[B-out filename]
[B-sign filename]
@@ -64,10 +63,6 @@ output the digest or signature in binary form.

output the digest in the coreutils format used by programs like Bsha1sum.

-=item B-hmac arg
-
-set the HMAC key to arg.
-
=item B-non-fips-allow

Allow use of non FIPS digest when in FIPS mode.  This has no effect when not in
-- 
1.8.4

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3820] [PATCH] Remove an unnecessary call to USER32!GetDesktopWindow

2015-05-02 Thread Rich Salz via RT 
OpenSSL_1_0_0-stable 6c63867 RT3820: Don't call GetDesktopWindow()
OpenSSL_1_0_1-stable ee827ad RT3820: Don't call GetDesktopWindow()
OpenSSL_1_0_2-stable a659386 RT3820: Don't call GetDesktopWindow()
master bed2edf RT3820: Don't call GetDesktopWindow()

Author: Gilles Khouzam gilles.khou...@microsoft.com
Date: Fri May 1 22:20:42 2015 -0400

RT3820: Don't call GetDesktopWindow()

Signed-off-by: Rich Salz rs...@openssl.org
Reviewed-by: Richard Levitte levi...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3820] [PATCH] Remove an unnecessary call to USER32!GetDesktopWindow

2015-04-25 Thread Gunnar Kudrjavets via RT 
Hello,

Summary: currently function LIBEAY32!OPENSSL_isservice() calls 
USER32!GetDesktopWindow() to determine if the code is running as a service or 
not. That function call is not necessary. Attached patch has the details.

Additional data:

1) Operating systems affected: all version of Windows.

2) OpenSSL versions affected: all versions running on Windows, starting Apr 7 
2005.

Thank you,
Gunnar Kudrjavets


From 7693250e03ea284c2fb3a565cd3cbceeb2512943 Mon Sep 17 00:00:00 2001
From: Gunnar Kudrjavets gunna...@microsoft.com
Date: Thu, 23 Apr 2015 13:22:49 -0700
Subject: [PATCH] Remove an unnecessary call to USER32!GetDesktopWindow

Currently function LIBEAY32!OPENSSL_isservice() calls GetDesktopWindow()
to determine if the code is running as a service or not. There are a couple
of issues with that:

1) That function call is not necessary and given that its result is ignored
then it can be removed from the code.

2) It introduces an unnecessary dependency on whatever binary happens to host
GetDesktopWindow() in some API Set on a particular version of Windows.

Testing performed:

1) Clean compilation for debug-VC-WIN32 and VC-WIN32.

2) Good test results (nmake -f ms\ntdll.mak test) for debug-VC-WIN32 and
VC-WIN32.

3) Stepped through relevant changes using WinDBG in cases when code was
both running as part of the service and not. Verified that the existing
behavior is maintained. The following OS-s were tested: Windows 8.1 Enterprise,
Windows Server 2012 R2 Datacenter, and Windows XP Version 2002 (SP 3 aka
5.1.2600). The test cases consisted of:

  *) Running a console application and verifying that OPENSSL_isservice()
 returns 0 as expected.

  *) Running a service containing code from OPENSSL_isservice() and verifying
 that the function returns 1 as expected.

The code to call GetDesktopWindow() was originally introduced as part of
9f2027e56d9e82dc89f079ed285d5571cbee5592.
---
 crypto/cryptlib.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/crypto/cryptlib.c b/crypto/cryptlib.c
index ce07b84..be4cdb0 100644
--- a/crypto/cryptlib.c
+++ b/crypto/cryptlib.c
@@ -288,8 +288,6 @@ int OPENSSL_isservice(void)
 if (_OPENSSL_isservice.p != (void *)-1)
 return (*_OPENSSL_isservice.f) ();
 
-(void)GetDesktopWindow();   /* return value is ignored */
-
 h = GetProcessWindowStation();
 if (h == NULL)
 return -1;
-- 
1.9.5.msysgit.1

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [PATCH] remove double initialization of cryptodev engine

2015-04-06 Thread Cristian Stoica 
cryptodev engine is initialized together with the other engines in
ENGINE_load_builtin_engines. The initialization done through
OpenSSL_add_all_algorithms is redundant.

Signed-off-by: Cristian Stoica cristian.sto...@freescale.com
---
 crypto/engine/eng_all.c | 12 
 crypto/engine/engine.h  |  4 
 crypto/evp/c_all.c  |  5 -
 util/libeay.num |  2 +-
 4 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/crypto/engine/eng_all.c b/crypto/engine/eng_all.c
index 7edf12e..8f5d1b2 100644
--- a/crypto/engine/eng_all.c
+++ b/crypto/engine/eng_all.c
@@ -125,15 +125,3 @@ void ENGINE_load_builtin_engines(void)
 #endif
 ENGINE_register_all_complete();
 }
-
-#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-void ENGINE_setup_bsd_cryptodev(void)
-{
-static int bsd_cryptodev_default_loaded = 0;
-if (!bsd_cryptodev_default_loaded) {
-ENGINE_load_cryptodev();
-ENGINE_register_all_complete();
-}
-bsd_cryptodev_default_loaded = 1;
-}
-#endif
diff --git a/crypto/engine/engine.h b/crypto/engine/engine.h
index e81096a..1c70250 100644
--- a/crypto/engine/engine.h
+++ b/crypto/engine/engine.h
@@ -858,10 +858,6 @@ typedef int (*dynamic_bind_engine) (ENGINE *e, const char 
*id,
  */
 void *ENGINE_get_static_state(void);
 
-# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-void ENGINE_setup_bsd_cryptodev(void);
-# endif
-
 /* BEGIN ERROR CODES */
 /*
  * The following lines are auto generated by the script mkerr.pl. Any changes
diff --git a/crypto/evp/c_all.c b/crypto/evp/c_all.c
index a3ed00d..719e34d 100644
--- a/crypto/evp/c_all.c
+++ b/crypto/evp/c_all.c
@@ -82,9 +82,4 @@ void OPENSSL_add_all_algorithms_noconf(void)
 OPENSSL_cpuid_setup();
 OpenSSL_add_all_ciphers();
 OpenSSL_add_all_digests();
-#ifndef OPENSSL_NO_ENGINE
-# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV)
-ENGINE_setup_bsd_cryptodev();
-# endif
-#endif
 }
diff --git a/util/libeay.num b/util/libeay.num
index b594caf..9eb2423 100755
--- a/util/libeay.num
+++ b/util/libeay.num
@@ -2803,7 +2803,7 @@ BIO_indent  3242  
EXIST::FUNCTION:
 BUF_strlcpy 3243   EXIST::FUNCTION:
 OpenSSLDie  3244   EXIST::FUNCTION:
 OPENSSL_cleanse 3245   EXIST::FUNCTION:
-ENGINE_setup_bsd_cryptodev  3246   
EXIST:__FreeBSD__:FUNCTION:ENGINE
+ENGINE_setup_bsd_cryptodev  3246   NOEXIST::FUNCTION:
 ERR_release_err_state_table 3247   EXIST::FUNCTION:LHASH
 EVP_aes_128_cfb83248   EXIST::FUNCTION:AES
 FIPS_corrupt_rsa3249   NOEXIST::FUNCTION:
-- 
2.3.5

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3779] [BUG][PATCH] Remove the second occurrence of -subj in the req man page

2015-04-01 Thread Erik Tews via RT 
Hi

The -subj parameter appears twice in the manpage of req for no reasons I
am aware of. This patch removes the second occurrence of the -subj
parameter. I have created a git commit and a git pull request for that
change.

https://github.com/openssl/openssl/pull/254
https://github.com/eriktews/openssl/commit/b338c639fcfbbaf5443598cf028da11dbfe79cd2

Attached is also a patch.

diff --git a/doc/apps/req.pod b/doc/apps/req.pod
index eb840be..513099f 100644
--- a/doc/apps/req.pod
+++ b/doc/apps/req.pod
@@ -30,7 +30,6 @@ Bopenssl Breq
 [B-keygen_engine id]
 [B-[digest]]
 [B-config filename]
-[B-subj arg]
 [B-multivalue-rdn]
 [B-x509]
 [B-days n]
@@ -213,13 +212,6 @@ this allows an alternative configuration file to be specified,
 this overrides the compile time filename or any specified in
 the BOPENSSL_CONF environment variable.
 
-=item B-subj arg
-
-sets subject name for new request or supersedes the subject name
-when processing a request.
-The arg must be formatted as I/type0=value0/type1=value1/type2=...,
-characters may be escaped by \ (backslash), no spaces are skipped.
-
 =item B-multivalue-rdn
 
 this option causes the -subj argument to be interpreted with full


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3563] remove team-member specific targets from Configure

2015-02-24 Thread Rich Salz via RT 
master f09e7ca Move build config table to separate files.

Author: Rich Salz rs...@openssl.org
Date: Tue Feb 24 17:40:22 2015 -0500

Move build config table to separate files.

Move the build configuration table into separate files. The Configurations
file is standard configs, and Configurations.team is for openssl-team
members. Any other file, Configurations*, found in the same directory
as the Configure script, is loaded.

To add another file, use --config=FILE flags (which should probably be
an absolute path).

Written by Stefen Eissing stefan.eiss...@greenbytes.de and Rich Salz
rs...@openssl.org, contributed by Akamai Technologies.

Reviewed-by: Richard Levitte levi...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3700] [PATCH] remove CRYPTO_strdup, switch callers to BUF_strdup

2015-02-13 Thread Cristian Rodríguez via RT 
No need to a keep a duplicate API.
---
 crypto/crypto.h  | 1 -
 crypto/jpake/jpake.c | 5 +++--
 crypto/mem.c | 8 
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/crypto/crypto.h b/crypto/crypto.h
index 9762398..7dd2223 100644
--- a/crypto/crypto.h
+++ b/crypto/crypto.h
@@ -366,7 +366,6 @@ int CRYPTO_is_mem_check_on(void);
 # define is_MemCheck_on() CRYPTO_is_mem_check_on()
 
 # define OPENSSL_malloc(num) CRYPTO_malloc((int)num,__FILE__,__LINE__)
-# define OPENSSL_strdup(str) CRYPTO_strdup((str),__FILE__,__LINE__)
 # define OPENSSL_realloc(addr,num) \
 CRYPTO_realloc((char *)addr,(int)num,__FILE__,__LINE__)
 # define OPENSSL_realloc_clean(addr,old_num,num) \
diff --git a/crypto/jpake/jpake.c b/crypto/jpake/jpake.c
index eb6654d..2492c1d 100644
--- a/crypto/jpake/jpake.c
+++ b/crypto/jpake/jpake.c
@@ -2,6 +2,7 @@
 #include openssl/crypto.h
 #include openssl/sha.h
 #include openssl/err.h
+#include openssl/buffer.h
 #include memory.h
 #include string.h
 
@@ -74,8 +75,8 @@ static void JPAKE_CTX_init(JPAKE_CTX *ctx, const char *name,
const BIGNUM *g, const BIGNUM *q,
const BIGNUM *secret)
 {
-ctx-p.name = OPENSSL_strdup(name);
-ctx-p.peer_name = OPENSSL_strdup(peer_name);
+ctx-p.name = BUF_strdup(name);
+ctx-p.peer_name = BUF_strdup(peer_name);
 ctx-p.p = BN_dup(p);
 ctx-p.g = BN_dup(g);
 ctx-p.q = BN_dup(q);
diff --git a/crypto/mem.c b/crypto/mem.c
index d059362..5173098 100644
--- a/crypto/mem.c
+++ b/crypto/mem.c
@@ -360,14 +360,6 @@ void *CRYPTO_malloc(int num, const char *file, int line)
 return ret;
 }
 
-char *CRYPTO_strdup(const char *str, const char *file, int line)
-{
-char *ret = CRYPTO_malloc(strlen(str) + 1, file, line);
-
-strcpy(ret, str);
-return ret;
-}
-
 void *CRYPTO_realloc(void *str, int num, const char *file, int line)
 {
 void *ret = NULL;
-- 
2.2.2


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1291] [PATCH] Remove old libdes support?

2015-02-02 Thread Rich Salz via RT 
commit 24956ca00f014a917fb181a8abc39b349f3f316f
Author: Rich Salz rs...@openssl.org
Date: Mon Feb 2 18:46:01 2015 -0500

Remove old DES API

Includes VMS fixes from Richard.
Includes Kurt's destest fixes (RT 1290).
Closes tickets 1290 and 1291

Reviewed-by: Kurt Roeckx k...@openssl.org
Reviewed-by: Richard Levitte levi...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3548] Remove some unsupported platforms

2015-01-13 Thread Rich Salz via RT 
Closed in a series of commits.
6d23cf97443bfedf755341b4f2d0d7fce254e020
fcf64ba0ace1bb76c6e00ca7d0c7cf7f9bebe628
b5526482ef81ee7906b967e326d23a45fbcf3abc
32dfde107636ac9bc62a5b3233fe2a54dbc27008
6c23ca0cbb0181f803f38694e3f25e53e409a238
5ad4fdce41bb1ce7762b70fb50f732f70e3772cf
f2319414445ef5991d77c015af86276d84b9fec1
e03b29871b2b87af9a4ec21c49eb3e1826eb772a
59ff1ce06108508eba0f289b295dd89582c9fbfc
b317819b2e74f1f84925695596aa3c7487a2264d

(Yeah, that's as clear as mud :)

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3647] Remove Heartbeat Extension entirely

2015-01-08 Thread Aaron Zauner via RT 
Hi,

It seems the DTLS heartbeat extension is still supported in current
OpenSSL versions (at least that's my impression while playing around
with `s_server` with verbose debug logging).

I've talked extensively to cryptographers and implementors about this
extension, I'm not aware of a single use case of DTLS heartbeats. WebRTC
applications are probably not going to rely on DTLS to manage /something
like/ heartbeats but will manage that on a application level. As far as
I know, most WebRTC clients do exactly that.

Going through your RT I could not find a appropriate bug filed for the
removal of this -- rather unnecessary -- extension (I'm sure there has
been discussion previously, but opening a bug seems reasonable). Please
correct me if I'm wrong.

Since the feature is in there, it might make more sense to have a
compile-time option to _enable_ DTLS heartbeats rather than to disable
them (which a lot of hosting companies and CDNs do right now).

Thanks for your consideration and time,
Aaron




signature.asc
Description: PGP signature
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3546] Remove IRIX_CC_BUG #ifdef's

2015-01-05 Thread Rich Salz via RT 
commit b5526482ef81ee7906b967e326d23a45fbcf3abc
Author: Rich Salz rs...@openssl.org
Date: Mon Jan 5 16:05:54 2015 -0500

RT3546: Remove #define IRIX_CC_BUG

Leftovers from commit 448155e9bbda27cbba365ff549a7e2044a8a399f
Remove now-unused #define's

Reviewed-by: Matt Caswell m...@openssl.org

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3544] Remove MWERKS support

2014-12-17 Thread Rich Salz via RT 
MWERKS added back to nw_rand.c
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3544] Remove MWERKS support

2014-12-17 Thread NormW 

Thanks!
Norm

On 18/12/2014 9:26 AM, Rich Salz via RT wrote:

MWERKS added back to nw_rand.c
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev



___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3544] Remove MWERKS support

2014-12-17 Thread NormW via RT 
Thanks!
Norm

On 18/12/2014 9:26 AM, Rich Salz via RT wrote:
 MWERKS added back to nw_rand.c
 --
 Rich Salz, OpenSSL dev team; rs...@openssl.org

 ___
 openssl-dev mailing list
 openssl-dev@openssl.org
 https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev



___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3543] Remove #ifdef LINT fluff

2014-12-10 Thread Rich Salz via RT 
master 5cf3795 RT3543: Remove #ifdef LINT

Author: Rich Salz rs...@openssl.org
Date: Tue Sep 23 13:23:09 2014 -0400

RT3543: Remove #ifdef LINT

I also replaced some exit/return wrappers in various
programs (from main) to standardize on return.

Reviewed-by: Richard Levitte levi...@openssl.org
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl.org #3544] Remove MWERKS support

2014-11-28 Thread Guenter via RT 
Hi Rich,
On 25.09.2014 00:09, Rich Salz via RT wrote:
 All sorts of pre-OSx mac support has been removed.

 commit 92c78463720f71e47c251ffa58493e32cd793e13
 Author: Rich Salz rs...@openssl.org
 Date: Wed Sep 24 12:18:19 2014 -0400

 RT3544: Remove MWERKS support

 The following #ifdef tests were all removed:
 __MWERKS__
 MAC_OS_pre_X
 MAC_OS_GUSI_SOURCE
 MAC_OS_pre_X
 OPENSSL_SYS_MACINTOSH_CLASSIC
 OPENSSL_SYS_MACOSX_RHAPSODY

 Reviewed-by: Andy Polyakov ap...@openssl.org

 Rich Salz, OpenSSL dev team; rs...@openssl.org
as already mentioned on the list the Metrowerks CodeWarrior for NetWare 
compiler also sets the __MWERKS__ macro - therefore please revert the 
changes to /crypto/rand/rand_nw.c of commit 
92c78463720f71e47c251ffa58493e32cd793e13 because this is a NetWare-only 
file and has nothing to do with your intention to remove old MAC_OS support.

Thanks!


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

RE: [openssl.org #3544] Remove MWERKS support

2014-11-28 Thread Salz, Rich 
Yes, I will revert the change.

RE: [openssl.org #3544] Remove MWERKS support

2014-11-28 Thread Salz, Rich via RT 
Yes, I will revert the change.

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

[openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits

2014-11-25 Thread Matt Caswell via RT 
Thanks for your submission. However Steve Henson has already commited a similar
patch, therefore closing this ticket.

Matt

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

Re: [openssl.org #3544] Remove MWERKS support

2014-11-13 Thread NormW 

On 30/10/2014 9:58 AM, NormW wrote:

G/M,
On 25/09/2014 2:09 AM, Rich Salz via RT wrote:

Not a supported platform, per our roadmap.

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


To be pendantic __MWERKS__ refers, AFAIK, to a compiler, and was the
compiler used by Novell aa the 'standard' for creating NetWare apps. As
I understand it (for the time being at least), support for NetWare is
being retained, it will be necessary to re-implement the

#ifdef __MWERKS__

section removed in .\crypto\rand\rand_nw.c ONLY, in the ossl trunk src.


To re-iterate: The patch changed in the following:
diff --git a/crypto/rand/rand_nw.c b/crypto/rand/rand_nw.c
index 17c1ea7..9239a72 100644 (file)
--- a/crypto/rand/rand_nw.c
+++ b/crypto/rand/rand_nw.c
@@ -154,13 +154,7 @@ int RAND_poll(void)

for( i=2; iENTROPY_NEEDED; i++)
{
-#ifdef __MWERKS__
-  asm
-  {
- rdtsc
- mov tsc, eax
-  }
-#elif defined(__GNUC__)  __GNUC__=2  !defined(OPENSSL_NO_ASM)  
!defined(OPENSSL_NO_INLINE_ASM)
+#if defined(__GNUC__)  __GNUC__=2  !defined(OPENSSL_NO_ASM)  
!defined(OPENSSL_NO_INLINE_ASM)

   asm volatile(rdtsc:=a(tsc)::edx);
 #endif



A review of all other __MWERKS__ code removed indicate they are only
used by MAC PC's.
Norm

__
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

Re: [openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits

2014-10-31 Thread Hubert Kario via RT 
On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote:
 Some SSLv3 parts (e.g. SSLv3 ciphers)

SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2

if you remove ciphers that are marked as SSLv3, you actually remove all 
ciphers that can be used with TLSv1.0 and TLSv1.1, as such, the only protocol 
version that will continue to work is TLSv1.2

I'm quite sure that's not the expected behaviour of no-ssl3 flag
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
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 #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits

2014-10-31 Thread Alin Năstac via RT 
That's odd, because I used a similar patch on an older openssl version
(one that doesn't know TLSv1.1 or TLSv1.2) on which I disabled support
on both SSLv2/SSLv3 and I was still able to use SSL clients and
servers linked with openssl library I built.

On Fri, Oct 31, 2014 at 11:45 AM, Hubert Kario via RT r...@openssl.org wrote:
 On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote:
 Some SSLv3 parts (e.g. SSLv3 ciphers)

 SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2

 if you remove ciphers that are marked as SSLv3, you actually remove all
 ciphers that can be used with TLSv1.0 and TLSv1.1, as such, the only protocol
 version that will continue to work is TLSv1.2

 I'm quite sure that's not the expected behaviour of no-ssl3 flag
 --
 Regards,
 Hubert Kario
 Quality Engineer, QE BaseOS Security team
 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 #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits

2014-10-31 Thread Kurt Roeckx via RT 
On Thu, Oct 30, 2014 at 11:26:15PM +0100, Alin Nastac via RT wrote:
 Some SSLv3 parts (e.g. SSLv3 ciphers) are built in  even if ssl3
 support is disabled.

SSLv3 ciphers are not specific to SSLv3, they can also be used
in TLS.

no-ssl3 doesn't disable the SSL3 methods.  That is, you can still
call SSLv3_client_method() and set up an SSLv3 connection with
that.  It assumes that if you say that you want an SSLv3
connection that that is really what you want.  There is work being
done to have an option to also disable that, that looks very
similar to your patch but then with a new configure option.


Kurt


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

Re: [openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits

2014-10-31 Thread Alin Năstac 
That's odd, because I used a similar patch on an older openssl version
(one that doesn't know TLSv1.1 or TLSv1.2) on which I disabled support
on both SSLv2/SSLv3 and I was still able to use SSL clients and
servers linked with openssl library I built.

On Fri, Oct 31, 2014 at 11:45 AM, Hubert Kario via RT r...@openssl.org wrote:
 On Thursday 30 October 2014 23:26:15 Alin Năstac via RT wrote:
 Some SSLv3 parts (e.g. SSLv3 ciphers)

 SSLv3 ciphers can be used with any version of TLS from TLSv1.0 to TLSv1.2

 if you remove ciphers that are marked as SSLv3, you actually remove all
 ciphers that can be used with TLSv1.0 and TLSv1.1, as such, the only protocol
 version that will continue to work is TLSv1.2

 I'm quite sure that's not the expected behaviour of no-ssl3 flag
 --
 Regards,
 Hubert Kario
 Quality Engineer, QE BaseOS Security team
 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

[openssl.org #3585] [PATCH] OPENSSL_NO_SSL3 doesn't remove all SSLv3 bits

2014-10-30 Thread Alin Năstac via RT 
Some SSLv3 parts (e.g. SSLv3 ciphers) are built in  even if ssl3
support is disabled.
Attached patch fixes it:

diff -Nru openssl-1.0.1j.orig/ssl/s3_clnt.c openssl-1.0.1j/ssl/s3_clnt.c
--- openssl-1.0.1j.orig/ssl/s3_clnt.c	2014-10-15 14:53:39.0 +0200
+++ openssl-1.0.1j/ssl/s3_clnt.c	2014-10-30 13:52:07.021038200 +0100
@@ -167,9 +167,9 @@
 #include openssl/engine.h
 #endif
 
-static const SSL_METHOD *ssl3_get_client_method(int ver);
 static int ca_dn_cmp(const X509_NAME * const *a,const X509_NAME * const *b);
 
+#ifndef OPENSSL_NO_SSL3
 static const SSL_METHOD *ssl3_get_client_method(int ver)
 	{
 	if (ver == SSL3_VERSION)
@@ -182,6 +182,7 @@
 			ssl_undefined_function,
 			ssl3_connect,
 			ssl3_get_client_method)
+#endif /* !OPENSSL_NO_SSL3 */
 
 int ssl3_connect(SSL *s)
 	{
diff -Nru openssl-1.0.1j.orig/ssl/s3_lib.c openssl-1.0.1j/ssl/s3_lib.c
--- openssl-1.0.1j.orig/ssl/s3_lib.c	2014-10-15 14:53:39.0 +0200
+++ openssl-1.0.1j/ssl/s3_lib.c	2014-10-30 13:52:07.022038285 +0100
@@ -169,6 +169,7 @@
 /* list of available SSLv3 ciphers (sorted by id) */
 OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={
 
+#ifndef OPENSSL_NO_SSL3
 /* The RSA ciphers */
 /* Cipher 01 */
 	{
@@ -883,6 +884,7 @@
 	128,
 	},
 #endif	/* OPENSSL_NO_KRB5 */
+#endif	/* OPENSSL_NO_SSL3 */
 
 /* New AES ciphersuites */
 /* Cipher 2F */
diff -Nru openssl-1.0.1j.orig/ssl/s3_meth.c openssl-1.0.1j/ssl/s3_meth.c
--- openssl-1.0.1j.orig/ssl/s3_meth.c	2014-10-15 14:51:06.0 +0200
+++ openssl-1.0.1j/ssl/s3_meth.c	2014-10-30 13:52:07.023038199 +0100
@@ -59,6 +59,7 @@
 #include stdio.h
 #include openssl/objects.h
 #include ssl_locl.h
+#ifndef OPENSSL_NO_SSL3
 
 static const SSL_METHOD *ssl3_get_method(int ver);
 static const SSL_METHOD *ssl3_get_method(int ver)
@@ -74,4 +75,11 @@
 			 ssl3_connect,
 			 ssl3_get_method)
 
+#else /* !OPENSSL_NO_SSL3 */
+
+# if PEDANTIC
+static void *dummy=dummy;
+# endif
+
+#endif
 
diff -Nru openssl-1.0.1j.orig/ssl/s3_srvr.c openssl-1.0.1j/ssl/s3_srvr.c
--- openssl-1.0.1j.orig/ssl/s3_srvr.c	2014-10-15 14:53:39.0 +0200
+++ openssl-1.0.1j/ssl/s3_srvr.c	2014-10-30 13:54:34.043101198 +0100
@@ -170,6 +170,7 @@
 #endif
 #include openssl/md5.h
 
+#ifndef OPENSSL_NO_SSL3
 static const SSL_METHOD *ssl3_get_server_method(int ver);
 
 static const SSL_METHOD *ssl3_get_server_method(int ver)
@@ -180,6 +181,12 @@
 		return(NULL);
 	}
 
+IMPLEMENT_ssl3_meth_func(SSLv3_server_method,
+			ssl3_accept,
+			ssl_undefined_function,
+			ssl3_get_server_method)
+#endif /* !OPENSSL_NO_SSL3 */
+
 #ifndef OPENSSL_NO_SRP
 static int ssl_check_srp_ext_ClientHello(SSL *s, int *al)
 	{
@@ -206,11 +213,6 @@
 	}
 #endif
 
-IMPLEMENT_ssl3_meth_func(SSLv3_server_method,
-			ssl3_accept,
-			ssl_undefined_function,
-			ssl3_get_server_method)
-
 int ssl3_accept(SSL *s)
 	{
 	BUF_MEM *buf;

Re: [openssl.org #3544] Remove MWERKS support

2014-10-29 Thread NormW 

G/M,
On 25/09/2014 2:09 AM, Rich Salz via RT wrote:

Not a supported platform, per our roadmap.

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

To be pendantic __MWERKS__ refers, AFAIK, to a compiler, and was the 
compiler used by Novell aa the 'standard' for creating NetWare apps. As 
I understand it (for the time being at least), support for NetWare is 
being retained, it will be necessary to re-implement the


#ifdef __MWERKS__

section removed in .\crypto\rand\rand_nw.c ONLY, in the ossl trunk src.

A review of all other __MWERKS__ code removed indicate they are only 
used by MAC PC's.

Norm

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

[openssl.org #3563] remove team-member specific targets from Configure

2014-10-13 Thread Rich Salz via RT 

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

[openssl.org #3549] Remove some obsolete files in crypto dirs

2014-10-02 Thread Rich Salz via RT 
commit df8c39d52256c2e5327a636928b6d1ed05f695a2
Author: Rich Salz rs...@openssl.org
Date: Tue Sep 30 17:30:19 2014 -0400

RT3549: Remove obsolete files in crypto

Reviewed-by: Andy Polyakov ap...@openssl.org

The following files have been removed:
crypto/bf/asm/bf-686.pl
crypto/bf/asm/readme
crypto/bf/bf_opts.c
crypto/bf/bfspeed.c
crypto/bn/asm/README
crypto/bn/asm/x86/add.pl
crypto/bn/asm/x86/comba.pl
crypto/bn/asm/x86/div.pl
crypto/bn/asm/x86/f
crypto/bn/asm/x86/mul.pl
crypto/bn/asm/x86/mul_add.pl
crypto/bn/asm/x86/sqr.pl
crypto/bn/asm/x86/sub.pl
crypto/bn/bn.mul
crypto/bn/bnspeed.c
crypto/bn/divtest.c
crypto/bn/exp.c
crypto/bn/expspeed.c
crypto/bn/todo
crypto/cast/cast_spd.c
crypto/cast/castopts.c
crypto/des/des_opts.c
crypto/des/speed.c
crypto/dh/p1024.c
crypto/dh/p192.c
crypto/dh/p512.c
crypto/idea/idea_spd.c
crypto/md2/md2.c
crypto/md4/md4.c
crypto/md5/md5.c
crypto/rc2/rc2speed.c
crypto/rc4/rc4speed.c
crypto/rc5/rc5speed.c
crypto/ripemd/rmd160.c
crypto/sha/sha.c
crypto/sha/sha1.c

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3549] Remove some obsolete files in crypto dirs

2014-09-30 Thread Rich Salz via RT 
The following files can be removed. There is another ticket (2910) that covers
a bunch of things in crypto/des.

crypto/bn/asm/x86/*
crypto/bn/asm/README
crypto/bn/bn.mul
crypto/bn/todo
crypto/bf/asm/readme
crypto/bf/asm/bf-686.pl
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3548] Remove some unsupported platforms

2014-09-29 Thread Rich Salz via RT 
This ticket is a catch-all for removing a handful of unsupported platforms.
This list includes:

BEOS
NeXT
NEWS
SUNOS
MPE/iX
ReliantUNIX
SINIX
DGUX
NCR
Tandem
Cray
WIN16

The intent is that each one will be done as a single commit, separate from all
the others, and merged to main one at a time, but to have only one ticket for
this first round of general platform reduction. Ticket 3540, BEOS, is being
merged into this.
This will be done on master, for part of the next release after 1.0.2

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3546] Remove IRIX_CC_BUG #ifdef's

2014-09-25 Thread Rich Salz via RT 
Self-explanatory.

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

[openssl.org #3544] Remove MWERKS support

2014-09-24 Thread Rich Salz via RT 
Not a supported platform, per our roadmap.

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

[openssl.org #3544] Remove MWERKS support

2014-09-24 Thread Rich Salz via RT 
All sorts of pre-OSx mac support has been removed.

commit 92c78463720f71e47c251ffa58493e32cd793e13
Author: Rich Salz rs...@openssl.org
Date: Wed Sep 24 12:18:19 2014 -0400

RT3544: Remove MWERKS support

The following #ifdef tests were all removed:
__MWERKS__
MAC_OS_pre_X
MAC_OS_GUSI_SOURCE
MAC_OS_pre_X
OPENSSL_SYS_MACINTOSH_CLASSIC
OPENSSL_SYS_MACOSX_RHAPSODY

Reviewed-by: Andy Polyakov ap...@openssl.org

Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3543] Remove #ifdef LINT fluff

2014-09-23 Thread Rich Salz via RT 
Can't find the lint program on a modern platform these days, and gcc/clang
warnings are much better anyway.
Remove that code.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3540] Remove BEOS support

2014-09-22 Thread Rich Salz via RT 
Remove BEOS and BEOS_R5 support.
Doesn't qualify to be a supported platform, per our roadmap.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #2351] PATCH: Remove obsolete ipsec extended key usages

2014-09-08 Thread Rich Salz via RT 
As drH says, not fixing this because being able to show obsolete OID's in text
form can be useful.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3508] [PATCH] Remove unused variable introduced by b09eb24.

2014-08-31 Thread Kurt Cancemi via RT 
Hello,

The following patch removes an unused variable introduced by b09eb24,
this also fixes the build with -Werror.

From 6e347fded0c050f4049e5bcbc2647bfdb742c48f Mon Sep 17 00:00:00 2001
From: Kurt Cancemi k...@x64architecture.com
Date: Thu, 28 Aug 2014 21:43:04 -0400
Subject: [PATCH] Remove unused variable introduced by b09eb24.

---
 crypto/asn1/t_req.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/crypto/asn1/t_req.c b/crypto/asn1/t_req.c
index 45348a7..5d03db7 100644
--- a/crypto/asn1/t_req.c
+++ b/crypto/asn1/t_req.c
@@ -92,7 +92,6 @@ int X509_REQ_print_ex(BIO *bp, X509_REQ *x, unsigned
long nmflags, unsigned long
  {
  long l;
  int i;
- const char *neg;
  X509_REQ_INFO *ri;
  EVP_PKEY *pkey;
  STACK_OF(X509_ATTRIBUTE) *sk;
-- 
2.1.0

---
Kurt Cancemi
https://www.x64architecture.com

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

[openssl.org #3508] [PATCH] Remove unused variable introduced by b09eb24.

2014-08-31 Thread Rich Salz via RT 
Fixed in head. Aargh, thanks.
commit b0426a0f8c6ce7656411b037e0c45465320cb325
Author: Kurt Cancemi k...@x64architecture.com
Date: Sun Aug 31 18:18:21 2014 -0400

RT3508: Remove unused variable introduced by b09eb24

Reviewed-by: Tim Hudson t...@openssl.org
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3006] [PATCH] Remove duplicated code in speed.c

2014-08-27 Thread Rich Salz via RT 
Fixed in rsalz-monolith branch of akamai/openssl fork on github.
To be part of post-1.0.2 release.
Thanks!
commit 15e5188312bc3bb199297be40ab58388d4141b3d
Author: Le Huang 4ta...@gmail.com
Date: Wed Aug 27 14:53:34 2014 -0400

PR3006: Needless duplication in speed.c

Ror some reason, the +F2: tag handling code are copied twice.
else if (!strncmp(buf,+F2:,4))
...
 else if (!strncmp(buf,+F2:,4))
 ...

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3142] Remove extraneous initialization from state_machine.c

2014-08-26 Thread Rich Salz via RT 
Fixed in HEAD
commit a520ae36288e01c19cd13dfca885b74bfd37d0e2
Author: Jeffrey Walton noloa...@gmail.com
Date: Tue Aug 19 12:59:41 2014 -0400

RT3142: Extra initialization in state_machine

Remove extra initialization calls in the sample program.

Reviewed-by: Emilia Kasper emi...@openssl.org
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #2575] [PATCH] remove redundant check in tls code

2014-08-19 Thread Rich Salz via RT 
Already fixed, at least in HEAD. Thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #2846] [PATCH 1/4] Remove unfinished/unused code with memory leaks (to silence static analyzer)

2014-08-17 Thread Rich Salz via RT 
It was already fixed in the next release after 1.0.2; see rsalz-monolith branch
in akamai/openssl fork on github. thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3023] [Patch] Remove redundant logical expressions

2014-08-15 Thread Rich Salz via RT 
Submitted, will be part of post-1.0.2 release; thanks!
commit 01e438f28844ad4f3fd7e8d772031524593d6441
Author: Hans Wennborg h...@chromium.org
Date: Fri Aug 15 00:54:00 2014 -0400

RT3023: Redundant logical expressions

Remove some redundant logical expressions

Reviewed-by: Emilia Kasper emi...@silkandcyanide.net

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

[openssl.org #3454] remove OPENSSL_SYS_WIN constraint for EC_GFp_nistp224_method()

2014-07-15 Thread Support via RT 

Hi,

Currently (14-07-2014, commit f8571ce82) the master branch doesn't
compile on Windows (mingw64) when using the enable-ec_nistp_64_gcc_128
option. The same option does work however on the OpenSSL_1_0_2-stable
branch.

This is due to a small difference in the file crypto/ec/ec.h. On
11-02-2011, a patch was applied (commit 65847ca378) only to the master
branch to (temporary ?) disable compiling on the WIN32 platform:

commit 65847ca378ea168964fbd9d36d970297d4fe45d7
Date:   Thu Feb 3 13:00:08 2011 +

For now disable EC_GFp_nistp224_method() for WIN32 so the WIN32 build
completes without linker errors.


Please find attached a patch for the master branch that removes this
restriction (and brings it more in line with the OpenSSL_1_0_2-stable
branch). This patch will make sure that compiling on Windows using the
enable-ec_nistp_64_gcc_128 flag works (again).


diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h
index c357b27..ce33942 100644
--- a/crypto/ec/ec.h
+++ b/crypto/ec/ec.h
@@ -152,7 +152,6 @@ const EC_METHOD *EC_GFp_mont_method(void);
 const EC_METHOD *EC_GFp_nist_method(void);

 #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
-#ifndef OPENSSL_SYS_WIN32
 /** Returns 64-bit optimized methods for nistp224
  *  \return  EC_METHOD object
  */
@@ -168,7 +167,6 @@ const EC_METHOD *EC_GFp_nistp256_method(void);
  */
 const EC_METHOD *EC_GFp_nistp521_method(void);
 #endif
-#endif

 #ifndef OPENSSL_NO_EC2M
 //


Thanks in advance,

Peter Mosmans



diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h
index c357b27..ce33942 100644
--- a/crypto/ec/ec.h
+++ b/crypto/ec/ec.h
@@ -152,7 +152,6 @@ const EC_METHOD *EC_GFp_mont_method(void);
 const EC_METHOD *EC_GFp_nist_method(void);
 
 #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
-#ifndef OPENSSL_SYS_WIN32
 /** Returns 64-bit optimized methods for nistp224
  *  \return  EC_METHOD object
  */
@@ -168,7 +167,6 @@ const EC_METHOD *EC_GFp_nistp256_method(void);
  */
 const EC_METHOD *EC_GFp_nistp521_method(void);
 #endif
-#endif
 
 #ifndef OPENSSL_NO_EC2M
 //

Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions

2014-07-04 Thread Hubert Kario 
- 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

Re: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions

2014-07-04 Thread Benny Baumann 
-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

2014-07-04 Thread Hubert Kario 
- 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: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions

2014-07-03 Thread Hubert Kario 
- 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.

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.

I won't even mention the whole issue of actually configuring TLS for more than
128 bit security...

-- 
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: [PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions

2014-07-03 Thread 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.
 
 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.
 
 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.

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
would be a 7680 assymetric key.  So I think that anything above
8192 bit doesn't make any sense at the moment.


Kurt

__
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

2014-07-03 Thread Wilfried Klaebe 
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.

  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.

  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.

 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
 would be a 7680 assymetric key.  So I think that anything above
 8192 bit doesn't make any sense at the moment.

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?

Also, considering how long #319 is open, I think it's not a bad idea to
raise the limit for DH primes from 1 bit to 2^14 bit or even more
before there's the need to open a new bug for that.

Regards,
Wilfried Klaebe
__
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

2014-07-03 Thread 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.

   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.

  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
  would be a 7680 assymetric key.  So I think that anything above
  8192 bit doesn't make any sense at the moment.
 
 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.


Kurt

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

[PATCH] LibReSSL/OpenSSL: Adjust/remove keysize restrictions

2014-07-02 Thread Benny Baumann 
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.

Find the patches attached to this mail. As the patches were originally
submitted as part of Debian Bug #747453 [1] they are in Debian format
suiteable for automatic application by the Debian tools. The patches
apply (automatically) to the latest released OpenSSL 1.0.1 version.

At the Debian BTS you can also find some of the previous discussion of
those patches.

The problems fixed by those patches surfaced for me in two different
situations both being related in nature and both having in common that
debugging was non-trivial due to no meaningful error messages being
returned.

The first issue affects OpenSSL clients connecting to  server with DH
parameters using a prime larger than 10kBit. While other libraries
(GnuTLS and libNSS) handle this without problems OpenSSL simply barks
and closes the connection. Debugging this issue required several hours
of studying network dumps and circling around in the OpenSSL source
without much success.

The second issue took about 2 weeks of debugging eJabberd instances
returning misleading error messages: Even though both eJabberd servers
happily talked to each other in plain (before STARTTLSing to something
secure) they failed with a remote-host-not-found error when mutually
authenticating each other (both servers use properly signed 8KBit RSA
keys as server certificates). The cause was finally found only by chance
when the certificates where replaced by smaller keys for testing (Usage
of 8KBit RSA is common with both server admins involed with this
debugging session).

Please find more details in the Debian BTS - or feel free to ask.

The modifications (new boundaries) are open for discussion as long as
the following conditions are met:
- a security level of 256 Bit equivalent strength can be reached for the
used certificate (which means ~16KBit RSA for Client Certs)
OR
- the limit can be adjusted by software and defaults to at least 192
bits of symmetric security.

Looking forward to seeing those patches or a modification thereof in an
upcoming release.

Kind regards,
Benny Baumann

[1] https://bugs.debian.org/747453
Description: Increase the maximum size allowed for client/server certificate packages on the wire
Author: Benny Baumann be...@geshi.org

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD

--- openssl-1.0.1e.orig/ssl/s3_srvr.c
+++ openssl-1.0.1e/ssl/s3_srvr.c
@@ -2926,7 +2926,7 @@ int ssl3_get_cert_verify(SSL *s)
 		SSL3_ST_SR_CERT_VRFY_A,
 		SSL3_ST_SR_CERT_VRFY_B,
 		-1,
-		516, /* Enough for 4096 bit RSA key with TLS v1.2 */
+		8200, /* Enough for 65536 bit RSA key with TLS v1.2 */
 		ok);
 
 	if (!ok) return((int)n);
Description: Remove DSA/DH keysize restrictions
Author: Benny Baumann be...@geshi.org

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD

--- openssl-1.0.1e.orig/crypto/dsa/dsa.h
+++ openssl-1.0.1e/crypto/dsa/dsa.h
@@ -84,10 +84,6 @@
 #endif
 #endif
 
-#ifndef OPENSSL_DSA_MAX_MODULUS_BITS
-# define OPENSSL_DSA_MAX_MODULUS_BITS	1
-#endif
-
 #define DSA_FLAG_CACHE_MONT_P	0x01
 #define DSA_FLAG_NO_EXP_CONSTTIME   0x02 /* new with 0.9.7h; the built-in DSA
   * implementation now uses constant time
--- openssl-1.0.1e.orig/crypto/dsa/dsa_ossl.c
+++ openssl-1.0.1e/crypto/dsa/dsa_ossl.c
@@ -325,11 +325,6 @@ static int dsa_do_verify(const unsigned
 		return -1;
 		}
 
-	if (BN_num_bits(dsa-p)  OPENSSL_DSA_MAX_MODULUS_BITS)
-		{
-		DSAerr(DSA_F_DSA_DO_VERIFY

OpenSSL should disable or remove heartbeat

2014-04-15 Thread Hanno Böck 
Hi,

I think this question needs to be asked.

We have a TLS extension here that - as far as I can see - nobody uses.
I have asked in different contexts recently if anyone is aware of real
software that makes use of the heartbeat extension. I got often
answerts like it could be used for X, but not a single one of them
saying there is software Y that does X with it. Also, a search on
ohloh turned up nothing.

I think there is no justification to have an extension that gets
enabled by default around if it is not used. So I propose that openssl
either disables it in the default build or removes it completely.
I'd suggest the first one if there are reasonable chances that anyone
might use it in the future.

And: I'd like to see a discussion on what further unused features there
are in OpenSSL that could be disabled just to reduce attack surface.
E.g. I could think of removing DSA key support, because nobody uses that
anyway and DSA is a bad algorithm.

cu,
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


signature.asc
Description: PGP signature

Re: OpenSSL should disable or remove heartbeat

2014-04-15 Thread Fedor Indutny 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Hanno!

Despite not a being an active community member, I'd like to share my
thoughts
on it, if you don't mind.

I certainly agree that this extension has a quite faulty specification and
very questionable
use. But perhaps, instead of just removing it from OpenSSL, we should try
to make IETF
deprecate it in a spec as well?

Cheers,
Fedor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTTSVtAAoJEPsOEJWxeXmZfDoP/25Eqt9Ec3SCnqOrUaSg9D01
JtNWZ8s8xq0BDdcjSCzeYh3yHPhWK2JbIhxm3t0Dq1vUK+TZtxvBHl6Vr141JioD
fM6WBGqr1eA8Htk5RkEC5xcIgDiEMs3xpGmeg0JYWaisPcdF9ChvPL51FII+FPXj
V26RJKHQhu+3XBKi3z4pmlJOvQNHaQ4B8EFw66mAfgyAVBXbi/EyHOpuJ0vZ/Z0p
WgPBnPSuhe8eu9Gmac440jvx/YHd+feYfjELw/vQiU5mZOCtgIKChu0hgSHQkke+
jTFGTTzBca/3wULAC3VtTFMwHif3bCHuN8GauuvW0NLemB3DslnbEYFCnYXp+vJl
Dv6YJOyc2XUOw576La3ZdAgyAvSnFhnGjWodkVZRYZJsXheblJcWhXOoH5TDK5Zq
mqIfTtFuPE5J2JplYs+Rgpjpss8F5hJgc1GbsfPqb4qU+VEN3DB0w2BdYBcSWt4B
PiANM0OcuaTwWS15KECR+yoItUJwbZyHmqCIsFzHlWNzymD5wr8xdcUtq0HFo8oV
B1G6vZXhoHxsB04xusK9kJZPwxbZXFL8hWwyvJprsPVEBD7v7taFHN01cItFXxGR
pSWVa0PdJc7JzvAOpJhXKKAqiQtr/cNcAUSl+BGXBkhzFMs5sPYVCXaD0a+01piw
jEjk3196JpBMEJOUBDbF
=Z4D3
-END PGP SIGNATURE-


On Tue, Apr 15, 2014 at 4:17 PM, Hanno Böck ha...@hboeck.de wrote:

 Hi,

 I think this question needs to be asked.

 We have a TLS extension here that - as far as I can see - nobody uses.
 I have asked in different contexts recently if anyone is aware of real
 software that makes use of the heartbeat extension. I got often
 answerts like it could be used for X, but not a single one of them
 saying there is software Y that does X with it. Also, a search on
 ohloh turned up nothing.

 I think there is no justification to have an extension that gets
 enabled by default around if it is not used. So I propose that openssl
 either disables it in the default build or removes it completely.
 I'd suggest the first one if there are reasonable chances that anyone
 might use it in the future.

 And: I'd like to see a discussion on what further unused features there
 are in OpenSSL that could be disabled just to reduce attack surface.
 E.g. I could think of removing DSA key support, because nobody uses that
 anyway and DSA is a bad algorithm.

 cu,
 --
 Hanno Böck
 http://hboeck.de/

 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42

Re: OpenSSL should disable or remove heartbeat

2014-04-15 Thread Michael Tuexen 
On 15 Apr 2014, at 14:26, Fedor Indutny fe...@indutny.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hello Hanno!
 
 Despite not a being an active community member, I'd like to share my thoughts
 on it, if you don't mind.
 
 I certainly agree that this extension has a quite faulty specification and 
 very questionable
 use. But perhaps, instead of just removing it from OpenSSL, we should try to 
 make IETF
 deprecate it in a spec as well?
I don't think there is a problem with the spec. The spec tells you
how to deal with packets having a faulty length field. The problem
was with the implementation.

I think OpenSSL has already a switch to disable the extension at
compile time. This is available for a lot of extensions/features.

Having also a runtime switch for features (with the default being
off) is a possibility. Might be something for other extensions
as well. So someone needing a feature needs to write code to
enable it.

Best regards
Michael
 
 Cheers,
 Fedor.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 
 iQIcBAEBAgAGBQJTTSVtAAoJEPsOEJWxeXmZfDoP/25Eqt9Ec3SCnqOrUaSg9D01
 JtNWZ8s8xq0BDdcjSCzeYh3yHPhWK2JbIhxm3t0Dq1vUK+TZtxvBHl6Vr141JioD
 fM6WBGqr1eA8Htk5RkEC5xcIgDiEMs3xpGmeg0JYWaisPcdF9ChvPL51FII+FPXj
 V26RJKHQhu+3XBKi3z4pmlJOvQNHaQ4B8EFw66mAfgyAVBXbi/EyHOpuJ0vZ/Z0p
 WgPBnPSuhe8eu9Gmac440jvx/YHd+feYfjELw/vQiU5mZOCtgIKChu0hgSHQkke+
 jTFGTTzBca/3wULAC3VtTFMwHif3bCHuN8GauuvW0NLemB3DslnbEYFCnYXp+vJl
 Dv6YJOyc2XUOw576La3ZdAgyAvSnFhnGjWodkVZRYZJsXheblJcWhXOoH5TDK5Zq
 mqIfTtFuPE5J2JplYs+Rgpjpss8F5hJgc1GbsfPqb4qU+VEN3DB0w2BdYBcSWt4B
 PiANM0OcuaTwWS15KECR+yoItUJwbZyHmqCIsFzHlWNzymD5wr8xdcUtq0HFo8oV
 B1G6vZXhoHxsB04xusK9kJZPwxbZXFL8hWwyvJprsPVEBD7v7taFHN01cItFXxGR
 pSWVa0PdJc7JzvAOpJhXKKAqiQtr/cNcAUSl+BGXBkhzFMs5sPYVCXaD0a+01piw
 jEjk3196JpBMEJOUBDbF
 =Z4D3
 -END PGP SIGNATURE-
 
 
 On Tue, Apr 15, 2014 at 4:17 PM, Hanno Böck ha...@hboeck.de wrote:
 Hi,
 
 I think this question needs to be asked.
 
 We have a TLS extension here that - as far as I can see - nobody uses.
 I have asked in different contexts recently if anyone is aware of real
 software that makes use of the heartbeat extension. I got often
 answerts like it could be used for X, but not a single one of them
 saying there is software Y that does X with it. Also, a search on
 ohloh turned up nothing.
 
 I think there is no justification to have an extension that gets
 enabled by default around if it is not used. So I propose that openssl
 either disables it in the default build or removes it completely.
 I'd suggest the first one if there are reasonable chances that anyone
 might use it in the future.
 
 And: I'd like to see a discussion on what further unused features there
 are in OpenSSL that could be disabled just to reduce attack surface.
 E.g. I could think of removing DSA key support, because nobody uses that
 anyway and DSA is a bad algorithm.
 
 cu,
 --
 Hanno Böck
 http://hboeck.de/
 
 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42
 

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

Re: OpenSSL should disable or remove heartbeat

2014-04-15 Thread Hanno Böck 
On Tue, 15 Apr 2014 14:35:36 +0200
Michael Tuexen michael.tue...@lurchi.franken.de wrote:

 On 15 Apr 2014, at 14:26, Fedor Indutny fe...@indutny.com wrote:
 
  I certainly agree that this extension has a quite faulty
  specification and very questionable use. But perhaps, instead of
  just removing it from OpenSSL, we should try to make IETF deprecate
  it in a spec as well?
 I don't think there is a problem with the spec. The spec tells you
 how to deal with packets having a faulty length field. The problem
 was with the implementation.

I disagree. Too many features and too much complexity is a problem in
the spec. Unused features is a problem in the spec, because nobody will
care to look after them.

 I think OpenSSL has already a switch to disable the extension at
 compile time. This is available for a lot of extensions/features.

Yes, and it should have sane defaults. Enabling an extension that
nobody uses shouldn't happen. So the default of that switch should be
off, unless someone has a convincing argument otherwise. Adding
features because we can is not helpful and adds attack surface.


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


signature.asc
Description: PGP signature

Re: OpenSSL should disable or remove heartbeat

2014-04-15 Thread Richard Könning 

Am 15.04.2014 14:35, schrieb Michael Tuexen:

On 15 Apr 2014, at 14:26, Fedor Indutny fe...@indutny.com wrote:



Hello Hanno!

Despite not a being an active community member, I'd like to share my thoughts
on it, if you don't mind.

I certainly agree that this extension has a quite faulty specification and very 
questionable
use. But perhaps, instead of just removing it from OpenSSL, we should try to 
make IETF
deprecate it in a spec as well?

I don't think there is a problem with the spec. The spec tells you
how to deal with packets having a faulty length field. The problem
was with the implementation.


When the spec leads to an unnecessary large implementation then there is 
a problem with the spec because more source code means in general more 
errors (there may be deviations from this rule when a more general spec 
allows to use common source parts).



I think OpenSSL has already a switch to disable the extension at
compile time. This is available for a lot of extensions/features.


At least in this case it would have been better to have a compile time 
option for *enabling* the extension. Or perhaps two options 
differentiating between DTLS and TLS would have been even better.



Having also a runtime switch for features (with the default being
off) is a possibility. Might be something for other extensions
as well. So someone needing a feature needs to write code to
enable it.


For people who provide OpenSSL libs for a broad audience with unknown 
needs a compile time option helps not much, here a runtime option (being 
off per default) helps to provide a functionality without imposing it on 
the user. With such an option the Heartbleed bug wouldn't have it made 
into the major news.


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

Re: OpenSSL should disable or remove heartbeat

2014-04-15 Thread Michael Tuexen 
On 15 Apr 2014, at 16:43, Hanno Böck ha...@hboeck.de wrote:

 On Tue, 15 Apr 2014 14:35:36 +0200
 Michael Tuexen michael.tue...@lurchi.franken.de wrote:
 
 On 15 Apr 2014, at 14:26, Fedor Indutny fe...@indutny.com wrote:
 
 I certainly agree that this extension has a quite faulty
 specification and very questionable use. But perhaps, instead of
 just removing it from OpenSSL, we should try to make IETF deprecate
 it in a spec as well?
 I don't think there is a problem with the spec. The spec tells you
 how to deal with packets having a faulty length field. The problem
 was with the implementation.
 
 I disagree. Too many features and too much complexity is a problem in
 the spec. Unused features is a problem in the spec, because nobody will
 care to look after them.
I don't think the spec is complex... I think it is simple, the problematic
case is explicitly mentioned. However, this does not avoid that
someone makes a mistake.
 
 I think OpenSSL has already a switch to disable the extension at
 compile time. This is available for a lot of extensions/features.
 
 Yes, and it should have sane defaults. Enabling an extension that
 nobody uses shouldn't happen. So the default of that switch should be
 off, unless someone has a convincing argument otherwise. Adding
 features because we can is not helpful and adds attack surface.
I guess the default could be always off. This would mean if an
application wants a new feature, it has to enable it. So if there
is no new code in the application, there is no new behaviour in
the (D)TLS stack.

Best regards
Michael
 
 
 -- 
 Hanno Böck
 http://hboeck.de/
 
 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42

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

Re: OpenSSL should disable or remove heartbeat

2014-04-15 Thread Michael Tuexen 
On 15 Apr 2014, at 18:23, Richard Könning richard.koenn...@ts.fujitsu.com 
wrote:

 Am 15.04.2014 14:35, schrieb Michael Tuexen:
 On 15 Apr 2014, at 14:26, Fedor Indutny fe...@indutny.com wrote:
 
 
 Hello Hanno!
 
 Despite not a being an active community member, I'd like to share my 
 thoughts
 on it, if you don't mind.
 
 I certainly agree that this extension has a quite faulty specification and 
 very questionable
 use. But perhaps, instead of just removing it from OpenSSL, we should try 
 to make IETF
 deprecate it in a spec as well?
 I don't think there is a problem with the spec. The spec tells you
 how to deal with packets having a faulty length field. The problem
 was with the implementation.
 
 When the spec leads to an unnecessary large implementation then there is a 
 problem with the spec because more source code means in general more errors 
 (there may be deviations from this rule when a more general spec allows to 
 use common source parts).
 
 I think OpenSSL has already a switch to disable the extension at
 compile time. This is available for a lot of extensions/features.
 
 At least in this case it would have been better to have a compile time option 
 for *enabling* the extension. Or perhaps two options differentiating between 
 DTLS and TLS would have been even better.
Having explicit compile time options for enabling is a possibility, however,
I think this is not how it is done in OpenSSL in general. I think there are a
lot of OPENSSL_NO_* defines. That is why OPENSSL_NO_HEARTBEATS was used
and not the opposite.
 
 Having also a runtime switch for features (with the default being
 off) is a possibility. Might be something for other extensions
 as well. So someone needing a feature needs to write code to
 enable it.
 
 For people who provide OpenSSL libs for a broad audience with unknown needs a 
 compile time option helps not much, here a runtime option (being off per 
 default) helps to provide a functionality without imposing it on the user. 
 With such an option the Heartbleed bug wouldn't have it made into the major 
 news.
 
 Best regards,
 Richard
 __
 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

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-30 Thread Misaki.Miyashita 



... The SPARC random
instruction was never implemented and never will be implemented.

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=926725b3d7c1528f2dc116a48623c42264188277
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e79d34c24b96943ae653dc93371bcae19021

As for getisax. One of limiting factors is ability to test and perform
regression tests. We don't have access to hardware running SPARC Solaris
(anymore) and for this reason something we can test elsewhere [i.e.
current exception-based procedure] is actually preferable.



Thanks for looking into the bug, Andy.

We like your proposed fix, especially the nice block of explanation and 
workaround  in the FAQ.

We appreciate it if you can integrate the fix.

Regards,

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

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-30 Thread Misaki.Miyashita via RT 

 ... The SPARC random
 instruction was never implemented and never will be implemented.
 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=926725b3d7c1528f2dc116a48623c42264188277
 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e79d34c24b96943ae653dc93371bcae19021

 As for getisax. One of limiting factors is ability to test and perform
 regression tests. We don't have access to hardware running SPARC Solaris
 (anymore) and for this reason something we can test elsewhere [i.e.
 current exception-based procedure] is actually preferable.


Thanks for looking into the bug, Andy.

We like your proposed fix, especially the nice block of explanation and 
workaround  in the FAQ.
We appreciate it if you can integrate the fix.

Regards,

Misaki Miyashita


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

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-28 Thread Andy Polyakov via RT 
Feels like Oracle convention all of a sudden...

 I think we need to clarify why this should be done.

The lesson is to always report underlying reasons. Because as we see 
here, it might turn out misleading.

 ... The SPARC random 
 instruction was never implemented and never will be implemented.

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=926725b3d7c1528f2dc116a48623c42264188277
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e79d34c24b96943ae653dc93371bcae19021

As for getisax. One of limiting factors is ability to test and perform 
regression tests. We don't have access to hardware running SPARC Solaris 
(anymore) and for this reason something we can test elsewhere [i.e. 
current exception-based procedure] is actually preferable.


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

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-27 Thread Dan Anderson 

On 12/26/13 08:03 PM, David Miller wrote:

From: Valerie Anne Bubb Fenwick valerie.fenw...@oracle.com
Date: Thu, 26 Dec 2013 15:46:42 -0800


both Dan and Misaki have noted, though, that this specific SPARC
instruction OpenSSL is checking for never existed and will never
exist in any SPARC chipset that Sun/Oracle shipped.  Could we at
least remove that check?  That capability does not and will not
exist, so it seems a waste of cycles to check (and confuses users,
we get lots of questions about this specific instruction and
why it doesn't work or which platform it should work on)

Does that make sense?  thanks!

I'm against this on fundamental grounds, you are just pushing the
problem around rather than truly fixing the issue.

I know what you want, you want the SIGILL to not happen on the systems
you most care about, and this is how you're going to go about doing it
rather than solving this issue at it's core.  In the debugger.

That's really distasteful to me.  Please fix things properly, rather
than chase after a scarecrow like this random instruction.


Hi David,

I really don't understand the desire to preserve dead, never-used code 
in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never 
used it and never can use it, but you don't want to remove the check for 
it. It seems silly to me.


Dan




--
uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1 858-526-9418




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-27 Thread David Miller 
From: Dan Anderson dan.ander...@oracle.com
Date: Fri, 27 Dec 2013 09:37:10 -0800

 I really don't understand the desire to preserve dead, never-used code
 in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never
 used it and never can use it, but you don't want to remove the check
 for it. It seems silly to me.

Ok, how about we replace the random instruction detection with an
explicit forced illegal instruction test early in the sparc init code
that makes sure the SIGILL facility is working properly?

That is, we'll unconditionally and always generate a SIGILL every time
openssl is used.

I'm perfectly fine with that, but you guys will be in the same
position you are now, having to cope with the debugger issue.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-27 Thread Dan Anderson 

On 12/27/13 10:46 AM, David Miller wrote:

From: Dan Anderson dan.ander...@oracle.com
Date: Fri, 27 Dec 2013 09:37:10 -0800


I really don't understand the desire to preserve dead, never-used code
in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never
used it and never can use it, but you don't want to remove the check
for it. It seems silly to me.

Ok, how about we replace the random instruction detection with an
explicit forced illegal instruction test early in the sparc init code
that makes sure the SIGILL facility is working properly?


Hi Dave,

That's fine--it's not all that we want (a Solaris-specific use of 
getisax()), but a half-a-loaf is better than none. At least a 
never-conceived SPARC instruction would not be checked for in OpenSSL.


A separate bug on the debugger will be filed separately.

BTW, we appreciate your SPARC contributions to OpenSSL in the past.

Dan



That is, we'll unconditionally and always generate a SIGILL every time
openssl is used.

I'm perfectly fine with that, but you guys will be in the same
position you are now, having to cope with the debugger issue.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org



--
uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1 858-526-9418




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-27 Thread Tom Kacvinsky 
There is a way to turn off break at SIGILL, at least in mdb, based on the
reading I've done


On Fri, Dec 27, 2013 at 1:46 PM, David Miller da...@davemloft.net wrote:

 From: Dan Anderson dan.ander...@oracle.com
 Date: Fri, 27 Dec 2013 09:37:10 -0800

  I really don't understand the desire to preserve dead, never-used code
  in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never
  used it and never can use it, but you don't want to remove the check
  for it. It seems silly to me.

 Ok, how about we replace the random instruction detection with an
 explicit forced illegal instruction test early in the sparc init code
 that makes sure the SIGILL facility is working properly?

 That is, we'll unconditionally and always generate a SIGILL every time
 openssl is used.

 I'm perfectly fine with that, but you guys will be in the same
 position you are now, having to cope with the debugger issue.
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-26 Thread Misaki Miyashita 
Sorry for the late reply.

Checking for chip capabilities by calling an invalid instruction causes an 
issue especially when people run debugger with an OpenSSL application.

That can be easily avoided by calling getisax(2) for SPARC, as Dan Anderson 
noted.

Please consider determining the chip capabilities for SPARC by calling 
getisax(2) instead of causing and catching SIGILL.
(For RNG, we'll never support the random instruction, and it can be just 
removed).

Thank you

-- misaki


- dan.ander...@oracle.com wrote:

 On 12/21/2013 7:07 PM, David Miller via RT wrote:
  From: Dan Anderson dan.ander...@oracle.com
  Date: Sat, 21 Dec 2013 17:54:52 -0800
 
  I think we need to clarify why this should be done. The SPARC
 random
  instruction was designed at Sun Microsystems (now Oracle
 Corporation)
  for a never-released processor several years ago. For SPARC,
  randomness is obtained by reading a special control register. The
  SPARC random instruction was never implemented and never will be
  implemented. Please remove code to detect this instruction.
 Thanks!
  The patch was presented as a way to get rid of SIGILL dropping the
  application into the debugger.
 
 True, but forget this for the sake of argument.
 
  The same problem is going to exist if people run this library on
  chips without the crypto instructions, or other ones we check for.
 
 You are checking for a SPARC instruction that was never implemented,
 is 
 not on any SPARC processor, and never will exist.
 
 All I'm suggesting is to not check for this instruction.
 
 Dan
 
 
 
 
 __
  OpenSSL Project
 http://www.openssl.org
  Development Mailing List  
 openssl-dev@openssl.org
  Automated List Manager  
 majord...@openssl.org
 
 
 -- 
 uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1
 858-526-9418
 
 __
 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

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-26 Thread David Miller 
From: Misaki Miyashita misaki.miyash...@oracle.com
Date: Thu, 26 Dec 2013 15:11:49 -0800 (PST)

 Checking for chip capabilities by calling an invalid instruction
 causes an issue especially when people run debugger with an OpenSSL
 application.

As has already been discussed in this thread, that's a debugger
problem.

 Please consider determining the chip capabilities for SPARC by
 calling getisax(2) instead of causing and catching SIGILL.  (For
 RNG, we'll never support the random instruction, and it can be just
 removed).

Again, as already discussed in this thread, the SIGILL technique
is portable across all operating systems, whereas getisax() is
not.

I really think you should work on getting the debugger to cope with
this SIGILL signal cleanly, rather than continuing to beat a dead
horse here.  This technique is quite common across libraries that
need to test for cpu instruction availability.

Thank you.

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

  1   2   >