Security

Please report potential security issues with the compiler or web site to phil@hagelb.org and jaawerth@gmail.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.

To verify:

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 phil@hagelb.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 .

Historical Issues

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.