[Swan-dev] Missing routes with KLIPS in 3.30

Paul Wouters paul at nohats.ca
Wed Feb 26 16:00:30 UTC 2020


On Wed, 26 Feb 2020, Antony Antony wrote:

>> I still do not prefer changing the way versioning works. We have never
>> done this before.
>
> why not?

Because we have never done this before. Everyone using libreswan has to
figure out what this new digit means. They might expect that we are
keeping a LTS version of 3.30.x around, which we do not have resources
to maintain.

> I think this a good time to start doing 3.30.X style branches and tags. If
> we do not master will jump from 3.30 to 3.32, missing 3.31 tag.

The idea was to do a merge, even if it is with no real changes just to
get the tag in.

> As far as I recollect last two times such a jump happened, think of v3.23
> and v3.29, no one was happy and requested 3.30.x style release.

I don't think people requested this style before. The idea we had the
first time was to do release branches and leave them "dead", while
master continued. When we did that, THEN people complained the tag
was not on master and that confused some tooling.

> Then it was
> harder to discuss because of CVE. Here is an opportunity to do better
> versioning and also discuss it. AFIK there is no CVE in the pipe line. When
> there is CVE it is harder even to start discussing new versioning style,
> which many of us want see happen for a long time already.

I don't think the situation is much different. We need to do a release
in the next few days, in a way more urgent that a CVE that we can keep
quiet on and delay a little bit. With 3.30 having a broken KLIPS and
broken rekey, it is far more important to get it out now.

>>> I also propse next non klips release bump to 4.0 Removing KLIPS feels
>>> like a
>>> big setp and 4.0 would reflect this big change.
>>
>> This was considered, but has a number of issues. The most important one
>> being that a _lot_ of people will not upgrade from 3.x to 4.x,
>> especially in stable releases. For example, for RHEL8/CentOS8, it
>> would likely not work and be postponed to RHEL9/CentOS9. The practical
>> result is that we then are maintaining 2 trees and doing a lot of
>> backporting and people won't be using our latest release.
>>
>> From a theoretical view, I agree it should be 4.x. But from a practical
>> point of view, it would accomplish the opposite of what we want to
>> happen.
>
> RHEL/CentOS Fedora build is always with KLIPS disabled? If we release soon
> then we could justfiy saying 3.30 and 4.0 very close. It is not adding new
> functionality instead removing functionality which was not enabled in RHEL
> or Fedora

Even if I managed to convince fedora/rhel of that, there are many other
distro's not as close to us, and those would just blindly assume the
bump of a major number means it is not meant to be used as stable
upgrade. And it is not sure I can convince people in Red Hat of this. We
already have one mismatch with the ikev2= setting that I have to keep
maintaining as a difference. And again, having 4.x means people expect
some 3.x releases as maintenance. We do not have the resources to do so.

> While for KLIPS users 3.X.X would mean a end of line. If we continue 3.X
> without klips they would be up for a surprise when they automagiclly install
> 3.X, or the next release from master.

We have been saying KLIPS is unmaintained and about to be removed for
years. People will not move until forced to. Forcing those people to
remain on a 3.x branch just means we will be getting requests for things
in the 4.x branch to get backported to 3.x. While continuing on 3.x
signals more that we are not going to do that and they need to bite the
bullet.

> My hope is 3.30.1 would be enough, and not 3.30.2.. an so on. However  the
> reality is KLIPS fixes are likely to come in and we should have clear branch
> for loyal (30+ years) KLIPS users:)

You can hope, but the signal you are giving is that you are open to
maintaining such a branch. It becomes a self-fulfilling prophecy I'm
trying to avoid.

> As far as the non KLIPS release, release 4.0 sooner than later. We can
> probbaly cut 4.0 right away. If we delay it is hard to predict what would
> happen.

If we do a 3.31 maintenance release right now, we still have time to
discuss the 3.x/4.x issue with KLIPS removal. I don't see why this is a
"sooner than later" discussion now, especially if you favour 3.30.x over
3.x ?

Look at another example. We removed DH2 in 3.30. We already got 3 people
upset with us, one claiming to migrate to strongswan. This configuration
was already unwise/obsolete in 1995. Every IKEv1 stack supporting DH2
also supported DH5. People simply ignore our advise until they are
forced to change.

Giving them options not to change to 3.x with XFRM and hanging on to KLIPS
with a "stable" 3.x branch, just means those people stay longer on DH2,
DH5, SHA1, MD5, 3DES, AES-CBC and IPv4, because KLIPS does not support
AES-GCM, CHACHA20-POLY1305, and halfheartedly supports SHA2 maybe with
cryptoapi enabled and does a buggy IPv6. I'd much rather signal that being
on KLIPS is incredibly bad and you should have really migrated years ago.
And that we understood ipsecX interfacaes was a main drive, and that's
why we have given them XFRM ipsecX interfaces. The time to migrate is
now, and staying on a really bad obsolete, mostly unmaintained version
is not a wise decision. And that is why I think a 3.x maintenance branch
and 4.x (seen as new and unstable) branch is a bad idea.

Paul


More information about the Swan-dev mailing list