On 29 February 2016 at 10:32, Paul Wouters <[email protected]> wrote: > On Mon, 29 Feb 2016, Andrew Cagney wrote: > >> On 28 February 2016 at 18:39, Paul Wouters <[email protected]> >> wrote: >>> >>> New commits: >>> commit 690fc62ba42febcb5b7c7040b6027756fe3c318f >>> Author: Paul Wouters <[email protected]> >>> Date: Sun Feb 28 18:39:05 2016 -0500 >>> >>> testing: Added basic-pluto-00 which runs the lib/libswan tests >> >> >> Something on my build todo list is to try convincing everyone that >> libswan should be abandoned; instead build: libpluto.a in >> programs/pluto and link whack, cavp, pluto, and the above tests >> against that. I guess this is as good a trigger as any for that >> discussion :-) >> >> It's not that I've something against libraries, just that here, the >> effort seems to have stalled so badly and for so long that it now just >> creates confusion. If a library or libraries is really desirable then >> first straighten out pluto. > > > How is that different, apart from the directory location?
Two existing problems get fixed: - cavp is built using a hard-wired link line containing an arbitrary chunk of pluto, some of which probably isn't or shouldn't be needed; the correct fix is to link both cavp and pluto against an archive and let the linker deal with this - alg_info's code is split between pluto and libswan; I get the feeling that this occurred because logging never got abstracted - having all the code in one directory will make it easier to re-structure - sort out the structure and then split off libraries (not the reverse as was done here) > If we would redo things, I'd like to create a shared library that is an > API to pluto that other software could use directly, instead of everyone > writing their own whacking wrappers. Think of this as a self contained and achievable step along such a path. BTW, based on this commit: commit 5a0626517900ae0e16e17c7a1d06b7ecf73e68d5 Author: Michael Richardson <[email protected]> Date: Thu Dec 8 17:15:29 2005 -0500 many files were moved from programs/pluto to lib/libopenswan such that they could be compiled and linked against other utilities. The specific goal is to make the ipsec.secrets parsing available to showhostkey. Likely many files in lib/libopenswan will be refactored some more, and some will move into libcrypto (md5/md2/sha/rsa). This code has been verified against basic-pluto-01, x509-pluto-01. psk-pluto-01 fails due to a failure to find the right secret. This will be further debugged with a unit test case. "libswan"'s been a [stalled] work-in-progress for some 10 years now. On the other hand, we can continue to ignore this :-) Andrew _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
