Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-06 Thread Benjamin Kaduk 
On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
> > This is one reason why keeping around old assembly code can have a cost. :(
> > 
> > https://github.com/openssl/openssl/pull/5320
> 
> There is nothing I can add to what I've already said. To quote myself.
> "None of what I say means that everything *has to* be kept, but as
> already said, some of them serve meaningful purpose..."
> 
> Well, I also said that "I'm *not* saying that bit-rot is not a concern,
> only that it's not really assembly-specific." And I can probably add
> something here, in addition to already mentioned example of legacy code
> relying on formally undefined or implementation-specific behaviour. It's
> not actually that uncommon that *new* C code is committed[!!!]
> "bit-rotten". So one can *just as well* say that supporting another
> operating system has a cost, and so does using another compiler... Why
> not get "angry" about that? What's the difference really? Relevant

Yes, supporting another operating system has a cost!
At risk of drawing Richard's ire, if we did not intend to support
(e.g.) VMS, we might have been able to get away with not writing our
own custom build system in favor of some "industry standard".
Supporting non-POSIX systems (e.g., Windows) also adds overhead in
how we implement many of our interfaces (file handling, thread
handling, locking, randomness, etc.).

I personally prefer a more conservative/restrictive approach than
the historical trend, and probably also more conservative than the
average of the team.  This is presumably shaped by my personal
experiences and career trajectory, and I understand that others'
path are different and so they will have different, but still valid,
preferences.  We as a team are charged with weighing the tradeoff of
supporting an additional platform against the burden of supporting
it and the risks against our ability to continue supporting it.  For
example, in this modern world where properly supporting a platform
basically does require some assembly code, for crypto-relevant
timing considerations, if only one person understands and will
support that assembly code, that is a risk.  Perhaps it's enough of
a risk to make officially supporting that platform a bad idea;
perhaps not -- it's just one factor that we must, as a whole, weigh
and consider.
Removing platform-specific assembly when not needed for security
would seem to reduce the risk, and presumably improve the
maintainability of the software as a whole.  But I don't see a good
way to not have these decisions all be made on a case-by-case basis.

-Ben
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-06 Thread Andy Polyakov 
> This is one reason why keeping around old assembly code can have a cost. :(
> 
> https://github.com/openssl/openssl/pull/5320

There is nothing I can add to what I've already said. To quote myself.
"None of what I say means that everything *has to* be kept, but as
already said, some of them serve meaningful purpose..."

Well, I also said that "I'm *not* saying that bit-rot is not a concern,
only that it's not really assembly-specific." And I can probably add
something here, in addition to already mentioned example of legacy code
relying on formally undefined or implementation-specific behaviour. It's
not actually that uncommon that *new* C code is committed[!!!]
"bit-rotten". So one can *just as well* say that supporting another
operating system has a cost, and so does using another compiler... Why
not get "angry" about that? What's the difference really? Relevant
question is what's more expensive, supporting multiple compilers?
multiple OSes? multiple assembly? To give a "tangible" example in the
context of forwarded message [that mentions PA-RISC assembly code.] How
long time did it take me to figure out what's wrong and verify that
problem is resolved? Couple of hours (mostly because old systems are
slw and it takes time to compile our stuff). How long time did it
take me to resolve HP-UX problems triggered by report on 20th of March?
I'm presumably[!] done by about now... To summarize, one can make same
argument about multiple things, yet we do them. Why? Because it works to
our advantage [directly or indirectly]...
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] build broken?

2018-04-06 Thread Matt Caswell 


On 05/04/18 20:13, Salz, Rich wrote:
> I thought someone else would beat me to it.  Like, maybe, the person who 
> broke things :)
> 
> But the fix is part of 5886 which you approved and I am merging now ...

Oops! Sorry :-)

The fix needs to go into 1.1.0 too to keep the numbers consistent:

https://github.com/openssl/openssl/pull/5892

Matt


> 
> On 4/5/18, 3:12 PM, "Richard Levitte"  wrote:
> 
> So, uhmmm, why didn't you make a PR from this?
> 
> In message  on Thu, 5 
> Apr 2018 17:18:13 +, "Salz, Rich"  said:
> 
> rsalz> Making update
> rsalz> CONF function code 122 collision at CONF_F_SSL_MODULE_INIT
> rsalz> 
> rsalz> diff --git a/crypto/err/openssl.txt b/crypto/err/openssl.txt
> rsalz> index d1cc039..de3dacc 100644
> rsalz> --- a/crypto/err/openssl.txt
> rsalz> +++ b/crypto/err/openssl.txt
> rsalz> @@ -335,7 +335,7 @@ CONF_F_NCONF_LOAD_BIO:110:NCONF_load_bio
> rsalz> CONF_F_NCONF_LOAD_FP:114:NCONF_load_fp
> rsalz> CONF_F_NCONF_NEW:111:NCONF_new
> rsalz> CONF_F_PROCESS_INCLUDE:116:process_include
> rsalz> -CONF_F_SSL_MODULE_INIT:122:ssl_module_init
> rsalz> +CONF_F_SSL_MODULE_INIT:123:ssl_module_init
> rsalz> CONF_F_STR_COPY:101:str_copy
> rsalz> CRYPTO_F_CRYPTO_DUP_EX_DATA:110:CRYPTO_dup_ex_data
> rsalz> CRYPTO_F_CRYPTO_FREE_EX_DATA:111:CRYPTO_free_ex_data
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 
> 
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project