The following contributor got their Debian Developer account in the last two
months:
The Debian LTS Team, funded by Freexian s Debian LTS offering,
is pleased to report its activities for
July.
The Debian LTS Team, funded by Freexian s Debian LTS offering, is
pleased to report its activities for May.
The Debian LTS Team, funded by Freexian s Debian LTS offering,
is pleased to report its activities for April.
The Debian LTS Team, funded by [Freexian s Debian LTS offering]
(https://www.freexian.com/lts/debian/), is pleased to report its activities for
March.
systemd-networkd, ifupdown, NetworkManager,
nothing)ifupdown (/etc/network/interfaces): traditional static
configuration system, mostly for workstations and servers that has
been there forever in Debian (since at least 2000), documented
in the Debian wikisystemd-network: used more for servers, see Debian reference Doc
Chapter 5 (introduced some time around Debian 8 "jessie", in
2015)ifupdown is on its way out, possibly replaced
by systemd-networkd. NetworkManager already manages most desktop
configurations.
ip= on the Linux kernel command line: for servers with a
single IPv4 or IPv6 address, no software required other than the
kernel and a boot loader (since 2002 or older)So by "new" I mean "new to me". This option is really old. The
nfsroot.txt where it is documented predates the git import of the
Linux kernel: it's part of the 2005 git import of 2.6.12-rc2. That's
already 20+ years old already.
The oldest trace I found is in this 2002 commit, which imports
the whole file at once, but the option might goes back as far as
1996-1997, if the copyright on the file is correct and the option
was present back then.
ip= parameter to the kernel's
command-line. The syntax, as mentioned above, is in nfsroot.txt
and looks like this:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>
<client-ip>: IP address of the server<gw-ip>: address of the gateway<netmask>: netmask, in quad notation<device>: interface name, if multiple available<autoconf>: how to configure the interface, namely:
off or none: no autoconfiguration (static)on or any: use any protocol (default)dhcp, essentially like on for all intents and purposes<dns0-ip>, <dns1-ip>: IP address of primary and secondary name
servers, exported to /proc/net/pnp, can by symlinked to
/etc/resolv.conf<server-ip>: IP address of the NFS server, exported to /proc/net/pnp<hostnname>: Name of the client, typically sent over the DHCP
requests, which may lead to a DNS record to be created in some
networks<ntp0-ip>: exported to /proc/net/ipconfig/ntp_servers, unused by
the kernelip=[<server-id>]:<gateway-IP-number>:<netmask>:<client-hostname>:inteface:[dhcp dhcp6 auto6 on any none off]
server-id is weird), and the
autoconf variable has other settings, so that's a bit odd.
ip=192.0.2.42::192.0.2.1:255.255.255.0:::off
ip=::::::dhcp
/etc/default/grub
(ugh) and find a line like:
GRUB_CMDLINE_LINUX=
GRUB_CMDLINE_LINUX=ip=::::::dhcp
systemd-boot UKI setups, it's simpler: just add the setting to
the /etc/kernel/cmdline file. Don't forget to include anything
that's non-default from /proc/cmdline.
This assumes that is the Cmdline=@ setting in
/etc/kernel/uki.conf. See 2025-08-20-luks-ukify-conversion for
my minimal documentation on this.
/etc/default/grub,
/boot/loader/entries/arch.conf for systemd-boot or
/etc/kernel/cmdline for UKI)/etc/default/grub, may be more RHEL mentions
grubby, possibly some systemd-boot things here as well)/etc/default/grub,
/efi/loader/entries/gentoo-sources-kernel.conf for systemd-boot,
or /etc/kernel/install.d/95-uki-with-custom-opts.install)/etc/default/grub is consistent across all
distributions above, while the systemd-boot setups are all over the
place (except for the UKI case), while I would have expected those be
more standard than GRUB.
dropbear-initramfs is setup, it already requires you to have
such a configuration, and it might not work out of the box.
This is because, by default, it disables the interfaces configured
in the kernel after completing its tasks (typically unlocking the
encrypted disks).
To fix this, you need to disable that "feature":
IFDOWN="none"
dropbear-initramfs from disabling the configured
interface.
ifupdown on servers
and NetworkManager on laptops, because that's essentially the
default. But on some machines, I've started using systemd-networkd
because ifupdown has ... issues, particularly with reloading network
configurations. ifupdown is a old hack, feels like legacy, and is
Debian-specific.
Not excited about configuring another service, I figured I would try
something else: just configure the network at boot, through the kernel
command-line.
I was already doing such configurations for dropbear-initramfs
(see this documentation), which requires the network the be up
for unlocking the full-disk encryption keys.
So in a sense, this is a "Don't Repeat Yourself" solution.
ifupdown does not either./etc/resolv.conf for you but the dns0-ip
and dns1-ip do end up in /proc/net/pnp which has a compatible
syntax, so a common configuration is:
ln -s /proc/net/pnp /etc/resolv.conf
apt purge systemd-networkd ifupdown network-manager netplan.io
ifupdown (and probably others) leave stray files in (e.g.)
/etc/network which you might want to cleanup, or keep in case all
this fails and I have put you in utter misery. Configuration files for
other packages might also be left behind, I haven't tested this, no
warranty.
In the past few years, the size of the kernel images in Debian have been
steadily growing. I don't see this as a problem per se, but it has been causing
me trouble, as my /boot partition has become too small to accommodate two
kernel images at the same time.
Since I'm running Debian Unstable on my personal systems and keep them updated
with unattended-upgrade, this meant each (frequent) kernel upgrade triggered
an error like this one:
update-initramfs: failed for /boot/initrd.img-6.17.11+deb14-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
/boot
partition to something larger than the default 456M. Since my systems use
full-disk encryption and LVM, this isn't trivial and would have required me to
play Tetris and swap files back and forth using another drive.
Another solution proposed by anarcat was to migrate to systemd-boot
(I'm still using grub), use Unified Kernel Images (UKI) and merge the
/boot and /boot/efi partitions. Since I already have a bunch of
configurations using grub and I am not too keen on systemd taking over all the
things on my computer, I was somewhat reluctant.
As my computers are all configured by Puppet, I could of course have done a
complete system reinstallation, but again, this was somewhat more involved than
what I wanted it to be.
After looking online for a while, I finally stumbled on this blog post by Neil
Brown detailing how to shrink the size of the initramfs images. With
MODULES=dep my images shrunk from 188M to 41M, fixing my issue. Thanks
Neil!
I was somewhat worried removing kernel modules would break something on my
systems, but so far, I only had to manually load the i2c_dev module, as I
need it to manage my home monitor's brightness using ddcutil.
dh-python to fix bugs and add features. This started
a month of attention
on dh-python, iterating through several bug fixes, and a couple of unfortunate
regressions.
dh-python is used by almost all packages containing Python (over 5000). Most
of these are very simple, but some are complex and use dh-python in unexpected
ways. It s hard to avoid almost any change (including obvious bug fixes) from
causing some unexpected knock-on behaviour. There is a fair amount of complexity
in dh-python, and some rather clever code, which can make it tricky to work on.
All of this means that good QA is important. Stefano spent some time
adding type annotations
and specialized types to make it easier to see what the code is doing and catch
mistakes. This has already made work on dh-python easier.
Now that Debusine has built-in repositories
and debdiff support, Stefano could quickly test the effects of changes on many
other packages. After each big change, he could upload dh-python to
a repository,
rebuild e.g. 50 Python packages with it, and see what differences appeared in
the output. Reviewing the diffs is still a manual process, but can be improved.
Stefano did a small test
on what it would take to replace direct setuptools setup.py calls with
PEP-517 (pyproject-style) builds. There is
more work to do here.
Python 3.14 as a supported version started in Debian unstable. To do this, we
update the list of supported versions in python3-defaults,
and then start rebuilding modules with C extensions from the leaves inwards.
This had already been tested in a PPA and Ubuntu, so many of the biggest
blocking compatibility issues with 3.14 had already been found and fixed. But
there are always new issues to discover.
Thanks to a number of people in the Debian Python team, we got through the first
bit of the transition fairly quickly. There are still a number of
open bugs
that need attention and many failed tests
blocking migration to testing.
Python 3.14.1 released just after we started the transition, and very soon
after, a follow-up 3.14.2 release came out to address a regression. We ran into
another regression in
Python 3.14.2.
ruby3.4 source package is already
available in experimental, also ruby-defaults added support to
Ruby 3.4. Lucas rebuilt all reverse dependencies against this new version of the
interpreter and published the results here.
Lucas also reached out to some stakeholders to coordinate the work.
Next steps are: 1) announcing the results to the whole team and asking for help
to fix packages failing to build against the new interpreter; 2) file bugs
against packages FTBFSing against Ruby 3.4 which are not fixed yet; 3) once we
have a low number of build failures against Ruby 3.4, ask the Debian Release
team to start the transition in unstable.
fail2ban powered firewall-level access limitation
for clients that display an abusive access pattern. This went through several
iterations, with some of them unfortunately blocking legitimate Debian
contributors, but the current state seems to strike a good balance between
blocking scrapers and not blocking real users. Please get in touch with the team
on the #debci OFTC channel if you are affected by this.
dose-builddebcheck to determine whether a package s dependencies can be
satisfied before attempting a build. About one third of Debian s packages fail
this check, so understanding the reasons is key to improving cross building.
Unfortunately, dose-builddebcheck stops after reporting the first problem and
does not display additional ones.
To address this, a greedy solver implemented in Python now examines each
build-dependency individually and can report multiple causes. dose-builddebcheck
is still used as a fall-back when the greedy solver does not identify any
problems. The report for bazel-bootstrap
is a lengthy example.
debhelper to its final installability test and builds a few more packages
required for installing it. It also now uses a variant of build-essential that
has been marked Multi-Arch: same
(see foundational work
from last year).
This in turn made the use of a non-default GCC version more difficult and
required more work to make it work for gcc-16 from experimental. Ongoing
archive changes temporarily regressed building fribidi and dash.
libselinux and groff have received patches for architecture specific changes
and libverto has been NMUed to remove the glib2.0 dependency.
python-authlib, python-mitogen, xdot.po-debconf-manager: added delete-package command,
show-information now uses properly formatted output (YAML), it now attaches
the translation on the bug reports for which a merge request has been opened too
long.po-debconf-manager but not
in the Debian l10n list.
Turns out that some packages had debian/po/templates.pot (appearing in
po-debconf-manager) but not the POTFILES.in file as expected.
Created a script
to find out which packages were in this or similar situation and
reported bugs.mbrola and festival) if using Orca speech synthesizer. Commented
a few issues and possible improvements in the debian-accessibility list.cmake_pkg_config builtin which is
not aware of the host architecture. He also
forwarded a Meson patch upstream.cups to fix a nasty bug that was
introduced by the latest security update.OpenSSH patch we ve been carrying
since 2008 to fix misleading verbose output from scp.astroid and pygments,
and wrote up the astroid case
on his blog.opencv
for the ffmpeg 8 transition.gnome-shell,
mutter, glib2.0).nocheck and nodoc
for the same git tree. Finally, Santiago provided
MR !685
to fix the documentation.
The Debian LTS Team, funded by [Freexian s Debian LTS offering]
(https://www.freexian.com/lts/debian/), is pleased to report its activities for
November.
The Debian LTS Team, funded by Freexian s Debian LTS
offering, is pleased to report
its activities for October.
root@mccoy:~# cryptsetup benchmark --cipher=xchacha12,aes-adiantum-plain64
# Tests are approximate using memory only (no storage IO).
# Algorithm Key Encryption Decryption
xchacha12,aes-adiantum 256b 159.7 MiB/s 160.0 MiB/s
xchacha20,aes-adiantum 256b 116.7 MiB/s 169.1 MiB/s
aes-xts 256b 52.5 MiB/s 52.6 MiB/s
With best-case reads from my SD card at 45MB/s (with dd if=/dev/mmcblk0 of=/dev/null bs=1048576 status=progress), either of the ChaCha-based algorithms will be fast enough. Great, I thought. Now I can just solve this problem without spending a dollar.
But not so fast.
Serial terminals vs. serial consoles
My primary use case for this device is to drive my actual old DEC vt510 terminal. I have long been able to do that by running a getty for my FTDI-based USB-to-serial converter on /dev/ttyUSB0. This gets me a login prompt, and I can do whatever I need from there.
This does not get me a serial console, however. The serial console would show kernel messages and could be used to interact with the pre-multiuser stages of the system that is, everything before the loging prompt. You can use it to access an emergency shell for repair, etc.
Although I have long booted that kernel with console=tty0 console=ttyUSB0,57600, the serial console has never worked but I d never bothered investigating because the text terminal was sufficient.
You might be seeing where this is going: to have root on an encrypted LUKS volume, you have to enter the decryption password in the pre-multiuser environment (which happens to be on the initramfs).
So I started looking. First, I extracted the initrd with cpio and noticed that the ftdi_sio and usbserial modules weren t present. Added them to /etc/initramfs-tools/modules and rebooted; no better.
So I found the kernel s serial console guide, which explicitly notes To use a serial port as console you need to compile the support into your kernel . Well, I have no desire to custom-build a kernel on a Raspberry Pi with MicroSD storage every time a new kernel comes out.
I thought well I don t stricly need the kernel to know about the console on /dev/ttyUSB0 for this; I just need the password prompt which comes from userspace to know about it.
So I looked at the initramfs code, and wouldn t you know it, it uses /dev/console. Looking at /proc/consoles on that system, indeed it doesn t show ttyUSB0. So even though it is possible to load the USB serial driver in the initramfs, there is no way to make the initramfs use it, because it only uses whatever the kernel recognizes as a console, and the kernel won t recognize this. So there is no way to use a USB-to-serial adapter to enter a password for an encrypted root filesystem.
Drat.
The on-board UARTs?
I can hear you know: The Pi already has on-board serial support! Why not use that?
Ah yes, the reason I don t want to use that is because it is difficult to use that, particularly if you want to have RTS/CTS hardware flow control (or DTR/DSR on these old terminals, but that s another story, and I built a custom cable to map it to RTS/CTS anyhow).
Since you asked, I ll take you down this unpleasant path.
The GPIO typically has only 2 pins for serial communication: 8 and 10, for TX and RX, respectively.
But dive in and you get into a confusing maze of UARTs. The mini UART , the one we are mostly familiar with on the Pi, does not support hardware flow control. The PL011 does. So the natural question is: how do we switch to the PL011, and what pins does it use? Great questions, and the answer is undocumented, at least for the Pi 4.
According to that page, for the Pi 4, the primary UART is UART1, UART1 is the mini UART, the secondary UART is not normally present on the GPIO connector and might be used by Bluetooth anyway, and there is no documented pin for RTS/CTS anyhow. (Let alone some of the other lines modems use) There are supposed to be /dev/ttyAMA* devices, but I don t have those. There s an enable_uart kernel parameter, which does things like stop the mini UART from changing baud rates every time the VPU changes clock frequency (I am not making this up!), but doesn t seem to control the PL011 UART selection. This page has a program to do it, and map some GPIO pins to RTS/CTS, in theory.
Even if you get all that working, you still have the problem that the Pi UARTs (all of them of every type) is 3.3V and RS-232 is 5V, so unless you get a converter, you will fry your Pi the moment you connect it to something useful. So, you re probably looking at some soldering and such just to build a cable that will work with an iffy stack.
So, I could probably make it work given enough time, but I don t have that time to spare working with weird Pi serial problems, so I have always used USB converters when I need serial from a Pi.
Conclusion
I bought a fanless x86 micro PC with a N100 chip and all the ports I might want: a couple of DB-9 serial ports, some Ethernet ports, HDMI and VGA ports, and built-in wifi. Done.
cryptsetup has a cryptsetup-reencrypt command,
surely we can do this in place?
Having not set aside enough room for /boot, I briefly
considered a "encrypted /boot" configuration and conversion (e.g. with
this guide) but remembered grub's support for this is flaky, at
best, so I figured I would try something else.
Here, I'm going to guide you through how I first converted from grub
to systemd-boot then to UKI kernel, then re-encrypt my main
partition.
Note that secureboot is disabled here, see further discussion below.
/boot. This neatly solves my problem,
because I already have such a clear-text partition and won't need to
re-partition my disk to convert.
Debian has started some preliminary support for this. It's not
default, but I found this guide from Vasudeva Kamath which was
pretty complete. Since the guide assumes some previous configuration,
I had to adapt it to my case.
Here's how I did the conversion to both systemd-boot and UKI, all at
once. I could have perhaps done it one at a time, but doing both at
once works fine.
Before your start, make sure secureboot is disabled, see the
discussion below.
apt install systemd-ukify systemd-boot
systemd-ukify, in /etc/kernel/install.conf:
layout=uki
initrd_generator=dracut
uki_generator=ukify
initrd with dracut, do
we care?/etc/kernel/uki.conf:
[UKI]
Cmdline=@/etc/kernel/cmdline
/etc/kernel/cmdline file doesn't actually exist here, and
that's fine. Defaults are okay, as the image gets generated from
your current /proc/cmdline. Check your /etc/default/grub and
/proc/cmdline if you are unsure. You'll see the generated
arguments in bootctl list below.dpkg-reconfigure linux-image-$(uname -r)
bootctl list
Type #2 (.efi) entry for the kernel.reboot
systemd-boot because (a) you won't
see grub and (b) the /proc/cmdline will reflect the configuration
listed in bootctl list. In my case, a systemd.machine_id variable
is set there, and not in grub (compare with /boot/grub/grub.cfg).
By default, the systemd-boot loader just boots, without a menu. You
can force the menu to show up by un-commenting the timeout line in
/boot/efit/loader/loader.conf, by hitting keys during boot
(e.g. hitting "space" repeatedly), or by calling:
systemctl reboot --boot-loader-menu=0
systemd-boot(7) manual for details on that.
I did not go through the secureboot process, presumably I had
already disabled secureboot. This is trickier: because one needs a
"special key" to sign the UKI image, one would need the collaboration
of debian.org to get this working out of the box with the
keys shipped onboard most computers.
In other words, if you want to make this work with secureboot enabled
on your computer, you'll need to figure out how to sign the generated
images before rebooting here, because otherwise you will break your
computer. Otherwise, follow the following guides:
cryptsetup-reencrypt for this which, amazingly, supports
re-encrypting devices on the fly. The trick is it needs free space at
the end of the partition for the LUKS header (which, I guess, makes it
a footer), so we need to resize the filesystem to leave room for that,
which is the trickiest bit.
This is a possibly destructive behavior. Be sure your backups are up
to date, or be ready to lose all data on the device.
We assume 512 byte sectors here. Check your sector size with fdisk
-l and adjust accordingly.
apt install cryptsetup systemd-cryptsetup cryptsetup-initramfs
qalc> 32Mibyte / ( 512 byte )
(32 mebibytes) / (512 bytes) = 65536
fdisk -l /dev/nvme0n1 awk '/filesystem/ print $1 " " $4 '
/boot and / filesystem:
$ sudo fdisk -l /dev/nvme0n1 awk '/filesystem/ print $1 " " $4 '
/dev/nvme0n1p2 999424
/dev/nvme0n1p3 3904979087
qalc> set precision 100
qalc> 3904979087 - 65536
fdisk -l /dev/nvme0n1 awk '/filesystem/ print $1 " " $4 - 65536 '
e2fsck -f /dev/nvme0n1p2
resize2fs /dev/nvme0n1p2 $(fdisk -l /dev/nvme0n1 awk '/nvme0n1p2/ print $4 - 65536 ')s
s here: it makes resize2fs interpret the
number as a 512 byte sector size, as opposed to the default (4k
blocks).cryptsetup reencrypt --encrypt /dev/nvme0n1p2 --resize-device-size=32M
Progress: 2.4% ETA 23m45s, 53GiB written, speed 1.3 GiB/s
cryptsetup open /dev/nvme0n1p2 crypt
mount /dev/mapper/crypt /mnt
mount /dev/nvme0n1p1 /mnt/boot/efi
chroot
for fs in proc sys dev ; do
mount --bind /$fs /mnt/$fs
done
chroot /mnt
grml-chroot /mnt bash
crypttab:
echo crypt_dev_nvme0n1p2 UUID=$(blkid -o value -s UUID /dev/nvme0n1p2) none luks,discard >> /etc/crypttab
/etc/fstab, make sure you have a line
like this:
/dev/mapper/crypt_dev-nvme0n1p2 / ext4 errors=remount-ro 0 1
initrd:
echo root=/dev/mapper/crypt_dev_nvme0n1p2 > /etc/kernel/cmdline
dpkg-reconfigure linux-image-$(uname -r)
systemd-boot inherits the command line from the
system where it is generated, so this will possibly feature some
unsupported commands from your boot environment. In my
case GRML had a couple of those, which broke the boot. It's still
possible to workaround this issue by tweaking the arguments at
boot time, that said.exit
reboot
initramfs-tools and grub, while I, above, switched to dracut and
systemd-boot). RHEL also has a similar guide, perhaps even
better.
Somehow I have made this system without LVM at all,
which simplifies things a bit (as I don't need to also resize the
physical volume/volume groups), but if you have LVM, you need to tweak
this to also resize the LVM bits. The RHEL guide has some information
about this.
 |
| Achieving full disk encryption using FIPS, TCG OPAL and LUKS to encrypt UEFI ESP on bare-metal and in VMs |
If one has a lot of estate and a lot of encryption keys to keep track off a key management solution is likely needed. The most popular solution is likely the one from Thales Group marketed under ChiperTrust Data Security Platform (previously Vormetric), but there are many others including OEM / Vendor / Hardware / Cloud specific or agnostic solutions.
I hope this crash course guide piques your interest to learn and discover modern confidentially and integrity solutions, and to re-affirm or change your existing controls w.r.t. to data protection at rest.
Full disk encryption, including UEFI ESP /boot/efi is now widely achievable by default on both baremetal machines and in VMs including with FIPS certification. To discuss more let's connect on Linkedin.
dig ns jing.rocks +short), I added a JP POP.
If we know each other, I would be glad to host a secondary NS for you in (IN and/or DE locations).
$ dig ns albony.in
; <<>> DiG 9.18.36 <<>> ns albony.in
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60525
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;albony.in. IN NS
;; ANSWER SECTION:
albony.in. 1049 IN NS ns3.albony.in.
albony.in. 1049 IN NS ns4.albony.in.
albony.in. 1049 IN NS ns2.albony.in.
albony.in. 1049 IN NS ns1.albony.in.
;; ADDITIONAL SECTION:
ns3.albony.in. 1049 IN AAAA 2a14:3f87:f002:7::a
ns1.albony.in. 1049 IN A 82.180.145.196
ns2.albony.in. 1049 IN AAAA 2403:44c0:1:4::2
ns4.albony.in. 1049 IN A 45.64.190.62
ns2.albony.in. 1049 IN A 103.77.111.150
ns1.albony.in. 1049 IN AAAA 2400:d321:2191:8363::1
ns3.albony.in. 1049 IN A 45.90.187.14
ns4.albony.in. 1049 IN AAAA 2402:c4c0:1:10::2
;; Query time: 29 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Jul 04 07:57:01 IST 2025
;; MSG SIZE rcvd: 286
$ dig ns sahil.rocks
; <<>> DiG 9.18.36 <<>> ns sahil.rocks
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64497
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;sahil.rocks. IN NS
;; ANSWER SECTION:
sahil.rocks. 6385 IN NS ns5.he.net.
sahil.rocks. 6385 IN NS puck.nether.net.
sahil.rocks. 6385 IN NS colin.sahilister.net.
sahil.rocks. 6385 IN NS marvin.sahilister.net.
sahil.rocks. 6385 IN NS ns2.afraid.org.
sahil.rocks. 6385 IN NS ns4.he.net.
sahil.rocks. 6385 IN NS ns2.albony.in.
sahil.rocks. 6385 IN NS ns3.jing.rocks.
sahil.rocks. 6385 IN NS ns0.1984.is.
sahil.rocks. 6385 IN NS ns1.1984.is.
sahil.rocks. 6385 IN NS ns-global.kjsl.com.
;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Jul 04 07:57:20 IST 2025
;; MSG SIZE rcvd: 313
This post is an unpublished review for The subjective value of privacy Assessing individuals' calculus of costs and benefits in the context of state surveillanceInternet users, software developers, academics, entrepreneurs basically everybody is now aware of the importance of considering privacy as a core part of our online experience. User demand, and various national or regional laws, have made privacy a continuously present subject. And privacy is such an all-encompassing, complex topic, the angles from which it can be studied seems never to finish; I recommend computer networking-oriented newcomers to the topic to refer to Brian Kernighan s excellent work [1]. However, how do regular people like ourselves, in our many capacities feel about privacy? Lukas Antoine presents a series of experiments aiming at better understanding how people throughout the world understands privacy, and when is privacy held as more or less important than security in different aspects, Particularly, privacy is often portrayed as a value set at tension against surveillance, and particularly state surveillance, in the name of security: conventional wisdom presents the idea of privacy calculus. This is, it is often assumed that individuals continuously evaluate the costs and benefits of divulging their personal data, sharing data when they expect a positive net outcome, and denying it otherwise. This framework has been accepted for decades, and the author wishes to challenge it. This book is clearly his doctoral thesis on political sciences, and its contents are as thorough as expected in this kind of product. The author presents three empirical studies based on cross-survey analysis. The first experiment explores the security justifications for surveillance and how they influence their support. The second one searches whether the stance on surveillance can be made dependent on personal convenience or financial cost. The third study explores whether privacy attitude is context-dependant or can be seen as a stable personality trait. The studies aim to address the shortcomings of published literature in the field, mainly, (a) the lack of comprehensive research on state surveillance, needed or better understanding privacy appreciation, (b) while several studies have tackled the subjective measure of privacy, there is a lack of cross-national studies to explain wide-ranging phenomena, (c) most studies in this regard are based on population-based surveys, which cannot establish causal relationships, (d) a seemingly blind acceptance of the privacy calculus mentioned above, with no strong evidence that it accurately measures people s motivations for disclosing or withholding their data. The specific take, including the framing of the tension between privacy and surveillance has long been studied, as can be seen in Steven Nock s 1993 book [2], but as Sannon s article in 2022 shows [3], social and technological realities require our undertanding to be continuously kept up to date. The book is full with theoretical references and does a very good job of explaining the path followed by the author. It is, though, a heavy read, and, for people not coming from the social sciences tradition, leads to the occasional feeling of being lost. The conceptual and theoretical frameworks and presented studies are thorough and clear. The author is honest in explaining when the data points at some of his hypotheses being disproven, while others are confirmed. The aim of the book is for people digging deep into this topic. Personally, I have authored several works on different aspects of privacy (such as a book [4] and a magazine number [5]), but this book did get me thinking on many issues I had not previously considered. Looking for comparable works, I find Friedewald et al. s 2017 book [6] chapter organization to follow a similar thought line. My only complaint would be that, for the publication as part of its highly prestigious publisher, little attention has been paid to editorial aspects: sub-subsection depth is often excessive and unclear. Also, when publishing monographs based on doctoral works, it is customary to no longer refer to the work as a thesis and to soften some of the formal requirements such a work often has, with the aim of producing a more gentle and readable book; this book seems just like the mass-production of an (otherwise very interesting and well made) thesis work. References:
Note that for this last test I picked the largest word list I had on my machine (dict/bokm l) as a fairly random work list and not because it is useful for cracking my particular use case from a few months ago. As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.Session..........: hashcat Status...........: Quit Hash.Mode........: 14600 (LUKS v1 (legacy)) Hash.Target......: hashcat.luks Time.Started.....: Tue Apr 8 23:06:08 2025 (1 min, 10 secs) Time.Estimated...: Tue Apr 8 23:12:49 2025 (5 mins, 31 secs) Kernel.Feature...: Pure Kernel Guess.Base.......: File (/usr/share/dict/bokm l) Guess.Queue......: 1/1 (100.00%) Speed.#1.........: 2821 H/s (8.18ms) @ Accel:128 Loops:128 Thr:32 Vec:1 Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new) Progress.........: 0/935405 (0.00%) Rejected.........: 0/0 (0.00%) Restore.Point....: 0/935405 (0.00%) Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:972928-973056 Candidate.Engine.: Device Generator Candidates.#1....: A-aksje -> fiskebil Hardware.Mon.#1..: Temp: 73c Fan: 77% Util: 99% Core:2625MHz Mem: 456MHz Bus:16
The Open Source Initiative has two classes of board seats: Affiliate seats, and Individual Member seats. In the upcoming election, each affiliate can nominate a candidate, and each affiliate can cast a vote for the Affiliate candidates, but there's only 1 Affiliate seat available. I initially expressed interest in being nominated as an Affiliate candidate via Debian. But since Bradley Kuhn is also running for an Affiliate seat with a similar platform to me, especially with regards to the OSAID, I decided to run as part of an aligned "ticket" as an Individual Member to avoid contention for the 1 Affiliate seat.Bradley and I discussed running on a similar ticket around 8/9pm Pacific, and I submitted my candidacy around 9pm PT on 17 February. I was dismayed when I received the following mail from Nick Vidal:Dear Luke,Nowhere on the "OSI s board of directors in 2025: details about the elections" page do they list a timezone for closure of nominations; they simply list Monday 17 February. The OSI's contact address is in California, so it seems arbitrary and capricious to retroactively define all of these processes as being governed by UTC.I was not able to participate in the "potential board director" info sessions accordingly, but people who attended heard that the importance of accommodating differing TZ's was discussed during the info session, and that OSI representatives mentioned they try to accommodate TZ's of everyone. This seems in sharp contrast with the above policy. I urge the OSI to reconsider this policy and allow me to stand for an Individual seat in the current cycle. Upd, N.B.: to people writing about this, I use they/them pronouns
Thank you for your interest in the OSI Board of Directors election. Unfortunately, we are unable to accept your application as it was submitted after the official deadline of Monday Feb 17 at 11:59 pm UTC. To ensure a fair process, we must adhere to the deadline for all candidates.
We appreciate your enthusiasm and encourage you to stay engaged with OSI s mission. We hope you ll consider applying in the future or contributing in other meaningful ways.
Best regards,
OSI Election Teams
Welcome to the second report in 2025 from the Reproducible Builds project. Our monthly reports outline what we ve been up to over the past month, and highlight items of news from elsewhere in the increasingly-important area of software supply-chain security. As usual, however, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website.
Table of contents:
Similar to last year s event, there was considerable activity regarding Reproducible Builds at FOSDEM 2025, held on on 1st and 2nd February this year in Brussels, Belgium. We count at least four talks related to reproducible builds. (You can also read our news report from last year s event in which Holger Levsen presented in the main track.)
Jelle van der Waa, Holger Levsen and kpcyrd presented in the Distributions track on A Tale of several distros joining forces for a common goal. In this talk, three developers from two different Linux distributions (Arch Linux and Debian), discuss this goal which is, of course, reproducible builds. The presenters discuss both what is shared and different between the two efforts, touching on the history and future challenges alike. The slides of this talk are available to view, as is the full video (30m02s). The talk was also discussed on Hacker News.
Zbigniew J drzejewski-Szmek presented in the ever-popular Python track a on Rewriting .pyc files for fun and reproducibility, i.e. the bytecode files generated by Python in order to speed up module imports: It s been known for a while that those are not reproducible: on different architectures, the bytecode for exactly the same sources ends up slightly different. The slides of this talk are available, as is the full video (28m32s).
Lastly, Simon Tournier presented in the Open Research track on the confluence of GNU Guix and Software Heritage: Source Code Archiving to the Rescue of Reproducible Deployment. Simon s talk describes design and implementation we came up and reports on the archival coverage for package source code with data collected over five years. It opens to some remaining challenges toward a better open and reproducible research. The slides for the talk are available, as is the full video (23m17s).
Vagrant Cascadian presented at this year s PyCascades conference which was held on February 8th and 9th February in Portland, OR, USA. PyCascades is a regional instance of PyCon held in the Pacific Northwest. Vagrant s talk, entitled Re-Py-Ducible Builds caught the audience s attention with the following abstract:
Crank your Python best practices up to 11 with Reproducible Builds! This talk will explore Reproducible Builds by highlighting issues identified in Python projects, from the simple to the seemingly inscrutable. Reproducible Builds is basically the crazy idea that when you build something, and you build it again, you get the exact same thing or even more important, if someone else builds it, they get the exact same thing too.More info is available on the talk s page.
The last few months have seen the introduction of reproduce.debian.net. Announced first at the recent Debian MiniDebConf in Toulouse, reproduce.debian.net is an instance of rebuilderd operated by the Reproducible Builds project.
Powering this work is rebuilderd, our server which monitors the official package repositories of Linux distributions and attempt to reproduce the observed results there. This month, however, Holger Levsen:
riscv64 nodes to a total of 4, and added a new amd64 node added thanks to our (now 10-year sponsor), IONOS.
devscripts package, incorporating changes from Jochen Sprickerhof to the debrebuild script specifically to fix the handling the Rules-Requires-Root header in Debian source packages.
rust-libbz2-rs-sys, rust-actix-web, rust-actix-server, rust-actix-http, rust-actix-server, rust-actix-http, rust-actix-web-codegen and rust-time-tz) after they were prepared by kpcyrd :
sbuild package to:
Rules-Requires-Root.--root-owner-group to old versions of dpkg.rust-i8n (random HashMap order)starship/shadowpython-assertpy.terminaltables3.acme.sh.node-svgdotjs-svg.js.onevpl-intel-gpu.rocdbgapi.siege.pkg-rocm-tools.warewulf4 (embeds CPU core count)highlight (timestamp)arch-wiki-lite (timestamp)f3d (timestamp)jacktrip (timestamp)prometheus (timestamp)go (clear GOROOT for func ldShared when -trimpath is used)
In Debian, 17 reviews of Debian packages were added, 6 were updated and 8 were removed this month adding to our knowledge about identified issues.
Thanks to an investment from the Sovereign Tech Agency, the FreeBSD project s work on unprivileged and reproducible builds continued this month. Notable fixes include:
pkg (hash ordering)makefs (source filesystem inode number leakage)FreeBSD base system packages (timestamp)
Finally, Douglas DeMaio published an article on the openSUSE blog on announcing that the Reproducible-openSUSE (RBOS) Project Hits [Significant] Milestone. In particular:
The Reproducible-openSUSE (RBOS) project, which is a proof-of-concept fork of openSUSE, has reached a significant milestone after demonstrating a usable Linux distribution can be built with 100% bit-identical packages.This news was also announced on our mailing list by Bernhard M. Wiedemann, who also published another report for openSUSE as well.
diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 288 and 289 to Debian:
asar to DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS in order to address Debian bug #1095057) [ ]CalledProcessError when calling html2text. [ ]1.14.1-2 was uploaded to Debian unstable by Holger Levsen.
There were a large number of improvements made to our website this month, including:
readdir component of Bernhard s own Unreproducible Package. [ ]
README file to document a couple of additional dependencies [ ][ ], as well as did more work on a future Getting Started guide page [ ][ ].
The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In January, a number of changes were made by Holger Levsen, including:
riscv64 archicture nodes and integrate them elsewhere in our infrastructure. [ ][ ]riscv64 architecture nodes. [ ][ ][ ][ ][ ]/all/api/ API endpoints on reproduce.debian.net by altering the nginx configuration. [ ]
mmdebstrap package [ ] as well as updating some documentation [ ].
#reproducible-builds on irc.oftc.net.
rb-general@lists.reproducible-builds.org
Nova gera o: uma entrevista com iniciantes no projeto Debian
Instala o personalizada e automatizada do Debian com preseed
Manipulando patches com git-buildpackage
debian.social: Socializando Debian do jeito Debian
Proxy reverso com WireGuard
Celebra o dos 30 anos do Debian!
Instalando o Debian em disco criptografado com LUKS
O que a equipe de localiza o j conquistou nesses 30 anos
Debian - Projeto e Comunidade!
Design Gr fico e Software livre, o que fazer e por onde come ar
Next.