fidzu : debian

pre-commit is a tool that is often a prerequisite for contributing to Python upstream projects. It installs as a git pre-commit hook and runs various checks on commit, using tools installed in a set of virtualenvs that it automatically manages.

In other words, it is a Remote Code Execution engine running with the permissions of your own user, and with read and write access to all your information (including, say, ~/.ssh or ~/.netrc). If you are lucky, and for as long as you're lucky, it will perform useful tasks on your code.

The recent eMudhra certificate situation, where I learnt how Python, as well as several other ecosystems, likes to embed CA certificate bundles in virtualenvs, caused my tolerance for this to lower to a point where I felt the need to limit pre-commit's reach.

However, I didn't want to end up with another containerized OS tree that it's then my responsibility to manage, and I tried to go the bubblewrap way, so that the environment where pre-commit runs will get the same security updates as the rest of my system.

The result is a pre-commit wrapper script that:

• Runs in a private filesystem, with no access to user's files or system configuration
• Runs in a filesystem where everything is read-only, except for the git working directory
• Even the .git directory is readonly, so that changes in the code can be reliably detected via git diff
• Runs without network unless explicitly requested by the user

Here's a breakdown of the bwrap options I used so far.

Set up usual filesystem expectations:

    --ro-bind /usr /usr \
    --symlink usr/bin /bin \
    --symlink usr/lib64 /lib64 \
    --symlink usr/lib /lib \
    --proc /proc \
    --dev /dev \

Make the working directory and pre-commit's environments storage available and writable:

    --bind ${CURDIR} "$GUEST_DIR" \
    --bind ~/.cache/pre-commit "/home/${USER}/.cache/pre-commit" \
    --chdir "$GUEST_DIR" \

Forward git's configuration:

    --ro-bind /etc/gitconfig /etc/gitconfig \
    --ro-bind ~/.gitconfig /home/${USER}/.gitconfig \

Make .git writable (pre-commit needs to stash, for example), but use a tmpfs overlay so that the writes don't persist:

    --overlay-src "$CURDIR/.git" \
    --tmp-overlay "$GUEST_DIR/.git" \

Remove access to everything except the above. Prevent keystroke injection at the terminal. Propagate ^C.

    --unshare-all \
    --new-session \
    --die-with-parent

If network is needed:

    --share-net \
    --ro-bind /etc/resolv.conf /etc/resolv.conf \
    --ro-bind /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt

To run it, you can set up the wrapper script to run with a higher priority in $PATH, but you need to edit .git/hooks/pre-commit to remove the first branch of the if that, frustratingly, tries to run it as python3 -m pre_commit.

I'm looking forward to a time where it becomes stadard practice to manage user commands this way: why should a desktop solitaire game have access to ~/.ssh? Or network? Why is it still normal, in 2026, to run a Desktop system like that?

26 Oct 2026 5:36pm GMT

In discussion about my post on banks and phones [1] questions were asked about CEO impersonation (link to an article on the security blog Krebs on Security about it) [2].

CEO fraud (or more generally executive fraud) is a subset of Business Email Compromise fraud which allegedly loses Australian businesses $84M/year [3]. The numbers vary a lot depending on what is counted, is it just attacks where money is lost or do situations where the bank reverses the transaction count? There's a lot of secrecy around this because of reputation issues related to fraud, a company that gets defrauded might be regarded as an unreliable business partner. Also in terms of interpreting results there are organisations that want to promote the idea that "it's a major crime that could cost you everything unless you pay us to improve your security".

My experience of these things is that at one company I worked for someone had gained access to an executive mailbox and setup rules to move mail from certain senders to a mailbox that wouldn't be checked (maybe .Sent or .Spam or something - I can't remember the details) as well as forwarding it to an address the attacker controlled. That meant that the executive wouldn't see email from the scam targets while the email gets forwarded to the attackers. At the time it appeared that Office 365 didn't have any features for sending automatic audit alerts for such changes. I think that all changes to executive email accounts should trigger alerts to the corporate security team (in that case me). One would hope that such exploitation would be a major wake-up call for the company but it wasn't. It was never discovered how the attacker got access to the account, I presume it was by compromising a personal computer of the executive which they used for company purposes. Having a strong separation of hardware used for work and hardware for personal use is a really good thing.

At the same company every time the CEO went on a scheduled trip there would be email sent impersonating him claiming that money needed to be transferred. It was never discovered how the attackers knew when he was on a trip. Was the CEO telling people on LinkedIn about his plans or something? Was his calendar shared to someone outside the company? Was there an employee leaking information? We never found out and surprisingly the executive team didn't think this was a problem. It's not necessarily bad for the CEO to publicise their trips even if that alerts hostile parties, but everyone needs to know what the situation is. An unexplained attack is more concerning than a known attack that can be predicted and dealt with.

The role of CEO has a unique combination of being able to authorise funds transfers while also being able to reject other security methods. You can tell a line manager that they need to follow the process for a $10 purchase but you can't necessarily tell the CEO that they need to follow the process for $100,000. Even if the CEO always follows the process for funds transfers you have to convince all the people involved in funds transfers that the CEO will follow the process and any unexpected email demanding an immediate transfer should be rejected.

A final problem is getting executives to understand the importance of computer security. My experience is that getting a CTO to adhere to good security practices can be a challenge and that even on the rare occasions someone like me gets to communicate with the CEO it's not possible to convince them to change anything.

Most computer security problems end up as people problems.

• [1] https://etbe.coker.com.au/2026/10/25/banks-phones/
• [2] https://tinyurl.com/j3byjek
• [3] https://ezyshield.com.au/threats/ceo-fraud/

26 Oct 2026 4:09am GMT

Debcraft is a tool that automates most of the repetitive and error-prone steps related to Debian packaging. It makes it easy to build .deb packages from source without having to manually prepare build environments. It clearly shows what changed in the build artifacts between two builds, automates parts of importing new upstream versions, and can automatically apply repetitive fixes to the packaging source code, including committing them in git.

While doing all of this, it also explains what it does and helps users learn best practices in Debian packaging, making the overall experience much easier and more fun than with any other tool before, while also being secure and fast.

Try out Debcraft 1.0 now!

Debcraft can be installed simply by running apt install debcraft on a recent version of Debian or Ubuntu. Check with debcraft --version that you have 1.0.0 or newer. The latest version can also always be installed from source at salsa.debian.org/debian/debcraft (does not require compiling anything).

Benefits

Debcraft was designed to offer the following three main benefits:

Easy

• Build any Debian/Ubuntu package by simply running debcraft build in the checked-out Debian packaging git repository.

• If the orig upstream source code tarball is neither already present nor available on a pristine-tar branch, the exact upstream tarball is downloaded from the Debian archive.

• Users are spared from having to manually prepare ahead or maintain build environments. Debcraft builds create a container on-the-fly (both Podman and Docker supported), built using the target Debian or Ubuntu suite in debian/changelog and with exact build dependencies from debian/control.

• Commands debcraft improve, debcraft test and debcraft update automate recurring package maintenance tasks and help maintainers produce high-quality, up-to-date packages, run Salsa CI, pass autopkgtest in Debian CI, and stay in sync across Debian archives and packaging git repositories.

• The command output is (relatively) easy to read, and it also teaches users about Debian packaging in context.

Fast

• Container layer caching is utilized to make builds and re-builds blazingly fast.

• If an apt-cacher-ng instance or equivalent is present, it will automatically be used.

• Debian packages that support ccache or sccache build even faster.

Secure

• The build phase happens inside hermetic containers with no network access. This ensures all dependencies are properly managed and that the built binaries are as trustworthy as the source code they were built from.

• Using containers also protects the host system from getting polluted with extra development libraries, and adds an extra layer of protection to prevent anything malicious in the source code from accessing secrets on the host system.

• The additional logs provided by Debcraft also help audit changes in Debian package sources and build artifacts.

See the Debcraft README.md for details on how this was implemented. I also previously wrote Debcraft - Easiest way to modify and build Debian packages, which explains the motivation and design in more detail.

Result of many years of development

The first commit in the git repository is from 2020 under the name debuildr. The project was renamed to Debcraft in a commit on December 8th, 2023. I have been developing this tool fairly actively since 2024 and using it for all my packaging, "dogfooding" so to say.

There have also been plenty of collaborators. In total, 13 people have contributed code across 21 MRs and PRs on Salsa.d.o, GitLab.com and GitHub.com.

Now, in October 2026, it was time to release Debcraft v1.0 as it has had extensive real-world use and iteration based on countless different packages and multiple users. Users have included both experienced fellow Debian Developers and lots of people who just started learning how Debian packaging works. As I mentor dozens of new contributors to Debian, I have seen that the latter group seems to benefit the most from Debcraft and its ease of use and built-in guidance, while to the more experienced developers the main benefit is having less details to remember and doing less mistakes.

Contributions welcome!

Try it: apt install debcraft, then run debcraft build in a checked-out Debian packaging repository. If you run into a problem, file a report or submit an improvement. New contributors can look for issues marked good first issue.

The code is intentionally written entirely in shell script to keep the barrier to code contribution as low as possible. It is also very easy to debug, as any command can be run with --debug to emit step-by-step information about what it is doing, and being Bash scripts, injecting set -x anywhere in the code will emit an even more detailed trace of every subcommand executed.

By the way, if you aspire to become a Debian Developer, and want to follow my examples in using state-of-the-art tooling and collaborate using salsa.debian.org, feel free to reach out for mentorship. I am glad to see more people contribute to Debian!

26 Oct 2026 12:00am GMT