[Openswan dev] Openswan 2.5.00 release (testing)
mcr at xelerance.com
Wed Nov 1 16:04:35 EST 2006
-----BEGIN PGP SIGNED MESSAGE-----
We have been working on a number of features, many of them somewhat
related, since the fall of 2005. These things have been known as the
"#public" branch. That's because we have also switched to using
cogito/git instead of CVS. This has been available from
http://git.openswan.org/ for sometime now.
The 2.5.00 release, according to our numbering system is a "testing"
release. It is presently running on a number of systems. It does not
presently pass all of our test cases, but it passes a significant number
It does patch against kernels up to 2.6.18, and we believe that it will
patch against 2.6.19.
(We know that 3.0.00 will not patch against 2.6.19 because it uses the
cryptoapi for hashes, and the interface for hashes has changed. The
2.5.xx releases will not use cryptoapi for hashes).
Significant things that have changed in 2.5.00:
a) we are using cogito/git for revision control.
b) we use only "libipsecconf" (aka "starter") for parsing the
configuration file. Unlike "starter", we still permit manual
control of the conns using "ipsec auto".
c) we always compile with OBJDIR enabled.
d) we have a more modular approach to interfacing to the kernel.
e) the userland code compiles on Windows, but hasn't got a kernel
interface. (The customer who paid for that work was going to
interface to a non-windows IPsec kernel anyway. Someone with
high windows fu could complete the work)
f) we have changed to having AES128 and sha1, as being the first
proposal for phase1 and phase2, so we default to them instead of
g) we accept modp2048 by default, and will propose it, but it isn't
the first thing proposed.
h) We have algo controls in pluto for AH.
i) one can load many more policies into pluto which it will never
negotiate. Previously, a number of policies which were incomplete
would not have loaded at all. We are doing this because when
an interface appears, policies which previously made no sense
might suddendly make sense.
This may mean that you can start pluto from, for instance,
inittab or even initrd, and have it operational for an IPsec
mount of file systems, etc.
It also may mean that one will not have to restart pluto when
PPPoE interfaces go up and down. None of this is finished yet.
j) the ipsec.secrets code has been refactored into a library,
and showhostkey has been converted from awk to C.
One can now, for instance, show the raw RSA key from a X.509
certificate using showhostkey.
It is not yet possible to produce a self-signed X.509 certificate
from a raw RSA (private/public) key.
Bugs that we are pretty sure we have observed:
1) DPD may not be complete. This may be a config file parsing issue.
2) XAUTH may not be compelte. This may be a config file parsing
3) passive OE configurations (i.e. having 0.0.0.0/0 in clear-or-private)
does not seem to function correctly. This may also affect
gateways that have road warriors.
WHY ARE WE RELEASING THIS JUNK?
Well, it has sat in our queue, and had way too many good things added into
it over the past 15 months, and we just have to let it out for people to
We are releasing numbered versions because we have customers who need to
use some of these features, and we have been giving them named git
trees, and this just isn't very traceable in bug reports for us.
We need to release our 3.xx series already as well, which will be
substantially less stable for awhile, and we think people should have
something that is a bit stable to play with.
Xelerance, VP R&D.
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Finger me for keys
-----END PGP SIGNATURE-----
More information about the Dev