[Swan-dev] libreswan in debian - Ondřej offered to help (fwd)
paul at nohats.ca
Mon Jun 20 17:25:26 UTC 2016
On Mon, 20 Jun 2016, Daniel Kahn Gillmor wrote:
>> 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.
no, those are unrelated. The PF_KEY API is unchanged in pluto and does
not depend on any pluto compile time options.
>> 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
> 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 :)
The VTI stuff is bleeding edge. So I can understand KLIPS users want to
still use it for a few more releases. We get frequent requests about
KLIPS. Anyway, if you're the maintainer we can do without KLIPS and
see what happens.
>> 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.
No one is objecting and we all agree it is the best. Like I said, we
just were not ready for it yet. I'm fine with you trying to make it
/var/lib/ipsec. I should probably cut a dr3 for you so at least you
have the right binaries with --configdir everywhere (rsasigkey,
> * 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.
Sounds good to me.
> * 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
yes. all commands except pluto have --configdir. We should give pluto
> Because i don't see --configdir mentioned in pluto(8), ipsec(8), or
> internally, the struct lsw_conf_options has:
> * confdir
> * confddir
> * nssdb
Yes, you can add to ipsec.conf:
And we should map nssdb to nssdir=
And maybe just rename --configdir to --nssdir (and leave the old name
> as far as i can tell, confdir is usually /etc, but is never actually
> used anywhere. can we just drop it?
It used to be used to find the secrets file in showhostkey, but that
was recently removed because we no longer need the secrets file for
showhostkey. So I think you are right and we can remove 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?
The originals are from NIST, but those contain errors. We have fixed up
versions at https://download.libreswan.org/cavs/
The license is actually a good question....
This is not specified anywhere. I'll send an email to NIST to ask them
>> 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?
>> 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 cannot think of a good one. The initnss will prompt for an optional
password, which you might not expect from newhostkey, which probably
is not a problem?
> I also note that the current head of git has removed the default
> --output parameter for newhostkey.
Yes, because it no longer writes to ipsec.secrets.
> 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:
Not needed, since the only consumer left of the data in ipsec.secrets
was showshowkey, and it just got fixed to read it all from NSS without
needing the secrets file.
>> paul at thinkpad:~$ /usr/libexec/ipsec/rsasigkey --configdir sql:/tmp/x 3072
>> ipsec rsasigkey: authentication of "NSS Certificate DB" failed
>> paul at thinkpad:~$ echo $?
> 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?
It failed because I did not initialise the NSS database :P See above :)
No one should call rsasigkey directly, it is supposed to go through the
newhostkey wrapper. Which you suggested above could cause the nss init.
More information about the Swan-dev