OMC VOTE: Accessing sensitive information policy

[Dr Paul Dale]

Topic: Accept the accessing sensitive information policy as of 
2894caf7b051387f16f0fbbd8f6c5c9ebd3b79e7

Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/25
Public: yes
Opened: 2022-11-11
Closed: -MM-DD

OMC VOTE: Travel Policy

[Dr Paul Dale]

Topic: Accept the travel policy as of 
a38676a4f62ef3131c82fade0e12cff4099e23e9

Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/29
Public: yes
Opened: 2022-11-11
Closed: -MM-DD

OMC VOTE: contractor invoicing policy

[Dr Paul Dale]

Topic: Accept the contractor invoicing policy as of 
6a31c748f65a39be1594bf93bd1209880fac8ee1

Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/30
Public: yes
Opened: 2022-11-11
Closed: -MM-DD

Re: Forthcoming OpenSSL Bug Fix Release

[Dr Paul Dale]

1.1.1 is not susceptible to the CVE that is being fixed in 3.0:

   /the forthcoming release of OpenSSL version 1.1.1s that is a *bug
   fix* release/.

(highlight added).


Dr Paul Dale

On 26/10/22 22:17, Matan Giladi wrote:

Does 1.1.1s is going to include any security fix?
Can you please confirm that the critical issue found in 3.0.6 version is 
irrelevant for 1.1.1?

-Original Message-
From: openssl-announce  On Behalf Of Ing. 
Martin Koci, MBA
Sent: Tuesday, October 25, 2022 21:36
To:openssl-annou...@openssl.org;openssl-us...@openssl.org;openssl-project@openssl.org;oss-secur...@lists.openwall.com
Subject: Forthcoming OpenSSL Bug Fix Release

Hello,

In addition to the already announced 3.0.7 release, the OpenSSL project team 
would like to announce the forthcoming release of OpenSSL version 1.1.1s that 
is a bug fix release.

This bug fix release will be made available on Tuesday 1st November 2022 
between 1300-1700 UTC too.

Yours
The OpenSSL Project Team


Email secured by Check Point
Report 
Phishing:https://mta-cnf.iaas.checkpoint.com/mta_feedback?id=b3dc9e6004806fac5adb86a1a47504d00416eb2590b631502621736f0652d7ea=3D4CC6C8CB55;48DE55E160E5;C5CEAA199888;=m

Email secured by Check Point

OMC VOTE: stop shipping 1.1.1r and 3.0.6 releases

[Dr Paul Dale]

Topic: Stop distributing 1.1.1r and 3.0.6 while the problems are 
investigated.

comment: An announcement should also be made.
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/32
Public: yes
Opened: 2022-10-12
Closed: 2022-10-12
Accepted:  yes  (for: 3, against: 0, abstained: 2, not voted: 1)

  Kurt   [  ]
  Mark   [ 0]
  Matt   [+1]
  Pauli  [+1]
  Richard    [ 0]
  Tim    [+1]

Vote: policy for releasing information

[Dr Paul Dale]

Topic: Accept the policy for releasing information as at c78f885
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/24
Opened: 2022-09-28

OMC vote: travel policy

[Dr Paul Dale]

Topic: Accept the travel policy as at commit f9f4922
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/26
comment: We need something in place quickly so flight planning for the
 upcoming face to face can be done.  There is an intention to
 consider the existing feedback and update the policy in the
 near future.
Public: yes
Opened: 2022-09-14
Closed: 2022-09-15
Accepted:  yes  (for: 4, against: 0, abstained: 1, not voted: 1)

OMC vote: travel policy

[Dr Paul Dale]

Vote called on https://github.com/openssl/general-policies/pull/26

With the upcoming face to face, this needs sorting out quickly and it 
can be revised later.



Pauli

Monthly status: July

[Dr Paul Dale]

Significant activities throughout February included:

 * Helping our new business administrator (ongoing)
 o setting things up
 o explaining processes
 o providing guidance and suggestions
 * QUIC
 o Working on the QUIC TX Packetiser design (ongoing)
 o Working on the QUIC Connection ID Cache (ongoing)
 o Reviewing the frame encoding and decoding PR
 o Changing OSSL_TIME to be a structure
 * Working on the AVX512 CVE and the security advisory
 * Work on various upcoming blog posts and announcements
 * Assisted with the release of 3.0.5 and 1.1.1q
 * Responding to questions from support customers
 * Coverity fixes (ongoing)
 * Fix the GCM record limit check
 * Fix the get IV length calls which had several issues
 * Added fallback seeding for the stochastic cache flush

This is in addition to the usual nightly and weekly meetings, issue 
triage, pull request reviews and responding to questions etc



Pauli

Monthly status: June

[Dr Paul Dale]

Significant activities throughout January included:

 * Fixes for Coverity issues
 * Various FIPS related tasks
 * QUIC project
 o Design and implement an event queue
 o Design packetisation (ongoing)
 o Reviewing other designs and PRs
 o Redrew the overview diagram using dot (ongoing)
 * Customer support: fixes and responses to questions
 * Wrote knowledge base article about modifying support customer details
 * Worked on security issues
 o investigating and creating fixes for new issues
 o investigating old issues
 * Partial on-boarding for administrative position

This is in addition to the usual nightly meetings, issue triage, pull 
request reviews and responding to questions.  I also had a bout of covid :(

Monthly status report: May 2022

[Dr Paul Dale]

Significant activities throughout February included:

 * Investigation and mitigation of performance problems with MS QUIC.
 * Banned older TLS/DTLS & SSL protocols as security levels above zero.
 * Removed unused and untested _fetch_by_number functions.
 * Design and implementation of a timer subsystem.
 * Investigated code generation problem with clang-14 (strict aliasing
   being broken in a non-obvious way).
 * Review of event queue design.
 * Merge event queue and timer subsystems.
 * Blog post about Spectre gadgets in our source code.
 * Participating in ongoing FIPS related discussions.
 * Fixes for Coverity raise problems.
 * Fix case insensitive string comparisons so that they don't rely on
   locale support.
 * Wrote (unpublished) blog post and emails relevant parties (also
   unpublished).
 * Begin working on the QUIC packisation design.
 * Reviews the substantial feature PRs.

This is in addition to the usual nightly meetings, issue triage, small 
pull requests, pull request reviews and responding to questions etc


Pauli

OMC vote: voting policy change to announcement vote

[Dr Paul Dale]

Topic: Accept the vote announcement to voting policy changes as at 395652c
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/19
Public: yes
Opened: 2022-05-11
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

corrected vote: minor policy edits

[Dr Paul Dale]

The issue link was incorrect.

Topic: Accept the process for minor policy edits as at commit id df47115
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/17
Public: yes
Opened: 2022-05-05
Closed: 2022-05-??
Accepted:  yes  (for: 0, against: 0, abstained: 0, not voted: 0)

  Kurt   [  ]
  Mark   [  ]
  Matt   [  ]
  Pauli  [+1]
  Richard    [  ]
  Tim    [  ]

Vote: accept process for minor policy edits

[Dr Paul Dale]

Topic: Accept the process for minor policy edits as at commit id df47115
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/7
Public: yes
Opened: 2022-05-05
Closed: 2022-05-??
Accepted:  yes  (for: 0, against: 0, abstained: 0, not voted: 0)

  Kurt   [  ]
  Mark   [  ]
  Matt   [  ]
  Pauli  [+1]
  Richard    [  ]
  Tim    [  ]

Monthly status: April

[Dr Paul Dale]

Significant activities throughout January included:

 * Fixes for Coverity issues (> 15)
 * Investigation into MS QUIC performance issues (ongoing)
 * Wrote document describing how to set up and performance test MS QUIC
 * Investigation into security vulnerably (not yet public)
 * Working on the contractor working hours policy
 * Investigation into timer based event queuing
 * Design and planning meetings for 3.1, including document reading
   that had fallen behind

This is in addition to the usual nightly meetings, issue triage, pull 
request reviews and responding to questions.

Monthly status: March

[Dr Paul Dale]

Significant activities throughout February included:

 * Fixing the status web page
 * Working on the contractor working hours policy
 * Investigating an undisclosed vulnerability
 * Classification of performance issues in 3.0
 * Did more of the policy glossary and linked policies to it
 * Triaged Coverity issues and provided fixes
 * Updated support contracts
 * Created a new roadmap page for the web site
 * Began investigation in MS Quic performance issues
 o Submitted patches to MS Quic that increase performance by circa
   4% (ongoing)
 o Investigated and updated the sparse array data structure to give
   another circa 4% boost

This is in addition to the usual nightly meetings, issue triage, small 
pull requests, pull request reviews and responding to questions etc


Pauli

OTC vote: backport #17973 to 3.0: reducing block size for sparse array

[Dr Paul Dale]

Topic: backport #17973 to 3.0
Proposed by: pauli
Issue link: 
https://github.com/openssl/technical-policies/issues/38Public: yes

Opened: 2022-03-29
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

  Dmitry [  ]
  Matt   [  ]
  Pauli  [+1]
  Tim    [+0]
  Richard    [  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [  ]

lhash statistics functions deprecation

[Dr Paul Dale]

Topic: lhash statistics functions to always report 0 in both master and 3.0.
   In addition we should deprecate the functions in master.
details: PR https://github.com/openssl/openssl/pull/17931
Proposed by: Pauli
Issue link: https://github.com/openssl/technical-policies/issues/35
Public: yes
Opened: 2022-03-22
Closed: 2022-03-22
Accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 1)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [+1]
  Tim    [ 0]
  Richard    [+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+0]

OTC vote: backport #17857 to 3.0 (EVP_MD performance fix)

[Dr Paul Dale]

Topic: Backport #17857 to 3.0
comment: EVP_MD performance fix (refcount cache contention)
Proposed by: pauli
Public: yes
Opened: 2022-03-15
Closed: 2022-03-15
Accepted:  yes  (for: 6, against: 0, abstained: 3, not voted: 1)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [+0]
  Tim    [ 0]
  Richard    [+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+0]

OMC: vote on adding additional glossary entries passed

[Dr Paul Dale]

Topic: Accept the glossary changes as at commit id 8385661
comment: this requires openssl/technical-policies#27
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/10
Public: yes
Opened: 2022-03-04
Closed: 2022-03-09
Accepted:  yes  (for: 4, against: 0, abstained: 0, not voted: 2)

  Kurt   [  ]
  Mark   [  ]
  Matt   [+1]
  Pauli  [+1]
  Richard    [+1]
  Tim    [+1]

OTC: vote on glossary cross referencing policies passed

[Dr Paul Dale]

Topic: Accept the glossary links as at commit id 8385661
comment: this requires openssl/general-policies#10
Proposed by: Pauli
Issue link: https://github.com/openssl/technical-policies/pull/27
Public: yes
Opened: 2022-03-04
Closed: 2022-03-09
Accepted:  yes  (for: 8, against: 0, abstained: 1, not voted: 1)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [+1]
  Tim    [+1]
  Richard    [+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+0]

OTC vote: Accept the glossary links as at commit id 8385661

[Dr Paul Dale]

Topic: Accept the glossary links as at commit id 8385661
comment: this requires openssl/general-policies#10
Proposed by: Pauli
Issue link: https://github.com/openssl/technical-policies/pull/27
Public: yes
Opened: 2022-03-04
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

  Dmitry [  ]
  Matt   [  ]
  Pauli  [+1]
  Tim    [  ]
  Richard    [  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [  ]

OMC vote: Accept the glossary changes as at commit id 8385661

[Dr Paul Dale]

Topic: Accept the glossary changes as at commit id 8385661
comment: this requires openssl/technical-policies#27
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/pull/10
Public: yes
Opened: 2022-03-04
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

  Kurt   [  ]
  Mark   [  ]
  Matt   [  ]
  Pauli  [+1]
  Richard    [  ]
  Tim    [  ]

Monthly status: February

[Dr Paul Dale]

Significant activities throughout February included:

 * Fixes for scrypt testing & maximum memory usage
 * Lots of policy updates and policy creation:
 o Committer policy
 o Documentation policy
 o Versioning policy
 o Staff unavailability policy (in progress)
 o Glossary and amalgamation of definitions
 * Coverity fixes as and when required
 * Responding to FIPS related questioning
 * Fixed the OMC/OTC/Committer status scripts
 * QUIC investigation and planning
 o Picoquic
 o lsquic
 o Timer wheels
 * Caching algorithms with NULL property queries

This is in addition to the usual nightly meetings, issue triage, pull 
request reviews and responding to questions etc



Pauli

Upcoming policy votes

[Dr Paul Dale]

There are two policy votes up coming.  Both are related to the new 
glossary of terms and cross linking existing items.


The PRs in question are:

 * https://github.com/openssl/general-policies/pull/10
 * https://github.com/openssl/technical-policies/pull/27

Rather than spurring people into reading the policy proposals once the 
vote is called (which is kind of late to make changes), I thought I'd 
give some notice and request input.




Pauli

committers vote passed

[Dr Paul Dale]

Topic: Accept the committer policy as of
Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/issues/8
Public: yes
Opened: 2022-02-17
Closed: 2022-02-21
Accepted:  yes  (for: 4, against: 0, abstained: 0, not voted: 2)

  Kurt   [+1]
  Mark   [  ]
  Matt   [+1]
  Pauli  [+1]
  Richard    [  ]
  Tim    [+1]

OMC vote: committer policy

[Dr Paul Dale]

Topic: Accept the committer policy as of 
3766d6ba2648e716e973af6e1821687ad46ee57c

Proposed by: Pauli
Issue link: https://github.com/openssl/general-policies/issues/8
Public: yes
Opened: 2022-02-17
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

  Kurt   [  ]
  Mark   [  ]
  Matt   [  ]
  Pauli  [+1]
  Richard    [  ]
  Tim    [  ]


Pauli

Vote on version policy

[Dr Paul Dale]

The vote passes.

Topic: Accept openssl/general-policies PR#6 - Version policy as of
   commit ac8266d. This will become an official OMC policy.
Proposed by: pauli
Issue link: https://github.com/openssl/general-policies/pull/6
Public: yes
Opened: 2022-02-09
Closed: 2022-02-17
Accepted:  yes  (for: 4, against: 0, abstained: 0, not voted: 2)

  Kurt   [+1]
  Mark   [  ]
  Matt   [+1]
  Pauli  [+1]
  Richard    [  ]
  Tim    [+1]

Vote about argument checking closed

[Dr Paul Dale]

Topic: Public functions should check their arguments as of commit 1e37b5f.
   This will become an official OTC policy.
Proposed by: Pauli
Issue link: https://github.com/openssl/technical-policies/pull/21
Public: yes
Opened: 2022-02-10
Closed: 2022-02-17
Accepted:  yes  (for: 8, against: 0, abstained: 1, not voted: 1)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [+1]
  Tim    [+1]
  Richard    [  ]
  Shane  [+1]
  Tomas  [ 0]
  Kurt   [+1]
  Matthias   [+1]
  Nicola [+1]

Vote: public function should check their arguments

[Dr Paul Dale]

Topic: Public functions should check their arguments
Proposed by: Pauli
Issue link: https://github.com/openssl/technical-policies/pull/21
Opened: 2022-02-10

Vote: version policy

[Dr Paul Dale]

Topic: Accept openssl/general-policies PR#6 - Version policy as of
commit 2858b2b. This will become an official OMC policy.
Proposed by: pauli
Issue link: https://github.com/openssl/general-policies/pull/6
Public: yes
Opened: 2022-02-09

Vote result: documentation policy

[Dr Paul Dale]

Topic: Accept openssl/technical-policies PR#18 - Documentation policy as of
commit 49f3b24. This will become an official OTC policy.
Proposed by: Pauli
Issue link: https://github.com/openssl/technical-policies/pull/18
Public: yes
Opened: 2022-02-03
Closed: 2022-02-08
Accepted:  yes  (for: 7, against: 1, abstained: 0, not voted: 2)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [+1]
  Tim    [+1]
  Richard    [  ]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [-1]
  Matthias   [+1]
  Nicola [  ]

Vote results: documentation policy

[Dr Paul Dale]

Topic: Accept openssl/technical-policies PR#18 - Documentation policy as of
commit 49f3b24. This will become an official OTC policy.
Proposed by: Pauli
Issue link: https://github.com/openssl/technical-policies/pull/18
Public: yes
Opened: 2022-02-03
Closed: 2022-02-08
Accepted:  yes  (for: 7, against: 1, abstained: 0, not voted: 2)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [+1]
  Tim    [+1]
  Richard    [  ]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [-1]
  Matthias   [+1]
  Nicola [  ]

Revert PR #13906 - as per discussion in #17568

[Dr Paul Dale]

Topic: revert change in PR #13906 for 3.0 & master and provide an 
alternative

mechanism for the desired behaviour.
Proposed by: Pauli
Issue link: https://github.com/openssl/technical-policies/issues/25
Public: yes
Opened: 2022-02-08
Closed: 2022-02-08
Accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 3)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [+1]
  Tim    [  ]
  Richard    [+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [  ]

OTC Vote for the documentation policy has started

[Dr Paul Dale]

The OTC vote for this policy proposal has now started.

OTC members please cast your votes here:

https://github.com/openssl/technical-policies/pull/18

Pauli

Monthly status: January

[Dr Paul Dale]

Significant activities throughout January included:

 * Wrote "removing a support customer" work flow
 * Wrote a documentation policy (ongoing)
 * Wrote a versioning policy (ongoing)
 * Wrote policy definitions (ongoing)
 * Added error reporting to the parameter helper functions
 * Added EVP_MD_CTX_dup and EVP_CIPHER_CTX_dup functions
 * Implemented EVP_KDF_CTX_dup for all KDFs (ongoing)
 * Added caching of EVP cipher key and IV lengths which addresses a
   performance regression
 * Investigation of a TSAN issue resulting in fixes for libcrypto and
   libssl
 * Ongoing Coverity support: figuring out reports and fixing them
 * Continued coordination of MIPS security bug resulting in CVE-2021-4160

This is in addition to the usual nightly meetings, issue triage, pull 
request reviews and responding to questions.

Monthly status: December

[Dr Paul Dale]

Significant activities throughout December included:

 * Working on improving the performance of the OSSL_PARAM locate calls
 * Reading QUIC RFCs
 * Investigating QUIC implementations
 * Fix for copying a HMAC context
 * Drafted a policy for coding standards
 * Performance improvements for property definition and property query
   to string conversions
 * CVE advisory work
 * Began implementing the missing EVP_xxx_CTX_dup functions

This is in addition to the usual nightly meetings, issue triage, pull 
request reviews, responding to questions and some vacation days.  The 
vacation days are why this is early.



Pauli

Monthly Status: November

[Dr Paul Dale]

Significant activities throughout November included:

 * Investigation of date based finish times for GHE
 * Reviewed and made suggestions for developer job description
 * Bug fixes in apps
 * Fixed test RNG and updated its documentation and added a unit test
 * Implemented a safe integer maths module including documentation and
   test cases
 * Made DES key checks constant time
 * Wrote blob post about community support of platforms
 * Reinstated Coverity builds (they were lost when we moved away from
   Travis)
 * Examined and fixed/ignore over forty Coverity issues
 * Created daily Coverity scans (previously was weekly)
 * Examine some thread sanitiser issues
 * Implemented a priority queue in anticipation of needing time based
   event processing
 * Documented some additional environment variables
 * Ongoing Coverity fixes as they appear
 * Re reading portions of the QUIC RFCs
 * QUIC planning
 * Investigation of a possible performance bottleneck in parameter
   location.



Pauli

Re: OTC VOTE: Accept Policy change process proposal

[Dr Paul Dale]

+1

Pauli

On 1/11/21 8:23 pm, Tomas Mraz wrote:

topic: Accept openssl/technical-policies PR#1 - the policy change
process proposal as of commit 3bccdf6. This will become an official OTC
policy.

comment: This will implement the formal policy change process so we can
introduce and amend further policies as set by OTC via a public
process.

Proposed by Tomáš Mráz
Public: yes
opened: 2021-11-01
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

    Dmitry [  ]
    Matt   [  ]
    Pauli  [  ]
    Tim    [  ]
    Richard    [  ]
    Shane  [  ]
    Tomas  [+1]
    Kurt   [  ]
    Matthias   [  ]
    Nicola [  ]

Monthly Status: October

[Dr Paul Dale]

Apart from three weeks of vaction, significant activities throughout 
October were:


 * Wrote up developer job desription
 * Investigated GHE due dates for issues
 * Fixed the test RNG, updated the documentation and added a unit test
 * Read through the proposed policy documents
 * Began an implementation of safe integer mathematical operations

In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.



Pauli

OMC vote: changing the web site landing page

[Dr Paul Dale]

topic: Replace the first two sentences of the current openssl.org front page
   with the new first paragraph of the OpenSSL Project Overview. The
   following sentence on the current website becomes a new paragraph.

comment: The new text being: `The OpenSSL Project develops and maintains the
 OpenSSL software - a robust, commercial-grade, full-featured 
toolkit

 for general-purpose cryptography and secure communication. The
 project's technical decision making is managed by the OpenSSL
 Technical Committee (OTC) and the project governance is managed
 by the OpenSSL Management Committee (OMC). The project operates
 under formal Bylaws.'

The vote passed with 6 for, none against, abstaining or not voting.

Re: OTC VOTE: Accept PR#16725

[Dr Paul Dale]

0

Pauli

On 19/10/21 8:07 pm, Matt Caswell wrote:
topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to 
the normal review process

Proposed by Matt Caswell
Public: yes
opened: 2021-10-19
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [+0]
  Matt   [+1]
  Pauli  [  ]
  Tim    [-1]
  Richard    [+0]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [-1]
  Nicola [-1]

Monthly Status: September

[Dr Paul Dale]

Significant activities throughout August were:

 * Lots of research into possible futures for the project
 o Reading RFCs, guides, source code
 o Discussions and meetings
 * Infrastructure planning
 * Various odd tasks relating to the 3.0 branch
 * Update several post 3.0 pull requests and get them through the
   review/merge
 o PVK KDF
 o Making OBJ thread safe
 o ...
 * Investigation of RAND double free issue and do half of the fix
 * CCM8 ciphers security strength change
 * Adding operating system zoo to GitHub Action CIs
 * Start investigating how to have a "must be finished before" option
   in github
 * Providing input to and drafting job descriptions


In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.



Pauli

OTC vote: include Keccak digests in OpenSSL

[Dr Paul Dale]

Accept PR#16594 into master subject to the normal review process



This doesn't meet the "is a standard" requirement but it is in use and 
we have the implementation.  It just isn't exposed.


  Dmitry [+1]
  Matt   [ 0]
  Pauli  [+1]
  Tim    [+0]
  Richard    [+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+0]


The vote passed.

Re: OTC VOTE: Restart merging of non-breaking small features

[Dr Paul Dale]

+1

Pauli


On 14/9/21 8:13 pm, Matt Caswell wrote:
topic: Allow the restart of merging of non-breaking small features to 
the master

   branch
Proposed by Matt Caswell
Public: yes
opened: 2021-09-14
closed: 2021-09-14
accepted:  yes  (for: 5, against: 1, abstained: 1, not voted: 2)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [  ]
  Tim    [-1]
  Richard    [+1]
  Shane  [ 0]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]

OMC vote: PR #16498

[Dr Paul Dale]

topic: Accept PR 16498 in 3.0 subject to our normal review process.
Proposed by Pauli.
Public: yes
opened: 2021-08-03
closed: 2021-08-06
ONE WEEK VOTE

  Matt   [+1]
  Mark   [ 0]
  Pauli  [+1]
  Tim    [+1]
  Richard    [+1]
  Kurt   [  ]

Vote passed

Monthly Status: August

[Dr Paul Dale]

Significant activities throughout August were:

 * Fixing TLS 1.3 KDF for FIPS validation
 * Fix bugs in dgst command
 * Investigation of threading issues (several different ones)
 * Investigation of 3DES wrap cipher in 1.1.1 and master
 * Fix problems with AES wrap
 * Add additional CI test loops (run checker, compiler zoo)
 * Chase down failures in CIs
 * Documentation for the 3.0 release (multiple items)
 * Various future planning investigations

In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.



Pauli

OTC vote: branching 3.0

[Dr Paul Dale]

topic: Create `openssl-3.0' git branch today.
comment: This cascades to other names/version information on GitHub.
 For example, change the release version information in the
 master branch to 3.1.0-dev
Proposed by Pauli.
Public: yes
opened: 2021-08-31
closed: 2021-08-31
accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 3)

  Dmitry [+1]
  Matt   [  ]
  Pauli  [+1]
  Tim    [+1]
  Richard    [+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [  ]


This is to create a git branch and related activities.

OTC vote: release of 3.0.0

[Dr Paul Dale]

topic:

   /Release 3.0.0 final on Tuesday the 7th of September 2021 if
   run-checker and CI builds have been clean for two days./


Proposed by Pauli.
Public: yes
opened: 2021-08-31
closed: 2021-08-31
accepted:  yes  (for: 8, against: 0, abstained: 0, not voted: 2)

  Dmitry [+1]
  Matt   [  ]
  Pauli  [+1]
  Tim    [+1]
  Richard    [+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]

Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process

[Dr Paul Dale]

The vote has closed and passed.

Pauli

   topic: Accept PR#16286 into 3.0 subject to the normal review process
   Proposed by Shane Lontis
   Public: yes
   opened: 2021-08-17
   closed: 2021-08-18
   accepted:  yes  (for: 5, against: 1, abstained: 1, not voted: 3)

  Dmitry [+1]
  Matt   [-1]
  Pauli  [+1]
  Tim    [ 0]
  Richard    [+1]
  Shane  [+1]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]



On 17/8/21 11:19 pm, Matt Caswell wrote:

topic: Accept PR#16286 into 3.0 subject to the normal review process
Proposed by Shane Lontis
Public: yes
opened: 2021-08-17
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [  ]
  Matt   [-1]
  Pauli  [+1]
  Tim    [ 0]
  Richard    [+1]
  Shane  [+1]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]

Re: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1

[Dr Paul Dale]

+0

Pauli

On 10/8/21 8:53 pm, Matt Caswell wrote:

topic: Revert the commits merged from PR #16027 in 1.1.1
Comment: Refer to issue #16266 for background
Proposed by Tomas Mraz
Public: yes
opened: 2021-08-10
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [+1]
  Matt   [+1]
  Pauli  [  ]
  Tim    [-1]
  Richard    [  ]
  Shane  [-1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [-1]

Re: OTC VOTE: RSA public exponent validation in 3.0

[Dr Paul Dale]

0

Pauli

On 10/8/21 8:54 pm, Matt Caswell wrote:
topic: RSA public exponent validation in 3.0 for the default provider 
should be

consistent with 1.1.1
Comment: See issue #16255 for background
Proposed by Matt Caswell
Public: yes
opened: 2021-08-10
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [ 0]
  Matt   [+1]
  Pauli  [  ]
  Tim    [+1]
  Richard    [  ]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [-0]

Re: OTC vote on accepting #16203: TLS 1.3 KDF

[Dr Paul Dale]

This vote has now passed:

   topic: Accept PR 16203 in 3.0 subject to our normal review process.
   Proposed by Pauli.
   Public: yes
   opened: 2021-08-03
   closed: 2021-08-05
   accepted:  yes  (for: 4, against: 1, abstained: 4, not voted: 1)

   ONE WEEK VOTE
  Dmitry [+1]
  Matt   [+1]
  Pauli  [+1]
  Tim    [ 0]
  Richard    [  ]
  Shane  [ 0]
  Tomas  [+1]
  Kurt   [-1]
  Matthias   [ 0]
  Nicola [+0]



Pauli

On 3/8/21 7:03 pm, Dr Paul Dale wrote:
Accept PR 16203 <https://github.com/openssl/openssl/pull/16203> in 3.0 
subject to our normal review process.


This one is still undergoing early review.


Pauli

Re: OTC vote on accepting #16171: config_diagnostic

[Dr Paul Dale]

This vote has now passed:

   topic: Accept PR 16171 in 3.0 subject to our normal review process.
   Proposed by Pauli.
   Public: yes
   opened: 2021-08-03
   closed: 2021-08-04
   accepted:  yes  (for: 6, against: 1, abstained:1, not voted: 2)
   ONE WEEK VOTE

  Dmitry [+1]
  Matt   [  ]
  Pauli  [+1]
  Tim    [+1]
  Richard    [  ]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [-1]
  Matthias   [ 0]
  Nicola [+1]


Pauli

On 3/8/21 7:02 pm, Dr Paul Dale wrote:
Accept PR 16171 <https://github.com/openssl/openssl/pull/16171> in 3.0 
subject to our normal review process.


Pauli

OTC vote on accepting #16171: config_diagnostic

[Dr Paul Dale]

Accept PR 16171  in 3.0 
subject to our normal review process.


Pauli

OTC vote on accepting #16203: TLS 1.3 KDF

[Dr Paul Dale]

Accept PR 16203  in 3.0 
subject to our normal review process.


This one is still undergoing early review.


Pauli

Monthly Status: July

[Dr Paul Dale]

Significant activities throughout June were:

 * Added a -fips command line option to util/wrap.pl
 * Wrote provider side PBKDF1 documentation that was missed earlier.
 * Document config_diagnostics option more widely.
 * Added other documentation that was missed.
 * Add config_diagnostics option to all of our configuration files
   (pending).
 * Moved the PVK KDF to providers for post 3.0.
 * Fix a problem with BN_div getting the remainder's sign incorrect in
   some circumstances.
 * Addressed the last old Coverity issue -- Coverity is now clean.
 * Update auto DH so that it honours the security level rather than
   picking something inappropriate and erroring.
 * Remove ERR_GET_FUNC() from the codebase.
 * Investigation Solaris failure.
 * Fix Windows makefile
 * Streamline the apps so they know more about the command line options
   given and don't search for algorithms inappropriately. Use libctx
   and propq more pervasively when specified and don't fall back to
   legacy if provider options have been specified.
 * Reallow short IVs for AES and ARIA GCM modes.
 * Fix a no-posix-io build problem.
 * Add demo code for PBKDF2, SCRYPT and GMAC.
 * Investigation into non-caching build running the test machine out of
   memory.
 * Add cross compiles to our CI loops including execution via QEMU
   where reasonable.
 * Investigation of possible problem in wrap cipher mode and multiple
   calls to update.
 * Modified CTR DRBG to allow operation without a derivation function
   in FIPS mode
 * Investigate TLS 1.3 FIPS self test requirements.
 * Investigated, compiled and run lab's test suite.
 * Review vendor evidence document.

In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.

Re: OTC VOTE: Accept PR 16128

[Dr Paul Dale]

+1

Pauli

On 22/7/21 10:51 pm, Matt Caswell wrote:

topic: Accept PR 16128 in 3.0 subject to our normal review process
Proposed by Matt Caswell
Public: yes
opened: 2021-07-22
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Matt   [+1]
  Pauli  [  ]
  Tim    [  ]
  Richard    [  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [  ]

Monthly Status: June

[Dr Paul Dale]

Significant activities throughout June were:

 * Fix new Coverity issues 26 real, 4 false positives
 * Address all outstanding (ancient) Coverity issues
 * Fix threads test ordering problem
 * Fix address sanitiser problems in apps relating to uninitialised BN
   pointers
 * Investigation memory leak in dlopen() that's a known problem with
   valgrind
 * Investigate and fix memory leak when threading in property code
 * Investigation and remediation of several threading problems
 * Add locks to obj_dat.c and obj_xref.c to make the OBJ subsection
   thread safe (post 3.0 after discussion)
 * Added decoded caching to avoid lots of allocations and repeated
   algorithm recreation
 * Implemented a property list find function
 * Add a key manager check to better reuse existing key managers in
   light of algorithm cache flushes
 * Convert SHA one short functions to be functions not macros, to
   accept NULL arguments in a way compatible to 1.1.1
 * Add a memory sanitiser build
 * Tweak the time of execution of CI jobs so they run more widely
 * Fix double to integer conversions in light of the VMS experience
 * Add integer size sanity checks in light of the VMS experience
 * Add tests to evp_test for EVP_Q_ functions
 * Change the way XTS and AEAD ciphers are filtered in apps to unify
   this behaviour
 * Earlier detection of bad digest in req command
 * Covert command line apps to use libctx and property query more
   extensively
 * Add a -digest option to spkac command
 * Fix auto DH problem where the chosen group didn't necessarily meet
   the current security level
 * Add RSA key size vs entropy checks in FIPS mode
 * Updates to the FIPS checksum script
 * Remove SM2 encoder and decoder from the FIPS provider ... hmmm.
 * Add digest, cipher and PKEY algorithm life cycle documentation
   (including pretty pictures)
 * Update platform policy to allow configuration additions to stable
   branches
 * Clean up all remaining TODO notes in the code
 * Update NEWS to current status
 * Fix documentation of up-calls from providers to libcrypto
 * Deprecation of ERR_GET_FUNC()
 * Create a list of things to do after 3.0 for future discussion

In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.

Repository

[Dr Paul Dale]

The repository is frozen in anticipation of the 3.0 beta release.

Pauli

Monthly Status: May

[Dr Paul Dale]

Significant activities throughout April were:

 * Conversion of most run-checker jobs to GitHub Actions
 * Ongoing fixes to keep the run-checker builds working
 * Addition of cross compilation CI builds & fixes to get them passing
 * Fixes and improvements in the list, mac and kdf apps
 * Fixing Coverity issues each week
 * Fix provider store flushing
 * Allow property queries to use names before they are defined
 * Investigation of memory leak run running power up self tests on FIPS
   provider load
 * Several minor documentation updates
 * Threading test fixes
 * Fixes to the FIPS checksumming to include headers and dependencies
 * Cleaning up public symbols that aren't in our reserved name spaces
 * Addition of image files to the HTML documation installation
 * Added a MAC get block size call
 * Review of state diagram, vendor evidence and security policy
   documents for FIPS validation
 * Update RSA strengths in accordance with IG 7.5
 * Add strengths to new RNG calls
 * Use size_t for lengths in new RAND calls
 * Cleaning up TODOs in codebase (ongoing)

In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.

Monthly status: April

[Dr Paul Dale]

Significant activities throughout April were:

 * Coverity triage and fixes
 * AES-CBC speed fix
 * KMAC buffer overflow fix
 * Removal of EVP_sha() and friends in favour of EVP_MD_fetch()
 * SipHash control fix
 * Document different returns from control functions
 * Fix double free issue
 * Triage and fix all failing run-checker jobs (ongoing)
 * Add additional run-checker jobs to cover missing options (ongoing)
 * EVP_MAC proposal for XOF MACs
 * Disable ACVP test code by default
 * Fix a threading problem in EVP_fetch with the default library context.


In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.



Pauli

Re: OTC VOTE: Reject PR#14759

[Dr Paul Dale]

-0

Pauli

On 20/4/21 8:23 pm, Nicola Tuveri wrote:
Following up on 
https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html 
 
we had a discussion on this during last week OTC meeting, and opened a 
vote limited exclusively to the matter of rejecting PR#14759.


We lost the record of the votes collected during the call, so opening 
it officially today with a clean slate.




topic: Reject PR#14759
Proposed by Nicola Tuveri
Public: yes
opened: 2021-04-20
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
  Matt       [  ]
  Mark       [  ]
  Pauli      [  ]
  Viktor     [  ]
  Tim        [  ]
  Richard    [  ]
  Shane      [  ]
  Tomas      [  ]
  Kurt       [  ]
  Matthias   [  ]
  Nicola     [+1]

Re: OTC VOTE: Set issue 11164 milestone to Post 3.0

[Dr Paul Dale]

+1


On 20/4/21 8:15 pm, Tomas Mraz wrote:

topic: Set issue 11164 milestone to Post 3.0
Proposed by Tim Hudson
Public: yes
opened: 2021-04-20
closed: 2021-04-20
accepted:  yes  (for: 6, against: 1, abstained: 0, not voted: 4)

   Matt   [+1]
   Mark   [  ]
   Pauli  [  ]
   Viktor [  ]
   Tim[+1]
   Richard[+1]
   Shane  [+1]
   Tomas  [+1]
   Kurt   [  ]
   Matthias   [+1]
   Nicola [-1]

Re: OTC VOTE: Set PR 13817 milestone to Post 3.0

[Dr Paul Dale]

+0

On 20/4/21 8:17 pm, Tomas Mraz wrote:

topic: Set PR 13817 milestone to Post 3.0
Proposed by Tim Hudson
Public: yes
opened: 2021-04-20
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

   Matt   [ 0]
   Mark   [  ]
   Pauli  [  ]
   Viktor [  ]
   Tim[+1]
   Richard[ 0]
   Shane  [+1]
   Tomas  [ 0]
   Kurt   [  ]
   Matthias   [ 0]
   Nicola [ 0]

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Dr Paul Dale]

We don't need a vote on the PR.
If we make the policy vote, it would be against policy to include it.

Pauli

On 9/4/21 9:24 pm, Nicola Tuveri wrote:
I agree with what Tomàš said, and that is the reason why I convoluted 
them in a single vote: we need to merge or reject the PR based on a 
policy, but if we do 2 separate votes we risk to create delays in the 
already quite loaded development cycles left!


Nicola

On Fri, Apr 9, 2021, 10:53 Tomas Mraz > wrote:


On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote:
>
> On 08/04/2021 18:02, Nicola Tuveri wrote:
> > Proposed vote text
> > ==
> >
> >      Do not merge PR#14759, prevent declaring properties
similar to
> >      `blinding=yes` or `consttime=yes` in our implementations and
> >      discourage 3rd parties from adopting similar designs.
>
> I think this vote tries to cover too much ground in a single
vote. I
> would prefer to see a simple vote of "Do not merge PR#14759"
> *possibly*
> followed up by separate votes on what our own policies should be
for
> provider implementations, and what we should or should not encourage
> 3rd
> parties to do.

I disagree partially. IMO we should primarily have a policy vote and
the closing or merging of PR#14759 should come out of it naturally.

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

Monthly Status - March

[Dr Paul Dale]

Significant activities throughout February were:

 * Add OSSL_PARAM arguments to the initialisation calls for all algorithms.
 * Figured out algorithm life cycles, produced diagrams and state
   descriptions.
 * Wrote up the life cycles for KDF, MAC and RAND (the "new" algorithm
   types).
 * Separated OSSL_CORE_BIO and BIO and fixed a number of bugs along the
   way.
 * Improved the fake RAND used by some of the test suite.
 * Fixed a threading problem with the for all loaded function.
 * Checked all the do all functions for potential threading problems.
 * Added a no-legacy build to the CI loop.
 * Planning for the pathway towards the FIPS validation and 3.0.
 * Fixed over fifty issues identified by Coverity.
 * Implemented the X509_PUBKEY_dup function and fixed bugs exposed by this.
 * Fixed a concurrent access problem in SSL_CTX_new.
 * Investigated, but haven't yet fixed, a threading problem in
   EVP_fetch with the default library context.


In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.



Pauli

Monthly Status - February

[Dr Paul Dale]

Significant activities throughout February were:

 * Deprecation of RAND_METHOD and associated fallout
 * no-cache builds work and multitude of problems that fell out of this
 * Fixing a DRBG problem reported by the FIPS lab to do with entropy input
 * Investigation of DRBG incorrect output issue
 * Add EVP_xxx_CTX_gettable_params and EVP_xxx_CTX_settable_params calls
 * Improvements to the MAC API
 * Improvements to the KDF API
 * Improvement to the RAND API


In addition were minor pull requests, reviewing, OMC and OTC business, 
et al.



Pauli

Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely

[Dr Paul Dale]

+1 here too.

Pauli

On 23/2/21 8:21 pm, Tomas Mraz wrote:

topic: The RSA_SSLV23_PADDING and related functions should be
completely removed from OpenSSL 3.0 code.

comment: The padding mode and the related functions (which are already
deprecated in the current master branch) is useless outside of SSLv2
support. We do not support SSLv2 and we do not expect anybody using
OpenSSL 3.0 to try to support SSLv2 by calling those functions.

Proposed by Tomas Mraz.

public: yes
opened: 2021-02-23

OTC vote: change PKCS #12 defaults

[Dr Paul Dale]

topic: Change PKCS#12 creation to use AES-256-CBC and SHA-256 by default.
comment: Both app and API, inlcude CHANGES entry.
Proposed by Pauli.
Public: yes
opened: 2020-02-09
closed: 2020-02-09
accepted:  yes  (for: 8, against: 0, abstained: 0, not voted: 3)

OTC vote: The EVP_xxx_CTX types should support an EVP_xxx_CTX_dup call but not an EVP_xxx_CTX_copy call.

[Dr Paul Dale]

topic: The EVP_xxx_CTX types should support an EVP_xxx_CTX_dup call but 
not an

   EVP_xxx_CTX_copy call.
comments: Existing EVP_xxx_copy() functions not to be removed in the 3.0
  timeframe.
Proposed by pauli.
Public: yes
opened: 2020-02-02
closed: 2020-02-02
accepted:  yes  (for: 8, against: 0, abstained: 0, not voted: 3)

OTC Vote: We should not support EVP_xxx_reset() operations.

[Dr Paul Dale]

topic: We should not support EVP_xxx_reset() operations.
comment: The existing EVP_xxx_dup() function supports this functionality.
 Existing EVP_xxx_reset() functions not to be removed in the 3.0
 timeframe.
Proposed by pauli.
Public: yes
opened: 2020-02-02
closed: 2020-02-02
accepted:  yes  (for: 7, against: 0, abstained: 1, not voted: 3)

OTC Vote: EVP_MAC_init should accept key and key length arguments.

[Dr Paul Dale]

topic: EVP_MAC_init should accept key and key length arguments.
Proposed by pauli.
Public: yes
opened: 2020-02-02
closed: 2020-02-02
accepted:  yes  (for: 4, against: 1, abstained: 4, not voted: 2)

OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters.

[Dr Paul Dale]

topic: EVP init functions should accept an OSSL_PARAM array to set 
parameters.

comment: This will mostly avoid calling the equivalent set_param call.
Proposed by pauli.
Public: yes
opened: 2020-02-02
closed: 2020-02-02
accepted:  yes  (for: 8, against: 0, abstained: 1, not voted: 2)

OTC VOTE: functions not conforming to the TYPE_NAME_action_name naming scheme are defects

[Dr Paul Dale]

topic: Where a function does not use the TYPE_NAME_action_name naming 
scheme,

   it is considered to be a defect.
comment: These are not considered blockers for 3.0 if the function 
existed in
 1.1.1.  New functions that do not conform must be fixed before 
release.

Proposed by pauli.
Public: yes
opened: 2020-02-02
closed: 2020-02-02
accepted:  yes  (for: 5, against: 0, abstained: 3, not voted: 3)

OTC Vote: Moving forwards we will use TYPE_NAME_action_name for function names.

[Dr Paul Dale]

topic: Moving forwards we will use TYPE_NAME_action_name for function names.
comment: Not camel case, underscores separating words.  I.e. EVP_MAC_update
 not EVP_MACUpdate or EVP_MAC_Update.
Proposed by pauli.
Public: yes
opened: 2020-02-02
closed: 2020-02-02
accepted:  yes  (for: 7, against: 0, abstained: 1, not voted: 3)

Change of scenery

[Dr Paul Dale]

Letting people know that I'm starting as an OpenSSL fellow today.

I'm looking forward to working as part of the team and I'll be able to 
fully devote my efforts to the benefit of the project.



Dr Paul Dale

Re: Remote unpack error when trying to push

[Dr Paul Dale]

Richard has fixed the space problem.

PRs can be merged again.


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




> On 9 Dec 2020, at 7:41 pm, Dr Paul Dale  wrote:
> 
> I can confirm that there is a disc full no the machine.
> I’m not confident I can safely fix it — it was the first time I’ve logged in 
> to it.
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 9 Dec 2020, at 7:00 pm, Tomas Mraz > <mailto:tm...@redhat.com>> wrote:
>> 
>> It seems we are out of space or there is other similar problem on
>> git.openssl.org 
>> <https://urldefense.com/v3/__http://git.openssl.org__;!!GqivPVa7Brio!Pw4Pho0qklzuh4x0vkC6LBpPFh4eJorpM7e4DoF7POSUZVSJsS9f6tsCFjs1TM0$>.
>> 
>> 
>> Pushing to openssl-...@git.openssl.org 
>> <mailto:openssl-...@git.openssl.org>:openssl.git
>> Enumerating objects: 7, done.
>> Counting objects: 100% (7/7), done.
>> Delta compression using up to 8 threads
>> Compressing objects: 100% (4/4), done.
>> Writing objects: 100% (4/4), 474 bytes | 474.00 KiB/s, done.
>> Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
>> error: remote unpack failed: unable to create temporary object directory
>> To git.openssl.org 
>> <https://urldefense.com/v3/__http://git.openssl.org__;!!GqivPVa7Brio!Pw4Pho0qklzuh4x0vkC6LBpPFh4eJorpM7e4DoF7POSUZVSJsS9f6tsCFjs1TM0$>:openssl.git
>> ! [remote rejected]   master -> master (unpacker error)
>> error: failed to push some refs to 'openssl-...@git.openssl.org 
>> <mailto:openssl-...@git.openssl.org>:openssl.git'
>> 
>> 
>> 
>> -- 
>> 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: Remote unpack error when trying to push

[Dr Paul Dale]

I can confirm that there is a disc full no the machine.
I’m not confident I can safely fix it — it was the first time I’ve logged in to 
it.


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




> On 9 Dec 2020, at 7:00 pm, Tomas Mraz  wrote:
> 
> It seems we are out of space or there is other similar problem on
> git.openssl.org.
> 
> 
> Pushing to openssl-...@git.openssl.org:openssl.git
> Enumerating objects: 7, done.
> Counting objects: 100% (7/7), done.
> Delta compression using up to 8 threads
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 474 bytes | 474.00 KiB/s, done.
> Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
> error: remote unpack failed: unable to create temporary object directory
> To git.openssl.org:openssl.git
> ! [remote rejected]   master -> master (unpacker error)
> error: failed to push some refs to 'openssl-...@git.openssl.org:openssl.git'
> 
> 
> 
> -- 
> 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.]
> 
> 

#8765

[Dr Paul Dale]

#8765 <https://github.com/openssl/openssl/pull/8765> has been sitting in an OTC 
hold state for a while and @DDvO has asked how it can be progressed.

The PR is attempting to change the bnrand_range() function.
Our existing code iterates (up to 100 times) and generates candidates which 
each have a 75% chance of being within the desired range.  It guarantees an 
unbiased result but is slow and variable in its timing.  It is also difficult 
to understand.
The code that currently stands 
<https://github.com/openssl/openssl/pull/8765/files> in the PR uses the method 
FIPS 186-4 B.1.1 / BSI TR-02102-1 Table B4 Method 2 to generate random numbers 
within a range quickly, although there is a very slight bias introduced.  This 
generates an extra 64 bits of randomness, modulo reduces the result and returns 
it.  The bias being that 2^(n+64) isn’t exactly divisible by the range (at 
least in general).  Again
The third approach 
<https://github.com/siemens/openssl/commit/71ce233d5d640de79b14130c78debe059c9f563d>
 with takes advantage of an idea from Lemire’s exquisite Fast Random Integer 
Generation in an Interval <https://arxiv.org/abs/1805.10941> to produce a 
similar biassed result using a multiplication instead of a modulus.  I.e. this 
one can be constant time and is faster again.
It is possible to implement Lemire’s algorithm completely which gives fast and 
unbiassed results, although it might have to iterate on occasion.
Do RNGs need to be constant time?  I’m not sure.  Our BN_mod() function isn’t 
and exposes potential side channel attacks (we have this now).
The variable number of iterations cannot be used for a timing attack because 
iteration means that the generated number is out of range and thrown away.  An 
attacker only learns that and nothing about the final out.

Do we want our RNG to be faster?  This seems like a decent idea.

Can we live with (slightly) biassed output?


As noted by @DDvO, some of the tests are failing.  At one point I implemented 
Lemire’s algorithm and the broken tests were what stopped me.  I don’t remember 
the precise details, I’ve a niggle that it might have been NIST’s KATs 
implicitly relying on the “standard” modulo reduce approach being used for 
random range generation.


Thoughts or suggestions?

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

Re: OTC VOTE: Keeping API compatibility with missing public key

[Dr Paul Dale]

+1

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




> On 4 Dec 2020, at 10:45 pm, Tomas Mraz  wrote:
> 
> Vote background
> ---
> 
> The vote on relaxing the conceptual model in regards to required public
> component for EVP_PKEY has passed with the following text:
> 
> For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without
> public components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not contain public keys and
> * our decoders unconditionally generate the public key (where
> possible).
> 
> However since then the issue 13506 [1] was reported.
> 
> During OTC meeting we concluded that we might need to relax also other
> public key algorithm implementations to allow private keys without
> public component.
> 
> Vote
> 
> 
> topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable
>   with 1.1.1 EVP_PKEY API or low level APIs without public component must
>   stay usable.
> 
>   This overrules the
> * all implementations apart from EC require the public component to 
> be present;
>   part of the vote closed on 2020-11-17.
> 
> Proposed by Tomas Mraz
> Public: yes
> opened: 2020-12-04
> 
> Tomas Mraz
> 
> 

Re: OTC VOTE: Fixing missing failure exit status is a bug fix

[Dr Paul Dale]

+1

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




> On 30 Nov 2020, at 10:03 pm, Nicola Tuveri  wrote:
> 
> Vote background
> ---
> 
> This follows up on a [previous proposal] that was abandoned in favor of
> an OMC vote on the behavior change introduced in [PR#13359].
> Within today's OTC meeting this was further discussed with the attending
> members that also sit in the OMC.
> 
> The suggestion was to improve the separation of the OTC and OMC domains
> here, by having a more generic OTC vote to qualify as bug fixes the
> changes to let any OpenSSL app return an (early) failure exit status
> when a called function fails.
> 
> The idea is that, if we agree on this technical definition, then no OMC
> vote to allow a behavior change in the apps would be required in
> general, unless, on a case-by-case basis, the "OMC hold" process is
> invoked for whatever reason on the specific bug fix, triggering the
> usual OMC decision process.
> 
> [previous proposal]:
> <https://urldefense.com/v3/__https://www.mail-archive.com/openssl-project@openssl.org/msg02241.html__;!!GqivPVa7Brio!NfJCTAAdJkitIZUnDXhh3CXZemoyuA3itUSr_vTfjZ4LQ9DnVDhBUKj0pihFNy0$
>  >
> [PR#13359]: 
> <https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359__;!!GqivPVa7Brio!NfJCTAAdJkitIZUnDXhh3CXZemoyuA3itUSr_vTfjZ4LQ9DnVDhBUKj0zvqbao4$
>  >
> 
> 
> 
> Vote text
> -
> 
> topic: In the context of the OpenSSL apps, the OTC qualifies as bug
>   fixes the changes to return a failure exit status when a called
>   function fails with an unhandled return value.
>   Even when these bug fixes change the apps behavior triggering
>   early exits (compared to previous versions of the apps), as bug
>   fixes, they do not qualify as behavior changes that require an
>   explicit OMC approval.
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2020-11-30

Vote results: remove -crypt option from passwd and C source output options

[Dr Paul Dale]

Vote: Drop from 3.0 support for the '-crypt' option from the passwd application

For: 6, Against: 0, Abstain: 0, Didn’t vote: 1

The vote passes.


Vote: Drop from 3.0 support for the C code output options from the applications 
where the use of deprecated APIs is required

For: 4, Against: 0, Abstain: 2, Didn’t vote: 1

The vote passes.


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

Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

[Dr Paul Dale]

An OMC vote deeming that adding error checks like this are or are not 
considered breaking changes.

My view is that detecting an error condition and returning an error code is a 
bug fix rather than a breaking change.


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




> On 11 Nov 2020, at 7:10 pm, Matt Caswell  wrote:
> 
> I have no problem  with the proposal or the vote text. I only wonder
> whether, as a breaking change an OMC vote is required? Or is an OTC vote
> sufficient?
> 
> Matt
> 
> 
> On 10/11/2020 16:15, Nicola Tuveri wrote:
>> ## Background
>> 
>> As part of the discussion in [issue #8435], it was highlighted that both
>> in 1.1.1 and master we are missing tests to validate decoded SM2 keys.
>> The `openssl pkey -check` (or `pkey -pubcheck` to validate only the
>> public key component) command allows to explicitly execute the
>> validation checks, while on regular operations (e.g., using `pkeyutl` or
>> `dgst`) no validation of the input keys is normally done (probably by
>> design).
>> 
>> In [PR 13359] I am adding new tests, using `openssl pkey -check` to
>> validate specific key corner cases, for P-256 as an exemplar for EC keys
>> and for SM2 keys.
>> Unfortunately `openssl pkey -check` behavior currently shows the result
>> of the validation only in the text output, so parsing of `stdout` would
>> require measuring the test results.
>> In the PR I am proposing to change the behavior of `openssl pkey` so
>> that an early exit is triggered if `-check` or `-pubcheck` validation
>> fails, exiting with a failure exit status: [apps/pkey.c changes].
>> 
>> This is a breaking change in the behavior of `openssl pkey` and the
>> reason why I am planning to raise a vote to approve this change.
>> 
>> Note that during our OTC meeting today it was proposed as an alternative
>> to have a more generic vote on approving this kind of change in general
>> for all similar situations across all the apps.
>> While I am not opposed to such a decision, I am afraid having such a
>> generic vote might be quite difficult:
>> 
>> - I am not sure I can express in a clear and unambiguous what are the
>>  conditions to fall within "similar situations", making such a
>>  decision hard to execute in practical terms;
>> - I personally cannot commit to execute such vote across all apps and
>>  all relevant conditions: doing so requires extensive review of the
>>  apps logic in parsing the CLI switches, of conformity with existing
>>  documentation and an exploration of existing use patterns in the user
>>  codebase to see what are the expectations and estimate the impact of
>>  such changes. It would also require writing an extensive battery of
>>  tests to ensure we behave as documented/expected across apps and CLI
>>  switches.
>> - The amount of work to which we would commit after such a generic
>>  decision, and the impact it could have on the behavior consistency
>>  w.r.t. 3.0 and 1.1.1, would make me think such a decision is more in
>>  the realm of strategic objectives, for which an OMC vote would be more
>>  appropriate.
>> 
>> For these reasons, at this time, I am opting to propose an OTC vote on
>> the single case of the behavior change of `pkey -check`/`pkey -pubcheck`
>> rather than a more generic one, and I will let others decide if a more
>> generic vote is also required/appropriate and if it can be framed
>> exclusively within the technical prerogatives of the OTC decision
>> process.
>> 
>> ## Proposed vote text
>> 
>>Change the behavior of `pkey -check`
>>and `pkey -pubcheck` in 3.0 to trigger an
>>early exit if validation fails, returning a
>>failure exit status to the parent process.
>> 
>> ---
>> 
>> Please leave feedback relevant to the proposed vote text and the scope
>> of the vote.
>> In absence of feedback I plan to open the actual vote in 24h.
>> 
>> 
>> 
>> Cheers,
>> 
>> Nicola
>> 
>> ---
>> 
>> [issue #8435]: 
>> <https://urldefense.com/v3/__https://github.com/openssl/openssl/issues/8435__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvrBSYf2E$
>>  
>> <https://urldefense.com/v3/__https://github.com/openssl/openssl/issues/8435__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvrBSYf2E$>
>>  >
>> [PR 13359]: 
>> <https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1Jw

Proposed OMC by law vote

[Dr Paul Dale]

Proposed vote text: Accept the by law changes proposed in #207.

Comment: https://github.com/openssl/web/pull/207 
<https://github.com/openssl/web/pull/207>


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

Proposed OMC vote to remove C source output from apps

[Dr Paul Dale]

Proposed vote text:

Remove -C option from the dhparam, dsaparam, ecparam and x509 apps.

This is a breaking change and requires OMC approval.  The rationale is that it 
is easier to not support this using the EVP calls and there is some doubt that 
the options are used anymore.


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

Proposed OMC vote: drop -crypt option from passwd app

[Dr Paul Dale]

Proposed vote text:

Remove the -crypt option from the passwd app.

The rationale behind this is that this is a very old, long broken algorithm and 
that supporting it is difficult using non-deprecated calls.  This is a breaking 
change and requires OMC approval.


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

Re: Project direction

[Dr Paul Dale]

This came in privately from Michael Richardson and is forwarded with permission:

> If you don't grow the user base, you decline.
> As long as the old APIs do not go away too quickly, or the new APIs are
> obvious refactors, then it won't be such a problem.
> 
> In general, I think that there are way too many APIs, and the documentation
> is poorly organized by what it does rather than what things it does it to
> (more OOP).
> I tried to collect notes at one point, I had other priorities.
> 
> And I still have a pull request which is waiting for me to validate that it
> works on VAX/VMS.


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




> On 30 Oct 2020, at 9:43 am, Dr Paul Dale  wrote:
> 
> At the OTC call on Tuesday Tim raise a point about the future direction of 
> the project.  I was tasked with bringing this to the OMC for consideration.
> 
> The question was should we design our APIs to ease the pain existing users of 
> OpenSSL or should we be trying to attract new users.
> The idea being that supporting existing users means not changing the existing 
> API, whereas catering to new users means working towards a new fresh 
> consistent API.
> 
> This is all in the context of function naming, argument ordering, cleanup for 
> beta 1.
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 

Project direction

[Dr Paul Dale]

At the OTC call on Tuesday Tim raise a point about the future direction of the 
project.  I was tasked with bringing this to the OMC for consideration.

The question was should we design our APIs to ease the pain existing users of 
OpenSSL or should we be trying to attract new users.
The idea being that supporting existing users means not changing the existing 
API, whereas catering to new users means working towards a new fresh consistent 
API.

This is all in the context of function naming, argument ordering, cleanup for 
beta 1.


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

Hacktoberfest

[Dr Paul Dale]

There has been a request in #13172 
<https://github.com/openssl/openssl/pull/13172> to tag the PR for Hacktoberfest 
<https://hacktoberfest.digitalocean.com/>.
There are two ways 
<https://hacktoberfest.digitalocean.com/hacktoberfest-update> to do this: add a 
tag to the PR or a topic to the project.

Is either something the project is interested in doing?

Rather than polluting our already busy tags menu, the topic seems the easier 
path to me.


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

Re: LTS+

[Dr Paul Dale]

Unless the change can be argued to be security hardening — an improved entropy 
source would be IMO.

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




> On 20 Oct 2020, at 9:10 am, Dr Paul Dale  wrote:
> 
> Not with the wording used.  The feature exists even if it’s rubbish.
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 20 Oct 2020, at 5:07 am, Tomas Mraz > <mailto:t...@t8m.info>> wrote:
>> 
>> I wonder if something like adding a new entropy source on an existing 
>> platform especially on some that currently don't have adequate ones would be 
>> covered by this.
>> 
>> ⁣Tomáš​
>> 
>> 19. 10. 2020 18:29, 18:29, Matt Caswell > <mailto:m...@openssl.org>> napsal/a:
>>> 
>>> 
>>> On 19/10/2020 15:14, Matt Caswell wrote:
>>>> LTS+ releases may contain the following new features:
>>>> - Support for additional platforms
>>>> - Performance improvements
>>> 
>>> Based on the discussion in PR #13176, I'd like to add to this list:
>>> 
>>> - Extending existing features to existing platforms where that feature
>>> does not yet exist
>>> 
>>> Thoughts?
>>> 
>>> Matt
>> 
> 

Re: LTS+

[Dr Paul Dale]

Not with the wording used.  The feature exists even if it’s rubbish.


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




> On 20 Oct 2020, at 5:07 am, Tomas Mraz  wrote:
> 
> I wonder if something like adding a new entropy source on an existing 
> platform especially on some that currently don't have adequate ones would be 
> covered by this.
> 
> ⁣Tomáš​
> 
> 19. 10. 2020 18:29, 18:29, Matt Caswell  napsal/a:
>> 
>> 
>> On 19/10/2020 15:14, Matt Caswell wrote:
>>> LTS+ releases may contain the following new features:
>>> - Support for additional platforms
>>> - Performance improvements
>> 
>> Based on the discussion in PR #13176, I'd like to add to this list:
>> 
>> - Extending existing features to existing platforms where that feature
>> does not yet exist
>> 
>> Thoughts?
>> 
>> Matt
> 

Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released

[Dr Paul Dale]

Nowhere has it been said that the weekly meeting will be 3 hours.
The existing 1.5 - 2 hour slot should be enough, although perhaps not for a few 
more weeks.

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




> On 10 Oct 2020, at 7:29 am, SHANE LONTIS  wrote:
> 
> [+1]  (reluctantly committing to 3 hour meetings :))
> 
> 
>> On 9 Oct 2020, at 10:00 pm, Nicola Tuveri > <mailto:nic@gmail.com>> wrote:
>> 
>> topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13
>>   and until 3.0 beta1 is released, in lieu of the weekly "developer
>>   meetings".
>> Proposed by Nicola Tuveri
>> Public: yes
>> opened: 2020-10-09
>> closed: 2020-mm-dd
>> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>> 
>>  Matt   [  ]
>>  Mark   [  ]
>>  Pauli  [  ]
>>  Viktor [  ]
>>  Tim[  ]
>>  Richard[  ]
>>  Shane  [  ]
>>  Tomas  [  ]
>>  Kurt   [  ]
>>  Matthias   [  ]
>>  Nicola [+1]
> 

Re: VOTE: Technical Items still to be done

[Dr Paul Dale]

[to the project list this time]

+1

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




> On 9 Oct 2020, at 12:47 am, Matt Caswell  wrote:
> 
> topic: The following items are required prerequisites for the first beta
> release:
> 1) EVP is the recommended API, it must be feature-complete compared with
>the functionality available using lower-level APIs.
>   - Anything that isn’t available must be put to an OTC vote to exclude.
>   - The apps are the minimum bar for this, subject to exceptions noted
> below.
> 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_,
>RAND_METHOD_.
>   - Does not include macros defining useful constants (e.g.
> SHA512_DIGEST_LENGTH).
>   - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`.
>   - There might be some others.
>   - Review for exceptions.
>   - The apps are the minimum bar to measure feature completeness for
> the EVP
> interface: rewrite them so they do not use internal nor deprecated
> functions (except speed, engine, list, passwd -crypt and the code
> to handle
> the -engine CLI option).  That is, remove the suppression of deprecated
> define.
> - Proposal: drop passwd -crypt (OMC vote required)
>   - Compile and link 1.1.1 command line app against the master headers and
> library.  Run 1.1.1 app test cases against the chimera.  Treat this
> as an
> external test using a special 1.1.1 branch. Deprecated functions
> used by
> libssl should be moved to independent file(s), to limit the
> suppression of
> deprecated defines to the absolute minimum scope.
> 3) Draft documentation (contents but not pretty)
>   - Need a list of things we know are not present - including things we
> have
> removed.
>   - We need to have mapping tables for various d2i/i2d functions.
>   - We need to have a mapping table from “old names” for things into the
> OSSL_PARAMS names.
> - Documentation addition to old APIs to refer to new ones (man7).
> - Documentation needs to reference name mapping.
> - All the legacy interfaces need to have their documentation
> pointing to
>   the replacement interfaces.
> 4) Review (and maybe clean up) legacy bridge code.
> 5) Review TODO(3.0) items #12224.
> 6) Source checksum script.
> 7) Review of functions previously named _with_libctx.
> 8) Encoder fixes (PKCS#8, PKCS#1, etc).
> 9) Encoder DER to PEM refactor.
> 10) Builds and passes tests on all primary, secondary and FIPS platforms.
> 11) Query provider parameters (name, version, ...) from the command line.
> 12) Setup buildbot infrastructure and associated instructions.
> 13) Complete make fipsinstall.
> 14) More specific decoding selection (e.g. params or keys).
> 15) Example code covering replacements for deprecated APIs.
> 16) Drop C code output options from the apps (OMC approval required).
> 17) Address issues and PRs in the 3.0beta1 milestone.
> Proposed by .
> Public: yes
> opened: 2020-10-08
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>  Matt   [+1]
>  Mark   [  ]
>  Pauli  [  ]
>  Viktor [  ]
>  Tim[  ]
>  Richard[  ]
>  Shane  [  ]
>  Tomas  [  ]
>  Kurt   [  ]
>  Matthias   [  ]
>  Nicola [  ]

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

[Dr Paul Dale]

+1

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




> On 9 Oct 2020, at 12:27 am, Matt Caswell  wrote:
> 
> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as
> shown in PR #13018 into the 3.0 release
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-10-08
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>  Matt   [+1]
>  Mark   [  ]
>  Pauli  [  ]
>  Viktor [  ]
>  Tim[  ]
>  Richard[  ]
>  Shane  [  ]
>  Tomas  [  ]
>  Kurt   [  ]
>  Matthias   [  ]
>  Nicola [  ]

Re: Vote proposal: Private keys can exist independently of public keys

[Dr Paul Dale]

Would it be feasible to change code that does ->pub_key to call a function that 
null checks the field and generates the public key if it is absent?


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




> On 7 Oct 2020, at 9:29 pm, Matt Caswell  wrote:
> 
> Issue #12612 exposes a problem with how we handle keys that contain
> private components but not public components.
> 
> There is a widespread assumption in the code that keys with private
> components must have public components. There is text in our public
> documentation that states this (and that text dates back to 2006).
> 
> OTOH, the code has not always enforced this. Issue #12612 describes a
> scenario where this has not historically been enforced, and it now is in
> the current 3.0 code causing a regression.
> 
> There are differences of opinion on how this should be handled. Some
> have the opinion that we should change the model so that we explicitly
> allow private keys to exists without the public components. Others feel
> that we should continue with the old model.
> 
> It seems we need a vote to decide this. Here is my proposed vote text:
> 
> We should change the 3.0 code to explicitly allow private components to
> exist in keys without the public components also being present.
> 
> Feedback please on the proposed vote text.
> 
> Matt

Would this be interesting to the project?

[Dr Paul Dale]

https://github.blog/2020-09-30-code-scanning-is-now-available/ 
<https://github.blog/2020-09-30-code-scanning-is-now-available/>

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

Re: Memory leak in openssl 1.1.1d

[Dr Paul Dale]

This isn’t enough information to diagnose the issue.  Which of the leak summary 
records is the problem?
Are you sure that your application is cleaning up properly (hint: it isn’t, 
e.g. OpenSSL never calls operator new() from the second record).

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




> On 10 Sep 2020, at 1:39 am, Abhi Arora  wrote:
> 
> I am using openssl 1.1.1d. I found out around 228 bytes are being directly 
> lost (as per valgrind) report. I have one application which uses curl (7.64) 
> and I wrote the same application using POCO HTTPS and I got the same result.
> 
> I thought it could be related to the cipher suit. I can see the leak is 
> dependent on the URL being used (all were https). For one of the urls, it was 
> leaking 228 (directly) per connection and disconnection. For one of the urls, 
> the same code doesn't leak atall (no matter how many times you run that code 
> in a for loop).
> 
> For the urls which were leaking, the following cipher suites were being used:
> 1. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
> 2. SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
> 
> Here is the valgrind summary:
> ==8620== HEAP SUMMARY:
> ==8620== in use at exit: 121,777 bytes in 1,097 blocks
> ==8620==   total heap usage: 129,382 allocs, 128,285 frees, 10,635,842 bytes 
> allocated
> ==8620==
> ==8620== 8 bytes in 1 blocks are possibly lost in loss record 16 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4E75523: ??? (in /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 8 bytes in 1 blocks are definitely lost in loss record 17 of 372
> ==8620==at 0x483F310: operator new(unsigned int) (vg_replace_malloc.c:336)
> ==8620==by 0x36D15: main (sample_pki.cpp:27)
> ==8620==
> ==8620== 8 bytes in 1 blocks are definitely lost in loss record 18 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4CBF14B: CRYPTO_zalloc (mem.c:230)
> ==8620==by 0x4C76E07: ECDSA_SIG_new (ec_asn1.c:1214)
> ==8620==by 0x537064B: pkcs11_try_pkey_ec_sign (p11_pkey.c:546)
> ==8620==by 0x537064B: pkcs11_pkey_ec_sign (p11_pkey.c:634)
> ==8620==by 0x4CB70CD: EVP_DigestSignFinal (m_sigver.c:148)
> ==8620==by 0x4BA9FF3: tls_construct_cert_verify (statem_lib.c:307)
> ==8620==by 0x4BA42C7: write_state_machine (statem.c:843)
> ==8620==by 0x4BA42C7: state_machine (statem.c:443)
> ==8620==by 0x4B8BABB: ssl3_read_bytes (rec_layer_s3.c:1278)
> ==8620==by 0x4B900E1: ssl3_read_internal (s3_lib.c:4473)
> ==8620==by 0x4B9013F: ssl3_read (s3_lib.c:4497)
> ==8620==by 0x4B96A6D: ssl_read_internal (ssl_lib.c:1761)
> ==8620==by 0x4B96B09: SSL_read (ssl_lib.c:1775)
> ==8620==
> ==8620== 16 bytes in 2 blocks are possibly lost in loss record 55 of 372
> ==8620==at 0x483EA30: malloc (vg_replace_malloc.c:306)
> ==8620==by 0x48419FF: realloc (vg_replace_malloc.c:834)
> ==8620==by 0x4E73B5D: amqpvalue_set_map_value (in 
> /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 40 bytes in 10 blocks are possibly lost in loss record 182 of 372
> ==8620==at 0x483EA30: malloc (vg_replace_malloc.c:306)
> ==8620==by 0x48419FF: realloc (vg_replace_malloc.c:834)
> ==8620==by 0x4E738BB: amqpvalue_set_list_item (in 
> /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 48 bytes in 1 blocks are possibly lost in loss record 210 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4E7582D: ??? (in /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 48 bytes in 2 blocks are possibly lost in loss record 211 of 372
> ==8620==at 0x48419B0: realloc (vg_replace_malloc.c:834)
> ==8620==by 0x4E73B5D: amqpvalue_set_map_value (in 
> /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 56 bytes in 1 blocks are possibly lost in loss record 215 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4E74FF9: ??? (in /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 64 bytes in 2 blocks are possibly lost in loss record 228 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4E74477: ??? (in /usr/lib/libuamqp.so.1.2.12)
> ==8620==
> ==8620== 64 bytes in 1 blocks are definitely lost in loss record 229 of 372
> ==8620==at 0x483EB28: malloc (vg_replace_malloc.c:307)
> ==8620==by 0x4A8D411: __libc_alloc_buffer_allocate 
> (alloc_buffer_allocate.c:26)
> ==8620==by 0x4AE2B51: alloc_buffer_allocate (alloc_buffer.h:143)
> ==8620==by 0x4AE2B51: __resolv_conf_allocate (resolv_conf.c:411)
> ==8620==by 0x4AE147D: __resolv_conf_load (res_init.c:592)
> ==8620==by 0x4AE

Re: Integration of new algorithms

[Dr Paul Dale]

Instead of using an engine, you should write a provider (assuming you’re using 
the soon to be released OpenSSL 3.0).  It doesn’t need a NID.

If you are using OpenSSL 1.1.1, try the OBJ_new_nid() function.


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




> On 26 Aug 2020, at 6:48 pm, Kris Kwiatkowski  wrote:
> 
> 
> Hey,
> 
> I'm working on development of OpenSSL ENGINE that integrates
> post-quantum algorithms (new NIDs). During integration I
> need to modify OpenSSL code to add custom function, but would
> prefer not to need add anything to OpenSSL code (so engine
> can be dynmicaly loaded by any modern OpenSSL).
> 
> So, In three cases, namely when the code is in callbacks for keygen,
> encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt 
> and EVP_PKEY_keygen) I need to get NID of the scheme. The problem
> is that, those functions are called with EVP_PKEY_CTX object
> provided as an argument. The NID is stored in the 
> EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API
> which would return that value.
> 
> I've added a simple function that returns pkey_id from the ctx, but
> that means that I need to change OpenSSL code. Is there any way
> to get NID without changing OpenSSL?
> 
> Kind regards,
> Kris
> 
> 
> 
> 

Re: VOTE: Accept the OTC voting policy as defined:

[Dr Paul Dale]

+1

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




> On 28 Sep 2020, at 10:02 pm, Dr. Matthias St. Pierre 
>  wrote:
> 
> topic: Accept the OTC voting policy as defined:
> 
>   The proposer of a vote is ultimately responsible for updating the 
> votes.txt
>   file in the repository.  Outside of a face to face meeting, voters MUST 
> reply
>   to the vote email indicating their preference and optionally their 
> reasoning.
>   Voters MAY update the votes.txt file in addition.
> 
>   The proposed vote text SHOULD be raised for discussion before calling 
> the vote.
> 
>   Public votes MUST be called on the project list, not the OTC list and 
> the
>   subject MUST begin with "VOTE:".  Private votes MUST be called on the
>   OTC list with "PRIVATE VOTE:" beginning subject.
> 
> Proposed by Matthias St. Pierre (on behalf of the OTC)
> Public: yes
> opened: 2020-09-28
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>  Matt   [  ]
>  Mark   [  ]
>  Pauli  [  ]
>  Viktor [  ]
>  Tim[  ]
>  Richard[  ]
>  Shane  [  ]
>  Tomas  [  ]
>  Kurt   [  ]
>  Matthias   [+1]
>  Nicola [  ]
>