[Swan-dev] ipsec.conf version specificaton

D. Hugh Redelmeier hugh at mimosa.com
Mon Jun 30 16:52:29 EEST 2014

[Warning: my opinions will be stated as facts.]

| From: Paul Wouters <paul at nohats.ca>
| Date: Mon, 23 Jun 2014 11:43:45 -0400 (EDT)

| On Sun, 22 Jun 2014, D. Hugh Redelmeier wrote:
| > Man page change:
| > -The first significant line of the file must specify the version of this
| > specification that it conforms to:
| > +The first significant line of the file may specify a version of this
| > specification for backwards compatibility with freeswan and openswan\&. It
| > is ignored and unused\&. For compatibility with openswan, specify:
| >
| > I think that it is a serious mistake to decommit from the version
| > specification in ipsec.conf
| note the man page was merely updated to reflect reality.

Right.  But the documentation is the contract with the user.  So
changing the documentation is the real step.

| > In FreeS/WAN, we went through a bit of agony to introduce it.
| >
| > Once we introduced it, it was a way to allow new config file features that
| > would break old ones.  FreeS/WAN code could know when to use the old rules
| > or the new ones, based on this option.
| >
| > Backward compatablility is such a straighjacket.  This is one way to
| > break out of it.
| These days, package managers are responsible for upgrading any kind of
| versioning and creating backup copies of config files. There was no good
| method used historically to bump it when things were added or removed,
| so it became a useless entry in the file.

So we need a convention to solve this.  Perhaps one config file that
gets managed by the system, and the one that does not.  Note the word
"convention".  No actual mechanism is needed.

Eventually, in FreeS/WAN, the main config file was supposed to be ONLY
local configuration.  Boilerplate was supposed to be in files
(usually) referenced from the main file.  We didn't get there 100%.

| Also, it seems preemptively failing on the version number is worse than trying
| your best and then failing due to a change.

I don't think you can say that generally.  Failing is better than
pretending to work.

| I think this made more sense in a world where /etc/ipsec.conf was not
| owned by a package with a maintainer, and people used "make install" to
| upgrade and were actually present and aware of performing a swan upgrade.
| That is less obvious with yum or apt-get update.

Right.  That's also a mistake.  We must fix this AGAIN.


We need to simplify all we can about Libreswan.
That means that we need a way to break backward compatibility
(otherwise you get monotonic increase in complexity).
This feature enables gracefully/safely decommitting from features.

It's all about architecting change, not hacking it in as you go.

More information about the Swan-dev mailing list