💾 Archived View for perso.pw › blog › rss.xml captured on 2024-07-09 at 01:32:48.
⬅️ Previous capture (2024-06-19)
-=-=-=-=-=-=-
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Solene'%</title>
<description></description>
<link>gemini://perso.pw/blog/</link>
<atom:link href="gemini://perso.pw/blog/rss.xml" rel="self" type="application/rss+xml" />
<item>
<title>WireGuard and Linux network namespaces</title>
<description>
<![CDATA[
<pre># Introduction
This guide explains how to setup a WireGuard tunnel on Linux using a dedicated network namespace so you can choose to run a program on the VPN or over clearnet.
I have been able to figure the setup thanks to the following blog post, I enhanced it a bit using scripts and sudo rules.
=> https://www.ismailzai.com/blog/creating-wireguard-jails-with-linux-network-namespaces Mo Ismailzai's blog: Creating WireGuard jails with Linux network namespaces
# Explanations
By default, if you connect WireGuard tunnel, its "allowedIps" field will be used as a route with a higher priority than your current default route. It is not always ideal to have everything routed through a VPN, so you will create a dedicated network namespace that uses the VPN as a default route, without affecting all other software.
Unfortunately, compared to OpenBSD rdomain (which provide the same features in this situation), network namespaces are much more complicated to deal with and requires root to run a program under a namespace.
You will create a SAFE sudo rule to allow your user to run commands under the new namespace, making it more practical for daily use.
# Setup
## VPN tunnel and namespace
You need a wg-quick compatible WireGuard configuration file, but do not make it automatically used at boot.
Create a script (for root use only) with the following content, then make it executable:
CONFIG=/etc/wireguard/my-vpn.conf
mkdir -p /etc/netns/vpn/
ip netns exec vpn ip l del tun0
ip netns del vpn
DNS=$(awk '/^DNS/ { print $3 }' $CONFIG)
IP=$(awk '/^Address/ { print $3 }' $CONFIG)
echo "nameserver $DNS" > /etc/netns/vpn/resolv.conf
ip netns add vpn
ip -n vpn link set lo up
ip link add tun0 type wireguard
ip link set tun0 netns vpn
ip netns exec vpn wg setconf tun0 <(wg-quick strip "$CONFIG")
ip -n vpn a add "$IP" dev tun0
ip -n vpn link set tun0 up
ip -n vpn route add default dev tun0
ip -n vpn add
This script autoconfigure the network namespace and the VPN interface + the DNS server to use. There are extra checks at the end of the script that you can uncomment if you want to take a look at the public IP and DNS resolver used just after connection. Running this script will make the netns "vpn" available for use. The command to run a program under the namespace is `ip netns exec vpn your command`, it can only be run as root. ## Sudo rule Now you need a specific rule so you can use sudo to run a command in vpn netns as your own user without having to log in as root. Add this to your sudo configuration file, in my example I allow the user `solene` to run commands as `solene` for the netns vpn:
solene ALL=(root) NOPASSWD: /usr/sbin/ip netns exec vpn /usr/bin/sudo -u solene -- *
When using this command line, you MUST use full paths exactly as in the sudo configuration file, this is important otherwise it would allow you to create a script called `ip` with whatever commands and run it as root, while `/usr/sbin/ip` can not be spoofed by a local script in $PATH. If I want a shell session with the VPN, I can run the following command:
sudo /usr/sbin/ip netns exec vpn /usr/bin/sudo -u solene -- bash
This runs bash under the netns vpn, so any command I'm running from it will be using the VPN.
# Limitations
It is not a real limitation, but you may be caught by it, if you make a program listening on localhost in the netns vpn, you can only connect to it from another program in the same namespace. There are methods to connect two namespaces, but I do not plan to cover it, if you need to search about this setup, it can be done using socat (this is explained in the blog post linked earlier) or a local bridge interface.
# Conclusion
Network namespaces are a cool feature on Linux, but it is overly complicated in my opinion, unfortunately I have to deal with it, but at least it is working fine in practice.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/linux-vpn-netns.gmi</guid>
<link>gemini://perso.pw/blog//articles/linux-vpn-netns.gmi</link>
<pubDate>Thu, 04 Jul 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>The Old Computer Challenge v4 (Olympics edition)</title>
<description>
<![CDATA[
<pre># Introduction
This is the time of the year where I announce the Old Computer Challenge (OCC) date.
I recommend visiting the community website about the OCC if you want to connect with the community.
=> https://occ.deadnet.se/ Old Computer Challenge community
=> https://dataswamp.org/~solene/tag-oldcomputerchallenge.html The Old Computer Challenge history
=> static/occ-v4.jpg The Old Computer Challenge v4 poster, by @prahou@merveilles.town on Mastodon
# When?
The Old Computer Challenge 4th edition will begin 13th July to 20th July 2024. It will be the prequel to Olympics, I was not able to get the challenge accepted there so we will do it our way.
# How to participate?
While the three previous editions had different rules, I came to agree with the community for this year. Choose your rules!
When I did the challenge for the first time, I did not expect it to become a yearly event nor that it would gather aficionados during the trip. The original point of the challenge was just to see if I could use my oldest laptop as my main computer for a week, there were no incentive, it was not a contest and I did not have any written rules.
Previous editions rules were about using an old laptop, use a computer with limited hardware (and tips to slow down a modern machine) or limit Internet access to a single hour per day. I always insist on the fact it should not hinder your job, so people participating do not have to "play" during work. Smartphones became complicated to handle, especially with the limited Internet access, all I can recommend to people is to define some rules you want to stick to, and apply to it the best you can. If you realllyyyy need once to use a device that would break the rules, so be it if it is really important, nobody will yell at you.
People doing the OCC enjoy it for multiple reasons, find yours! Some find the opportunity to disconnect a bit, change their habit, do some technoarcheology to run rare hardware, play with low-tech, demonstrate obsolescence is not a fatality etc...
Some ideas if you do not know what to do for the challenge:
vnconfig vnd0 /path/to/file.iso
This will create a new device `/dev/vnd0`, now you can mount it on your file-system with:
mount -t cd9660 /dev/vnd0c /mnt
You should be able to browser your iso file content in /mnt at this point. # Unmounting If you are done with the file, you have to umount it with `umount /mnt` and destroy the vnd device using `vnconfig -u vnd0`. # Going further: Using a file as an encrypted disk If you want to use a single file as a file system, you have to provision the file with disk space using the command `dd`, you can fill it with zeroes but if you plan to use encryption on top of it, it's better to use random data. In the following example, you will create a file `my-disk.img` of a size of 10 GB (1000 x 10 MB):
dd if=/dev/random of=my-disk.img bs=10M count=1000
Now you can use vnconfig to expose it as a device:
vnconfig vnd0 my-disk.img
Finally, the command `bioctl` can be used to configure encryption on the disk, `disklabel` to partition it and `newfs` to format the partitions. You can follow OpenBSD FAQ guides, make sure use the the device name `/dev/vnd0` instead of wd0 or sd0 from the examples.
=> https://www.openbsd.org/faq/faq14.html#softraidCrypto OpenBSD FAQ: Encrypting external disk
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/mount-iso-file-openbsd.gmi</guid>
<link>gemini://perso.pw/blog//articles/mount-iso-file-openbsd.gmi</link>
<pubDate>Tue, 18 Jun 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>OpenBSD extreme privacy setup</title>
<description>
<![CDATA[
<pre># Introduction
This blog post explains how to configure an OpenBSD workstation with extreme privacy in mind.
This is an attempt to turn OpenBSD into a Whonix or Tails alternative, although if you really need that level of privacy, use a system from this list and not the present guide. It is easy to spot OpenBSD using network fingerprinting, this can not be defeated, you can not hide the fact you use OpenBSD to network operators.
I did this guide as a challenge for fun, but I also know some users have a use for this level of privacy.
Note: this guide explains steps related to increase privacy of OpenBSD and its base system, it will not explain how to configure a web browser or how to choose a VPN.
# Checklist
OpenBSD does not have much network activity with a default installation, but the following programs generate traffic:
127.0.0.9 firmware.openbsd.org
## Packages, firmware and mirrors The firmware installation and OpenBSD mirror configuration using Tor and I2P are covered in my previous article, it explains how to use tor or i2p to download firmware, packages and system sets to upgrade. => https://dataswamp.org/~solene/2024-05-25-openbsd-privacy-friendly-mirror.html OpenBSD privacy-friendly mirrors There is a chicken / egg issue with this though, on a fresh install you have neither tor nor i2p, so you can not download tor or i2p packages through it. You could download the packages and their dependencies from another system and install them locally using USB. Wi-Fi and some other devices requiring a firmware may not work until you run fw_update, you may have to download the files from another system and pass the network interface firmware over a USB memory stick to get network. A smartphone with USB tethering is also a practical approach for downloading firmware, but you will have to download it over clearnet. ## DNS DNS is a huge topic for privacy-oriented users, I can not really recommend a given public DNS servers because they all have pros and cons, I will use 1.1.1.1 and 9.9.9.9 for the example, but use your favorite DNS. Enable the daemon unwind, it is a local DNS resolver with some cache, and supports DoT, DoH and many cool features. Edit the file `/etc/unwind.conf` with this configuration:
forwarder { 1.1.1.1 9.9.9.9 }
As I said, DoT and DoH is supported, you can configure it directly in the forwarder block, the man page explains the syntax: => https://man.openbsd.org/unwind.conf OpenBSD manual pages: unwind.conf Now, enable, start and make sure the service is running fine:
rcctl enable unwind
rcctl start unwind
rcctl check unwind
A program named `resolvd` is running by default, when it finds that unwind is running, resolvd modifies `/etc/resolv.conf` to switch DNS resolution to 127.0.0.1, so you do not have anything to do. ## Firewall configuration A sane firewall configuration for workstations is to block all incoming connections. This can be achieved with the following `/etc/pf.conf`: (reminder, last rule matches)
set block-policy drop
set skip on lo
match in all scrub (no-df random-id max-mss 1440)
antispoof quick for egress
block
pass out quick inet
pass out quick inet6
pass in proto icmp
Reload the rules with `pfctl -f /etc/pf.conf`. ## Network configuration Everything is ready so you can finally enable networking. You can find a list of network interfaces with `ifconfig`. Create the hostname.if file for your network device. => https://man.openbsd.org/hostname.if OpenBSD manual pages: hostname.if An ethernet device configuration using DHCP would look like this
inet autoconf
A wireless device configuration would look like this:
join SSID_NAME wpakey password1
join OTHER_NET wpakey hunter2
inet autoconf
You can randomize your network device MAC address at each boot by adding the line `lladdr random` to its configuration file. Start the network with `sh /etc/netstart ifname`. # Special attention during updates When you upgrade your OpenBSD system from a release to another or to a newer snapshot using `sysupgrade`, the command `fw_update` will automatically be run at the very end of the installer. It will bypass any `/etc/hosts` changes as it runs from a mini root filesystem, if you do not want `fw_update` to be used over clearnet at this step, the only method is to disable network at this step, which can be done by using `sysupgrade -n` to prepare the upgrade without rebooting, and then:
mv /etc/hostname.* /root/
sysupgrade -n
echo 'mv /root/hostname.* /etc/' > /etc/rc.firsttime
echo 'sh /etc/netstart' >> /etc/rc.firsttime
chmod +x /etc/rc.firsttime
reboot
It will move all your network configuration in `/root/`, run sysupgrade, and configure the next boot to restore the hostname files back to place and start the network.
# Webcam and Microphone protection
By default, OpenBSD "filters" webcam and microphone use, if you try to use them, you get a video stream with a black background and no audio on the microphone. This is handled directly by the kernel and only root can change this behavior.
To toggle microphone recording, change the sysctl `kern.audio.record` to 1 or 0 (default).
To toggle webcam recording, change the sysctl `kern.video.record` to 1 or 0 (default).
What is cool with this mechanism is it makes software happy when they make webcam/microphone a requirement, they exist but just record nothing.
# Conclusion
Congratulations, you achieved a high privacy level with your OpenBSD installation! If you have money and enough trust in some commercial services, you could use a VPN instead (or as a base) of Tor/I2P, but it is not in the scope of this guide.
I did this guide after installing OpenBSD on a laptop connected to another laptop doing NAT and running Wireshark to see exactly what was leaking over the network. It was a fun experience.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/openbsd-privacy-setup.gmi</guid>
<link>gemini://perso.pw/blog//articles/openbsd-privacy-setup.gmi</link>
<pubDate>Mon, 10 Jun 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>OpenBSD mirror over Tor / I2P</title>
<description>
<![CDATA[
<pre># Introduction
For an upcoming privacy related article about OpenBSD I needed to setup an access to an OpenBSD mirror both from a Tor hidden service and I2P.
The server does not contain any data, it only act as a proxy fetch files from a random existing OpenBSD mirror, so it does not waste bandwidth mirroring everything, the server does not have the storage required anyway. There is a little cache to keep most requested files locally.
=> https://en.wikipedia.org/wiki/I2P Wikipedia page about I2P protocol
=> https://en.wikipedia.org/wiki/The_Tor_Project Wikipedia page about Tor
It is only useful if you can not reach OpenBSD mirrors, or if you really need to hide your network activity. Tor or I2P will be much slower than connecting to a mirror using HTTP(s).
However, as they exist now, let me explain how to start using them.
# Tor
Using a client with tor proxy enabled, you can reach the following address to download installers or sets.
=> http://kdzlr6wcf5d23chfdwvfwuzm6rstbpzzefkpozp7kjeugtpnrixldxqd.onion/pub/OpenBSD/ OpenBSD onion mirror over Tor
If you want to install or update your packages from tor, you can use the onion address in `/etc/installurl`. However, it will not work for sysupgrade and syspatch, and you need to export the variable `FETCH_CMD="/usr/local/bin/curl -L -s -q -N -x socks5h://127.0.0.1:9050"` in your environment to make `pkg_*` programs able to use the mirror.
To make sysupgrade or syspatch able to use the onion address, you need to have the program `torsocks` installed, and patch the script to use torsocks:
[MIRROR]
type = client
address = 127.0.0.1
port = 8080
destination = 2st32tfsqjnvnmnmy3e5o5y5hphtgt4b2letuebyv75ohn2w5umq.b32.i2p
destinationport = 8081
keys = mirror.dat
Now, enable and start i2pd with `rcctl enable i2pd && rcctl start i2pd`. After a few minutes to let i2pd establish tunnels, you should be able to browse the mirror over i2p using the address `http://127.0.0.1:8080/`. You can configure the port 8080 to another you prefer by modifying the file `tunnels.conf`. You can use the address `http://127.0.0.1:8080/pub/OpenBSD/` in `/etc/installurl` to automatically use the I2P mirror for installing/updating packages, or keeping your system up to date with syspatch/sysupgrade. Note: from experience the I2P mirror works fine to install packages, but did not play well with fw_update, syspatch and sysupgrade, maybe because they use ftp command that seems to easily drop the connection. Downloading the files locally using a proper HTTP client supporting transfer resume would be better. On the other hand, this issue may be related to the current attack the I2P network is facing as of the time of writing (May 2024). # Firmware mirror OpenBSD pulls firmware from a different server than the regular mirrors, the address is `http://firmware.openbsd.org/firmware/`, the files on this server are signed packages, they can be installed using `fw_update $file`. Both i2p and tor hidden service hostname can be reused, you only have to change `/pub/OpenBSD/` by `/firmware/` to browse the files. The proxy server does not cache any firmware, it directly proxy to the genuine firmware web server. They are on a separate server for legal matter, it seems to be a grey area. ## Disable firmware.openbsd.org For maximum privacy, you need to neutralize `firmware.openbsd.org` DNS lookup using a hosts entry. This is important because `fw_update` is automatically used after a system upgrade (as of 2024). In `/etc/hosts` add the line:
127.0.0.9 firmware.openbsd.org
The IP in the snippet above is not a mistake, it will avoid fw_update to try to connect to a local web server if any. ## Tor access If you use tor, it is complicated to patch `fw_update` to use torsocks, the best method is to download the firmware manually. => http://kdzlr6wcf5d23chfdwvfwuzm6rstbpzzefkpozp7kjeugtpnrixldxqd.onion/firmware/ Firmware onion address ## I2P access If you use i2p, you can reuse the tunnel configuration described in the I2P section, and pass the full url to `fw_update`:
fw_update -p http://127.0.0.1:8080/firmware/$(uname -r)/
fw_update -p http://127.0.0.1:8080/firmware/snapshots/
Or you can browse the I2P url using an http client with the i2p proxy to download the firmware manually.
=> http://2st32tfsqjnvnmnmy3e5o5y5hphtgt4b2letuebyv75ohn2w5umq.b32.i2p:8081/firmware/ Firmware i2p address
# Conclusion
There were no method to download OpenBSD files over Tor and I2P for people really needing it, it is now a thing.
If you encounter issues with the service, please let me know.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/openbsd-privacy-friendly-mirror.gmi</guid>
<link>gemini://perso.pw/blog//articles/openbsd-privacy-friendly-mirror.gmi</link>
<pubDate>Sat, 25 May 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>Improve your SSH agent security</title>
<description>
<![CDATA[
<pre># Introduction
If you are using SSH quite often, it is likely you use an SSH agent which stores your private key in memory so you do not have to type your password every time.
This method is convenient, but it comes at the expense of your SSH key use security, anyone able to use your session while the agent holds the key unlocked can use your SSH key. This scenario is most likely to happen when using a compromised build script.
However, it is possible to harden this process at a small expense of convenience, make your SSH agent ask for confirmation every time the key has to be used.
# Setup
The tooling provided with OpenSSH comes with a simple SSH agent named `ssh-agent`. On OpenBSD, the agent is automatically started and ask to unlock your key upon graphical login if it finds a SSH key in the default path (like `~/.ssh/id_rsa`).
Usually, the method to run the ssh-agent is the following. In a shell script defining your environment at an early stage, either your interactive shell configuration file or the script running your X session, you use `eval $(ssh-agent -s)`. This command runs ssh-agent and also enable the environment variables to make it work.
Once your ssh-agent is correctly configured, it is required to add a key into it, now, here are two methods to proceed.
## OpenSSH ssh-add
In addition to ssh-agent, OpenSSH provides ssh-add to load keys into the agent. It is simple of use, just run `ssh-add /path/to/key`.
=> https://man.openbsd.org/ssh-add ssh-add manual page
If you want to have a GUI confirmation upon each SSH key use, just add the flag `-c` to this command line: `ssh-add -c /path/to/key`.
In OpenBSD, if you have your key at a standard location, you can modify the script `/etc/X11/xenodm/Xsession` to change the first occurrence of `ssh-add` by `ssh-add -c`. You will still be greeting for your key password upon login, but you will be asked for each of its use.
## KeepassXC
It turns out the password manager KeepassXC can hold SSH keys, it works great for having used for a while. KeepassXC can either store the private key within its database or load a private key from the filesystem using a path and unlock it using a stored password, the choice is up to you.
You need to have the ssh-agent variables in your environment to have the feature work, as KeepassXC will replace ssh-add only, not the agent.
KeepassXC documentation has a "SSH Agent integration" section explaining how it works and how to configure it.
=> https://keepassxc.org/docs/ KeepassXC official documentation
In the key settings and "SSH Agent" tab, there is a checkbox to ask user confirmation upon each key use.
# Other security features
## Timeout
I would recommend to automatically delete the key from the agent after some time, this is especially useful if you do not actively use your SSH key.
In `ssh-add`, this can be achieved using `-t time` flag (it's tea time, if you want to remember about it), where time is a number of seconds or a time format specified in sshd_config, like 5s for 5 seconds, 10m for 10 minutes, 16h for 16 hours or 2d for 2 days.
In KeepassXC, it's in the key settings, within the SSH agent tab, you can configure the delay before the key is removed from the agent.
# Conclusion
The ssh-agent is a practical software that ease the use of SSH keys without much compromise with regards to security, but some extra security could be useful in certain scenarios, especially for developers running untrusted code as their user holding the SSH key.
While the extra confirmation could still be manipulated by a rogue script, it would come with a greater complexity at the cost of being spotted more easily. If you really want to protect your SSH keys, you should use them from a hardware token requiring a physical action to unlock it. While I find those tokens not practical and expensive, they have their use and they can not be beaten by a pure software solution.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/ssh-agent-security-enhancement.gmi</guid>
<link>gemini://perso.pw/blog//articles/ssh-agent-security-enhancement.gmi</link>
<pubDate>Mon, 27 May 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>Organize your console with tmuxinator</title>
<description>
<![CDATA[
<pre># Introduction
This article is about the program tmuxinator, a tool to script the generation of tmux sessions from a configuration file.
=> https://github.com/tmuxinator/tmuxinator tmuxinator official project website on GitHub
This program is particularly useful when you have repeated tasks to achieve in a terminal, or if you want to automate your tmux session to save your fingers from always typing the same commands.
tmuxinator is packaged in most distributions and requires tmux to work.
# Configuration
tmuxinator requires a configuration file for each "session" you want to manage with it. It provides a command line parameter to generate a file from a template:
$ tmuxinator new name_here
By default, it will create the yaml file for this project in `$HOME/.config/tmuxinator/name_here.yml`, if you want the project file to be in a directory (to make it part of a versioned project repository?), you can add the parameter `--local`. # Real world example Here is a tmuxinator configuration file I use to automatically do the following tasks, the commands include a lot of monitoring as I love watching progress and statistics:
name: dpb
root: ~/
on_project_start: cd /usr/ports && doas -u solene git pull -r
windows:
- dpb:
layout: tiled
panes:
- dpb:
- cd /root/packages/packages
- ./dpb.sh -P list.txt -R
- watcher:
- cd /root/logs
- ls -altrh locks
- date
- while true ; do clear && env CCACHE_DIR=/build/tmp/pobj/.ccache/ ccache -s ; sleep 5 ; done
- while true ; do df -h /build/tmp/pobj_mfs/ | grep % ; sleep 10 ; done
- top
- top -U _pbuild
# Going further
Tmuxinator could be used to ssh into remote servers, connect to IRC, open your email client, clean stuff, there are no limits.
This is particularly easy to configure as it does not try to run commands, but only send the keys to each tmux panes, which mean it will send keystrokes like if you typed them. In the example above, you can see how the pane "dpb" can cd into a directory and then run a command, or how the pane "watcher" can run multiple commands and leave the shell as is.
# Conclusion
I knew about tmuxinator for a while, but I never gave it a try before this week. I really regret not doing it earlier. Not only it allows me to "script" my console usage, but I can also embed some development configuration into my repositories. While you can use it as an automation method, I would not rely too much on it though, it only types blindly on the keyboard.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/potw-tmuxinator.gmi</guid>
<link>gemini://perso.pw/blog//articles/potw-tmuxinator.gmi</link>
<pubDate>Mon, 20 May 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>What is going on in Nix community?</title>
<description>
<![CDATA[
<pre># Introduction
You may have heard about issues within the Nix/NixOS community, this blog post will try to help you understand what is going on.
Please note that it is hard to get a grasp of the big picture, it is a more long term feeling that the project governance was wrong (or absent?) and people got tired.
This blog posts was written with my knowledge and feelings, I clearly do not represent the community.
=> https://save-nix-together.org/ Save Nix Together: an open letter to the NixOS foundation
=> https://xeiaso.net/blog/2024/much-ado-about-nothing/ Xe blog post: Much ado about nothing
There is a maintainer departure milestone in the Nixpkgs GitHub project.
=> https://github.com/NixOS/nixpkgs/milestone/27 GitHub milestone 27: Maintainers leaving
# Project structure
First, it is important to understand how the project works.
Nix (and NixOS, but it is not the core of the project), was developed by Eelco Dolstra early 2000. The project is open source, available on GitHub and everyone can contribute.
Nix is a tool to handle packaging in a certain way, and it has another huge repository (top 10 GitHub repo) called nixpkgs that contains all packages definition. nixpkgs is known to be the most up-to-date repository and biggest repository of packages, thanks to heavy automation and a huge community.
The NixOS foundation (that's the name of the entity managing the project) has a board that steer the project in some direction and handle questions. First problem is that it is known to be slow to act and response.
Making huge changes to Nix or Nixpkgs requires making an RFC (Request For Comment), explaining the rationale behind a change and a consensus has to be found with others to agree (it is somewhat democratic). Eelco decided a while ago to introduce a huge change in Nix (called Flakes) without going through the whole RFC process, this introduced a lot of tension and criticism because they should have gone through the process like every other people, and the feature is half-baked but got some traction and now Nix paradigm was split between two different modes that are not really compatible.
=> https://github.com/NixOS/rfcs/pull/49#issuecomment-659372623 GitHub Pull request to introduce Flakes: Eelco Dolstra mentioning they could merge it as experimental
There are also issues related to some sponsors in the Nix conferences, like companies related to militaries, but this is better explained in the links above, so I will not make a recap.
# Company involvement
This point is what made me leave NixOS community. I worked for a company called Tweag, involved into Nix for a while and paying people to contribute to Nix and Nixpkgs to improve the user experience for their client. This made me realize the impact of companies into open source, and the more I got involved into this, the more I realized that Nix was mostly driven by companies paying developers to improve the tool for business.
Paying people to develop features or fixing bug is fine, but when a huge number of contributors are paid by companies, this lead to poor decisions and conflicts of interest.
In the current situation, Eelco Dolstra published a blog post to remember the project is open source and belong to its contributors.
=> https://determinate.systems/posts/on-community-in-nix/ Eelco Dolstra blog post
The thing in this blog post, that puzzles me, is that most people at Determinate Systems (Eelco co-founded company) are deeply involved into Nix in various way. In this situation, it is complicated for contributors to separate what they want for the project from what their employer wants. It is common for nix contributors to contribute with both hats.
# Conclusion
Unfortunately, I am not really surprised this is happening. When a huge majority of people spending their free time contributing to a project they love and that companies relentlessly quiet their voice, it just can't work.
I hope Nix community will be able to sort this out and keep contributing to the project they love. This is open source and libre software, most affected people contribute because they like doing so, they do not deserve what is happening, but it never came with any guarantees either.
# Extra: Why did I stop using Nix?
I don't think this deserved a dedicated blog post, so here are some words.
From my experience, contributing to Nix was complicated. Sometimes, changes could be committed in minutes, leaving no time for other to review a change, and sometimes a PR could take months or years because of nitpicking and maintainer losing faith.
Another reason I stopped using nix was that it is quite easy to get nixpkgs commit access (I don't have commit access myself, I never wanted to inflict the nix language to myself), a supply chain attack would be easy to achieve in my opinion: there are so many commits done that it is impossible for a trustable group to review everything, and there are too many contributors to be sure they are all trustable.
# Alternative to Nix/NixOS?
If you do not like Nix/NixOS governance, it could be time to take a look at Guix, a Nix fork that happened in 2012. It is a much smaller community than nix, but the tooling, packages set and community is not at rest.
Guix being a 100% libre software project, it does not target MacOS like nix, nor it will include/package proprietary software, however for the second "problem", there is an unofficial repository called guix-nonfree that contains many packages like firmware and proprietary software, most users will want to include this repo.
Guix is old school, people exchange over IRC and send git diff over email, please do not bother them if this is not your cup of tea. On top of that, Guix uses the programming language Scheme (a Lisp-1 language) and if you want to work with this language, emacs is your best friend (try geiser mode!).
=> https://guix.gnu.org/ Guix official project webpage
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/nix-internal-crisis.gmi</guid>
<link>gemini://perso.pw/blog//articles/nix-internal-crisis.gmi</link>
<pubDate>Sat, 27 Apr 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>OpenBSD scripts to convert wg-quick VPN files</title>
<description>
<![CDATA[
<pre># Introduction
If you use commercial VPN, you may have noticed they all provide WireGuard configurations in the wg-quick format, this is not suitable for an easy use in OpenBSD.
As I currently work a lot for a VPN provider, I often have to play with configurations and I really needed a script to ease my work.
I made a shell script that turns a wg-quick configuration into a hostname.if compatible file, for a full integration into OpenBSD. This is practical if you always want to connect to a given VPN server, not for temporary connections.
=> https://man.openbsd.org/hostname.if OpenBSD manual pages: hostname.if
=> https://git.sr.ht/~solene/wg-quick-to-hostname-if Sourcehut project: wg-quick-to-hostname-if
# Usage
It is really easy to use, download the script and mark it executable, then run it with your wg-quick configuration as a parameter, it will output the hostname.if file to the standard output.
wg-quick-to-hostname-if fr-wg-001.conf | doas tee /etc/hostname.wg0
In the generated file, it uses a trick to dynamically figure the current default route which is required to keep a non-vpn route to the VPN gateway. # Short VPN sessions When I shared my script on mastodon, Carlos Johnson shared their own script which is pretty cool and complementary to mine. If you prefer to establish a VPN for a limited session, you may want to take a look at his script. => https://gist.github.com/callemo/aea83a8d0e1e09bb0d94ab85dc809675#file-wg-sh Carlos Johnson GitHub: file-wg-sh gist # Prevent leaks If you need your WireGuard VPN to be leakproof (= no network traffic should leave the network interface outside the VPN if it's not toward the VPN gateway), you should absolutely do the following: