nixpkgs-crate-holes can build a markdown report detailing all vulnerable
crates pinned in cargoDeps vendors in nixpkgs according to RustSec's
advisory db. This report is intended to be pasted into a GitHub issue.
The report is produced by a derivation and can be obtained like this:
nix-build -A users.sterni.nixpkgs-crate-holes.full \
--argstr nixpkgsPath /path/to/nixpkgs
Example output: https://gist.github.com/sternenseemann/27509eece93d6eff35cd4b8ce75423b5
Additionally, you can obtain a more verbose report for a single
attribute of nixpkgs, in HTML format since we just reuse the command
line output of cargo-audit and convert it to HTML using ansi2html:
nix-build -A users.sterni.nixpkgs-crate-holes.single \
--argstr nixpkgsPath /path/to/nixpkgs --argstr attr ripgrep
Change-Id: Ic1c029ab67770fc41ba521b2acb798628357f9b2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3715
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
For now mblog only contains the mnote-html executable which takes a mime
message from a maildir and prints the equivalent HTML fragment to
stdout. It is intended to work with the mblaze(7) utilities,
i. e. mnote-html resolves all `object` tags to proper `img` inclusions
with the correct filename, so mshow(1)'s -x version can supply the
needed image files. A note created using Apple's Notes app (tested with
the iOS version) can be converted in a viewable HTML file like this:
$ mnote-html path/to/msg > fragment.html
$ mshow -x path/to/msg
$ cat <(echo "<!DOCTYPE html>") fragment.html > document.html
$ xdg-open document.html
Note that only the limited feature set of Apple Notes when using the
IMAP backend is supported. The iCloud-based one has more (quite neat)
features, but its notes can only accessed via an internal API as far as
I know.
This CLI is a bit impractical due to the big startup overhead of loading
the lisp image. mblog should be become a fully fletched static site
generator in the future, but this is a good starting point and providing
the mnote-html tool is certainly useful.
Change-Id: Iee6d1558e939b932da1e70ca2d2ae75638d855df
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3271
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This is mostly to yet another silly idea which turns out to be
possible. This may be actually useful should I implement more
sophisticated format specifiers like "%xd" or "%f".
Change-Id: Ia56cd6f5793a09fe5e19c91a8e8f9098f3244d57
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3537
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Since //web/bubblegum depends on nint, we need to move it to a non user
directory to conform with the policy established via cl/3434.
Note that this likely doesn't mean greater stability (which isn't
really implied in depot anyways), since I still would like to use a more
elaborate calling convention to allow for additional useful features.
Change-Id: I616f905d8df13e3363674aab69a797b0d39fdd79
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3506
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This allows me to add stuff without doing a commit for every feed. I can
always import them in bunches if I want to later.
Change-Id: I080f40b3627940a1f68cf13598c102953f4994b1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3505
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This lets us benefit from the recent OpenSSL security-related
update [1]. Since nixos-unstable is still stuck, we temporarily
use nixos-unstable-small as our unstable channel.
Fixes necessary:
* //users/sterni/nix/char:
Someone has decided to drop writers.writeC upstream [2],
so we reimplement it ad-hoc using runCommandCC
[1]: https://www.openssl.org/news/secadv/20210824.txt
[2]: 982f46985e
Change-Id: Id84756e2e370296b7a27e1a3f1744f58f8fe3c47
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3463
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
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>
I think it’s solid enough to use in a wider context.
Change-Id: If53e8bbb6b90fa88d73fb42730db470e822ea182
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3055
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: lukegb <lukegb@tvl.fyi>
As a complementation to builtins.functionArgs this function checks if
the function has a set pattern that contains an ellipsis
(i. e. `{ [arg, [ arg1, [ … ]]] ... }:`). The implementation of this is
pretty cursed however since there is no clean way to do this in vanilla
nix: We need to match on the output of builtins.toXML which does try to
serialize functions by outputting their argument and information about
it (whether it is a normal argument or a attribute set pattern, in the
latter case it also serialize every component of the pattern).
Change-Id: I0f33721811a3180cec205a0c98e6d92e10e92075
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2950
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This should ease migrating to a distinction between depot.third_party
and pkgs (as in nixpkgs) in the future.
Ref cl/2910, b/108.
Change-Id: I53a854071fddd7c0d0526cc4c5b16998202082c6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2913
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Profpatsch and me are basically the only users of
depot.users.Profpatsch.writers.rustSimple*. To pull in the odd
dependency we usually use buildRustCrate which is rather convenient.
However we've picked up the bad habit of inlining these in a let
somewhere instead of managing them in a more central location although
there has been an (unsuccesful) attempt at this in
//users/Profpatsch/rust-crates.nix.
This CL moves all buildRustCrate based derivations into
third_party.rust-crates and deletes any duplicate derivations we have
accumulated in the tree.
Change-Id: I8f68b95ebd546708e9af07dca36d72dba9ca8c77
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2769
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: Profpatsch <mail@profpatsch.de>
More or less direct port of https://dotti.me to mdoc(7) with the
following changes:
* Add a RFC3339 column to the EXAMPLES table. RFC3339 is a well
specified subset of ISO8601 whose specification is also more
accessible so this could help someone out.
* Add a SEE ALSO section linking to the web site
* Add an AUTHORS section
Change-Id: I8db00bd402697aa52f6f651f28692617b487f832
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2642
Tested-by: BuildkiteCI
Reviewed-by: edef <edef@edef.eu>
nint (short for nix interpreter) is a tiny wrapper around nix-instantiate
which allows to run nix scripts, i. e. nix expressions that conform to
a certain calling convention. A nix script runnable using nint must
conform to the following constraints:
* It must evaluate to a function which has a set pattern with an
ellipsis as the single argument.
* It must produce a string as a return value or fail.
When invoked, a the expression receives the following arguments:
* `currentDir`: the current working directory as a nix path
* `argv`: a list of strings containing `argv` including `argv[0]`
* extra arguments which are manually specified which allows for
passing along dependencies or libraries, for example:
nint --arg depot '(import /depot {})' my-prog.nix [ argv[1] … ]
would pass along depot to be used in `my-prog.nix`.
Such nix scripts are purely functional in a sense: The way inputs can be
taken is very limited and causing effects is also only possible in a
very limited sense (using builtins.fetchurl if TARBALL_TTL is 0,
adding files and directories to the nix store, realising derivations).
As an approximation, a program executed using nint can be thought of
as a function with the following signature:
λ :: environment → working directory → argv → stdout
where environment includes:
* the time at the start of the program (`builtins.currentTime`)
* other information about the machine (`builtins.currentSystem` …)
* environment variables (`builtins.getEnv`)
* the file system (`builtins.readDir`, `builtins.readFile`, …) which
is the biggest input impurity as it may change during evaluation
Additionally import from derivation and builtin fetchers are available
which introduce further impurities to be utilized.
Future work:
* Streaming I/O via lazy lists. This would allow usage of
stdin and output before the program terminates. However this would
require using libexpr directly or writing a custom nix interpreter.
A description of how this would work can be found on the website of the
esoteric programming language Lazy K: https://tromp.github.io/cl/lazy-k.html
* An effect system beyond stdin / stdout.
* Better error handling, support setting exit codes etc.
These features would require either using an alternative or custom
interpreter for nix (tvix or hnix) or to link against libexpr directly
to have more control over evaluation.
Change-Id: I61528516eb418740df355852f23425acc4d0656a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2745
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
We use builtins.split directly as it should be a bit more efficient as
lib.splitStrings. Also its returning of a list for every regex match is
useful to update the state while parsing the tokens:
* The tokens are obtained by splitting the string at every '%'
* Everytime we see a boundary (that is a list in the returned
list of builtins.split), we know that the first two chars of
the next string are a percent encoded character.
One implementation flaw is that it will currently crash if it encounters
mal-formed URLs (since int.fromHex chrashes if it encounters any non
hex digit characters) and accepts some malformed urlencoding like
"foo %A".
Change-Id: I90d08d7a71b16b4f4a4879214abd7aeff46c20c8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2744
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
We make use of the -O man=… option of mandoc(1) which allows to convert
cross references via the .Xr macro into actual hyperlinks in the output.
This can be disabled (by passing "none") or done in two modes:
* all: links all .Xr cross references as if they were in
$out/%N.%S.html. This will lead to broken links of course.
* inManDir: only link to files in $out if the man page is found in
manDir, use the template defined in linkXrFallback if not.
all is the default, since we don't require all man pages to be in
manDir, so it would be potentially confusing if the path attribute was
used in the pages list.
linkXrFallback uses the debian online man viewer by default currently,
since it can be decently hyperlinked and debian has a lot of packages.
Other options would be:
* https://manpages.ubuntu.com/manpages/latest/en/man%S/%N.%S.html
* https://man.archlinux.org/man/%N.%S.en
* https://man.openbsd.org/%N.%S
* https://www.man7.org/linux/man-pages/man%S/%N.%S.html
Change-Id: I1363b9dfdda25cb7383c7310b8115c335444bd3d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2597
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
htmlman is a very simple nix based static site generator which is
intended for rendering HTML representations for man pages plus an index
page listing all available pages. For the sake of simplicity (and unlike
previous iterations of this piece of code) other documentation artifacts
and formats are not supported.
Usually web services like GitHub and depot's web interface are pretty
good at displaying "normal" documentation artifacts like markdown files,
but man pages are usually not rendered — with the additional problem
that it's source is virtually unreadable. htmlman should provide a
simple static site generator which can be plugged into GitHub actions or
the like to automatically generate rendered version of man pages tracked
in version control.
Change-Id: Ib53292964b3ff84c32d70c5fde257a2edb8c2122
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2596
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: Profpatsch <mail@profpatsch.de>
Reviewed-by: sterni <sternenseemann@systemli.org>
users.sterni.nix.utf8 implements UTF-8 decoding in pure nix. We
implement the decoding as a simple state machine which is fed one byte
at a time. Decoding whole strings is possible by subsequently calling
step. This is done in decode which uses builtins.foldl' to get around
recursion restrictions and a neat trick using builtins.deepSeq puck
showed me limiting the size of the thunks in a foldl' (which can also
cause a stack overflow).
This makes decoding arbitrarily large UTF-8 files into codepoints using
nix theoretically possible, but it is not really practical: Decoding a
36KB LaTeX file I had lying around takes ~160s on my laptop.
Change-Id: Iab8c973dac89074ec280b4880a7408e0b3d19bc7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2590
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
switch would probably otherwise be called match, but has been renamed so
it isn't confused with string.match and the enum matching capabilities
yants has.
It implements the closest to pattern matching nix can come which is
still flexible enough to not be painful: Syntactically it works like
cond, but is given a value. Instead of booleans it checks passed
predicates or equality if simple values are passed. Both types of checks
can be mixed.
Change-Id: I40f000979cfd469316e15fd58d6c3a80312c1cc4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2589
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Since nix ends the substring at the end of the string anyways we can
just statically use the largest nix integer as the length of the string.
According to my testing this it ever so slightly faster as well.
Change-Id: I64566e91c7b223f03dcebe3bc5710696dc4261bc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2587
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
After all it only matches strings.
Change-Id: I3d2e5221ef43f692de69028e78ed98b6b11f82d1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2586
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
What you see here is mostly the fallout of me implementing a correct
urlencode implementation in nix for Profpatsch's blog implementation
(although they'll probably keep it at arm's length).
Where I want to go from here:
* Extend this library towards general purpose nix™, mainly by
implementing missing interfaces which you'd still have to use
<nixpkgs/lib> for right now. Reexposing parts of <nixpkgs/lib>
with better naming is fine for now, at some point I'd contemplate
making this depend on nothing outside of depot, maybe even itself
(should be easy we only use yants for an easily replaceable check).
* Improve error messages possibly by carefully reintroducing yants. I
originally typed essentially everything using yants, but turns out
this can a) be dangerous when stuff you are handling throws because
type checking means evaluating and b) has a incredible performance
cost in some cases.
* Reexpose builtins with better naming and slightly wrapped so they
don't unrecoverably throw in cases where a null or something would
suffice.
Change-Id: I33ab08ca4e62dbc16b86c66c653935686e6b0e79
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2541
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: Profpatsch <mail@profpatsch.de>
Tested-by: BuildkiteCI
This way ci should pick up on clhs-lookup since only a single derivation
is exposed with the default.nix and it is less cumbersome to type the
attribute path (users.sterni.clhs.clhs-lookup →
users.sterni.clhs-lookup). The exposed CLHS wasn't used for anything
anyways and I can always expose it again using passthru or extra if it's
ever merged.
Change-Id: I6c5aeba1b58ca650700c6efa0913e4b42685ea6b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2461
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Probably very similar to M-x sly-hyperspec-lookup: take a list of
common lisp symbols on the command line open the corresponding pages
in a local copy of the hyperspec in $BROWSER. Optionally the paths can
be printed to stdout.
Change-Id: I389e254f14eb0fc8fd8b18a4dbfe7adeeda9ba72
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2397
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
