We retrospectively added openconnect_set_sni() with the @OPENCONNECT_5_8
symbol version, *long* after API v5.8 was set in stone with the v9.00
release in April 2022.
Fix that by retconning it into a @OPENCONNECT_5_9 version which will be
part of the *next* release.
We have a unit test to prevent us from doing it again, and this commit
is the exception to the general rule that we should *never* commit to
libopenconnect5.symbols except as a side-effect of 'make tag' creating
a new release.
Fixes: 494edf49e628 ("Add openconnect_set_sni API function and Java setSNI() wrapper")
Signed-off-by: David Woodhouse <email address hidden>
Add dpkg-gensymbols template file and test for ABI violations
Symbol versioning is hard.
Add some sed magic to build a symbols file of the form consumed by
dpkg-gensymbols, which maps symbols+versions to the first version
of the package in which they appeared.
This serves two purposes.
Firstly it allows us to have a unit test which helps prevent us from
retrospectively adding symbols to a given version after it is first
released — as we did for example when we added openconnect_set_sni() to
OPENCONNECT_5_8 in the 9.10 release.
Secondly, it helps the Debian packaging to get dependencies right. In
RPM distributions, symbol versions map automatically to RPM dependencies
and everyhing Just Works. The package with the library gets a virtual
Provides: of e.g. 'libopenconnect.so.5(OPENCONNECT_5_8)(64bit)', any
package which *uses* symbols from the library will get a corresponding
virtual Requires: — for the symbols it's actually *using* — and it all
works out perfectly. Debian packages, on the other hand, appear to be
held together with duct tape and tears, and need the developer or the
packager to manually curate a file with the mapping of symbol versions
to the first version of the package in which they appeared.
Look Ma! I can sed!
Signed-off-by: David Woodhouse <email address hidden>
The CA has expired. Rebuild it (and remove the old GnuTLS CA from the
ca-key.pem file where it was just noise).
Rebuild all other certificates while we're at it, but leave the keys
as they were. Extend the validity to 10000 days which should expire
in 2050, by which time it probably won't be my problem.
Dan seems young and healthy; maybe he can thank me then for pedantially
scripting it all instead of doing it manually. Or maybe it'll have
bitrotted so much by then that it won't help.
Most of it worked out of the box this time, but I re-imported the certs
into SoftHSM manually because I didn't want to start from scratch using
the softhsm-setupX make targets. I think some of the behaviour of the
GnuTLS tools (not importing pubkeys, etc) has changed since I did this.
Arguably we should rewrite those rules to import things the same way
into each token and then explicitly tweak them, deleting the public
keys and explicitly marking objects public or private as needed for
each token.
The SoftHSM modifications also had to be done with an older version
of SoftHSM (I used 2.2.0 on Ubuntu 18.04) because doing it with a
newer version meant the newly-imported certs weren't visible in the
Ubuntu 18.04 or CentOS 9 test runs.
Fixes: #609
Signed-off-by: David Woodhouse <email address hidden>
