327. This version includes the following changes:
[ Colin Watson ]
* Handle missing openssh-client binaries in autopkgtests.
On Saturday 25 July 2026, the annual Debian Developers and Contributors
Conference came to a close.
Over 270 attendees representing 35 countries from around the world came
together for a combined 90 events (including some which took place during
the DebCamp) including more than 27 Talks, 21 Short Talks,
29 Birds of a Feather sessions ("BoF" informal meeting between developers
and users), 8 workshops, and activities in support of furthering our
distribution and free software, learning from our mentors and peers, building
our community, and having a bit of fun.
The conference was preceded by the annual
DebCamp hacking session held 13
through 19 July where Debian Developers and Contributors convened to
focus on their individual Debian-related projects or work in team sprints
geared toward in-person collaboration in developing Debian.
As has been the case for several years, a special effort has been made to
welcome newcomers and help them become familiar with Debian and DebConf
by organizing a sprint "New Contributors Onboarding" every day of Debcamp,
followed more informally by mentorship during DebConf. Half a dozen new
contributors joined the sessions and learned about Debian, free software,
packaging and much more.
This year, a week-long DebCamp session was dedicated to auditing,
patching, and modernizing the Go ecosystem in Debian and enable the
transition triggered by the recent upload of dh-golang enabling GO111MODULE=on
by default in Experimental.
In order to make the conference more accessible for local participants,
a local language track was included in the schedule for talks in Spanish,
as was done at DebConf19 in Brazil.
The actual Debian Developers Conference started on Monday 20 July 2026.
In addition to the traditional "Bits from the DPL" talk, the continuous
key-signing party, lightning talks, and the announcement of next year's
DebConf27, there were several update sessions shared by internal projects
and teams.
Many of the hosted discussion sessions were presented by our technical
core teams with the usual and useful "Meet the Technical Committee", three
talks about Linux Kernel, early boot and improving Debian s kernel and
installer support for Chromebooks, and about twenty BoFs and talks about
Debian packaging policy, Debian infrastructure, security and privacy.
This year, and echoing ongoing discussions within the Free Software community,
Artificial Intelligence and Age Verification have been the subject of
several talks. The Python, Perl, Ruby, Go, and Rust programming
language teams also shared updates on their work and efforts.
More than 17 BoFs and talks about community, diversity, and local outreach
highlighted the work of various teams involved in not just the technical but
also the social aspect of our community
The schedule
was updated each day with planned and ad hoc activities introduced by
attendees over the course of the conference. Several traditional activities
took place: a poetry performance, the traditional Cheese and Wine party, the
Group Photos, and the Day Trip.
For those who were not able to attend, most of the talks and sessions were
broadcasted live and recorded. One can find the seventy hours of recorded
videos available via the conference
schedule,
or alternatively through this
link.
Almost all of the sessions facilitated remote participation via IRC and Matrix
messaging apps or online collaborative text documents which allowed remote
attendees to "be in the room" and ask questions or share comments with the
speaker or assembled audience. DebConf26 saw over 341 T-shirts, a day trip,
and up to 130 meals planned per day.
All of these events, activities, conversations, and streams coupled with our
love, interest, and participation in Debian and F/OSS certainly made this
conference an overall success both here in Santa Fe, Argentina and online
around the world.
The DebConf26 website
will remain active for archival purposes and will continue to offer
links to the presentations and videos of talks and events.
Next year, DebConf27 will be held
in Asahikawa, Hokkaido, Japan, from Sunday September 5th to Saturday
September 11th, 2027. As tradition follows before the next DebConf the
local organizers in Japan will start the conference activities with DebCamp
with a particular focus on individual and team work towards improving the
distribution.
DebConf is committed to a safe and welcome environment for all
participants. See the
web page about the Code of Conduct on the DebConf26 website
for more details on this.
Debian thanks the commitment of numerous
sponsors
to support DebConf26, particularly our Platinum Sponsors:
Infomaniak, and
Proxmox,
and our Gold Sponsors : Freexian, and
Viridien.
We also wish to thank our Video and Infrastructure teams, the DebConf26
and DebConf committees, our host nation of Argentina, and each and every
person who helped contribute to this event and to Debian overall.
Thank you all for your work in helping Debian continue to be "The Universal
Operating System".
See you next year!
About Debian
The Debian Project was founded in 1993 by Ian Murdock to be a truly free
community project. Since then the project has grown to be one of the
largest and most influential Open Source projects. Thousands of
volunteers from all over the world work together to create and maintain
Debian software. Available in 70 languages, and supporting a huge range
of computer types, Debian calls itself the universal operating system.
About DebConf
DebConf is the Debian Project's developer conference. In addition to a
full schedule of technical, social and policy talks, DebConf provides an
opportunity for developers, contributors and other interested people to
meet in person and work together more closely. It has taken place
annually since 2000 in locations as varied as Scotland, Bosnia and Herzegovina,
India, Korea, France. More information about DebConf is available from
https://debconf.org/.
About Infomaniak
Infomaniak is an independent, employee-owned
Swiss technology company that designs, develops, and operates its own cloud
infrastructure and digital services entirely in Switzerland. With over
300 employees more than 70% engineers and developers the company reinvests
all profits into R&D. Its public cloud is built on OpenStack, with managed
Kubernetes, Database as a Service, object storage, and sovereign AI services
accessible via OpenAI-compatible APIs, all running on its own Swiss
infrastructure. Infomaniak also develops a sovereign collaborative suite
messaging, email, storage, online office tools, videoconferencing, and a
built-in AI assistant developed in-house and as a privacy-respecting
solution to proprietary platforms. Open source is central to how Infomaniak
operates. Its latest data center (D4) runs on 100% renewable energy and uses
no traditional cooling: all the heat generated by its servers is captured and
fed into Geneva's district heating network, supplying up to 6,000 homes in
winter and hot water year-round. The entire project has been documented and
open-sourced at d4project.org.
About Proxmox
Proxmox develops powerful, yet easy-to-use
open-source server solutions. The comprehensive open-source ecosystem is
designed to manage divers IT landscapes, from single servers to large-scale
distributed data centers. Our unified platform integrates server
virtualization, easy backup, and rock-solid email security ensuring seamless
interoperability across the entire portfolio. With the Proxmox Datacenter
Manager, the ecosystem also offers a "single pane of glass" for centralized
management across different locations. Since 2005, all Proxmox solutions have
been built on the rock-solid Debian platform. We are proud to return to
DebConf26 as a sponsor because the Debian community provides the foundation
that makes our work possible. We believe in keeping IT simple, open, and under
your control.
Contact Information
For further information, please visit the DebConf26 web page at
https://debconf26.debconf.org/ or send
mail to press@debian.org.
This post is an unpublished review for Subscription Bombing Email under AttackOne of the most important inputs one can have when designing a response strategy against a security attack is a good characterization. This article describes a relatively newly described attack mode (subscription bombing), hypothetizes on the motivations that can lie behind it, and presents some countermeasures that can be taken by different actors to reduce its impact. At its core, suscription bombing is a classical reflection attack: it uses a third party service so that the answer to a relatively simple request is amplified and results in a distributed denial of service (DDoS) for the victim. And, as with most DDoS attacks, its effectivity lies in that there is not much a person can do against traffic coming from seemingly random different providers all around the world. The core differentiatof for subscription bombing is that the attack s victim is not a network port, but an individual s e-mail address. The attacker builds a database of service providers that allow interested users to sign up for newsletter on their activities, or a mailing list, or even just to create a new account on a given Web system. This action will generate a (seemingly legitimate) confirmation mail sent to the victim. But the attacker scripts together hundreds of thousands of such request, creating a deluge of confirmation mails sent to the unsuspecting victim. The authors explain the goals an attacker might pursue by performing this kind of attack. They suppose this can be due to harassment (a disgruntled employee being denied a salary raise, a political adversary, or even a romantic ex-partner wanting to inconvenience the victim s use of their e-mail). More worryingly, the attack can be used as a distraction: by sending a high volume of mails in a controlled timeframe, the attacker can reduce the probability of the victim noticing a specific attack warning them of, i.e., financial fraud, unwanted purchases, or break-in attempts into their accounts. Attacks targetting mailboxes at private mail servers can also lead to overloading an account s limit, causing it to reject mails after the attack is delivered and before the folder is cleaned. And it can also pave the way for follow-up, targetted deception attacks, where the attackers call the victim pretending to be the company s IT department, and get them to install a remote desktop monitoring and management tool, with which they can effectively seize control of the victim s data. To do this, they present a study they made over 24 cases of victims, from which 47,970 total e-mails were received between October and December 2024, with individual attacks receiving between 81 and 3,387 e-mails per hour, from where they presented several descriptive analysis. The authors explored cyber criminal s offers on underground websites, comparing flooding services and pricing schemes. Finally, mitigation strategies are discussed. Mitigation is quite problematic, as none of the mail servers is acting in either a hostile way or lacking permissions they are performing just the task they should. The authors suggest four mitigation strategies for mail server operators to reduce the burden on their users, although none of them is easily automatizab (rate-limit the number of emails a given inbox can receive from previously unseen senders; educate users about this kind of attacks; group similar newsletter or account reset mails during active attacks; and automatically unsubscribe or bounce newsletter messages when a surge is detected). They also recommend newsletter providers and services accepting the unrestricted creation of user accounts to provide some hardening to increase the effort wrongdoers need to spend to abuse their services, such as requiring CAPTCHAs or requiring users to take several steps before requesting a subscription, although they recognize this adds friction to the process providers are most interested in providing; filtering and triaging known-good and known-bad domains, although this is hard to implement on a preemptive fashion, and adhering to easy unsubscription standards, such as easily identifiable headers with which mass unsubscription could be performed more easily victims, instead of hunting for the right places to click, potentially even in mails written in an unknown language. The described problem is interesting, and properly tackling it can be a game changer for many users who will suffer this kind of abuse, and the article is easy to read and soundly supports its claims.
systemd-inhibit --list --mode=block doesn't help much:
$ systemd-inhibit --list --mode=block
WHO UID USER PID COMM WHAT WHY MODE
enrico 1000 enrico 3042 gsd-power handle-lid-switch External monitor attached block
enrico 1000 enrico 3037 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses block
enrico 1000 enrico 2878 gnome-session-b sleep user session inhibited block
gnome-session-inhibit:
$ gnome-session-inhibit --list
mutter: idle-inhibit (idle)
/usr/lib/chromium/chromium: Playing audio (suspend)
Welcome to post 58 in the R4 series.
R and the CRAN repositories maintain a very
high level of what we might call quality assurrance by requiring that
newly-added code does not break any existing dependencies. This is
frequently called a reverse-dependency check . For any given CRAN package one can quickly
determine it reverse dependencies. Calling
tools::package_dependencies(pkgName, reverse=TRUE) will for
a scalar or vector-valued argument return a named list with the reverse
dependencies. It is then a matter of looping over this list. There are
helper functions in base R as well as in contributed packages on and off
CRAN. I also wrote my own with
package prrd which,
while possibly a wee bit specialised and under-documented has served me
well to check on Rcpp and
related packages which can indeed have a large number of
reverse dependencies.
I recently looked into one of these contributed runner packages, and
while I will refrain from naming its implementation language let me just
mention that the term cargo cult may be a real thing
here. What go me interested in this was the fact that if one
has a simple-to-use runner then the fact that r2u makes it fast, easy,
reliable: pick all three (to borrow its slogan) to deal with actual
depencies if Ubuntu has indeed been selected as the host. We will
maintain the position that if you can in fact integrate with
the system-wide package management then any alternative per-repo package
management approach not doing so will likely be dominated by an approach
that does integrate with the system facilities. Which is what precisely
what r2u does, and
offers. And why it is used enough to by now have shipped eighty eight
million binary packages. So I tested it for the reverse-dependency check
task.
What I learned by looking into the (much more complicated) runner was
that it at the end of the day it hands the actual task of running the
reverse dependecies off to a helper function rev_check that
is part of the xfun package
by Yuhui. I quickly found that besides xfun we would also need its
suggested dependency tinytex which in turn
would error unless the tlmgr binary was present. So as the
sole requirement (on an Ubuntu system with r2u) turns out to be
where we do it all in one apt call (as root
in the container). (Given r2u we could also call
install.packages(c("xfun","tinytext")) followed by
apt install texlive-base but it is simpler for this setup
step to be just one call).
With that we are basically done. I did this (twice) using a
rocker/r2u container with r2u preinstalled, mounting
a local work and scrap directory for the container. In it we expand the
package to be tested (i.e. tar xaf pkgName_*tar.gz for a
given source package pkgName from CRAN) and then just call with the
package name and expanded direcrtory. I.e. I used this call to test my
package AsioHeaders (which has just three reverse
dependencies) to both name it and to point to the expanded source
directory created for this purposed:
> system.time( res <- xfun::rev_check("AsioHeaders", src="AsioHeaders") )
## ... earlier output omitted for brevity here ...
user system elapsed
35.732 3.333 149.683
> res
httpgd ipaddress websocket
0 0 0
> res. As I checked the current CRAN version, the check was as
expected free of concerns or issues.
To support this, r2u
did indeed go off and install about sixty seven binary packages (and the
total includes all binary dependencies fully resolved) delivering on the
just works promise by the r2u documentation.
As another check, I did the same for RcppAnnoy which has
seven reverse dependencies and needed about two hundred CRAN packages to be installed. The
full test took just over four minutes with the timing function reporting
some nice gains from parallelisation as total user compute time was on
the order of just under eight minutes. Again, test results were clean
and free of worries as expected:
> system.time( res <- xfun::rev_check("RcppAnnoy", src="RcppAnnoy") )
## ... earlier output omitted for brevity here ...
user system elapsed
471.765 378.220 266.855
> res
bbknnR bigANNOY blocking scDHA Seurat uwot VectrixDB
0 0 0 0 0 0 0
> This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.
Screenshot by VulcanSphere via Wikimedia Commons MIT License/net), processes are files, the display is a file (/dev/draw). Because every resource speaks 9P and every process has its own namespace, you can mount another machine's /net into your namespace and your program makes network calls through that machine's stack without knowing or caring. No sockets API, no RPC layer, just ordinary file system operations through a simple system call interface.
Some would say that OS research is dead, and that backwards-compatibility and POSIX killed it. Rob Pike himself argued as much in his 2000 talk, "Systems Software Research is Irrelevant" - but we didn't care at the time. There was so much happening that we didn't have time to take it all in. And then Linux happened, and Software Freedom became a focal point (more on that in a later post).
In the summer of 2020, with the world deep in Covid lockdowns, I decided to build a toy operating system, just to try my hand at the the thing that I had always wanted to do. I spent three feverish months working on Odyssey and, looking back, it is perhaps the most fun I have ever had. I would not dare compare it to the magnum opus that is Plan 9, but it gave me perspective: how hard it is to build an OS from scratch, and above all, how fun it is to build an OS from scratch, and why the original creators kept coming back to the same problem. The highlight of those three months was booting the OS and watching it render "The Great Wave off Kanagawa". Nothing in my professional achievements to date captures what that meant to me.
Odyssey displaying "The Great Wave Off Kanagawa"
Today I stumbled over some behavior that I found quite surprising:
$ ipython3 -c 'import httpx;print(httpx.URL("https://example.com/foo/bar/../../baz"))'
https://example.com/baz
Even more surprising that behavior is actually standards-compliant,
even mandated by RFC 3986.
The underlying motivation is relative reverences.
If some resource reachable by "https://example.com/foo/bar"
references another resource relatively as "../../baz" then
this is of course the intended result.
Getting from this problem to what RFC 3986 suggests
might be surprising in the result, but somewhat understandable if you
look at the consequences of that problem:
Giving the path components ".." (and ".")
special meaning at the start of the relative reference means that if you allowed
them in absolute URLs those would be impossible (or at least very convoluted)
to address as relative URLs.
So RFC 3986 describes a way to handle them everywhere:
Just join the path of the base URL and the path of the relative reference
and normalize the result. Or normalize the absolute on either side if only
that is to be taken.
This makes things very convenient:
Multiple reference URLs can just be joined without special handling for
relative references starting with dots, making writing applications handling
them easier.
Programmers don't have to care how to handle relative references and can
just join everything in whatever way they want.
For maximum elegance there is still some corner case left:
What happens if an absolute URL has a path starting with double-dot components?
Or an relative path starting with more of them then the base URL's path has components.
You just ignore them:
$ ipython3 -c 'import httpx;print(httpx.URL("https://example.com/../../baz"))'
https://example.com/baz
With that last point every URL is valid and has well-defined meaning.
Handling relative references and relative paths is very easy and convenient.
So this shows a high regard for simplicity, elegance and convenience.
And a total and uncompromising disregard of security.
After all the most convenient it is for an attacker;
If they are allowed to supply a path component for a request a system
does in their behalf, then they can easily escape anything they were supposed
to be limited to.
The ignoring of dots at the start means they don't even have to know
exactly how deep their request is:
$ python3 -c 'import httpx;print(httpx.URL("https://example.com/public/api/public/resources/harmless/../../../../../../../../../internal/data"))'
https://example.com/internal/data
So even if the resource server securely handles request
(unless you consider not having any way to lower your permissions for one request to a specific subset),
your fully RFC conforming client library will already request the permission they should not have permission for.
Even worse dots are usually not characters you can easily forbid so once slashes are to be allowed things get complicated.
There also would have been a simple, elegant and secure way:
Consider every path element ".." or "."
in an (absolute) URL an error.
Define a reference resolution that allows the relative reference to only start
with "./" or one or multiple "../" and
consider every appearance of a dot or two dots as path components after than an error.
Everything joining two paths has to either use an implementation of that path joining
algorithm, but only if they want to joins paths in the potentially dangerous
way allowing leading "../". Otherwise they can just use the normal
join and even if an attacker gets those dots that will just cause the generated URL
to be rejected as invalid.
Of course using a secure implementation is now even more inconvenient thanks to RFC 3986 being around:
If you have no control over the generator of relative references, it is always possible
that they generate relative references with ".." components after non-dot
components.
And if you check all code to properly filter out "/../",
keep in mind that convienence does not stop there.
After all it is not unheared of for server implementations to helpfully normalize
unicode characters, too, or translate them to their nearest ASCII equivalents.
Or translate percent escaped characters back before doing path splitting.
Or you might think there was some unicode codepoints between those two dots,
but they that those were some meaningless control characters that can be omitted.
So you need some really restrictive allow lists...
I dedicate this release of C-Kermit to Frank da Cruz. Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long. When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so. Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines. As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit. John Goerzen, July 2026
$ ./packet_edit_meme [*] target /bin/su as uid 1000; entry at file offset 0x4340; shellcode 48 bytes unshare: Permission denied [-] page-cache corruption failedHere is the audit log entry for this failure:
type=AVC msg=audit(1785640621.498:1843): avc: denied create for pid=1770 comm="packet_edit_mem" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=user_namespace permissive=0Here s the result of running it from the unconfined_t domain:
$ ./packet_edit_meme [*] target /bin/su as uid 1001; entry at file offset 0x4340; shellcode 48 bytes [+] su entry overwritten; exec'ing su -> interactive root shell # id uid=0(root) gid=0(root) groups=0(root),1001(test2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 #Daniel Baumann wrote a blog post describing how this is fixed for Debian systems without SE Linux.
| Series: | Chaotic Orbits #2 |
| Publisher: | DAW Books |
| Copyright: | December 2024 |
| ISBN: | 0-7564-1949-2 |
| Format: | Kindle |
| Pages: | 143 |
"I don't think anyone should have enough personal wealth to decimate a large country's income just because he's going through a midlife crisis."Ada's interactions with Strom Fetor are an absolute delight. He is so sure of himself that he is incapable of registering her as a threat, and she effortlessly deceives him by hiding in plain sight.
"You really shouldn't be talking about this," Rian starts. Fetor waves aside his concerns. "We're all friends here." "Not me," I say. "I hate you. Remember?" Fetor laughs in a tone I'm sure he thinks is charming.Fetor's complete inability to realize that a beautiful woman might both sincerely not like him and not be flirting with him is perfect. I was cackling through half of this book. Like any good heist story, there are twists and turns, surprises, double agents, unexpected complications, and a delightful amount of verbal fencing. I adore the narrative tone Revis uses for these stories. Ada has just the right mix of idealism, cynicism, professionalism, and irreverence to carry off the feeling that she's a step ahead of everyone else. Underneath the bones of a delightful plot is a character who cares deeply but is very aware of her limitations, and therefore has taught herself to laugh at and be ruthless with her own emotions. I am finding it an incredibly compelling type of competence porn. I enjoyed the first book of this series, but this one was so much better. These stories are exactly the right length to keep the reader engrossed throughout and satisfied but wanting more at the end. How to Steal a Galaxy ends on a cliffhanger of sorts, to be resolved in the next and final book. I can hardly wait to start it. Highly recommended. Followed by Last Chance to Save the World. Rating: 9 out of 10
| Series: | Midlife Recorder #2 |
| Publisher: | Linzi Day |
| Copyright: | November 2022 |
| ISBN: | 9798360228431 |
| Format: | Kindle |
| Pages: | 577 |
I built my current house server back in 2019. It had an upgrade from the original Ryzen 2700 to a 5700G in late 2021, but otherwise is still running with the original setup. Back in November it developed some erratic behaviour (initially manifesting as problems with the TPM, which is ironic as I ve spent a bunch of time at my day job trying to improve TPM reliability), culminating in unreliable reboots. I had a limited amount of ability to swap parts out, but ultimately decided it was a motherboard issue (thinking perhaps VRM problems), found a replacement locally, and everything seemed fine.
Until May.
At that point I rebooted the machine for a Debian point release, and it failed to come back. Fans would spin, but there was no sign of actual life. I ended up pressing a temporary machine into service (that could at least run the Home Assistant container, and a few other critical bits) while I tried to work out what was wrong. I d kept the previous motherboard, and still had the Ryzen 2700, so I did a bunch of swaps (and obtained a motherboard buzzer to try and get some indication about whether there were useful beep codes being emitted), and ultimately came to the conclusion that the CPU had died.
I m not quite clear what happened here. I played it safe and replaced the PSU at the same time, in case that was the original cause back in November and ultimately damaged the CPU, but both old + new motherboards worked just fine with the 2700.
That left a decision about what to do. This previous server was from 2013, so this machine has now lasted longer than that and I could justifiably upgrade. However when I went to look at what the equivalent modern machine would be it s only a couple of generations later (Zen 5 vs Zen 3), and 64GB RAM alone would have set me back ~ 1k. For not a lot of gain. So I ended up buying a replacement Ryzen 5700G, hopefully allowing me to put off thinking about an upgrade until Zen 6 is out, and RAM prices are saner (though I understand that might take a couple of years).
It s not the first time I ve had a faulty PSU be the cause of a dead machine, but it was a pretty frustrating experience.
Next.