On 31/05/17 17:48, Simon Matter wrote: [...snip...] >> >> Do you depend on building against OpenSSL 0.9.8? If so, which >> OS/distribution do you use? > > Yes, I have a case with very customized CentOS 5 systems where we also > backport security related patches.
Well, officially we no longer support RHEL 5 or older as of v2.4.
AFAIR, we even agreed late last year when getting ready for the 2.4
release that we won't intentionally break 2.4 builds on unsupported
distros but we will not bother supporting it when we want to move forward.
It is good you take care of backporting security related patches. But
wanting the OpenVPN community to maintain new OpenVPN releases buildable
on those old distros is effectively shifting that responsibility over to
the OpenVPN community.
Had the v2.5 release been in the pipe for the next 6-7 months or so,
then I would be more easily persuaded to let v2.4 keep support for
openssl-0.9.8 around. But the reality is that we don't currently have
a release plan for v2.5.
> Of course the same could be done for openvpn but it's easier to just
> follow the current 2.4 stream.
Right, having others doing your work is always the easiest path for
yourself ;-)
> That's why my suggestion to keep all the compat hacks in 2.4.x and
> kick them out only in the main devel branch.
Which is really speaking against what was the agreement when the 2.4
release started to take shape late last year.
But AFAIR, there also exists compat-openssl10 in RHEL5. Which could
resolve this issue for you.
> I guess that's what most package maintainers expect to happen and
> it keep mailing lists quiet
Most package maintainers wants to have as little work as possible while
providing the latest and greatest to their users. But how that is
achieved is primarily the package maintainer's responsibility.
We as a the upstream project will strive to make life as easy as
possible for package maintainers, but not at any cost.
I further encourage you to read chapter 6.9 in the Quarklabs security
audit [1]. Their recommendation is:
"We thus recommend suppressing these workarounds and to return an
error during compile time if the OpenSSL version is too old. Only
versions 1.0.2 and further should be satisfactory."
Also have in mind that this audit is performed against the v2.4 code base.
So when we're having 1.0.1e as the oldest supported OpenSSL version (as
that is what RHEL6 and RHEL7 ships and gets security fixes), I think
that enforcing v2.4 to comply to this strengthens the overall security
in OpenVPN.
If package maintainers want to run OpenVPN v2.4 on older OS/distro
releases with older OpenSSL libraries, then that is their own decision
and they need to take care of the additional work themselves. Insisting
on upstream OpenVPN developers to make package maintainer's life easy
and disregarding recommendations from security auditors at the same time
is at best a fairly ignorant attitude.
And in practicality, package maintainers will then need to revert the
two commits which removes support for older OpenSSL versions.
[1] <https://ostif.org/wp-content/uploads/2017/05/OpenVPN1.2final.pdf>
--
kind regards,
David Sommerseth
OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
