Re: [openssl-dev] Work on a new RNG for OpenSSL
On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev ( openssl-dev@openssl.org) wrote: I think the safest thing is for us to not change the default. Programs that know they are going to fork can do the right/safe thing. It would be nicer if we could automatically always do the right thing, but I don’t think it’s possible. It appears the current position is that since there will be edge cases where a reseed would fail (thus either halting the RNG or silently not reseeding it) that we should not attempt to reseed? I would argue it is better to attempt to reseed and document that edge cases may need to reseed themselves. This dramatically narrows the window from "everybody needs to do it" to "users in certain scenarios that are becoming rarer by the day need to do it". Given that backwards compatibility is a concern maybe failure to reseed on fork should only drop an error on the child process's error queue though? That behavior could potentially be a separate flag that OpenSSL uses by default (OPENSSL_TRY_TO_INIT_ATFORK), and then OPENSSL_INIT_ATFORK can be more strict about reseed failures if desired. -Paul -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
Great news and congratulations to everyone on landing this work. I see that the RNG is now capable of automatically reseeding itself on fork, which will be a huge win for applications that aren't rigorous about doing so themselves (read: most of them). However, it appears that OPENSSL_INIT_ATFORK is not set as an option when OpenSSL calls OPENSSL_init_crypto. Would it be possible to make this default? This would be a large improvement in terms of protecting applications linking against OpenSSL. -Paul Kehrer (reaperhulk) On Mon, Aug 14, 2017 at 10:45 AM, Salz, Rich via openssl-dev <openssl-dev@openssl.org> wrote: > Thanks everyone for the discussion (mainly in June) about this. There’s a > blog post describing what we’ve done for the 1.1.1 release: > https://www.openssl.org/blog/blog/2017/08/12/random/ > > > > > -- > 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 #4405] 1.1.0 compile failure with no-comp
When trying to compile 1.1.0 with no-comp no-shared flags current master fails with the following error on linux: ./libcrypto.so: undefined reference to `COMP_zlib_cleanup' collect2: error: ld returned 1 exit status And perhaps a more instructive one on OS X: Undefined symbols for architecture x86_64: "_COMP_zlib_cleanup", referenced from: _OPENSSL_cleanup in libcrypto.a(init.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [link_dso.darwin] Error 1 make: *** [engines/dasync.dylib] Error 2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4405 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS
I can only plead ignorance. Those functions do indeed do what I need. With that I don't have any direct need for the d2i implementation, although it is still a bit odd for them to be defined on all the other extensions but not NAME_CONSTRAINTS. Thanks for the help! -Paul On January 9, 2016 at 7:14:12 PM, Dr. Stephen Henson (st...@openssl.org) wrote: On Sat, Jan 09, 2016, Paul Kehrer wrote: > The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in > the current OpenSSL releases. This is inconsistent with other extension > structs and (I believe) means you either need to declare them yourself or > attempt to build NAME_CONSTRAINTS using nconf functions. Below is a patch to > current git master that adds support for these functions. > > If there's a preferred way to test that these macros behave as expected I'll > be happy to add the tests to this patch. > Why do you need the i2d/d2i functions? It is possible to encode and decode the extension using X509_get_ext_d2i() and X509_add1_ext_i2d(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ 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] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS
The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in the
current OpenSSL releases. This is inconsistent with other extension structs and
(I believe) means you either need to declare them yourself or attempt to build
NAME_CONSTRAINTS using nconf functions. Below is a patch to current git master
that adds support for these functions.
If there's a preferred way to test that these macros behave as expected I'll be
happy to add the tests to this patch.
-Paul Kehrer
diff --git a/crypto/x509v3/v3_ncons.c b/crypto/x509v3/v3_ncons.c
index d3f79ba..e679f0a 100644
--- a/crypto/x509v3/v3_ncons.c
+++ b/crypto/x509v3/v3_ncons.c
@@ -109,7 +109,7 @@ ASN1_SEQUENCE(NAME_CONSTRAINTS) = {
IMPLEMENT_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE)
-IMPLEMENT_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS)
+IMPLEMENT_ASN1_FUNCTIONS(NAME_CONSTRAINTS)
static void *v2i_NAME_CONSTRAINTS(const X509V3_EXT_METHOD *method,
X509V3_CTX *ctx, STACK_OF(CONF_VALUE) *nval)
diff --git a/include/openssl/x509v3.h b/include/openssl/x509v3.h
index b5ea84a..f2e8598 100644
--- a/include/openssl/x509v3.h
+++ b/include/openssl/x509v3.h
@@ -591,7 +591,7 @@ DECLARE_ASN1_ITEM(GENERAL_SUBTREE)
DECLARE_ASN1_ALLOC_FUNCTIONS(GENERAL_SUBTREE)
DECLARE_ASN1_ITEM(NAME_CONSTRAINTS)
-DECLARE_ASN1_ALLOC_FUNCTIONS(NAME_CONSTRAINTS)
+DECLARE_ASN1_FUNCTIONS(NAME_CONSTRAINTS)
DECLARE_ASN1_ALLOC_FUNCTIONS(POLICY_CONSTRAINTS)
DECLARE_ASN1_ITEM(POLICY_CONSTRAINTS)
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Backporting opaque struct getter/setter functions
With OpenSSL 1.1.0 opaquing most of the structs getter/setter functions are required to perform many operations. What do people think about backporting those accessors into the 1.0.2 branch? It might simplify supporting 1.1.0 (but only as projects drop 0.9.8/1.0.0/1.0.1 support of course). -Paul Kehrer ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5 added a check to see if it should use the ADDX instructions based on the clang version. Unfortunately, on older versions of clang on OS X this check incorrectly returns true and compilation then fails due to not knowing the instructions: x86_64-mont.s:966:2 error: invalid instruction mnemonic 'adcxq' adcxq %rax,%r12 ^ The version of the compiler in question is: `Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)` (On an ancient OS X 10.7 VM) This issue was also filed in Github (https://github.com/openssl/openssl/issues/494) ___ 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
