openssl / technical-policies Goto Github PK

Mirror of the repository for technical policies, governed by the OTC (OpenSSL Technical Committee)

technical-policies's Introduction

OpenSSL Technical Policies

This repository contains the technical policies and procedures established by the OTC in accordance with the project bylaws and the requirements specified by the OMC.

The Policies

The policies are stored in the policies subdirectory, each in a separate markdown file called policy-name.md where policy-name is a short memorable description of the policy such as voting-procedure, design-process, or similar.

New policies or changes to existing policies are proposed and discussed in pull requests and issues of this repository, and finally merged after an approval by an OTC vote. The details are regulated by the policy-change-process and the voting-procedure policy.

The Vote Records

The records of the policy votes are stored in the votes subdirectory, each in a separate file. The format of those records is described in the voting-procedure policy.

technical-policies's People

Contributors

Stargazers

Watchers

technical-policies's Issues

Vote: Change from PR #18267 is acceptable for backport into 3.0 branch.

Topic: Change from PR #18267 is acceptable for backport into 3.0 branch.
Proposed by: Tomas Mraz
Issue link: https://github.com/openssl/technical-policies/issues/70
Public: yes
Opened: 2023-07-11
Closed: 2023-07-19
Accepted:  yes  (for: 6, against: 1, abstained: 2, not voted: 1)

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

vote: FIPS indicator design

Topic: OTC approve the FIPS indicator design presented in PR#23609 subject to the
normal review process
Proposed by: Matt Caswell
Issue link: https://github.com/openssl/openssl/pull/23609
Public: yes
Opened: 2024-05-28
Closed: 2024-05-28
Accepted:  yes  (for: 6, against: 0, abstained: 0, not voted: 0)

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

See openssl/openssl#23609

Revert #13906 for 3.0 & master

Topic: revert change in PR #13906 for 3.0 & master and provide an alternative
mechanism for the desired behaviour.
Proposed by: Pauli
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     [  ]

Exposing OPENSSL_str[n]casecmp functions in 3.0

We consider openssl/openssl#18039 as a serious regression needed to be fixed.
The proper fix requires introducing API functions OPENSSL_str[n]casecmp because case insensitive comparison is widely used in openssl itself and should be available for 3rd-party provider authors.

The question is: do we support the export of OPENSSL_str[n]casecmp as public API functions in 3.0?

Topic: We export OPENSSL_str[n]casecmp as public API functions in 3.0
Proposed by: Dmitry
Issue link: https://github.com/openssl/openssl/issues/18039, https://github.com/openssl/openssl/issues/18069, https://github.com/openssl/openssl/issues/18103 
Public: yes
Opened: 2022-04-19
Closed: 2022-04-20
Accepted:  yes  (for: 5, against: 2, abstained: 3, not voted: 0)

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

vote: Allow the backport of the AES-XTS optimization on Power platform

Topic: Allow the backport of the AES-XTS optimization on Power platform as per
#24531 to all branches back to 3.0 subject to the standard review process
normal review process
Proposed by: Matt Caswell
Issue link: https://github.com/openssl/openssl/issues/96
Public: yes
Opened: 2024-06-04
Closed: 2024-06-04
Accepted:  yes  (for: 4, against: 0, abstained: 3, not voted: 2)

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

Vote: Automatically compute public key on import if missing

Topic: For all currently implemented algorithms, where it is possible,
       if the public key component is missing when a key is imported
       into a provider, the public key component should be computed.
Proposed by: Tomas Mraz
Issue link:.
Public: yes
Opened: 2022-09-06
Closed:.
Accepted:  yes/no  (for: , against: , abstained: , not voted: )

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

Documentation requirements

It seems there is at least not an agreement on what all needs to be documented. It would be good to have a policy document so that we can all agree on what is needed.

The only thing I could find that mentions anything about it is the roadmap, which says new public APIs will be documented.

My understanding of what we talked about many years ago is that we want all functions, including internal, to be documented. This means all new functions, public or not, will be documented. The strategy for existing functions, public or not, is that we check/add the documentation when we modify the function.

Vote: OTC considers PR#17984 as a bug fix

PR#17984

Topic: OTC considers PR#17984 as a bug fix and therefore can be backported to
       the 3.0 branch
Proposed by: Matt Caswell
Issue link: .
Public: yes
Opened: 2022-10-11
Closed: YYYY-MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

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

vote: Accept PR #20484 into the 3.1.0 release

topic: Accept PR #20484 into the 3.1.0 release
Proposed by Tim.
Public: yes
opened: 2023-03-14
closed: 2023-03-14
accepted: yes   (for: 8, against: 0, abstained: 1, not voted: 2)

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

Vote: Backport PR #19681 to 3.0 as a bug fix

Topic: Backport PR #19681 to 3.0 as a bug fix
Comment: Fundamentally OTC must decide if in the 3.0 release we should
         honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and
         default to UNCOMPRESSED) in our provider implementations, and
         apply corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: https://github.com/openssl/technical-policies/issues/60
Public: yes
Opened: 2022-12-01
Closed: 2022-12-14
Accepted:  yes  (for: 4, against: 0, abstained: 5, not voted: 2)

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

Convenience links

PR in question: openssl/openssl#19681
Vote to accept the PR for 3.1: #59
Triaged bug report: openssl/openssl#16595

EVP_DigestFinal() and EVP_Digest() should fail for SHAKE-128 and SHAKE-256 unless the xoflen param is set

Topic: The EVP_DigestFinal() and EVP_Digest() functions should fail for SHAKE-128 and
SHAKE-256 unless the xoflen param is set by the application.
Proposed by: Tomas Mraz
Issue link: https://github.com/openssl/technical-policies/issues/93
Public: yes
Opened: 2024-04-23
Closed: 2024-04-23
Accepted:  yes  (for: 6, against: 0, abstained: 1, not voted: 3)

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

Policy exception: change the default no-asm implementation in 3.0 to the faster non-constant time version

Topic: OTC approves the OMC request for an exception to the stable release
policy to allow changing the default AES for no-asm builds from the
constant time one introduced in PR#10828 to the prior non-constant
time version.
Proposed by: Tim
Public: yes
Opened: 2022-01-25
Closed: 2022-01-25
Accepted: yes (for: 7, against: 1, abstained: 0, not voted: 2)

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

Approve the source ready for the 3.3. beta release

Topic: OTC approve the source is ready for 3.3 beta release subject to the following
occuring prior to beta release:
- req return value change must be merged (#23773)
- RCU test should be disabled for Mac platform (#23967)
- CHANGES and NEWS should be updated
Proposed by: Matt Caswell
Issue link: https://github.com/openssl/technical-policies/issues/92
Public: yes
Opened: 2024-03-26
Closed: 2024-03-26
Accepted:  yes  (for: 5, against: 0, abstained: 3, not voted: 2)

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

vote: Approval for contractors to access security issues

topic: OTC extends standing approval for contractors to have access to the
security repository and security mailing list when approved at the discretion of
the engineering manager.
Proposed by Nicola
Public: yes
opened: 2023-11-21
closed: 2023-11-21
accepted:  yes  (for: 9, against: 0, abstained: 0, not voted: 1)

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

vote: Support for the NonStop SPT threading model and SPT build configs

#22807: Deprecate SPT threading on NonStop
    The NonStop maintainer has requested dropping support for SPT
        in 3.2 and master.
    We should remove support for SPT in 3.2.
    There is no contest that this should be removed in master.

    topic: Support for the NonStop SPT threading model and SPT build configs
           can be removed from 3.2 branch subject to no objections being
           received from the community within two weeks after this vote passing
    Proposed by Tim
    Public: yes
    opened: 2023-11-28
    closed: 2023-11-28
    accepted:  yes  (for: 9, against: 0, abstained: 0, not voted: 1)

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

Vote: Accept PR#18407 for backfit to 3.0 as a policy exception.

The topic of this vote is: Accept PR#18407 for backfit to 3.0 as a policy exception.

The snippet below records the current votes as cast during the weekly OTC meeting (2022-05-31) during which the vote was called.
The vote is still open.

Topic: Accept PR#18407 for backfit to 3.0 as a policy exception.
Proposed by: Nicola
Issue link: https://github.com/openssl/technical-policies/issues/52
Public: yes
Opened: 2022-05-31
Closed: 
Accepted:    (for: , against: , abstained: , not voted: )

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

vote: Accept #22493 for 3.2 (including the RNG changes) subject to normal review process

topic: Accept #22493 for 3.2 (including the RNG changes)
   subject to normal review process.
comment: https://github.com/openssl/openssl/pull/22493
Proposed by Hugo.
Public: yes
opened: 2023-10-31
closed: 2023-10-31
accepted:  yes  (for: 4, against: 1, abstained: 4, not voted: 2)

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

Switch to C11 instead of C89/C90

The main reason we were stuck on C89/C90 is that Microsoft Visual C didn't support anything more recent. Recent versions do support C11: https://docs.microsoft.com/en-us/cpp/overview/install-c17-support?view=msvc-170. Note that they don't support C99. I suggest we consider changing to C11.

vote: OTC F2F

topic: OTC will hold a face to face meeting in Brno on 19th-21st June 2023 open
       to all OTC members and committers. Attendees must confirm participation by 14th
       April including whether or not project funding is required.
Proposed by Tim.
Public: yes
opened: 2023-03-28
closed: 2023-03-28
accepted: yes   (for: 8, against: 0, abstained: 0, not voted: 3)

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

vote: OTC agrees that #22577 and 22679 can merge immediately without waiting for the 24 hour timer and should go into 3.2.0

topic: OTC agrees that #22577 and #22679 can merge immediately without waiting
for the 24 hour timer and should go into 3.2.0.
Proposed by Hugo
Public: yes
opened: 2023-11-21
closed: 2023-11-21
accepted:  yes (for: 4, against: 0, abstained: 5, not voted: 1)

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

Vote: OpenSSL 3.1 beta 1 release approval

Topic: OTC approves 3.1 beta 1 release on Wed Dec 21 2022 assuming all
       the outstanding items on the release check-list (#19864) are done
       including the provisions for Coverity and Coveralls items as
       mentioned in the check list issue.
Proposed by: Tomas Mraz
Issue link: https://github.com/openssl/technical-policies/issues/
Public: yes
Opened: 2022-12-13
Closed: 2022-12-13
Accepted:  yes  (for: 8, against: 0, abstained: 0, not voted: 3)

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

Security advisories

I think we need to have a document describing what should all be covered in a security advisory. We've talked about this several times in the past, but I can't actually find an open issue for it.

Some of the things we should consider:

Should we document CVSS? In many cases, this gives the wrong answer for the users because it's a library. Maybe we should at least internally determine it. But a score if you use that part of the library can also be useful.
If we don't (publicly) document the CVSS, maybe we should at least document some of the values that go into it, like the complexity of the attack and the impact. This can be as text.
We should probably document how likely that we think you're affected, which is one of the things we use to determine the severity
It should cover internal use in the libraries and the apps.

Vote: Accept PR #19400 in master and 3.0 subject to normal review process

Topic: Accept PR #19400 in master and 3.0 subject to normal review process
Comment: As we published 3.0.6 release with the error reporting added a vote is needed to revert the addition.
Proposed by: Tomas Mraz
Issue link: https://github.com/openssl/technical-policies/issues/56
Public: yes
Opened: 2022-10-18
Closed: 2022-10-18
Accepted:  yes  (for: 8, against: 0, abstained: 1, not voted: 2)

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

Coming soon

https://fariborz.substack.com/p/coming-soon?r=1fm97q&s=w&utm_campaign=post&utm_medium=web&utm_source=direct

Backport #17857 to 3.0 - EVP_MD performance fix

Vote to back port a performance improvement to 3.0.

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]

Coding style assertion table is ugly

The table listing the various asserts and their impacts in debug/non-debug builds is ugly.
Some tweaking of boarders could improve things.

lhash statistics functions deprecation

topic: lhash statistics functions to always report 0 in both master and 3.0. In addition we should deprecate the functions in master.
details: pull request openssl/openssl#17931

Release criteria

We need some release criteria for major, minor, patch, alpha and beta releases.
Removed from the versioning policy (wrt the web page):
Release criteria

For a major or minor release, the following release criteria apply:

all open GitHub issues and pull requests older than 2 weeks at the time of
release need to be assessed for relevance to the version being released.
Any flagged with the a milestone for the version to be released must
be closed (see below);
clean builds in GitHub Actions for two days and
no open Coverity issues (not flagged as False Positive or Ignore).

Valid reasons for closing an issue/PR with a milestone for the version
include:

we have just now or sometime in the past fixed the issue;
unable to reproduce (following discussion with original reporter
if possible);
working as intended;
deliberate decision not to fix this issue until a later release (this
wouldn't actually close the issue/PR but change the milestone instead) and
not enough information and unable to contact reporter.

Exceptions require a vote by the OTC as per the OTC whatever.

VOTE: Accept PR #17998 into master and 3.0 branches

Topic: Accept PR #17998 into master and 3.0 branches
Proposed by: Tomas
Issue link: https://github.com/openssl/technical-policies/issues/41
Public: yes
Opened: 2022-04-07
Closed: 
Accepted:  yes/no  (for: ?, against: ?, abstained: ?, not voted: ?)

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

Add coding-style chapter on assertion usage

There is a web pull request that can be used as a starting point: openssl/web#42

Nawab Ikramullah Khan’s Notes’

Backport #17973 to 3.0: reduction of block size in sparse array

Reducing the block size greatly increase the performance of ossl_sa_doall_arg.
None of the other ossl_sa_* functions feature in profiling.

This trades the doall performance for an extra indirection or two when looking up.

vote: Accept PR #22602

topic: Accept PR #22602
comment: https://github.com/openssl/openssl/pull/22602
Proposed by Matt.
Public: yes
opened: 2023-11-14
closed: 2023-11-14
accepted:  no  (for: 1, against: 3, abstained: 5, not voted: 2)

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

Move technical policies from the website to the repository

At least the coding style should be moved. Not sure if there are others.

New compilers, old releases?

Refer: ⌗20961

The OTC should formally decide about using new compilers with old releases and what our policy/guidelines are:

Is a new warning which will cause failures when -Werror is specified be considered a bug?
Can we add test cases that exist to exercise newer compilers in old releases?

vote: #23394 (without the NonStop changes) can be backported to 3.2, 3.1 and 3.0

Topic: #23394 (without the NonStop changes) can be backported to 3.2, 3.1 and 3.0
Proposed by: Hugo
Issue link: https://github.com/openssl/technical-policies/issues/89
Public: yes
Opened: 2024-02-13
Closed: 2024-02-13
Accepted:  yes  (for: 3, against: 0, abstained: 5, not voted: 1)

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

Definitions

The technical policy definitions should amalgamated into a single document and referenced from other documents rather than included.

This prevents duplicate definitions which might not be quite the same.

Clarify what constitutes API break and what not

DDvO commented Mar 21, 2023

The problem is that basically anything that changes in the public API headers that can potential break a compilation for > anyone is an API break. So until we found that this is very unlikely to break anyone it was considered an API break. Not > sure how to record this and where.

Thanks for your response, which more or less includes a definition of an API break.
Unfortunately, it won't be easy to give simple syntactic rules to correctly and completely determine what will constitute an API break or not.

For instance, the following header file changes do not lead to API breaks:

whitespace and comment changes
adding or removing the const qualifier before a primitive (i.e., non-reference) type
adding or removing the name or changing the name of a function parameter
adding a declaration
...?

I suggest adding something like this to the technical policies, next to the coding style.

vote: The OTC should establish a public communications policy for OTC members

topic: The OTC should establish a public communications policy for OTC members
Proposed by Tim
Public: yes
opened: 2024-01-23
closed:
accepted:    (for: 2, against: 2, abstained: 3, not voted: 2)

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

vote: OpenSSL 3.2.0 release readiness, Coverity exemption

topic: For OpenSSL-3.2 release, we have relaxed the requirement of "There are no
outstanding untriaged Coverity issues" as there has been an update introduced to
scan.coverity.org on 18-Nov-2023 that has identified 30 potential issues. We
will document this as a known issue. OTC approves 3.2.0 as ready for release.
Proposed by Tim
Public: yes
opened: 2023-11-21
closed: 2023-11-21
accepted:  yes  (for: 9, against: 0, abstained: 0, not voted: 1)

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

VOTE: Accept the technical requirements document

Topic: Accept the technical requirements document provided in openssl/openssl#17577
Proposed by: Matt Caswell
Public: yes
Opened: 2022-03-25
Closed: YYYY-MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

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

See openssl/openssl#17577

Text from the release strategy page should be reviewed

The release strategy is currently available on the website here:

https://www.openssl.org/policies/releasestrat.html

There is information on:

The versioning scheme
Definitions of alpha/beta release and standard release criteria

We should consider whether any of the above text should be converted into a technical policy (either as-is or rewritten).

Other sections of that page are probably more OMC policy. I've created a proposal for those sections here:

openssl/general-policies#3

As noted in that PR, I've left out 2 bullets about stability that currently exist on the release strategy page. Specifically;

No existing public interface can be modified except where changes are unlikely to break source compatibility or where structures are made opaque.
When structures are made opaque, any newly required accessor macros or functions are added in a feature release of the extant LTS release and all supported intermediate successor releases.

We should consider whether any of this text should be incorporated into our stable release updates policy.

Accept PR #16705 into 3.0

topic: Accept PR #16705 into 3.0 subject to the normal review process
Proposed by Matt Caswell
Public: yes
opened: 2021-12-07
closed: 2021-12-07
accepted: yes (for: 4, against: 1, abstained: 3, not voted: 2)

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

Vote: Undeprecate OPENSSL_VERSION_NUMBER macro and OpenSSL_version_num() function

Topic: Undeprecate OPENSSL_VERSION_NUMBER macro and OpenSSL_version_num() function in the documentation in 3.0 branch
Proposed by: Tomáš Mráz
Issue link: https://github.com/openssl/technical-policies/....
Public: yes
Opened: 2022-02-08
Closed: 2022-02-08
Accepted:  yes  (for: 6, against: 0, abstained: 1, not voted:3)

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

Vote: OTC F2F meeting

Topic: OTC should propose to the OMC that we hold an OTC/committer face-2-face 
            meeting in Czech Republic on 19th-21st June 2023
Proposed by: Dmitry Belyavskyi
Issue link: https://github.com/openssl/technical-policies/issues/63
Public: yes
Opened: 2023-01-10
Closed: 2023-01-18
Accepted:  yes  (for: 9, against: 0, abstained: 2, not voted: 0)

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

Move the coding style into the technical policies repository

Vote: Accept PR #19681 in 3.1 subject to normal review process

Topic: Accept PR #19681 in 3.1 subject to normal review process
Comment: Fundamentally OTC must decide if in the 3.1 release we should
         honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and
         default to UNCOMPRESSED) in our provider implementations, and
         apply corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: https://github.com/openssl/technical-policies/issues/59
Public: yes
Opened: 2022-11-15
Closed: 2022-11-27
Accepted:  yes  (for: 7, against: 0, abstained: 2, not voted: 2)

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

Convenience link to the PR in question: openssl/openssl#19681

Voting procedure

I think the public voting policy could use some additional clarification:

If not all OTC members are present at an OTC meeting, a call for votes should be send
After closing, the results of the votes should be send to the openssl-project list