Please report potential security issues with the compiler or web site to firstname.lastname@example.org and email@example.com .
Sensitive reports may be encrypted with the PGP key listed below.
Fennel releases and tags are signed with the PGP key 9D13D9426A0814B3373CF5E3D8A8243577A7859F.txt . Before that the keys 6A2D483DB59437EBB97D09B1040193357D0606ED 8F2C85FFC1EBC016A3B683DE8BD38C28CCFD2DA6 and 20242BACBBE95ADA22D0AFD7808A33D379C806C3 was used.
curl https://technomancy.us/9D13D9426A0814B3373CF5E3D8A8243577A7859F.txt | gpg --import -
$ gpg --verify fennel-1.4.1.asc
From 1.0 onwards, releases are also signed with
.sig files using SSH keys:
$ curl -O allowed https://fennel-lang.org/downloads/allowed_signers
$ ssh-keygen -Y verify -f allowed -I firstname.lastname@example.org -n file -s fennel-1.4.1.sig < fennel-1.4.1
You can compare the key in the allowed_signers file with the keys published at technomancy.us Sourcehut and Github .
In versions from 1.0.0 to 1.3.1, it was possible for code running in the compiler sandbox to call un-sandboxed functions from applications or Fennel libraries when running with metadata enabled. This could result in RCE when evaluating untrusted code in a way that relied on the sandbox for services running with metadata enabled.
In addition, even when metadata was disabled, it was still possible for sandboxed code to trigger loading of a module already on the load path. In most cases if an attacker can get a file on the load-path then they've already won, but in the context of tools that run static analysis on untrusted code, this could result in a vulnerability.
Versions prior to 1.0.0 did not sandbox macros.