Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea

2022-07-13 Thread Lucas Kanashiro
Hi,

On Fri, 8 Jul 2022 11:36:51 +0200 Raphael Hertzog 
wrote:

> On Wed, 06 Jul 2022, Bernhard Schmidt wrote:
> > > As such I really believe that this git snapshot should have stayed in
> > > experimental. Why was it uploaded to unstable before its upstream
> > > release?
> >
> > I respectfully disagree. This is what unstable/testing is for. 2.6
is to be
> > released really soon, it contains breaking changes which we need to
iron out
> > / document with both upstream and Debian packaging. This can't wait
until
> > the last minute before the freeze. The 2.6 upload was influenced by
OpenSSL
> > 3.0, but this was definitely not the only reason to do this.

The current snapshot actually is missing one important commit to better
support OpenSSL 3:

https://github.com/OpenVPN/openvpn/commit/88342ed8277c579704c0

This is a recommendation from one of the upstream developers here:

https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1975574/comments/3

Could we try at least to get a newer snapshot which includes the
mentioned upstream commit?

Another thing worrying this upstream maintainer was the fact that we
seem to have experimental OpenVPN dco code which has been constantly
improved:

https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1975574/comments/6

> If you were aware of regressions to iron out, it would have made sense to
> file an RC bug to avoid the migration to testing until it has matured in
> unstable.
>
> I understand it's always a trade off and that not all Debian developers
> put the bar at the same level, but keeping testing "constantly usable"
> has been something of a goal for a long time.

I do not see the current version as unusable but a version with
important breaking changes, and those will hit users at some point.

> > This could be discussed with upstream.
>
> I certainly encourage you to discuss with upsream on whether they believe
> a git snapshot ought to be delivered to unstable/testing (and thus
> ultimately ubuntu too).

As Raphael mentioned, upstream is against distros using snapshots from
the master branch, however I do understand the reasons to do it earlier.
>From the Debian perspective, I believe the important thing here is to
make sure we ship 2.6 in the next release.

-- 
Lucas Kanashiro



Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea

2022-07-08 Thread Raphael Hertzog
On Wed, 06 Jul 2022, Bernhard Schmidt wrote:
> > As such I really believe that this git snapshot should have stayed in
> > experimental. Why was it uploaded to unstable before its upstream
> > release?
> 
> I respectfully disagree. This is what unstable/testing is for. 2.6 is to be
> released really soon, it contains breaking changes which we need to iron out
> / document with both upstream and Debian packaging. This can't wait until
> the last minute before the freeze. The 2.6 upload was influenced by OpenSSL
> 3.0, but this was definitely not the only reason to do this.

If you were aware of regressions to iron out, it would have made sense to
file an RC bug to avoid the migration to testing until it has matured in
unstable.

I understand it's always a trade off and that not all Debian developers
put the bar at the same level, but keeping testing "constantly usable"
has been something of a goal for a long time.

> This could be discussed with upstream.

I certainly encourage you to discuss with upsream on whether they believe
a git snapshot ought to be delivered to unstable/testing (and thus
ultimately ubuntu too).

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com



Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea

2022-07-06 Thread Bernhard Schmidt

Am 05.07.22 um 09:23 schrieb Raphaël Hertzog:


as Kali is based on Debian testing, our users started to experience
the git snapshot of OpenVPN that you uploaded. Unfortunately, we got
multiple reports that their VPN break because many VPN services ship .opvn
files that rely on --cipher.

At the same time, it's not really reasonable to expect (commercial)
services to be ready for a version of OpenVPN that is not released yet.

Upstream OpenVPN contributors are blaming Debian/Kali for this choice:
https://forums.openvpn.net/viewtopic.php?p=107165#p107154

As such I really believe that this git snapshot should have stayed in
experimental. Why was it uploaded to unstable before its upstream
release?


I respectfully disagree. This is what unstable/testing is for. 2.6 is to 
be released really soon, it contains breaking changes which we need to 
iron out / document with both upstream and Debian packaging. This can't 
wait until the last minute before the freeze. The 2.6 upload was 
influenced by OpenSSL 3.0, but this was definitely not the only reason 
to do this.



If we don't want to switch back to 2.5.x, it might make sense to
temporarily revert the backwards incompatible change
that breaks most people's setup, I'm speaking of this commit:
https://github.com/OpenVPN/openvpn/commit/65f6da8eeb84fbcea357765e13fa73d0169a143c


I don't see a good reason to do this in Debian. We either have to keep 
that change forever, or at some point later revert the revert, which 
will immediately break these setups again. At least this way users see a 
major version upgrade in their apt log.


This could be discussed with upstream.

Bernhard



Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea

2022-07-05 Thread Raphaël Hertzog
Package: openvpn
Version: 2.6.0~git20220518+dco-2
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@freexian.com

Hello Bernhard,

as Kali is based on Debian testing, our users started to experience
the git snapshot of OpenVPN that you uploaded. Unfortunately, we got
multiple reports that their VPN break because many VPN services ship .opvn
files that rely on --cipher.

At the same time, it's not really reasonable to expect (commercial)
services to be ready for a version of OpenVPN that is not released yet.

Upstream OpenVPN contributors are blaming Debian/Kali for this choice:
https://forums.openvpn.net/viewtopic.php?p=107165#p107154

As such I really believe that this git snapshot should have stayed in
experimental. Why was it uploaded to unstable before its upstream
release?

I assume it was due to OpenSSL 3 becoming the default. However I notice
that upstream released 2.5.7 on May 31 that adds limited support of
OpenSSL 3.x. Can we switch back to 2.5.7 until 2.6 is released upstream?

(We will likely do this in Kali with a version like 2.6.0~really2.5.7)

If we don't want to switch back to 2.5.x, it might make sense to
temporarily revert the backwards incompatible change
that breaks most people's setup, I'm speaking of this commit:
https://github.com/OpenVPN/openvpn/commit/65f6da8eeb84fbcea357765e13fa73d0169a143c

It seems to be the change that is causing most issues.

Thank you for maintaining such an important package!