openssl / general-policies Goto Github PK

Background:

Our platform policy makes no reference to old versions of Windows. The primary Windows platforms are listed as "VC-WIN64A" and "mingw64" both on Windows 10. There are no community supported Windows platforms. There are a number of Windows platforms in the "unadopted" list - but none of them specify a specific Windows version that they apply to.

In the code we define the macro _WIN32_WINNT to the value 0x0501:

https://github.com/openssl/openssl/blob/4c149cf9f6a2ba665d74dbd4cf44f080816c900b/include/internal/e_os.h#L85-L100

According to the Microsoft documentation this corresponds to Windows XP:

https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170

This means that (by default) we are unable to use functions introduced later than that in the code. We do have some conditionally compiled code which checks the value of _WIN32_WINNT and, if it is sufficient high, uses more recent functions. It is possible to override the default value at Configure time (e.g. perl Configure -D_WIN32_WINNT=...) - but this possibility does not seem to be documented and it seems unlikely that many people do this.

PR openssl/openssl#18270 proposes updating the default value of _WIN32_WINNT to 0x0600 which would exclude Windows XP and Windows Server 2003 users. Microsoft ended support for Windows XP in April 2014 and for Windows Server 2003 in July 2015.

According to this tweet, 5.6% of Windows curl users say they use it on Windows XP:
https://twitter.com/bagder/status/1534465987269083136

Proposal:

This issue is proposing the following vote text in order that PR openssl/openssl#18270 may proceed:

"We will no longer support Windows XP or Windows Server 2003 from OpenSSL 3.1"

(Note: I am not actually calling this vote yet - just gathering feedback).

Our policy currently says:

All submissions must be reviewed and approved by at least two committers, one of whom must also be an OTC member. Neither of the reviewers can be the author of the submission.

This means that if an OTC member is the author, we also need an OTC member to review it. I'm not sure if that was intentional or not.

Policy titles are currently a mess, most visible on our website. Some have the words "OpenSSL" or "Policy" in them, while others don't, and some have the latter in the beginning of the title while others have it at the end. This doesn't help readability.

In general policies, this is what it currently looks like:

• Accessing Sensitive Information Policy
• Contractors Invoicing Policy
• Information Release Policy
• OpenSSL Travel Policy
• OpenSSL release versioning policy
• Platform Policy
• Policy for OpenSSL Committers
• Policy on Proposing General Policy Changes
• Security Policy
• The Public Voting Procedure of OMC

Before making a proposal, I'd like to discuss alternatives that we can throw rocks at.

Topic: Provider selection and handling for SHA1 and RIPEMD160 should be identical given the current understanding of algorithm specific security issues.
Proposed by: Tim

Votes recorded in https://github.com/openssl/general-policies/blob/master/votes/vote-20221012-handling-sha1-and-ripemd160.txt

Background:

We need to expanding our testing process to cover the ABI guarantee we made for 3.0 for providers.
Some issues have been noted in #19171
Partial fixes are in #19201

All provider modules for all prior releases are meant to be able to work seamlessly with later releases. It was a fundamental part of the provider design for 3.0. We aren't testing this well enough currently.

Proposal:

Prior to any future release, we will confirm the provider ABI works for all prior released versions of provider modules (currently fips and legacy).

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.

Topic: Accept PR#19375 to add RIPEMD160 to the default provider for 3.0 subject to the normal review process
Proposed by: Tim

Votes recorded in https://github.com/openssl/general-policies/blob/master/votes/vote-20221012-ripemd160-in-3.0-default-provider.txt

This issue to hold a vote on the next LTS release.

The proposal is:

We should announce that the next LTS release will be 3.0

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

Also change the review criteria to not count the author as a reviewer.
Plus some cleanup of labelling and clarify how the various holds are done.
Review wording and realign with reality.

This issue is to hold a vote on extending the set of primary platforms listed in the platform policy:

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

The proposal is:

We should add linux-x86, linux-generic32 and linux-generic64 as primary platforms in the platform policy

In this case, the definitions differ:

Dear Maintainers,

I maintain the openssl package in Ubuntu. While doing so, I had many occasions
to reflect on the openssl release schedule. I discussed updates a few months
ago with some people of the team on launchpad and I'm really doing all I can in
order to make it better for everyone but users often have incompatible wishes.

NB:

• I pondered a lot about the best place to discuss this
• I will be at FOSDEM and will very happily discuss this in-person

The new release schedule seems very promising but I also have several
concerns with the current release schedule which I think can be fairly easily
improved:

• due to the long-term maintenance needs, we stick to LTS releases unless we
  are sure there will be another openssl LTS by the next Ubuntu LTS
• the openssl team will have to maintain concurrently many releases
• I'm wondering about the audience for interim releases that are maintained for
  2 years but released every 6 months

I'm bringing that up now specifically because Ubuntu 24.04 will still be using
3.0.(latest) unless openssl 3.3 is an LTS (and I arrange for some extra things
due to both ubuntu and openssl releasing in April with beta/RC phases). We
discussed this a lot and couldn't find another way. This also made me think a
lot about the release schedules.

I made a pretty markdown+unicode table/graph in order to explain this.
The Years line (the first one) gives the time in terms of half-years, starting
from an arbitrary point. Full-color blocks indicate full support while shaded
ones indicate security-only maintenance. LTS and Interim releases are grouped
separately due to their different schedule.
The "total" line at the bottom counts how many releases are supported at the
same time.

The first table uses the current release schedule. Except for the first year or
so, there will often be 5 releases supported at the same time, sometimes 4, for
an average of 4.75 in steady state.

I believe that the two year support for interim releases is more than needed
because people who are interested in such a duration are probably using LTS
releases instead, while people who upgrade more frequently are ready to update
every 6 or 12 months.

On the other hand, an LTS every two years would be very helpful and would help
updating tremendously, all while keeping the number of concurrently-supported
versions lower than with the current schedule thanks

Another option could be to keep the same duration for maintenance of interim
releases but release every 12 months instead. I don't think that aligns with
the current goals which probably include releases of a manageable size. (and I
don't want to do another markdown table!).

Do you have opinions on this? I genuinely believe these are small changes that
will be helpful to everyone, especially in the long run.

Thanks.