[Swan-dev] Libreswan signing key (907E790F25C1E8E561CD73B585FF4B43B30FC6F9)
Hi folks-- I just noticed that the self-sigs over the libreswan signing key and its subkey binding signature are all made using SHA1. As SHA1 is further deprecated, this makes the certificate difficult to use, since the self-sig is what asserts signing capabilities from the primary key -- if the self-sig is considerd invalid because of, say, an implementation declining to accept SHA-1 digests, then the primary key isn't considered signing-capable, which means that signatures made by it won't be considered valid. the digest used in the subkey-binding signature is relevant if you want to be able to receive encrypted mail (e.g. security bug reports). To fix this, just re-issue the self-sigs and subkey binding signatures with a stronger digest (at least SHA2-256). If you're using a modern version of GnuPG that has access to the secret key, the arcane command to do that is probably something like: gpg --cert-digest-algo sha256 --quick-set-expire 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 0 gpg --cert-digest-algo sha256 --quick-set-expire 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 0 '*' and then re-export and re-publish the OpenPGP certificate wherever it's published (at least in LIBRESWAN-GPG-KEY.txt in the git repo). The first line updates the expiration date and re-issues the self-sig for the primary key, the second handles the subkey binding signature. Note that leaving the expiration date unset (the "0" above) might itself be problematic if you ever lose control over the key and you don't have any revocation certificate handy, but that's a separate question. i'd recommend setting an expiration date of "2y" (instead of "0" above), and then just repeat this process every time you have a release. Since releases come out in a less-than-2-year cadence, this should be fine. But i'd be happy for now with just a primary key with a non-SHA1 self-sig. Thanks for maintaining libreswan! --dkg PS here's the diagnosis: The "sig:.*:2:" lines are SHA1 signatures here: 0 dkg@alice:~$ gpg --with-colons --check-sigs 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 tru::1:1652480124:1691085522:3:1:5 pub:-:4096:1:85FF4B43B30FC6F9:1357089367:::-:::scESC::23::0: fpr:907E790F25C1E8E561CD73B585FF4B43B30FC6F9: uid:-1357089367::ED0B44951C7DD5295C3DDEF9C67942731B01068E::Libreswan (Signing Key) ::0: sig:!::1:85FF4B43B30FC6F9:1357089367Libreswan (Signing Key) :13x:2: sig:?::1:E71806A6B5CC27E1:1357192633:10x:8: sig:!::1:C30040228501D2EC:1357583027:10x:2: sig:!::1:467564B7505DA62B:1420472842:10x:2: sig:!::1:62D3582FE0FD94D2:1418273023:10x:8: sig:?::1:CCD2ED94D21739E9:1490035473:155310747310l::0EE5BE979282D80B9F7540F1CCD2ED94D21739E9:::10: sub:-:4096:1:43CD400C70C28757:1357089367::e::23: fpr:1CF137415217927923F01BB943CD400C70C28757: sig:!::1:85FF4B43B30FC6F9:1357089367Libreswan (Signing Key) :18x:2: 0 dkg@alice:~$ signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Consdiering maintenance releases?
On Fri 2022-01-14 13:38:23 -0500, Paul Wouters wrote: > It's good to have these conversations, even if it does not result in any > changes, so thanks for bringing it up. Thanks for the feedback, Paul! this is definitely useful information to have. I understand your reasoning, even if y'all didn't go the route that i was asking for. all the best, --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] Consdiering maintenance releases?
Hi Libreswan devs-- Thanks for your maintenance work defending against CVE-2022-23094! In particular, as the debian maintainer, i appreciate the attention to older versions that some stable distros are still shipping. (debian's stable release 11 ships libreswan 4.3) But as noted in https://github.com/libreswan/libreswan/pull/613, the patch released for 4.2 and 4.3 didn't apply safely (caused a build failure). Not a huge deal, and a relatively obvious fix in this case, but i do wonder whether it would make sense to issue point releases (e.g. 4.3.1) for those versions that you're willing to backport security fixes to? By making a point release, you have the opportunity to apply the full test suite against it pre-built packages with the patches applied to make sure the patches work. I find git useful when managing this kind of approach. I've pushed an example branch named branch-4.3 to https://github.com/dkg/libreswan to demonstrate one way that it could be handled. Obviously, as an external maintainer, i'm not in a position make a 4.3.1 release on behalf of the project. And I've already sent the necessary patch to the debian security team so that debian stable should be fixed shortly. So for this round i don't need it. But if future vulnerabilities are discovered that apply to 4.3, and narrowly-targeted fixes are made available, i'd actually prefer to push upstream 4.3.x into debian stable. I'd prefer that because i'd be happier knowing that the upstream build/test machinery was run against the particular combination of patches we ship, rather than manually applying specific patches and hoping that i've landed on the expected variant. Alternately (or in addition?), i could try to replicate the upstream testing practices on the debian testing infrastructure, but I haven't figured out how to get debian's testing infrastructure to run all the complicated kvm- or docker-based stuff that i think y'all use upstream. What do y'all think? --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] git tagging best practices
On Wed 2019-06-12 10:45:59 -0400, Paul Wouters wrote: > I'll try and remember, and somehow add that to our process. Currently, > we just pick up the first section of the CHANGES file which has that > structure. cool, thanks. > These tags should really be done with the t...@libreswan.org key and not > mine. Confusion here happens because I cannot seem to select a prefered > email/key within the git tree, or outside in ~/.gitconfig to only match > certain git repositories. i think it's just: git config user.signingKey $FINGERPRINT does this not work for you? (it's documentd in git-tag(1)). > No script, all human. If you're at IETF 105, let's talk there. i'll be there, happy to talk to you more about this. --dkg ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] [Swan-announce] libreswan-3.29 released to address CVE-2019-10155
On Mon 2019-06-10 14:30:32 -0400, Libreswan Team wrote: > The Libreswan Project has released libreswan-3.29 > > This is a security release addressing CVE-2019-10155. thanks for this fix! I notice that there is no v3.29 tag in the https://github.com/libreswan/libreswan repo yet. Perhaps a push failed (or forgot to use --follow-tags)? at any rate, it would help me as a downstream packager if the libreswan release process could adopt a test to ensure that the tag is published before the release annoncement is sent out. thanks for your work on libreswan! --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] git tagging best practices
Hi Libreswan folks-- I've been looking at git release tag verification across the broader free software ecosystem, and i want to commend the libreswan project on its release tagging practices. In particular, i note that every modern libreswan tag is cryptographically signed, and its tag message contains not only the version number but also a list of relevant changes in the release. I have two suggestions for improvements to future git tag messages: a) (nit-pick) please include a blank line between the initial version/date line and the rest of the message. b) please include the work "Libreswan" in the "subject" line of the tag message. So rather than "v3.28 (June 03, 2019)", the subject line would be "Libreswan v3.28 (June 03, 2019)" (btw, i'm not trying to set a timeline for the release of v3.28, just using an imaginary future release to avoid implying that i think you need to retroactively change already-existing tags, which i'm not asking you to do) The rationale for (a) is just to have the tag message conform more closely to git's conventional "subject" and "body" commit message format. The rationale for (b) is that it lets downstream verifiers distinguish between something signed by Paul Wouters' key that *is* a libreswan release, and something signed by Paul's key that *isn't* a libreswan release. This is a subtle point (and maybe irrelevant if Paul never releases any software other than Libreswan), but one that would be great to establish as a baseline. I'm asking this of libreswan because what i really want is an exemplar that i can point other projects to and say "do it like they do". And i also want to encourage downstream verifying tools to build sensible automated new release verification steps, and being able to point to a project and say "this tool should at least be able to verify a new Libreswan release isn't just a maliciously-renamed tag from some other git repository". let me know if i can help make this change happen for future releases! i couldn't find any script for generating the tag in the libreswan repo, but maybe i wasn't looking in the right place. All the best, --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] simple setup
On Mon 2018-10-08 18:07:14 -0400, Paul Wouters wrote: > Now, when you are talking about a real remote access VPN, I'm assuming this means an "encrypted internet proxy" -- is that right? > I do agree it is a little more complicated then desired: > > conn vpn.nohats.ca > left=%defaultroute > leftcert=letoams.nohats.ca > leftsubnet=0.0.0.0/0 > rightid=@vpn.nohats.ca > right=vpn.nohats.ca > rightsubnet=0.0.0.0/0 > narrowing=yes > ikev2=insist > leftmodecfgclient=yes > > It would be nice if this could become: > > conn vpn.nohats.ca > type=remote-access-vpn > leftcert=letoams.nohats.ca > right=vpn.nohats.ca What does it take to get there from here? and doesn't this minimal setup (as nice as it looks) require some interaction with a certificate authority to get the certs right in the first place? (not to mention certificate maintenance) -- or do we have a story for automated certificate management that i'm not aware of? Also, how is a novice admin supposed to know what "left" and "right" mean here? Wireguard's [Interface] vs [Peer] stanzas make it pretty clear which part corresponds to the local machine and which part corresponds to everybody else. I note that the conf.ini-style syntax wireguard uses is probably marginally visually simpler for most admins (thanks to inheritance from years of microsoft, in addition to adoption by systemd) than libreswan's indented stanzas, but i'm sure that's also a matter of taste, and not a religious war i want to fight right now. :) I want to see libreswan get to this level of simplicity and ease of use! i'm asking these questions to try to push in that direction, not trying to throw shade. If there's some way to get us closer to this, that'd be great. Good, opinionated defaults could go a long way here, and we can "bundle" them with just such a type= argument so that we're not worried about shifting an already-deployed base. --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] simple setup
On Sat 2018-10-06 09:26:09 +0300, Kim B. Heino wrote:
> Back to topic: Webgui will not make libreswan simple to setup for first
> time user. It makes it even more complex.
I agree with the goals of this thread. I've been nudging Paul for over
a year now with the hopes of getting something running that "just works"
with something as close to an "{apt|dnf} install libreswan" as possible.
I recognize that where authentication is important, there will need to
be some additional config -- at least to identify the relevant peers --
but i'm happy to automate those bits as much as we can.
I agree with Kim that a web interface is *not* the way to go. wireguard
configuration files are pretty simple, dumb .ini-file style configs that
identify peers by public key.
Below is the most complex example from wg(8):
[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820
[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
Endpoint = 192.95.5.67:1234
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24
[Peer]
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
Endpoint = [2607:5300:60:6b0::c05f:543]:2468
AllowedIPs = 10.192.122.4/32, 192.168.0.0/16
[Peer]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
Endpoint = test.wireguard.com:18981
AllowedIPs = 10.10.10.230/32
(note that even the "Endpoint" lines aren't necessary for the the
passive side (the "server") of a VPN connection)
Can libreswan offer something comparably simple for users whose goal is
a "VPN"? Or, if libreswan sees that targeted use case as not-in-scope,
is there some other use case that libreswan can offer a comparably
compelling minimalist configuration?
--dkg
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] debian continuous integration
Hi Antony-- On Mon 2017-12-11 23:47:50 +0100, Antony Antony wrote: > Subject: [PATCH] tests/opportunistic fix, asymetric dnssec teest thanks for this! I confess i'm still a little confused as to why this DNSSEC-driven policy should be labeled "opportunistic" as compared with the fully-opportunistic authnull policy. shouldn't we have a separate test for the dnssec-driven policies? --dkg ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] disabling kips tests
On Wed 2017-11-29 11:17:06 -0500, Andrew Cagney wrote: > The idea's been floated that klips tests and the module build be > disabled by default. > > My first idea for how to do this was to just tweak TESTLIST so that it > lists those tests as 'klips' instead of 'good'. The debian packaging doesn't ship the klips stuff at all, so please don't keep it around for my sake :) I'd personally be happy to see the codebase reduced, so that whatever development time the project has available can be more tightly focused on successful, modern implementation that takes advantage of the existing features in the Linux kernel. --dkg ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] debian continuous integration
Hi folks-- I want to have more regular full-stack roundtrip tests for libreswan in debian. So i wrote the following simple test for debian's continuous integration initiative: https://anonscm.debian.org/git/collab-maint/libreswan.git/tree/debian/tests/opportunistic as you can see, i'm just triyng to get the configuration-free opportunistic workflow to Just Work (this is what i want to be able to recommend to users who don't have time to think through a stronger configuration). However, it has never succeeded. This is initially because i configured the debian test suite wrong :P but now i've configured it right, and it's still failing. here's the log of it failing currently: https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreswan/20171115_141544/log.gz Am i doing something wrong in the test? is the responder at oe.libreswan.org something i can rely on for this purpose? Thoughts and suggestions welcome, --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] debian patch for dnssec root.key
Hi Antony-- On Mon 2017-06-26 10:22:03 +0200, Antony Antony wrote: > I think Debian will need this patch for pluto to read > /usr/share/dns/root.key file. thanks, i think this is the right thing to do. I'll be including it in the 3.21~rc5 packaging i'm working on. I hope more OSes produce DNS root key updates via their standard system update mechanism, the same way that updates to tzdata and publicsuffix and ca-certificates and other packages that reflect the state of the world (or the state of the global network at least) are handled. Regards, --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Bug#853947: libreswan FTBFS on mips and mipsel: error: "_ABI64" is not defined [-Werror=undef]
On Wed 2017-02-08 13:37:39 -0500, Andrew Cagney wrote: > On 3 February 2017 at 13:57, Daniel Kahn Gillmor > wrote: >> -MMD -MF ./base64_rsa_pubkey.d \ >> -o ./base64_rsa_pubkey.o \ >> -c /«PKGBUILDDIR»/lib/libswan/base64_rsa_pubkey.c >> In file included from /usr/include/nspr/prtypes.h:26:0, >> from /usr/include/nss/seccomon.h:17, >> from /usr/include/nss/nss.h:34, >> from /«PKGBUILDDIR»/lib/libswan/base64_rsa_pubkey.c:21: >> /usr/include/nspr/prcpucfg.h:511:18: error: "_ABI64" is not defined >> [-Werror=undef] >> #if _MIPS_SIM == _ABI64 >> ^~ >> cc1: all warnings being treated as errors >> ../../../mk/depend.mk:28: recipe for target 'base64_rsa_pubkey.o' failed > > Would you know how NSS deals with this on MIPS? I don't know what to say about this, but nss itself builds fine on MIPS: https://buildd.debian.org/status/logs.php?arch=&pkg=nss as do packages that depend on it, like ceph or systemtap: https://buildd.debian.org/status/logs.php?arch=&pkg=ceph https://buildd.debian.org/status/logs.php?arch=&pkg=systemtap other dependent packages appear to have some build failures there too: https://buildd.debian.org/status/logs.php?arch=&pkg=dogtag-pki Sorry to not understand the problem space better! I hope the build logs linked above are useful in getting new ideas for how to solve it. --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] CAVP testing of libreswan build on debian
On Fri 2017-02-03 19:48:55 -0500, Paul Wouters wrote: >> 18:46 < dkg> which means i'd need to review their licensing :/ >> >> I don't see any licensing info immediately available in them either :( > > It is published by the US Government, if that helps. > > http://csrc.nist.gov/groups/STM/cavp/ Right, i think that makes them public domain, though explicit confirmation would be great. > It states at: > > http://csrc.nist.gov/groups/STM/cavp/key-derivation.html#kbkdfvs > > Test Vectors > > Use of these test vectors does not replace validation obtained through > the CAVP. > > The test vectors linked below can be used to informally verify the > correctness of the KBKDF algorithm listed above. > > See the KBKDFVS document for an explanation of the files. > > Unfortunately, there is no clear mention on the NIST website either > what the license of these files are. Apostol, can you clarify this? I'm also not sure how to think about the "preferred form of modification" for these, which is something Debian tends to care about, but i would think mainly static test vectors should be understood as useful data in their own right. At least one of the files i've looked at contains a comment in the header that says "generated" -- but it's not clear what generated them. Any info on that? Regards, --dkg ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Bug#854094: libreswan FTBFS on x32 due to missing
over in https://bugs.debian.org/854094: On Fri 2017-02-03 19:10:43 -0500, Daniel Schepler wrote: > On Fri, Feb 3, 2017 at 3:29 PM, Daniel Kahn Gillmor > wrote: >> Package: libreswan >> Version: 3.19-2 >> X-Debbugs-Cc: x...@buildd.debian.org, swan-dev@lists.libreswan.org >> >> Hi Debian x32 builders-- >> >> I note that libreswan is failing to build from source on the x32 >> platform due to a missing sys/time.h: >> >> https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=x32&ver=3.19-2&stamp=1486146097&raw=0 >> >> … >> /<>/linux/include/libreswan.h:44:22: fatal error: sys/time.h: >> No such file or directory >> #include >> ^ >> >> the code in linux/include/libreswan.h is just: >> >> 42 #if !defined(__KERNEL__) >> 43 >> 44 #include >> 45 #include >> 46 >> >> It builds on other debian platforms without a problem. Is something >> significantly different on x32 that we should know about? > > It's trying to build with -m64, which would be a cross build for amd64 > rather than a native build for x32. (So, the immediate symptom is > caused by the compiler looking for sys/time.h in > /usr/include/x86_64-linux-gnu and not finding it there because > libc6-dev-amd64 isn't installed.) hm, i don't think we want it to build for amd64 if we're doing native builds on x32, right? In mk/userland-cflags.mk, we have: ifeq ($(origin GCCM),undefined) ifeq ($(ARCH),i686) GCCM=-m32 endif ifeq ($(ARCH),x86_64) GCCM=-m64 endif endif USERLAND_CFLAGS+=$(GCCM) is ARCH defined as x86_64 for x32? If so, is there a preferred way that libreswan should make this distinction? or should i just manually set GCCM to -m32 in debian/rules when building for x32? --dkg PS for the libreswan folks who've just joined this thread, here's an explanation of the x32 port on debian: https://wiki.debian.org/X32Port signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] libreswan FTBFS on hppa and alpha due to lack of -fstack-protector
On Fri 2017-02-03 19:53:22 -0500, Paul Wouters wrote:
> On Fri, 3 Feb 2017, Daniel Kahn Gillmor wrote:
>
>> i notice that mk/userland-cflags.mk has -fstack-protector-all set inside
>> USERCOMPILE.
>>
>> However, there are at least two debian unofficial architectures (alpha
>> and hppa) where gcc doesn't have -fstack-protector available.
>
> You can pass USERCOMPILE= to the "make programs" ?
> eg you could use:
>
> make
>USERCOMPILE=" -fexceptions -fno-strict-aliasing -fPIE -DPIE
> -DFORCE_PR_ASSERT" \
>programs
This seems like an unpleasant maintenance situation to be in -- it means
that if you improve USERCOMPILE in mk/userland-cflags.mk at some point,
debian won't get those changes on these platforms unless i notice and
update them. What i really want is to be able to just strip one of
these options out on the two architectures.
I can go this route if you prefer, but it seems unclean. any other suggestions?
>> You can detect it with something like:
>>
>> printf 'int main() { return 0;}' | gcc -x c -fstack-protector-all -
>
> Well, that would be terrible for those cross compiling :P
well, i guess if you used $(CC) from whatever the cross environment is,
then you should be able to cross-build ok, right? not that anyone's
doing a lot of cross-compiling on hppa or alpha these days :)
--dkg
signature.asc
Description: PGP signature
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] Bug#854094: libreswan FTBFS on x32 due to missing
Package: libreswan Version: 3.19-2 X-Debbugs-Cc: x...@buildd.debian.org, swan-dev@lists.libreswan.org Hi Debian x32 builders-- I note that libreswan is failing to build from source on the x32 platform due to a missing sys/time.h: https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=x32&ver=3.19-2&stamp=1486146097&raw=0 … /<>/linux/include/libreswan.h:44:22: fatal error: sys/time.h: No such file or directory #include ^ the code in linux/include/libreswan.h is just: 42 #if !defined(__KERNEL__) 43 44 #include 45 #include 46 It builds on other debian platforms without a problem. Is something significantly different on x32 that we should know about? --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] libreswan FTBFS on hppa and alpha due to lack of -fstack-protector
hey libreswan folks--
i notice that mk/userland-cflags.mk has -fstack-protector-all set inside
USERCOMPILE.
However, there are at least two debian unofficial architectures (alpha
and hppa) where gcc doesn't have -fstack-protector available.
A couple example builds from those arches:
https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=alpha&ver=3.19-1&stamp=1485414786&raw=0
https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=hppa&ver=3.19-2&stamp=1486145521&raw=0
they fail with:
make[5]: Entering directory '/<>/OBJ.linux.parisc64/lib/libswan'
cc -g -O2 -fdebug-prefix-map=/<>=. -Wformat
-Werror=format-security -I/<>/lib/libcrypto/libsha2
-I/<>/lib/libcrypto/libaes_xcbc
-I/<>/ports/linux/include -I/<>/ports/linux/include
-I/<>/ports/linux/include -I. -I/<>/linux/net/ipsec
-I/<>/linux/include -I/<> -DPFKEYV2
-I/usr/include/nss -I/usr/include/nspr -I/<>/include
-I/<>/ports/linux/include -I/<>/ports/linux/include
-I/<>/ports/linux/include -std=gnu99 -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-all -fno-strict-aliasing
-fPIE -DPIE -DFORCE_PR_ASSERT -DDNSSEC -DLIBCURL -DLDAP_VER=3 -DHAVE_NM
-DUSE_MD5 -DUSE_SHA2 -DUSE_SHA1 -DUSE_AES -DUSE_3DES -DUSE_CAMELLIA
-DUSE_SERPENT -DUSE_TWOFISH -DUSE_CAST -DUSE_RIPEMD
-DFIPSPRODUCTCHECK=\"/etc/system-fips\" -DIPSEC_CONF=\"/etc/ipsec.conf\"
-DIPSEC_CONFDDIR=\"/etc/ipsec.d\" -DIPSEC_NSSDIR=\"/var/lib/ipsec/nss\"
-DIPSEC_CONFDIR=\"/etc\" -DIPSEC_EXECDIR=\"/usr/lib/ipsec\"
-DIPSEC_SBINDIR=\"/usr/sbin\" -DIPSEC_VARDIR=\"/var\"
-DPOLICYGROUPSDIR=\"/etc/ipsec.d/policies\"
-DIPSEC_SECRETS_FILE=\"/etc/ipsec.secrets\" -DRETRANSMIT_INTERVAL_DEFAULT="500"
-DUSE_FORK=1 -DUSE_VFORK=0 -DUSE_DAEMON=0 -DUSE_PTHREAD_SETSCHEDPRIO=1
-DGCC_LINT -DALLOW_MICROSOFT_BAD_PROPOSAL -Werror -Wall -Wextra -Wformat
-Wformat-nonliteral -Wformat-security -Wundef -Wmissing-declarations
-Wredundant-decls -Wnested-externs -I/<>/lib/libcrypto/libsha2
-I/<>/lib/libcrypto/libaes_xcbc
-I/<>/ports/linux/include -I/<>/ports/linux/include
-I/<>/ports/linux/include -I/<>/ports/linux/include
-I. -I/<>/linux/net/ipsec -I/<>/linux/include
-I/<> -DPFKEYV2 -I/usr/include/nss -I/usr/include/nspr
-I/<>/include -I/<>/ports/linux/include
-I/<>/ports/linux/include -I/<>/ports/linux/include
-I/<>/ports/linux/include -std=gnu99 -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-all -fno-strict-aliasing
-fPIE -DPIE -DFORCE_PR_ASSERT -DDNSSEC -DLIBCURL -DLDAP_VER=3 -DHAVE_NM
-DUSE_MD5 -DUSE_SHA2 -DUSE_SHA1 -DUSE_AES -DUSE_3DES -DUSE_CAMELLIA
-DUSE_SERPENT -DUSE_TWOFISH -DUSE_CAST -DUSE_RIPEMD
-DFIPSPRODUCTCHECK=\"/etc/system-fips\" -DIPSEC_CONF=\"/etc/ipsec.conf\"
-DIPSEC_CONFDDIR=\"/etc/ipsec.d\" -DIPSEC_NSSDIR=\"/var/lib/ipsec/nss\"
-DIPSEC_CONFDIR=\"/etc\" -DIPSEC_EXECDIR=\"/usr/lib/ipsec\"
-DIPSEC_SBINDIR=\"/usr/sbin\" -DIPSEC_VARDIR=\"/var\"
-DPOLICYGROUPSDIR=\"/etc/ipsec.d/policies\"
-DIPSEC_SECRETS_FILE=\"/etc/ipsec.secrets\" -DRETRANSMIT_INTERVAL_DEFAULT="500"
-DUSE_FORK=1 -DUSE_VFORK=0 -DUSE_DAEMON=0 -DUSE_PTHREAD_SETSCHEDPRIO=1
-DGCC_LINT -DALLOW_MICROSOFT_BAD_PROPOSAL -Werror -Wall -Wextra -Wformat
-Wformat-nonliteral -Wformat-security -Wundef -Wmissing-declarations
-Wredundant-decls -Wnested-externs -I/<>/ports/linux/include
-I/<>/ports/linux/include -I/<>/ports/linux/include
-I/<>/ports/linux/include \
-MMD -MF ./addrtoa.d \
-o ./addrtoa.o \
-c /<>/linux/net/ipsec/addrtoa.c
cc1: error: -fstack-protector not supported for this target [-Werror]
cc1: all warnings being treated as errors
../../../mk/depend.mk:28: recipe for target 'addrtoa.o' failed
make[5]: *** [addrtoa.o] Error 1
It's not going to be the end of the world if libreswan doesn't build on
these architectures (i can just mark it as explicitly not for those
arches if you prefer), but otoh, it might be nice if we could build
there anyway.
Would you consider making the build flag optional somehow, or only
enabling it if it's detected to be available? or should i mark
libreswan as not for those architectures?
You can detect it with something like:
printf 'int main() { return 0;}' | gcc -x c -fstack-protector-all -
(note that this will create a.out in the current directory)
--dkg
signature.asc
Description: PGP signature
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Bug#853947: libreswan FTBFS on mips and mipsel: error: "_ABI64" is not defined [-Werror=undef]
On Thu 2017-02-02 20:26:26 -0500, Paul Wouters wrote: > Can you try the attached patch? > > Totally untested, because I don't have that build environment, and based > on some random googling :) > > Paul > diff --git a/lib/libswan/nss_copies.c b/lib/libswan/nss_copies.c > index b90bbf0..16976db 100644 > --- a/lib/libswan/nss_copies.c > +++ b/lib/libswan/nss_copies.c > @@ -3,6 +3,10 @@ > * file, You can obtain one at http://mozilla.org/MPL/2.0/. > */ > > +#ifdef _MIPS_SIM > +# include > +#endif > + > #include > #include > #include "nss_copies.h" I've tried this as bugfix-853947/0010-Try-to-include-the-correct-headers-on-MIPS.patch in 3.19-2, and it does not seem to resolve the build problems on mips and mipsel: https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=mips&ver=3.19-2&stamp=1486145635&raw=0 ends with: cc -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -I/«PKGBUILDDIR»/lib/libcrypto/libsha2 -I/«PKGBUILDDIR»/lib/libcrypto/libaes_xcbc -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I. -I/«PKGBUILDDIR»/linux/net/ipsec -I/«PKGBUILDDIR»/linux/include -I/«PKGBUILDDIR» -DPFKEYV2 -I/usr/include/nss -I/usr/include/nspr -I/«PKGBUILDDIR»/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -std=gnu99 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-all -fno-strict-aliasing -fPIE -DPIE -DFORCE_PR_ASSERT -DDNSSEC -DLIBCURL -DLDAP_VER=3 -DHAVE_NM -DUSE_MD5 -DUSE_SHA2 -DUSE_SHA1 -DUSE_AES -DUSE_3DES -DUSE_CAMELLIA -DUSE_SERPENT -DUSE_TWOFISH -DUSE_CAST -DUSE_RIPEMD -DFIPSPRODUCTCHECK=\"/etc/system-fips\" -DIPSEC_CONF=\"/etc/ipsec.conf\" -DIPSEC_CONFDDIR=\"/etc/ipsec.d\" -DIPSEC_NSSDIR=\"/var/lib/ipsec/nss\" -DIPSEC_CONFDIR=\"/etc\" -DIPSEC_EXECDIR=\"/usr/lib/ipsec\" -DIPSEC_SBINDIR=\"/usr/sbin\" -DIPSEC_VARDIR=\"/var\" -DPOLICYGROUPSDIR=\"/etc/ipsec.d/policies\" -DIPSEC_SECRETS_FILE=\"/etc/ipsec.secrets\" -DRETRANSMIT_INTERVAL_DEFAULT="500" -DUSE_FORK=1 -DUSE_VFORK=0 -DUSE_DAEMON=0 -DUSE_PTHREAD_SETSCHEDPRIO=1 -DGCC_LINT -DALLOW_MICROSOFT_BAD_PROPOSAL -Werror -Wall -Wextra -Wformat -Wformat-nonliteral -Wformat-security -Wundef -Wmissing-declarations -Wredundant-decls -Wnested-externs -I/«PKGBUILDDIR»/lib/libcrypto/libsha2 -I/«PKGBUILDDIR»/lib/libcrypto/libaes_xcbc -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I. -I/«PKGBUILDDIR»/linux/net/ipsec -I/«PKGBUILDDIR»/linux/include -I/«PKGBUILDDIR» -DPFKEYV2 -I/usr/include/nss -I/usr/include/nspr -I/«PKGBUILDDIR»/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -std=gnu99 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-all -fno-strict-aliasing -fPIE -DPIE -DFORCE_PR_ASSERT -DDNSSEC -DLIBCURL -DLDAP_VER=3 -DHAVE_NM -DUSE_MD5 -DUSE_SHA2 -DUSE_SHA1 -DUSE_AES -DUSE_3DES -DUSE_CAMELLIA -DUSE_SERPENT -DUSE_TWOFISH -DUSE_CAST -DUSE_RIPEMD -DFIPSPRODUCTCHECK=\"/etc/system-fips\" -DIPSEC_CONF=\"/etc/ipsec.conf\" -DIPSEC_CONFDDIR=\"/etc/ipsec.d\" -DIPSEC_NSSDIR=\"/var/lib/ipsec/nss\" -DIPSEC_CONFDIR=\"/etc\" -DIPSEC_EXECDIR=\"/usr/lib/ipsec\" -DIPSEC_SBINDIR=\"/usr/sbin\" -DIPSEC_VARDIR=\"/var\" -DPOLICYGROUPSDIR=\"/etc/ipsec.d/policies\" -DIPSEC_SECRETS_FILE=\"/etc/ipsec.secrets\" -DRETRANSMIT_INTERVAL_DEFAULT="500" -DUSE_FORK=1 -DUSE_VFORK=0 -DUSE_DAEMON=0 -DUSE_PTHREAD_SETSCHEDPRIO=1 -DGCC_LINT -DALLOW_MICROSOFT_BAD_PROPOSAL -Werror -Wall -Wextra -Wformat -Wformat-nonliteral -Wformat-security -Wundef -Wmissing-declarations -Wredundant-decls -Wnested-externs -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include -I/«PKGBUILDDIR»/ports/linux/include \ -MMD -MF ./base64_rsa_pubkey.d \ -o ./base64_rsa_pubkey.o \ -c /«PKGBUILDDIR»/lib/libswan/base64_rsa_pubkey.c In file included from /usr/include/nspr/prtypes.h:26:0, from /usr/include/nss/seccomon.h:17, from /usr/include/nss/nss.h:34, from /«PKGBUILDDIR»/lib/libswan/base64_rsa_pubkey.c:21: /usr/include/nspr/prcpucfg.h:511:18: error: "_ABI64" is not defined [-Werror=undef] #if _MIPS_SIM == _ABI64 ^~ cc1: all warnings being treated as errors ../../../mk/depend.mk:28: recipe for target 'base64_rsa_pubkey.o' failed and it's the same thing on mipsel: https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=mipsel&ver=3.19-2&stamp=1486145643&raw=0 --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Bug#853947: libreswan FTBFS on mips and mipsel: error: "_ABI64" is not defined [-Werror=undef]
Hi Radovan-- Over on https://bugs.debian.org/853947 you wrote: On Thu 2017-02-02 07:02:59 -0500, Radovan Birdic wrote: > Package: libreswan > Version: 3.19-1 > Severity: important > Tags: sid + patch > Justification: FTBFS > User: debian-m...@lists.debian.org > Usertags: mips-patch > > > Package libreswan_3.19-1 FTBFS on mips and mipsel with following error: > >> In file included from /usr/include/nspr/prtypes.h:26:0, >> from /usr/include/nspr/plarena.h:15, >> from /usr/include/nss/cert.h:13, >> from /«PKGBUILDDIR»/lib/libswan/nss_copies.c:6: >> /usr/include/nspr/prcpucfg.h:511:18: error: "_ABI64" is not defined >> [-Werror=undef] >> #if _MIPS_SIM == _ABI64 >> ^~ >> cc1: all warnings being treated as errors >> ../../../mk/depend.mk:28: recipe for target 'nss_copies.o' failed >> make[5]: *** [nss_copies.o] Error 1 > > Full build log: > https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=mips&ver=3.19-1&stamp=1485409760&raw=0 > > On 32-bit mips (ABIO32) _ABI64 is not defined so using -Wundef flag causes > build failure. > > I have created and attached a patch that exclude this flag for mips/mipsel. > With this patch package builds successfully on mips, mipsel and mips64el. > > Regards, > Radovan > --- libreswan-3.19_orig/debian/rules 2017-01-25 23:37:04.0 + > +++ libreswan-3.19/debian/rules 2017-02-02 20:01:47.654502204 + > @@ -1,5 +1,12 @@ > #!/usr/bin/make -f > > +DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH) > +ifneq (,$(filter $(DEB_BUILD_ARCH),mips mipsel)) > + ADDITIONAL_WARNING_CFLAGS = -Wall -Wextra -Wformat > -Wformat-nonliteral -Wformat-security -Wmissing-declarations > -Wredundant-decls -Wnested-externs > +else > + ADDITIONAL_WARNING_CFLAGS = -Wall -Wextra -Wformat > -Wformat-nonliteral -Wundef -Wformat-security -Wmissing-declarations > -Wredundant-decls -Wnested-externs > +endif > + > %: > dh $@ --with systemd > > @@ -17,7 +24,8 @@ override_dh_auto_build: > USE_LIBCAP_NG=true \ > USE_LABELED_IPSEC=false \ > USE_KLIPS=false \ > - USE_DNSSEC=true > + USE_DNSSEC=true \ > + WARNING_CFLAGS="$(ADDITIONAL_WARNING_CFLAGS)" > > override_dh_auto_install-arch: > # Add here commands to install the package into debian/libreswan I appreciate the patch, but i think excluding the warning is probably not a great idea -- presumably, upstream should be doing something differently there. I'm cc'ing upstream on this. upstream folks, you can see build logs for 3.1.19-1 on debian over here: https://buildd.debian.org/status/logs.php?pkg=libreswan&ver=3.19-1&suite=sid The failing mips build log is here: https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=mips&ver=3.19-1&stamp=1485409760&raw=0 and the failing mipsel build log is here: https://buildd.debian.org/status/fetch.php?pkg=libreswan&arch=mipsel&ver=3.19-1&stamp=1485507191&raw=0 If this is something you can fix upstream, i'm happy to pull the patch into debian's packaging directly. Regards, --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-dev] libreswan 3.19 uploaded to debian unstable (unauth OE, debian strategies)
hi all-- i've just uploaded libreswan 3.19 to debian unstable. thanks very much for all your work on libreswan! I've also posted a couple pull requests and issues on github related to minor nitpicks i found while packaging. I hope they're helpful. Unauthenticated Opportunistic Encryption I've been trying to test out the unauthenticated opportunistic mode, and i haven't had as much luck with it as i'd like yet. in particular, i was hoping that i could just get the package installed, and then do: cp oe-upgrade-authnull.conf /etc/ipsec.d/ systemctl start ipsec ipsec whack --trafficstatus ping -c 4 libreswan.org sleep 5 ipsec whack --trafficstatus to see a new association successfully (opportunistically) configured. However, when i do that, the "ipsec whack --trafficstatus" lines show no output either time. if i look at "ipsec whack --shuntstatus" then i see: 000 Bare Shunt list: 000 […] 000 W.X.Y.Z/32:0 -0-> 188.127.201.229/32:0 => %pass 0oe-failing (188.127.201.229 is the IP address i'm seeing for libreswan.org; i've anonymized the source IP address, but i'd be happy to share it in private debugging conversation) I've also tried browsing to http://oe.libreswan.org/ and gotten the "Oh no! You are NOT protected by Opportunistic IPsec!" message, and seen "ipsec whack --shuntstatus" tell me: 000 A.B.C.D/32:0 -0-> 193.110.157.124/32:0 => %pass 0oe-failing Any thoughts on what i might be missing or what my next steps for debugging should be? I've tried this on hosts that are behind a NAT and hosts that are not NAT'ed at all. Packaging in Debian --- Despite failing to get this OE mode working, I've uploaded the package to debian unstable so that it can reach a wider audience. It's possible (though unlikely) that this package could migrate to debian testing in time for the upcoming freeze for debian "stretch" (the next stable release). To do that, there would need to be no serious bugs found in it over the next 10 days. That said, i'm not sure we necessarily want it in debian stable yet anyway. Committing to 3.19 being in debian stable means being willing to support that version for several years, and i'm not yet convinced i have the bandwidth to do that without serious upstream support. I don't know how much y'all want to commit to 3.19 long term anyway. If it stays out of debian stable for now, but it stabilizes in the near future, we can always use the stretch-backports repository to make it available for stretch users without committing to a long-term stable release (backports are allowed/expected to change more frequently). I suspect this approach would give libreswan the better balance between exposure and stability for this debian release cycle, but if y'all feel differently as upstream, i'd be happy to hear about it. Please let me know! I'd really like to try to sort out the OE stuff! I'll look for you on over on #swan to try to get that sorted, but i'm also happy to hear any suggestions on (or off) this mailing list. Happy hacking, --dkg signature.asc Description: PGP signature ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] libreswan in debian - Ondřej offered to help (fwd)
On Wed 2016-06-22 19:41:59 -0400, Paul Wouters wrote: > On Wed, 22 Jun 2016, Daniel Kahn Gillmor wrote: >> the EXAMPLES section in ipsec_rsasigkey(8) shows: >> >> ipsec rsasigkey --verbose 4096 >mykey.txt >> >> but of course that fails... > > It does? It works for me. Ah, it works for the superuser. > If you specify --configdir then it does need to get the sql: prefix > unfortunately. We do need to fix our tools to always add that to a > prefix if not there. is this bug/enhancement reported/tracked someplace? As a non-privileged user, it works if i first initnss (supplying --configdir without sql:) and then rsasigkey --configdir *with* the sql: prefix. --dkg ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] libreswan in debian - Ondřej offered to help (fwd)
On Mon 2016-06-20 13:25:26 -0400, Paul Wouters wrote: > 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. Let's start it that way. If that works for some folks, but others rally around KLIPS, then we can add it in. It's much easier to go in that direction than to take something away from even a tiny number of people once they've come to expect it :) > 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) OK, i'll modify debian to make it use /var/lib/ipsec/nss for the nss directory. > And maybe just rename --configdir to --nssdir (and leave the old name > undocumented) I'm happy to have --nssdir be the formal name for all of the subcommands which need it. What i don't want is for that configuration parameter to influence other file locaions. What option will libreswan use to look for policies/ and passwd and nsspassword ? (and cacerts/ and crls/ for as long as those remain an option) > No one should call rsasigkey directly, it is supposed to go through the > newhostkey wrapper. Which you suggested above could cause the nss init. Maybe it should be named _rsasigkey then? should the documentation have big scary warnings? i'd assumed that the convention was that documented subcommands without a leading underscore were knobs that admins were expected to be able to twiddle. the EXAMPLES section in ipsec_rsasigkey(8) shows: ipsec rsasigkey --verbose 4096 >mykey.txt but of course that fails... --dkg ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] libreswan in debian - Ondřej offered to help (fwd)
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, enu
