We now check for whether the build is done on Windows, so that:
-We link to -lws2_32, which is necessary for the networking functions
on Windows.
-We default to using libicu on Windows for the runtime and builtins,
as the code using libidn and libidn2 use stuff from langinfo.h, which
is not available on Windows.
-We do not build and run the tests under fuzz/ as Windows does not have
fmemopen().
This enables the code to be built on Windows via MinGW.
Add --enable-cfi ./configure option to enable
LLVM/Clang's Control Flow Integrity for builds.
CFI aborts a program upon detecting certain forms of undefined behavior
that can potentially allow attackers to subvert the program’s control flow.
Also add a new ./configure function to set a distribution wide
PSL file used by psl_latest(): --with-psl-distfile
If possible that filename should point to a DAFSA PSL file that
becomes updated regularly.
I've talked to the good people on #debian-bootstrap who would be most
affected by the possible build-dep cycle, and i think the simplest
approach is actually to split out make_dafsa.py into its own
architecture-independent package.
I'm thinking i'll call the package psl-make-dafsa, and in the course of
shipping it, i'll place src/make_dafsa.py as /usr/bin/psl-make-dafsa.
This is because:
* debian discourages scripts on the $PATH from having language-specific
suffixes like .py:
https://lintian.debian.org/tags/script-with-language-extension.html
* "-" appears to be a more common delimiter in command names than "_":
0 dkg@alice:~$ for x in - _; do printf "%s: %d " "$x" $(ls -1 ${PATH//:/ } | grep -c "$x"); done; echo
-: 1235 _: 368
0 dkg@alice:~$
* i'd prefer to prefix the command with "psl-" since it really is
producing and interpreting PSL-specific data structures.
Accepting this patch would mean i'd have fewer changes to make in the
debian packaging, and would allow other distributors to take a similar
approach if they want to.
Chun-wei Fan
Tim Rühsen
Dagobert Michelsen
Daniel Kahn Gillmor