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
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 :)
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,
showhostkey)
* 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.
Agreed.
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.
Thanks!
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?
yes. all commands except pluto have --configdir. We should give pluto
--configdir too.
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
Yes, you can add to ipsec.conf:
ipsecdir=
And we should map nssdb to nssdir=
And maybe just rename --configdir to --nssdir (and leave the old name
undocumented)
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/
See http://csrc.nist.gov/groups/STM/cavp/documents/components/askdfvs.pdf
The license is actually a good question....
This is not specified anywhere. I'll send an email to NIST to ask them
about this.
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?
Sure!
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@thinkpad:~$ /usr/libexec/ipsec/rsasigkey --configdir sql:/tmp/x 3072
ipsec rsasigkey: authentication of "NSS Certificate DB" failed
paul@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?
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.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
