[Swan-dev] libreswan in debian - Ondřej offered to help (fwd)

Daniel Kahn Gillmor dkg at fifthhorseman.net
Mon Jun 20 15:54:38 UTC 2016


Hi all--

On Mon 2016-06-20 09:12:59 -0400, Paul Wouters wrote:
> Can we wait a few days? We are working on two important bugfixes that
> need to go into 3.18. We will do a 3.18rc1 when we fixed those two. We
> really need to get this release out, so it will be very soon.

sure, i don't mind waiting on the upload.

> I pulled in two of the three. I need to verify the flex/bison one, as
> that one is very sensitive to specific versions of those tools and gcc,
> so I need to ensure this still compiles on various other older OSes.

totally understood.  fwiw, i've tested that patch and it works fine
against debian stable (flex 2.5.39-8, gcc 4:4.9.2-2) and
unstable/testing (flex 2.6.0-11, gcc 4:5.3.1-3).  I've just added that
to the pull request.

> I'm fine with no KLIPS module, as we are moving towards VTI and 3.18 is
> the first release that will have it. However, I'd still like to see the
> userland compiled with USE_KLIPS=true, so that people can just compile
> the kernel code without needing to recompile the userland. Once we are
> ready to kill KLIPS, we will likely call it libreswan-4 and kill it off.

My impression of the build process is that there are a number of
variables and configuration options that might need to be sync'ed across
the builds.  If someone is "just compiling the kernel code", it seems
likely that they could get those options wrong and the kernel stuff
might not be compatible in some way.  if they're building the kernel
modules they'll have to build binaries as well, right?  So if someone is
doing that on debian, i'd rather they just use both.

> Note that some files are used by both, eg kernel_pfkey.c, and we have
> not done much testing with USE_KLIPS disabled. So the safer and more
> compatible option is to keep it enabled. It will install some of the
> supporting tools like "ipsec eroute" and "ipsec tncfg" required for
> KLIPS.

i really would like to avoid shipping code in debian that i don't plan
on supporting long-term.  maintenance and support (and eventual removal)
of code we don't plan to keep in action is an additional chunk of time i
could be spending helping sort out the bugs in USE_KLIPS=false :)

> It is the right thing, but we werent ready for it for rhel7, so we
> didn't do it yet. Although we were thinking of /var/lib/ipsec/ instead
> of /var/lib/libreswan/nss/. If you don't want /var/lib/ipsec, can we
> at least stick to /var/lib/libreswan and not /var/lib/libreswan/nss ?

I'd be fine with /var/lib/ipsec if you prefer it over
/var/lib/libreswan.  But i really do want an isolated nss directory, for
several reasons:

 * different versions of nss (including different builds of the same
   version, like whether or not HW pkcs11 is supported) use different
   files.  for example, libreswan documentation talks about *.db, but
   doesn't mention pkcs11.txt, which is also part of the NSS directory.
   It seems entirely possible that newer versions of NSS could introduce
   a file named *.conf, or a directory named "policies" or something
   else that collides with potential libreswan data.

 * i want to be able to give simple and clear directions about how to
   clean up/destroy the NSS database.  If it's isolated to its own
   directory, we can destroy it with "rm -rf".  This is a flaw in NSS
   itself (that it offers no programmatic way to cleanly tear down an
   NSS database), but it's an easy workaround.

 * One of the most confusing things a new admin faces is understanding a
   piece of software is what all the different moving parts are.  It
   might be just me, but the fact that *.conf and *.secrets are mixed up
   in ipsec.d/ with policies/ and passwd and nsspassword and cacerts/
   and crls/ made my head spin.  Moving the NSS database to its own
   directory makes it cleaner and clearer.

> Andrew did do a couple of commits in the last few days to fixup some of
> the hardcoded paths, and also did some fixing with *.in files so we
> can have @FOO@ strings in the man pages to get automatically rewritten,.

awesome, i'll take a look at that and see if i can offer you patches for
@FINALNSSDIR@ on master.

> Andrew has been working on fixing the tools for this. I think we might
> need to rename the option though. Currently there is --ipsecdir and
> --configdir. Possibly we should rename --configdir to --nssdir ?

do you mean --configdir when used as an argument for the ipsec nss
subcommands?

Because i don't see --configdir mentioned in pluto(8), ipsec(8), or
ipsec.conf(5).

internally, the struct lsw_conf_options has:

 * confdir
 * confddir
 * nssdb

as far as i can tell, confdir is usually /etc, but is never actually
used anywhere.  can we just drop it?

> The cavp binary does the NIST CAVS testing, but it requires
> ikev1_dsa.fax.bz2, ikev1_psk.fax.bz2 and ikev2.fax.bz2. We include those
> in the fedora/rhel package and run the test in rpm's %check phase.

hm, where are those distributed from, and what are their licenses?

> pluto also has some startup tests, enum names consistency and some
> crypto tests, but we currently don't have a pluto --selftest option
> that only runs those and exits. We probably should just add that.

That would be great!  Do you want a patch for this?

> The parser can be checked using ipsec readwriteconf. Given a properly
> formated input file, it should create the same output file. Some
> sorting happens, so you should probably run any example config
> manually through readwriteconf, confirm it, and then use that as the
> input test file.
 [...]
> You can create newhostkey/rsasigkey tests but you might need current
> git instead of 3.18dr2 to get some of the latest fixes Andrew did. but
> then I think you can run (sprinkle safe tempdirs)
>
> mkdir /tmp/xxx
> ipsec initnss --configdir /tmp/xxx
> ipsec newhostkey --configdir /tmp/xxx
> ipsec showhostkey --configdir /tmp/xxx --list
> ipsec showhostkey --configdir /tmp/xxx --left --ckaid <ckaid from output above>


Is there a reason that newhostkey shouldn't automatically do the initnss
if it detects that it's needed?

I also note that the current head of git has removed the default
--output parameter for newhostkey.

This patch (against dr2, but i can rebase it if you like it): suggests
having --output default to /etc/ipsec.d/newhostkey-generated.secrets
instead of trying to append to /etc/ipsec.secrets directly:

  https://anonscm.debian.org/git/collab-maint/libreswan.git/tree/debian/patches/0004-ipsec-newhostkey-default-to-etc-ipsec.d-newhostkey-g.patch

The advantage of this, again, is easier/simpler automated cleanup, and
less likelihood that automated tools trample on human-generated data.


>> 0 dkg at alice:~$ /usr/sbin/ipsec rsasigkey --configdir sql:$(mktemp -d) 3072
>> ipsec rsasigkey: key pair generation failed: "-8037"
>> 0 dkg at alice:~$
>
> ipsec rsasigkey --configdir /tmp/xxx 3072 works for me. Possibly you
> hadn't initialised the database or Andrew fixed another issue that
> is not yet in 3.18dr2 ?
>
>> (also, shouldn't that return a non-zero error code?)
>
> It does for me?
>
> paul at thinkpad:~$ mkdir /tmp/x
> paul at thinkpad:~$ /usr/libexec/ipsec/rsasigkey --configdir sql:/tmp/x 3072
> ipsec rsasigkey: authentication of "NSS Certificate DB" failed
> paul at thinkpad:~$ echo $?
> 1

hm, looks like the return code part got fixed in between 3.18dr2 and
master.  but it still fails, eh?  shouldn't that command succeed?

         --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20160620/2d84dc4d/attachment.sig>


More information about the Swan-dev mailing list