Re: Deprecations

[Dr Paul Dale]

Matthew,

Good idea.  I’ll add it.


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




> On 5 Mar 2020, at 8:55 am, Matthew Lindner  wrote:
> 
> Shouldn't the deprecation notice that's printed also print the version it was 
> deprecated in?
> 
> - Matthew Lindner
> 
>> On Mar 4, 2020, at 2:48 PM, Dr Paul Dale > > wrote:
>> 
>> EXTERNAL MAIL: openssl-project-boun...@openssl.org 
>> 
>> 
>> Unless I’ve missed something, the documentation should specify the 
>> alternatives.  Mostly these are one to one, but in one case it is one to two 
>> (and there both are listed).
>> With the caveat that I might not have got every place or detail correct.
>> 
>> Moreover, the deprecated commands print something to the effect of: "The 
>> command dsa is deprecated. Use ‘pkey’ instead." when executed.
>> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 
>> 
>> 
>> 
>>> On 5 Mar 2020, at 5:15 am, Kurt Roeckx >> > wrote:
>>> 
>>> On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
 
 
 On 28/02/2020 23:43, Dr Paul Dale wrote:
> Any suggestions for a consensus on this thread?
 
 I think we can probably agree that:
 
 - Command option deprecations should be handled better
 - We should look at whether we can resurrect some of the "old" commands
 (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
>>> 
>>> What about at least pointing to the alternative function in the
>>> documentation?
>>> 
>>> 
>>> Kurt
>>> 
>> 
> 

Re: Deprecations

[Matthew Lindner]

Shouldn't the deprecation notice that's printed also print the version it was 
deprecated in?

- Matthew Lindner

On Mar 4, 2020, at 2:48 PM, Dr Paul Dale 
mailto:paul.d...@oracle.com>> wrote:


EXTERNAL MAIL: 
openssl-project-boun...@openssl.org


Unless I’ve missed something, the documentation should specify the 
alternatives.  Mostly these are one to one, but in one case it is one to two 
(and there both are listed).
With the caveat that I might not have got every place or detail correct.

Moreover, the deprecated commands print something to the effect of: "The 
command dsa is deprecated. Use ‘pkey’ instead." when executed.


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




On 5 Mar 2020, at 5:15 am, Kurt Roeckx mailto:k...@roeckx.be>> 
wrote:

On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:


On 28/02/2020 23:43, Dr Paul Dale wrote:
Any suggestions for a consensus on this thread?

I think we can probably agree that:

- Command option deprecations should be handled better
- We should look at whether we can resurrect some of the "old" commands
(possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

What about at least pointing to the alternative function in the
documentation?


Kurt

Re: Deprecations

[Dr Paul Dale]

Unless I’ve missed something, the documentation should specify the 
alternatives.  Mostly these are one to one, but in one case it is one to two 
(and there both are listed).
With the caveat that I might not have got every place or detail correct.

Moreover, the deprecated commands print something to the effect of: "The 
command dsa is deprecated. Use ‘pkey’ instead." when executed.


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




> On 5 Mar 2020, at 5:15 am, Kurt Roeckx  wrote:
> 
> On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>> 
>> 
>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>> Any suggestions for a consensus on this thread?
>> 
>> I think we can probably agree that:
>> 
>> - Command option deprecations should be handled better
>> - We should look at whether we can resurrect some of the "old" commands
>> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
> 
> What about at least pointing to the alternative function in the
> documentation?
> 
> 
> Kurt
> 

Re: Deprecations

[Matt Caswell]

On 04/03/2020 19:15, Kurt Roeckx wrote:
> On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>>
>>
>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>> Any suggestions for a consensus on this thread?
>>
>> I think we can probably agree that:
>>
>> - Command option deprecations should be handled better
>> - We should look at whether we can resurrect some of the "old" commands
>> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
> 
> What about at least pointing to the alternative function in the
> documentation?

Yes, we should do that. Pauli is currently investigating the possibility
of rewriting the old commands using EVP:

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

Matt

Re: Deprecations

[Kurt Roeckx]

On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
> 
> 
> On 28/02/2020 23:43, Dr Paul Dale wrote:
> > Any suggestions for a consensus on this thread?
> 
> I think we can probably agree that:
> 
> - Command option deprecations should be handled better
> - We should look at whether we can resurrect some of the "old" commands
> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

What about at least pointing to the alternative function in the
documentation?


Kurt

Re: Face to face

[Nicola Tuveri]

I would like to propose as a date for the OTC meeting somewhere close to
the projected release date for 3.0alpha1.

Ideally it would be nice if OMC and OTC could coordinate the dates to be
close enough to ease the discussion of agenda items that might require
coordination between OMC and OTC.

My rationale for proposing a date next to the alpha1 release is:
- there might be open items for the release process that might benefit from
the attention of the whole OTC and be expedited with f2f discussions
- OMC and OTC might have items to discuss in both directions regarding the
final stages of the 3.0 release roadmap and the milestones for alpha2,
alpha3,  beta1

---

Regarding time for the OTC meeting, I would personally prefer during the
week.
Considering that the bulk of OTC members seem to be distributed between
Europe and Australia, would 7:00 (AM) UTC be a suitable time?

Keep in mind that dates between 29.03 and 05.04 happen to be between
daylight saving time changes in Europe and Australia, so using 31.03 as the
tentative date for the meeting 7:00 AM UTC would mean [0]:
- 8 AM in London
- 9 AM in Berlin/Brussels/Prague/Stockholm
- 5 PM in Brisbane

Nicola

[0]: http://j.mp/39oYWhw

On Tue, 3 Mar 2020 at 10:22, Dr Paul Dale  wrote:

> 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
>
>
>
>
>

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

[Tomas Mraz]

On Wed, 2020-03-04 at 10:18 +, Matt Caswell wrote:
> 
> On 04/03/2020 08:15, Tomas Mraz wrote:
> > The current implementation in the PR - unconditionally returning
> > error
> > - is completely useless. It would make some (not much) sense if we
> > aimed for ABI compatibility with 3.0 however that is definitely not
> > the
> > case so the only reasonable thing is to either try to emulate the
> > behavior as much as possible or remove completely so the users of
> > the
> > API would know immediately that they have to be changed.
> > 
> 
> I don't have a strong view, but I think I tend to agree that removal
> is
> the better option. 3.0 *is* a major release and we've never
> guaranteed
> that there will be *no* breaking changes at all. We've only aimed for
> most applications that work in 1.1.1 not having to change. Since
> these
> functions exist in 1.1.1, but always fail, it seems reasonable to
> think
> that very few 1.1.1 application actually call them.

But they do not fail always - the FIPS_mode_set just works fine if you
do not use it to actually enable the FIPS mode and FIPS_mode always
returns 0 (without error). And that is fine because there is no FIPS
module in 1.1.1. But of course this behavior would not be fine with
3.0, it would be completely confusing.

>  If there are any
> that do so, then they probably need to re-examine their code anyway
> to
> confirm what the behaviour should be with 3.0.

Exactly.

> If we remove them then we should have some good documentation
> somewhere
> that explains what people should do instead.

+1

> I also think this will probably need an OMC vote.
> 
> Matt
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

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

[Matt Caswell]

On 04/03/2020 08:15, Tomas Mraz wrote:
> The current implementation in the PR - unconditionally returning error
> - is completely useless. It would make some (not much) sense if we
> aimed for ABI compatibility with 3.0 however that is definitely not the
> case so the only reasonable thing is to either try to emulate the
> behavior as much as possible or remove completely so the users of the
> API would know immediately that they have to be changed.
> 

I don't have a strong view, but I think I tend to agree that removal is
the better option. 3.0 *is* a major release and we've never guaranteed
that there will be *no* breaking changes at all. We've only aimed for
most applications that work in 1.1.1 not having to change. Since these
functions exist in 1.1.1, but always fail, it seems reasonable to think
that very few 1.1.1 application actually call them. If there are any
that do so, then they probably need to re-examine their code anyway to
confirm what the behaviour should be with 3.0.

If we remove them then we should have some good documentation somewhere
that explains what people should do instead.

I also think this will probably need an OMC vote.

Matt

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

[Tomas Mraz]

On Wed, 2020-03-04 at 13:47 +1000, SHANE LONTIS wrote:
> 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..

I believe that making these function return an error unconditionally is
a breaking change as well and for that reason I prefer removing them
completely or actually removing the FIPS_mode_set() and making the
FIPS_mode() to query the fips properties of the default context.

As for the use-cases the FIPS_mode() call has in the applications I
know of this implementation would be completely OK. If the call is
removed these applications would call the
EVP_default_properties_is_fips_enabled on the default context anyway.
The applications do not call FIPS_mode() to query for the FIPS
compliance but they use it to change their behavior i.e. prefer or
select different algorithms to be used.

The current implementation in the PR - unconditionally returning error
- is completely useless. It would make some (not much) sense if we
aimed for ABI compatibility with 3.0 however that is definitely not the
case so the only reasonable thing is to either try to emulate the
behavior as much as possible or remove completely so the users of the
API would know immediately that they have to be changed.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]