Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or completely removed..

2020-03-03 Thread SHANE LONTIS
FIPS_mode() and FIPS_mode_set() are functions that were used by the old FOM.

In OpenSSL_111 they were stripped down to do almost nothing
i.e:-

int FIPS_mode(void)  
{  
/* This version of the library does not support FIPS mode. */  
return 0;  
}

int FIPS_mode_set(int on)  
{
if (r == 0)  
return 1;

CRYPTOerr(0, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED); 
return 0;  
}

The original plan for these API’s is listed in the design document for 3.0
i.e- the set would - set the global property and then do a fetch of a 
particular algorithm (this is problematic in itself since the algorithm may not 
exist for a 3rd party fips provider which could just implement a single 
algorithm).
And FIPS_mode() would just return true if the global property for fips was set.

This got some pushback and after discussion with a few other otc members - it 
was decided that the functions should be deprecated since it would be confusing 
to a user because there are multiple library contexts allowed each with their 
own fips property that can be changed at
any time.

This is done in https://github.com/openssl/openssl/pull/11075 
 and there is a related 
discussion in the comments.

This PR has also been rejected the deprecation and discusses
- FIPS_mode_set() function could be completely removed.
- FIPS_mode() - query using the default library context OR completely remove.

I have no issue with both functions being deleted as they no longer really mean 
the same thing as they did before.
Each library context has its own default properties - so querying FIPS_mode() 
could only return what the default library context’s fips properties are - it 
doesnt mean every library context is in fips mode, or even that the fips module 
is loaded. 
If the functions are removed then it may require a OMC vote since this could be 
viewed as a breaking change..

Does anyone have any thoughts on this?

Regards
Shane

Re: My next step in handling stale PRs

2020-03-03 Thread Mark J Cox
> But recently you started to
> add various prefixes like "Automated Ping:" and now "openssl-machine:". I'd 
> prefer if the messages
> were consistently without a prefix, because they only distract from the gist 
> of the message IMHO,
> in particular consistency junkies like me.

openssl-machine: was just my reminder prefix to run this as
openssl-machine and not me, but it's a fair point on the automated
ping and future consistency.  People may even pay more attention if
they don't realise it was a python script hassling them.

Thanks, Mark


RE: My next step in handling stale PRs

2020-03-03 Thread Dr. Matthias St. Pierre
Hi Mark,

your proposal sounds reasonable, and I let me take the opportunity to pay a 
compliment to your bot,
he is doing a great job :-).

I have just a tiny little nit: since the sender is clearly identified as 
"openssl-machine", it is not necessary
to add a special prefix to the text of the message to indicate the message was 
automated. In fact, the
"ready-to-merge" reminder, which started it all, doesn't have a prefix.  But 
recently you started to
add various prefixes like "Automated Ping:" and now "openssl-machine:". I'd 
prefer if the messages
were consistently without a prefix, because they only distract from the gist of 
the message IMHO,
in particular consistency junkies like me.

Matthias




My next step in handling stale PRs

2020-03-03 Thread Mark J Cox
We have over 50 PRs that are in the state where they are held
requiring a CLA, and stale (over 30 days since any comments).  My
intention is to have my script ping all these PRs with a comment like
this:

openssl-machine: This PR has the label "hold: cla required" and is
stale: it has not been updated in X days.   Note that this PR may be
automatically closed in the future if no CLA is provided.  For CLA
help see https://www.openssl.org/policies/cla.html

In another month we can decide it we want to autoclose them (note that
any comment, label change, etc, made to the PR after the above will
reset the timer and take it out of the list of possible ones to close)

I'll run it later in the week to give people a chance to voice any
comments or concerns.

Mark


Face to face

2020-03-03 Thread Dr Paul Dale
I propose that we don’t have either an OMC or OTC face to face meeting at ICMC.
Travel restrictions and the availability list make it look unlikely.

Instead, I’d suggest a video conference for both.

This will probably require some kind of vote (for both).


Any suggestions as to date and time.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia