Re: [Openvpn-users] [Openvpn-devel] OpenVPN 2.4.3 released (with security fixes)

[David S. <op...@sf...>]

On 21/06/17 12:47, Samuli Seppänen wrote:
> The OpenVPN community project team is proud to release OpenVPN 2.4.3. It
> can be downloaded from here:
> 
> <http://openvpn.net/index.php/open-source/downloads.html>
> 
> OpenVPN v2.4.2 was analyzed closely using a fuzzer by Guido Vranken. In
> the process several vulnerabilities were found, some of which are
> remotely exploitable in certain circumstances. We recommend you to
> upgrade to OpenVPN 2.4.3 or 2.3.17 as soon as possible. More details are
> available in our official security announcement:
> 
> <https://community.openvpn.net/openvpn/wiki/VulnerabilitiesFixedInOpenVPN243>
> 
> In addition a number of bugs with no security impact have been fixed.
> The one big feature in the 2.4.3 release is support for building with
> OpenSSL 1.1.
> 
> A summary of all included changes is available here:
> 
> <https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst>
So just trying to hijack this discussion which is to be found a few more
places elsewhere in this mail thread.  No need to let this discussion
run longer.

There are several area where we definitely can improve the release
process.  Last round where we managed to mess up the 2.3.15 release, so
I wrote a brand new "prepare release tarballs" script, which also
handles the signing.  This script _was_ used to produce the files to be
pushed out for the 2.4.3/2.3.17 releases.

But for reasons unknown to me, those tarballs got re-created somewhere
later in the release chain.  The contents of all tarballs are
essentially the same, but due to the "nice" artefact that the tar format
is non-deterministic on the output, even though the input is the same,
that begins to prepare the stage for this chaos.  Especially when what
is being uploaded is partly from the initial run and then some files
from a different run.

All that is history now.  Now we need to look forward.  Many good points
have been raised.

- Do we need .tar.gz and .zip files?  Where and why?
  The fewer source tarballs we need to handle, the less chance for
  errors

- Improve Makefile.am to not generate dist-gz files when running
  distcheck.  The distcheck run often provides very good indicator if we
  have packaged all the needed files in the source tarball.  If this
  doesn't pass, something is really wrong.

- Do we really need to re-create the source tarballs which the new
  ./dev-tools/gen-release-tarballs.sh?  Why?

- What can be done with Cloudflare to fully ensure their caches are
  truly purged when we ask for it?  As Jonathan noticed, their caches
  are tightly connected to the web browser and have a non-deterministic
  behaviour across browsers, even on the same computer.

- What else in the release process can be automated and put into a
  script?  This to ensure consistency between all releases we do.

- We need to write down a proper check-list of all the steps needed
  for a release, including putting a clear responsibility for each
  release.  This list must also mention which scripts to be run.  Again,
  automation is key to reduce the risk for errors.

- Consider how many who really needs to be involved in producing a
  release.  More chefs in a kitchen can result in great food, but it can
  also end up quite messy.

- At the same time, ensure we don't end up in a "single point of
  failure".  More of us core developers need to be able to step in for
  others, and still be able to produce a release without errors.  This
  can be the end result if we have proper scripts, both for automated
  and manual tasks.


My intention with these points are primarily "food for thought".  I
don't fully believe it will be easy to have a well structured debate
about the complete release process in a mailing list thread.

So I suggest we take a few weeks holiday, let this sink in, and then we
can schedule a meeting some time in August where we discuss these
issues.  And lets hope we don't need to rush yet another release before
August :)


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc