mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tvl-depot/third_party/lisp/ironclad.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

156 lines
3.7 KiB
Nix
Raw Normal View History

feat(3p/lisp): Add ironclad Add ironclad, a common lisp library for cryptography. This is a huge library with a lot of moving parts - probably most notable here is that I've had to turn off compiling with `:ironclad-assembly`, as it was causing an infinite loop in the compiler due to https://github.com/sharplispers/ironclad/blob/master/src/opt/sbcl/cpu-features.lisp#L9-L10, a mutually self-recursive function that looks like: (defun aes-ni-support-p () (aes-ni-support-p)) Without knowing much about how sbcl handles native-compiled assembly, it seems like this definition should actually be skipped entirely, due to it being defined as a `defknown` in `fndb.lisp`: (defknown ironclad::aes-ni-support-p () (boolean) (any) :overwrite-fndb-silently t) But something about how we're compiling things was causing that not to happen, and the infinite recursion caused the compiler to hang. This should be fixed at some point, but given I only need this library as a transitive dependency down a level I'm not going to attempt to do so now. Change-Id: Id768717991404f959b003c7e2f28f1f4d532b94b Reviewed-on: https://cl.tvl.fyi/c/depot/+/1333 Tested-by: BuildkiteCI Reviewed-by: kanepyork <rikingcoding@gmail.com>
2020-07-21 20:29:58 +02:00
{ depot, pkgs, ...}:
let
inherit (pkgs) runCommand;
inherit (depot.nix.buildLisp) bundled;
src = pkgs.fetchFromGitHub {
owner = "sharplispers";
repo = "ironclad";
rev = "c3aa33080621abc10fdb0f34acc4655cc4e982a6";
sha256 = "0k4bib9mbrzalbl9ivkw4a7g4c7bbad1l5jw4pzkifqszy2swkr5";
};
feat(nix/buildLisp): add ecl Adds ECL as a second supported implementation, specifically a statically linked ECL. This is interesting because we can create statically linked binaries, but has a few drawbacks which doesn't make it generally useful: * Loading things is very slow: The statically linked ECL only has byte compilation available, so when we do load things or use the REPL it is significantly worse than with e. g. SBCL. * We can't load shared objects via the FFI since ECL's dffi is not available when linked statically. This means that as it stands, we can't build a statically linked //web/panettone for example. Since ECL is quite slow anyways, I think these drawbacks are worth it since the biggest reason for using ECL would be to get a statically linked binary. If we change our minds, it shouldn't be too hard to provide ecl-static and ecl-dynamic as separate implementations. ECL is LGPL and some libraries it uses as part of its runtime are as well. I've outlined in the ecl-static overlay why this should be of no concern in the context of depot even though we are statically linking. Currently everything is building except projects that are using cffi to load shared libaries which have gotten an appropriate `badImplementations` entry. To get the rest building the following changes were made: * Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now use `bundled "asdf"` for all implementations except SBCL. From my testing, SBCL seems to be the only implementation to support using `(require 'uiop)` to only load the UIOP package. Where both a dependency on ASDF and UIOP exists, we just delete the UIOP one. `(require 'asdf)` always causes UIOP to be available. * Where appropriate only conditionally compile SBCL-specific code and if any build the corresponding files for ECL. * //lisp/klatre: Use the standard condition parse-error for all implementations except SBCL in try-parse-integer. * //3p/lisp/ironclad: disable SBCL assembly optimization hack for all other platforms as it may interfere with compilation. * //3p/lisp/trivial-mimes: prevent call to asdf function by substituting it out of the source since it always errors out in ECL and we hardcode the correct path elsewhere anyways. As it stands ECL still suffers from a very weird problem which happens when compiling postmodern and moptilities: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651 Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> Reviewed-by: eta <tvl@eta.st>
2021-08-09 02:47:07 +02:00
getSrc = f: "${src}/src/${f}";
feat(3p/lisp): Add ironclad Add ironclad, a common lisp library for cryptography. This is a huge library with a lot of moving parts - probably most notable here is that I've had to turn off compiling with `:ironclad-assembly`, as it was causing an infinite loop in the compiler due to https://github.com/sharplispers/ironclad/blob/master/src/opt/sbcl/cpu-features.lisp#L9-L10, a mutually self-recursive function that looks like: (defun aes-ni-support-p () (aes-ni-support-p)) Without knowing much about how sbcl handles native-compiled assembly, it seems like this definition should actually be skipped entirely, due to it being defined as a `defknown` in `fndb.lisp`: (defknown ironclad::aes-ni-support-p () (boolean) (any) :overwrite-fndb-silently t) But something about how we're compiling things was causing that not to happen, and the infinite recursion caused the compiler to hang. This should be fixed at some point, but given I only need this library as a transitive dependency down a level I'm not going to attempt to do so now. Change-Id: Id768717991404f959b003c7e2f28f1f4d532b94b Reviewed-on: https://cl.tvl.fyi/c/depot/+/1333 Tested-by: BuildkiteCI Reviewed-by: kanepyork <rikingcoding@gmail.com>
2020-07-21 20:29:58 +02:00
in depot.nix.buildLisp.library {
name = "ironclad";
deps = with depot.third_party.lisp; [
(bundled "asdf")
feat(nix/buildLisp): add ecl Adds ECL as a second supported implementation, specifically a statically linked ECL. This is interesting because we can create statically linked binaries, but has a few drawbacks which doesn't make it generally useful: * Loading things is very slow: The statically linked ECL only has byte compilation available, so when we do load things or use the REPL it is significantly worse than with e. g. SBCL. * We can't load shared objects via the FFI since ECL's dffi is not available when linked statically. This means that as it stands, we can't build a statically linked //web/panettone for example. Since ECL is quite slow anyways, I think these drawbacks are worth it since the biggest reason for using ECL would be to get a statically linked binary. If we change our minds, it shouldn't be too hard to provide ecl-static and ecl-dynamic as separate implementations. ECL is LGPL and some libraries it uses as part of its runtime are as well. I've outlined in the ecl-static overlay why this should be of no concern in the context of depot even though we are statically linking. Currently everything is building except projects that are using cffi to load shared libaries which have gotten an appropriate `badImplementations` entry. To get the rest building the following changes were made: * Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now use `bundled "asdf"` for all implementations except SBCL. From my testing, SBCL seems to be the only implementation to support using `(require 'uiop)` to only load the UIOP package. Where both a dependency on ASDF and UIOP exists, we just delete the UIOP one. `(require 'asdf)` always causes UIOP to be available. * Where appropriate only conditionally compile SBCL-specific code and if any build the corresponding files for ECL. * //lisp/klatre: Use the standard condition parse-error for all implementations except SBCL in try-parse-integer. * //3p/lisp/ironclad: disable SBCL assembly optimization hack for all other platforms as it may interfere with compilation. * //3p/lisp/trivial-mimes: prevent call to asdf function by substituting it out of the source since it always errors out in ECL and we hardcode the correct path elsewhere anyways. As it stands ECL still suffers from a very weird problem which happens when compiling postmodern and moptilities: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651 Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> Reviewed-by: eta <tvl@eta.st>
2021-08-09 02:47:07 +02:00
{ sbcl = bundled "sb-rotate-byte"; }
{ sbcl = bundled "sb-posix"; }
feat(3p/lisp): Add ironclad Add ironclad, a common lisp library for cryptography. This is a huge library with a lot of moving parts - probably most notable here is that I've had to turn off compiling with `:ironclad-assembly`, as it was causing an infinite loop in the compiler due to https://github.com/sharplispers/ironclad/blob/master/src/opt/sbcl/cpu-features.lisp#L9-L10, a mutually self-recursive function that looks like: (defun aes-ni-support-p () (aes-ni-support-p)) Without knowing much about how sbcl handles native-compiled assembly, it seems like this definition should actually be skipped entirely, due to it being defined as a `defknown` in `fndb.lisp`: (defknown ironclad::aes-ni-support-p () (boolean) (any) :overwrite-fndb-silently t) But something about how we're compiling things was causing that not to happen, and the infinite recursion caused the compiler to hang. This should be fixed at some point, but given I only need this library as a transitive dependency down a level I'm not going to attempt to do so now. Change-Id: Id768717991404f959b003c7e2f28f1f4d532b94b Reviewed-on: https://cl.tvl.fyi/c/depot/+/1333 Tested-by: BuildkiteCI Reviewed-by: kanepyork <rikingcoding@gmail.com>
2020-07-21 20:29:58 +02:00
alexandria
bordeaux-threads
nibbles
];
srcs = [
feat(nix/buildLisp): add ecl Adds ECL as a second supported implementation, specifically a statically linked ECL. This is interesting because we can create statically linked binaries, but has a few drawbacks which doesn't make it generally useful: * Loading things is very slow: The statically linked ECL only has byte compilation available, so when we do load things or use the REPL it is significantly worse than with e. g. SBCL. * We can't load shared objects via the FFI since ECL's dffi is not available when linked statically. This means that as it stands, we can't build a statically linked //web/panettone for example. Since ECL is quite slow anyways, I think these drawbacks are worth it since the biggest reason for using ECL would be to get a statically linked binary. If we change our minds, it shouldn't be too hard to provide ecl-static and ecl-dynamic as separate implementations. ECL is LGPL and some libraries it uses as part of its runtime are as well. I've outlined in the ecl-static overlay why this should be of no concern in the context of depot even though we are statically linking. Currently everything is building except projects that are using cffi to load shared libaries which have gotten an appropriate `badImplementations` entry. To get the rest building the following changes were made: * Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now use `bundled "asdf"` for all implementations except SBCL. From my testing, SBCL seems to be the only implementation to support using `(require 'uiop)` to only load the UIOP package. Where both a dependency on ASDF and UIOP exists, we just delete the UIOP one. `(require 'asdf)` always causes UIOP to be available. * Where appropriate only conditionally compile SBCL-specific code and if any build the corresponding files for ECL. * //lisp/klatre: Use the standard condition parse-error for all implementations except SBCL in try-parse-integer. * //3p/lisp/ironclad: disable SBCL assembly optimization hack for all other platforms as it may interfere with compilation. * //3p/lisp/trivial-mimes: prevent call to asdf function by substituting it out of the source since it always errors out in ECL and we hardcode the correct path elsewhere anyways. As it stands ECL still suffers from a very weird problem which happens when compiling postmodern and moptilities: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651 Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> Reviewed-by: eta <tvl@eta.st>
2021-08-09 02:47:07 +02:00
{
# TODO(grfn): Figure out how to get this compiling with the assembly
# optimization eventually - see https://cl.tvl.fyi/c/depot/+/1333
sbcl = runCommand "package.lisp" {} ''
substitute ${src}/src/package.lisp $out \
--replace \#-ecl-bytecmp "" \
--replace '(pushnew :ironclad-assembly *features*)' ""
'';
default = getSrc "package.lisp";
}
] ++ map getSrc [
feat(3p/lisp): Add ironclad Add ironclad, a common lisp library for cryptography. This is a huge library with a lot of moving parts - probably most notable here is that I've had to turn off compiling with `:ironclad-assembly`, as it was causing an infinite loop in the compiler due to https://github.com/sharplispers/ironclad/blob/master/src/opt/sbcl/cpu-features.lisp#L9-L10, a mutually self-recursive function that looks like: (defun aes-ni-support-p () (aes-ni-support-p)) Without knowing much about how sbcl handles native-compiled assembly, it seems like this definition should actually be skipped entirely, due to it being defined as a `defknown` in `fndb.lisp`: (defknown ironclad::aes-ni-support-p () (boolean) (any) :overwrite-fndb-silently t) But something about how we're compiling things was causing that not to happen, and the infinite recursion caused the compiler to hang. This should be fixed at some point, but given I only need this library as a transitive dependency down a level I'm not going to attempt to do so now. Change-Id: Id768717991404f959b003c7e2f28f1f4d532b94b Reviewed-on: https://cl.tvl.fyi/c/depot/+/1333 Tested-by: BuildkiteCI Reviewed-by: kanepyork <rikingcoding@gmail.com>
2020-07-21 20:29:58 +02:00
"macro-utils.lisp"
feat(nix/buildLisp): add ecl Adds ECL as a second supported implementation, specifically a statically linked ECL. This is interesting because we can create statically linked binaries, but has a few drawbacks which doesn't make it generally useful: * Loading things is very slow: The statically linked ECL only has byte compilation available, so when we do load things or use the REPL it is significantly worse than with e. g. SBCL. * We can't load shared objects via the FFI since ECL's dffi is not available when linked statically. This means that as it stands, we can't build a statically linked //web/panettone for example. Since ECL is quite slow anyways, I think these drawbacks are worth it since the biggest reason for using ECL would be to get a statically linked binary. If we change our minds, it shouldn't be too hard to provide ecl-static and ecl-dynamic as separate implementations. ECL is LGPL and some libraries it uses as part of its runtime are as well. I've outlined in the ecl-static overlay why this should be of no concern in the context of depot even though we are statically linking. Currently everything is building except projects that are using cffi to load shared libaries which have gotten an appropriate `badImplementations` entry. To get the rest building the following changes were made: * Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now use `bundled "asdf"` for all implementations except SBCL. From my testing, SBCL seems to be the only implementation to support using `(require 'uiop)` to only load the UIOP package. Where both a dependency on ASDF and UIOP exists, we just delete the UIOP one. `(require 'asdf)` always causes UIOP to be available. * Where appropriate only conditionally compile SBCL-specific code and if any build the corresponding files for ECL. * //lisp/klatre: Use the standard condition parse-error for all implementations except SBCL in try-parse-integer. * //3p/lisp/ironclad: disable SBCL assembly optimization hack for all other platforms as it may interfere with compilation. * //3p/lisp/trivial-mimes: prevent call to asdf function by substituting it out of the source since it always errors out in ECL and we hardcode the correct path elsewhere anyways. As it stands ECL still suffers from a very weird problem which happens when compiling postmodern and moptilities: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651 Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> Reviewed-by: eta <tvl@eta.st>
2021-08-09 02:47:07 +02:00
] ++ [
{ sbcl = getSrc "opt/sbcl/fndb.lisp"; }
{ sbcl = getSrc "opt/sbcl/cpu-features.lisp"; }
{ sbcl = getSrc "opt/sbcl/x86oid-vm.lisp"; }
feat(3p/lisp): Add ironclad Add ironclad, a common lisp library for cryptography. This is a huge library with a lot of moving parts - probably most notable here is that I've had to turn off compiling with `:ironclad-assembly`, as it was causing an infinite loop in the compiler due to https://github.com/sharplispers/ironclad/blob/master/src/opt/sbcl/cpu-features.lisp#L9-L10, a mutually self-recursive function that looks like: (defun aes-ni-support-p () (aes-ni-support-p)) Without knowing much about how sbcl handles native-compiled assembly, it seems like this definition should actually be skipped entirely, due to it being defined as a `defknown` in `fndb.lisp`: (defknown ironclad::aes-ni-support-p () (boolean) (any) :overwrite-fndb-silently t) But something about how we're compiling things was causing that not to happen, and the infinite recursion caused the compiler to hang. This should be fixed at some point, but given I only need this library as a transitive dependency down a level I'm not going to attempt to do so now. Change-Id: Id768717991404f959b003c7e2f28f1f4d532b94b Reviewed-on: https://cl.tvl.fyi/c/depot/+/1333 Tested-by: BuildkiteCI Reviewed-by: kanepyork <rikingcoding@gmail.com>
2020-07-21 20:29:58 +02:00
feat(nix/buildLisp): add ecl Adds ECL as a second supported implementation, specifically a statically linked ECL. This is interesting because we can create statically linked binaries, but has a few drawbacks which doesn't make it generally useful: * Loading things is very slow: The statically linked ECL only has byte compilation available, so when we do load things or use the REPL it is significantly worse than with e. g. SBCL. * We can't load shared objects via the FFI since ECL's dffi is not available when linked statically. This means that as it stands, we can't build a statically linked //web/panettone for example. Since ECL is quite slow anyways, I think these drawbacks are worth it since the biggest reason for using ECL would be to get a statically linked binary. If we change our minds, it shouldn't be too hard to provide ecl-static and ecl-dynamic as separate implementations. ECL is LGPL and some libraries it uses as part of its runtime are as well. I've outlined in the ecl-static overlay why this should be of no concern in the context of depot even though we are statically linking. Currently everything is building except projects that are using cffi to load shared libaries which have gotten an appropriate `badImplementations` entry. To get the rest building the following changes were made: * Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now use `bundled "asdf"` for all implementations except SBCL. From my testing, SBCL seems to be the only implementation to support using `(require 'uiop)` to only load the UIOP package. Where both a dependency on ASDF and UIOP exists, we just delete the UIOP one. `(require 'asdf)` always causes UIOP to be available. * Where appropriate only conditionally compile SBCL-specific code and if any build the corresponding files for ECL. * //lisp/klatre: Use the standard condition parse-error for all implementations except SBCL in try-parse-integer. * //3p/lisp/ironclad: disable SBCL assembly optimization hack for all other platforms as it may interfere with compilation. * //3p/lisp/trivial-mimes: prevent call to asdf function by substituting it out of the source since it always errors out in ECL and we hardcode the correct path elsewhere anyways. As it stands ECL still suffers from a very weird problem which happens when compiling postmodern and moptilities: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651 Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> Reviewed-by: eta <tvl@eta.st>
2021-08-09 02:47:07 +02:00
{ ecl = getSrc "opt/ecl/c-functions.lisp"; }
feat(nix/buildLisp): add ccl This adds support for Clozure's CL implementation to buildLisp. This is quite trivial in comparison to ECL since SBCL and CCL have very similar in how they work (so much so that CCL also suffers from b/136). Also the similarities in the code actually added here are striking, so I'll try to make an effort to reduce the code duplication in the future. To fix builds with CCL the following changes were made: * //3p/lisp/nibbles: The double inclusion of the types.lisp file was fixed. CCL doesn't like double definitions and refuses to compile otherwise. * //3p/lisp/physical-quantities: Update to a new bug fix release which contains a compilation fix for CCL. * //3p/lisp/routes: apply a patch fixing the build which was previously failing due to a double definition. * //3p/lisp/usocket: only depend on sb-bsd-sockets for SBCL and ECL, the latter of which seems to have a SBCL compatible implementation of the package. * Conditionally include a few CCL-specific source files and add `badImplementation` entries for the remaining failures which are //fun/gemma (to be expected) and //web/panettone which fails with an incredibly vague message. Change-Id: I666efdc39a0f16ee1bb6e23225784c709b04e740 Reviewed-on: https://cl.tvl.fyi/c/depot/+/3350 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in>
2021-08-13 22:24:50 +02:00
{ ccl = getSrc "opt/ccl/x86oid-vm.lisp"; }
feat(nix/buildLisp): add ecl Adds ECL as a second supported implementation, specifically a statically linked ECL. This is interesting because we can create statically linked binaries, but has a few drawbacks which doesn't make it generally useful: * Loading things is very slow: The statically linked ECL only has byte compilation available, so when we do load things or use the REPL it is significantly worse than with e. g. SBCL. * We can't load shared objects via the FFI since ECL's dffi is not available when linked statically. This means that as it stands, we can't build a statically linked //web/panettone for example. Since ECL is quite slow anyways, I think these drawbacks are worth it since the biggest reason for using ECL would be to get a statically linked binary. If we change our minds, it shouldn't be too hard to provide ecl-static and ecl-dynamic as separate implementations. ECL is LGPL and some libraries it uses as part of its runtime are as well. I've outlined in the ecl-static overlay why this should be of no concern in the context of depot even though we are statically linking. Currently everything is building except projects that are using cffi to load shared libaries which have gotten an appropriate `badImplementations` entry. To get the rest building the following changes were made: * Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now use `bundled "asdf"` for all implementations except SBCL. From my testing, SBCL seems to be the only implementation to support using `(require 'uiop)` to only load the UIOP package. Where both a dependency on ASDF and UIOP exists, we just delete the UIOP one. `(require 'asdf)` always causes UIOP to be available. * Where appropriate only conditionally compile SBCL-specific code and if any build the corresponding files for ECL. * //lisp/klatre: Use the standard condition parse-error for all implementations except SBCL in try-parse-integer. * //3p/lisp/ironclad: disable SBCL assembly optimization hack for all other platforms as it may interfere with compilation. * //3p/lisp/trivial-mimes: prevent call to asdf function by substituting it out of the source since it always errors out in ECL and we hardcode the correct path elsewhere anyways. As it stands ECL still suffers from a very weird problem which happens when compiling postmodern and moptilities: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651 Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> Reviewed-by: eta <tvl@eta.st>
2021-08-09 02:47:07 +02:00
] ++ map getSrc [
feat(3p/lisp): Add ironclad Add ironclad, a common lisp library for cryptography. This is a huge library with a lot of moving parts - probably most notable here is that I've had to turn off compiling with `:ironclad-assembly`, as it was causing an infinite loop in the compiler due to https://github.com/sharplispers/ironclad/blob/master/src/opt/sbcl/cpu-features.lisp#L9-L10, a mutually self-recursive function that looks like: (defun aes-ni-support-p () (aes-ni-support-p)) Without knowing much about how sbcl handles native-compiled assembly, it seems like this definition should actually be skipped entirely, due to it being defined as a `defknown` in `fndb.lisp`: (defknown ironclad::aes-ni-support-p () (boolean) (any) :overwrite-fndb-silently t) But something about how we're compiling things was causing that not to happen, and the infinite recursion caused the compiler to hang. This should be fixed at some point, but given I only need this library as a transitive dependency down a level I'm not going to attempt to do so now. Change-Id: Id768717991404f959b003c7e2f28f1f4d532b94b Reviewed-on: https://cl.tvl.fyi/c/depot/+/1333 Tested-by: BuildkiteCI Reviewed-by: kanepyork <rikingcoding@gmail.com>
2020-07-21 20:29:58 +02:00
"common.lisp"
"conditions.lisp"
"generic.lisp"
"util.lisp"
"ciphers/padding.lisp"
"ciphers/cipher.lisp"
"ciphers/chacha.lisp"
"ciphers/modes.lisp"
"ciphers/salsa20.lisp"
"ciphers/xchacha.lisp"
"ciphers/xsalsa20.lisp"
"ciphers/aes.lisp"
"ciphers/arcfour.lisp"
"ciphers/arcfour.lisp"
"ciphers/aria.lisp"
"ciphers/blowfish.lisp"
"ciphers/camellia.lisp"
"ciphers/cast5.lisp"
"ciphers/des.lisp"
"ciphers/idea.lisp"
"ciphers/keystream.lisp"
"ciphers/kalyna.lisp"
"ciphers/kuznyechik.lisp"
"ciphers/make-cipher.lisp"
"ciphers/misty1.lisp"
"ciphers/rc2.lisp"
"ciphers/rc5.lisp"
"ciphers/rc6.lisp"
"ciphers/seed.lisp"
"ciphers/serpent.lisp"
"ciphers/sm4.lisp"
"ciphers/sosemanuk.lisp"
"ciphers/square.lisp"
"ciphers/tea.lisp"
"ciphers/threefish.lisp"
"ciphers/twofish.lisp"
"ciphers/xor.lisp"
"ciphers/xtea.lisp"
"digests/digest.lisp"
"digests/adler32.lisp"
"digests/blake2.lisp"
"digests/blake2s.lisp"
"digests/crc24.lisp"
"digests/crc32.lisp"
"digests/groestl.lisp"
"digests/jh.lisp"
"digests/kupyna.lisp"
"digests/md2.lisp"
"digests/md4.lisp"
"digests/md5.lisp"
"digests/md5-lispworks-int32.lisp"
"digests/ripemd-128.lisp"
"digests/ripemd-160.lisp"
"digests/sha1.lisp"
"digests/sha256.lisp"
"digests/sha3.lisp"
"digests/sha512.lisp"
"digests/skein.lisp"
"digests/sm3.lisp"
"digests/streebog.lisp"
"digests/tiger.lisp"
"digests/tree-hash.lisp"
"digests/whirlpool.lisp"
"prng/prng.lisp"
"prng/generator.lisp"
"prng/fortuna.lisp"
"prng/os-prng.lisp"
"math.lisp"
"macs/mac.lisp"
"macs/blake2-mac.lisp"
"macs/blake2s-mac.lisp"
"macs/cmac.lisp"
"macs/hmac.lisp"
"macs/gmac.lisp"
"macs/poly1305.lisp"
"macs/siphash.lisp"
"macs/skein-mac.lisp"
"kdf/kdf-common.lisp"
"kdf/argon2.lisp"
"kdf/password-hash.lisp"
"kdf/pkcs5.lisp"
"kdf/scrypt.lisp"
"kdf/hmac.lisp"
"aead/aead.lisp"
"aead/eax.lisp"
"aead/etm.lisp"
"aead/gcm.lisp"
"public-key/public-key.lisp"
"public-key/curve25519.lisp"
"public-key/curve448.lisp"
"public-key/dsa.lisp"
"public-key/ed25519.lisp"
"public-key/ed448.lisp"
"public-key/elgamal.lisp"
"public-key/pkcs1.lisp"
"public-key/rsa.lisp"
feat(nix/buildLisp): add ecl Adds ECL as a second supported implementation, specifically a statically linked ECL. This is interesting because we can create statically linked binaries, but has a few drawbacks which doesn't make it generally useful: * Loading things is very slow: The statically linked ECL only has byte compilation available, so when we do load things or use the REPL it is significantly worse than with e. g. SBCL. * We can't load shared objects via the FFI since ECL's dffi is not available when linked statically. This means that as it stands, we can't build a statically linked //web/panettone for example. Since ECL is quite slow anyways, I think these drawbacks are worth it since the biggest reason for using ECL would be to get a statically linked binary. If we change our minds, it shouldn't be too hard to provide ecl-static and ecl-dynamic as separate implementations. ECL is LGPL and some libraries it uses as part of its runtime are as well. I've outlined in the ecl-static overlay why this should be of no concern in the context of depot even though we are statically linking. Currently everything is building except projects that are using cffi to load shared libaries which have gotten an appropriate `badImplementations` entry. To get the rest building the following changes were made: * Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now use `bundled "asdf"` for all implementations except SBCL. From my testing, SBCL seems to be the only implementation to support using `(require 'uiop)` to only load the UIOP package. Where both a dependency on ASDF and UIOP exists, we just delete the UIOP one. `(require 'asdf)` always causes UIOP to be available. * Where appropriate only conditionally compile SBCL-specific code and if any build the corresponding files for ECL. * //lisp/klatre: Use the standard condition parse-error for all implementations except SBCL in try-parse-integer. * //3p/lisp/ironclad: disable SBCL assembly optimization hack for all other platforms as it may interfere with compilation. * //3p/lisp/trivial-mimes: prevent call to asdf function by substituting it out of the source since it always errors out in ECL and we hardcode the correct path elsewhere anyways. As it stands ECL still suffers from a very weird problem which happens when compiling postmodern and moptilities: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651 Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> Reviewed-by: eta <tvl@eta.st>
2021-08-09 02:47:07 +02:00
];
feat(3p/lisp): Add ironclad Add ironclad, a common lisp library for cryptography. This is a huge library with a lot of moving parts - probably most notable here is that I've had to turn off compiling with `:ironclad-assembly`, as it was causing an infinite loop in the compiler due to https://github.com/sharplispers/ironclad/blob/master/src/opt/sbcl/cpu-features.lisp#L9-L10, a mutually self-recursive function that looks like: (defun aes-ni-support-p () (aes-ni-support-p)) Without knowing much about how sbcl handles native-compiled assembly, it seems like this definition should actually be skipped entirely, due to it being defined as a `defknown` in `fndb.lisp`: (defknown ironclad::aes-ni-support-p () (boolean) (any) :overwrite-fndb-silently t) But something about how we're compiling things was causing that not to happen, and the infinite recursion caused the compiler to hang. This should be fixed at some point, but given I only need this library as a transitive dependency down a level I'm not going to attempt to do so now. Change-Id: Id768717991404f959b003c7e2f28f1f4d532b94b Reviewed-on: https://cl.tvl.fyi/c/depot/+/1333 Tested-by: BuildkiteCI Reviewed-by: kanepyork <rikingcoding@gmail.com>
2020-07-21 20:29:58 +02:00
}
Reference in a new issue Copy permalink