Create a proposal for offering binaries

[arapov]

Proposal:
We should offer windows binaries to our users as part of our release process. Others might be good as well, but non-windows platforms seem content to either build their own, or use a distro-provided build. As such this should be focused on windows binaries only

I think given the scope of this effort, we should focus on the creation of the installer as a openssl-3.4.0 target, and attempt to make the installer available as a signed, downloadable artifact in our next LTS release, openssl-3.5.0

Tasks

Beta Give feedback

1. Determine a windows installer generation tool to use
2. Determine windows code signing procedures/tools/certificates needed
3. Add windows installer generation to CI, and test its installation

Notes:

• NSIS seems like an appropriate installer creation tool. Its mature, fairly robust, open source, and allows for installer creation on the command line, which fits well with our CI
• Signing an application installer seems to be fairly straightforward/self-contained. While Microsoft appears to require that driver packages be signed by microsoft, signing of application packages is less restrictive, allowing for the creation of a certificate that is either self signed, or signed by a key from a certificate authority, which I believe we already posses.

[hlandau]

Seconding use of NSIS.

[nhorman]

Proposal

Rationale

The OpenSSL user base has often requested that openssl distribute windows binaries, as frequently, windows users are consumers of openssl, but are not in a position to build it themselves. This proposal seeks to meet that need

Immediate Requirements

• OpenSSL binaries should be shipped via a Windows installer
• The installer(s) should offer both 64 and 32 bit X86 builds (the most common target for Windows)
• The installer should allow for side-by-side installation of multiple versions
• The installer should allow for the uninstallation of any specific version independent of other installed versions
• The installer should be buildable via our github ci on the latest supported platform release (currently windows-2022)

Long Term Requirements

• OpenSSL installers should be signed using the process outlined by microsoft
• Signed OpenSSL installer packages should be produced as artifacts of our release process and made available via our existing release channels (openssl.org and github.com)

Development schedule

• Immediate Requirements above should be implemented asap (targeting openssl-3.4) to allow for building and testing
• Long term requirements should be developed and implemented after the immediate requirements are fulfilled in a subsequent release (ideally our next LTS openssl-3.5)
• Long term requirements development will require:
  • That we implement our immediate requirements first
  • That we identify or generate a certificate for signing our installer (either using an already signed certificate, or creating a new one)
  • That we make said certificate available to a windows system for use (ideally in our CI via HSM or other means)
  • That we modify our release procedure to include the generation and signing of our installer (ideally this will need to be done via manually triggered workflow in github, to ensure that we have a consistent build environment - This is particularly important as our current 'official' build system is source only and not windows based, preventing local generation)

Notes on signing the installer

• we have a few choices regarding the signing of an installer binary
  • We can self sign a certificate for use in code signing - this is easy, but requires that we distribute the certificate which customers would have to install on target systems to trust
  • We can alternatively purchase a commercial certificate from Thawte, Verisign or Microsoft
  • We can not use a lets encrypt certificate as they do not support app signing
• Once a certificate is obtained
  • We need to find a good way to store and control access to the certificate
  • We need to find a way to provide the certificate to a CI job for building (Not sure if using github secrets is sufficient here)

[nhorman]

Notes:
move to separate repo
Upgrade on minor releases
productize later