Why does Debian change software?
74 comments
·May 22, 2025TekMol
exiguus
Most good stuffed Distros do this. For example SUSE recently banned a package because of "calling home" e.g. did side-leading. https://security.opensuse.org/2025/05/07/deepin-desktop-remo...
Debian indeed does this. In release FF has disabled telemetry: https://wiki.debian.org/Firefox
pjmlp
So they have their own Go fork?
Just one possible example, among many others that have telemetry code into them.
deng
No they don't. The formulation in TFA is a bit too generic - Debian will usually not remove any code that "calls home". There are perfectly valid reasons for software to "phone home", and yes, that includes telemetry. In fact, Debian has its own "telemetry" system:
Telemetry is perfectly acceptable as long as it is opt-in and does not contain personal data, and both apply to Go's telemetry, so there's no need for a fork.
layer8
“Will remove” means that it’s one of the typical/accepted reasons why patches are applied by Debian maintainers, as in meaning 4 here [0], not that there is a guarantee of all telemetry being removed.
pabs3
This is unfortunately not part of Debian Policy yet, and there are still lots of privacy issues of different severities in Debian.
sshine
This policy is missing from nixpkgs, although there is a similar policy for the build process for technical reasons.
So I can add spotify or signal-desktop to NixOS via nixpkgs, and they won’t succeed at updating themselves. But they might try, which would be a violation of Debian’s guidelines.
It’s a tough line — I like modern, commercial software that depends on some service architecture. And I can be sure it will be sort of broken in 10-15 years because the company went bust or changed the terms of using their service. So I appreciate the principles upheld by less easily excited people who care about the long term health of the package system.
mort96
In the process of trying to update, Spotify on NixOS will likely display some big error message about how it's unable to install updates, which results in a pretty bad user experience when everything is actually working as intended. It seems fair to patch software to remove such error messages.
guappa
It's not guaranteed that they manage to catch all the software that does this though :D
pabs3
I'm glad that opensnitch is available in Debian trixie too, to mitigate the issues that Debian has not found yet.
vaporary
I was extremely disappointed to recently learn that visidata(1) phones home, and that this functionality has not been disabled in the Debian package, despite many people requesting its removal:
lqet
One of the many reasons I switched from Ubuntu to Debian 2 years ago. Another reason was snap.
master_crab
Yup. Snap is emblematic of all the complexity Canonical bakes into Ubuntu.
lifthrasiir
The counterpoint would be the Debian-specific loss of private key entropy [1] back in 2008. While this is now a very ancient bug, the obvious follow-up question would be: how does Debian prevent or mitigate such incidents today? Was there any later (non-security, of course) incident of similar nature?
[1] https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_ke...
upofadown
Debian does a lot of patching that is not strictly required for distribution reasons. Here are the GnuPG patches for example:
* https://udd.debian.org/patches.cgi?src=gnupg2&version=2.4.7-...
There is a lot of political stuff in there related to standards. For a specific example see:
* https://sources.debian.org/src/gnupg2/2.4.7-19/debian/patche...
The upstream GnuPG project (and the standards faction they belong to) specifically opposes the use of keys without user IDs as it is a potential security issue. It is also specifically disallowed by the RFC4880 OpenPGP standard. By working through the Debian process, the proponents of such keys are bypassing the position of the upstream project and the standard.
guappa
Do you have any statistics that show that Debian patches introduce more CVE worthy bugs than the software already contains? OpenSSL doesn't really have a pristine history.
Let's not forget that the patch had been posted on the OpenSSL mailing list and had received a go ahead comment before that.
Having said that, if you're asking if there's a penetration test team that reviews all the patches. No there isn't. Like there isn't any such thing on 99.999999999% of all software that exists.
lmm
The patch was posted on the wrong OpenSSL mailing list, and frankly that particular Debian bug was worse than anything else we've seen even from OpenSSL.
Last I knew Debian didn't do dedicated security review of patches to security-critical software, which is normal practice for other distributions.
lifthrasiir
That was the kind of answer I wanted to hear, thanks. (Of course I don't think Debian should be blamed for incidents.) Does Debian send other patches as well? For example, I didn't know that Debian also often creates a man page by its own.
aragilar
If you go to https://tracker.debian.org/ for any package, it lists patches that need to be sent upstream.
pabs3
Debian definitely aims to contribute upstream, but that doesn't always happen, due to upstream CLAs, because most Debian packagers are volunteers, many Debian contributors are busy, many upstreams are inactive and other reasons.
aragilar
https://research.swtch.com/openssl provides more context: openssl was asked about the change, and seemingly approved it (whether everyone understood what was being approved is a different question). It's not clear why openssl never adopted the patch (was everyone else just lucky?), but I wonder what the reaction would have been if the patch had been applied (or the lines hidden away by a build switch).
master_crab
If it involves OpenSSL, I will give the benefit of the doubt to everyone else first over OpenSSL.
Why? Heartbleed.
JdeBP
The point about manual pages has always seemed to me to be one of the points where the system fails us. There are a fair number of manual pages that the world at large would benefit from having in the original softwares, that are instead stuck buried in a patches subdirectory in a Debian git repository, and have been for years.
This is not to say that Debian is the sole example of this. The FreeBSD/NetBSD packages/ports systems have their share of globally useful stuff that is squirrelled away as a local patch. The point is not that Debian is a problem, but that it too systematizes the idea that (specifically) manual pages for external stuff go primarily into an operating system's own source control, instead of that being the last resort.
pabs3
Usually the Debian manual page author or package maintainer will send that upstream. Same goes for patches. Sometimes upstream doesn't want manual pages, or wants it in a different format, and the Debian person doesn't have time to rewrite it.
JdeBP
There's a belief that this is usual. But having watched the process for a couple of decades, it seems to me that that is just a belief, and actual practice doesn't work that way. A lot of times this stuff just gets stuck and never sent along.
I also think that the idea that original authors must not accept manual pages is a way of explaining how the belief does not match reality, without accepting that it is the belief itself that is wrong. Certainly, the number of times that things work out like the net-tools example elsethread, where clearly the original authors do want manual pages, because they eventually wrote some, and end up duplicating Debian's (and FreeBSD's/NetBSD's) efforts, is evidence that contradicts the belief that there's some widespread no-manual-pages culture amongst developers.
capitol_
It's also easy for people to have the opinion the those who do the unpaid work of packaging software should do even more work for free.
I have sent about 50 or so patches upstream for the 300 packages I maintain and while it reduces the amount of work long-term it's also surprisingly amount of work.
Typically the Debian patches are licensed under the same license as the original project. So there is nothing stopping anyone who feels that more patches should be sent upstream to send them.
Typically the Debian maintai
ckastner
This.
And often it's not an unhelpful upstream, just an upstream that sees little use for man pages in their releases, and doesn't want to spend time maintaining documentation in parallel to what their README.md or --help provides (with which the man page must be kept in sync).
guappa
That only happens if the project lacks a manual page or if it's really bad.
JdeBP
"only happens" is a lot more often that you think. In my experience, "only" is quite frequent.
A randomly picked case in point:
Debian has had a local manual page for the original software's undocumented (in the old Sourceforge version) iptunnel(8) command for 7 years:
https://salsa.debian.org/debian/net-tools/-/blob/debian/sid/...
Independently, the original came up with its own, quite different, manual page 3 years later:
https://github.com/ecki/net-tools/blob/master/man/en_US/iptu...
Then Debian imported that!
https://salsa.debian.org/debian/net-tools/-/blob/debian/sid/...
This sort of thing isn't a rare occurrence.
null
jeroenhd
All of these reasons are good, but they're not comprehensive. Unless someone can tell me what category Debian's alterations to xscreensaver fall under, maybe. As far as I can tell, that was just done for aesthetic reasons and packagers disagreeing with upstream.
pabs3
The patches and their explanations are listed here:
https://udd.debian.org/patches.cgi?src=xscreensaver&version=...
Edit: can't find any that are for aesthetic reasons.
mnau
91_remove_version_upgrade_warnings.patch is the one for asthetic reasons.
Debian keeps ancient versions that have many fixed bugs. Upstream maintainer has to deal with fallout of bug reports of obsolete version. To mitigate his workload, he added obsolete version warning. Debian removed it.
quietbritishjim
I'll admit that I haven't inspected the patch, but how could that warning possibly work without checking version information somewhere on the internet? That was listed in OP.
BonusPlay
Not the best name for the article. My first guess was version changes, or software being added/removed from repo. Turns out this is about source code modification.
alias_neo
As a native (British) English speaker, I was also unclear until reading the article.
Personally, I believe s/change/modify would make more sense, but that's just my opinion.
That aside, I'm a big fan of Debian, it has always "felt" quieter as a distro to me compared to others, which is something I care greatly about; and it's great to see that removing of calling home is a core principle.
All the more reason to have a more catchy/understandable title, because I believe the information in those short and sweet bullet points are quite impactful.
pabs3
Patching out privacy issues isn't in Debian Policy, its just part of the culture of Debian, but there are still unfixed/unfound issues too, it is best to run opensnitch to mitigate some of those problems.
alias_neo
Thanks for the link, that'll come in very useful.
> it is best to run opensnitch to mitigate some of those problems
Opensnitch is a nice recommendation for someone concerned about protecting their workstation(s); for me, I'm more concerned about the tens of VMs and containers running hundreds of pieces of software that are always-on in my Homelab, a privacy conscious OS is a good foundation, and there are many more layers that I won't go into unsolicited.
galad87
The best part is when they swap FFmpeg or other libraries, make things compile somehow, don't test the results, and then ship completely broken software.
anthk
OpenBSD too, but for security and proper POSIX functions vs Linuxisms, such as wordexp.
Affric
But what does Debian see as the risks of patching the software they distribute and how do they mitigate them?
guappa
Debian isn't a single person. A lot of patches are backport fixes for CVEs.
Then there's stuff like: "this project only compiles with an obsolete version of gcc" so the alternatives are dropping it or fixing it. Closely related are bugs that only manifest on certain architectures, because the developers only use amd64 and never compile or run it on anything else, so they make incorrect assumptions.
Then there's python that drops standard library modules every release, breaking stuff. So they get packaged separately outside of python.
There's also cherry picking of bugfixes from projects that haven't released yet.
Is there any reason you think debian developers are genetically more prone to making mistakes than anyone else? Considering that debian has an intensive test setup that most projects don't even have.
aragilar
I mean, it would depend on what the patch is? If you're adding a missing manpage, I'm not sure what can go wrong? Is changing the build options (e.g. enabling or disabling features) a patch, or an expected change (and if such a config option is bad, what blame should be put on upstream for providing it)? What about default config files (which could both make the software more secure or less, such as what cyphers to use with TLS or SSH)?
hsbauauvhabzb
Do distro maintainers share patches, man pages, call home metrics and other data with other distros’ maintainers (and them back)?
Further, do they publish any change information publicly?
pjc50
There should be a source package for every binary package, and patches are usually in a subdirectory of the package.
steeleduncan
> ... do they publish any change information publicly?
This is utter FUD, of course they do, it is an open source distribution. Everything can be found from packages.debian.org
sgc
They even have a portal that publishes this information specifically, with statistics, and many notes as to why a specific change has been made: https://udd.debian.org/patches
pabs3
They usually send everything upstream, and everything is public in their source control. Some maintainers look at repology.org to find package stuff from other distros.
gspr
> Do distro maintainers share patches, man pages, call home metrics and other data with other distros’ maintainers (and them back)?
Yes, at a minimum the patches are in the Debian source packages. Moreover, maintainers are highly encouraged to send patches upstream, both for the social good and to ease the distribution's maintenance burden. An automated tool to look for such patches is the "patches not yet forwarded upstream" field on https://udd.debian.org/patches.cgi
commandersaki
Yeah no thanks, just look at the abomination like pure-ftpd, apache, nginx, etc. I don't need some weird opinion configuration framework to go with the software I use.
Barrin92
I second that. Not only are there not infrequent cases of package maintainers breaking software, it's effectively nothing but the "app store" model, having an activist distributor insert themselves between the user and software.
It's why I'm really glad flatpaks/snaps/appimages and containerization are where they are at now, because it's greatly dis-intermediated software distribution.
gspr
Since this is the FOSS world, you are of course free to eschew distributions. But:
> it's effectively nothing but the "app store" model, having an activist distributor insert themselves between the user and software.
is just factually wrong. Distributions like Debian try to make a coherent operating system from tens of thousands of pieces of independently developed software. It's fine not to like that. It's fine to instead want to use and manage those tens of thousands of pieces of independent software yourself. But a distribution is neither an "app store", nor does it "insert itself" between the user and the software. The latter is impossible in the FOSS world. Many users choose to place distros between them and software. You can choose otherwise.
vbezhenar
I'm using Arch and, AFAIK, it tries to use upstream code as much as possible. That's much better model IMO.
INTPenis
This is one of the reasons I switched to RHEL 10+ years ago.
I actually prefer the RHEL policy of leaving packages the way upstream packaged them, it means upstream docs are more accurate, I don't have to learn how my OS moves things around.
One example that sticks out in memory is postgres, RHEL made no attempt to link its binaries into PATH, I can do that myself with ansible.
Another annoying example that sticks out in Debian was how they create admin accounts in mysql, or how apt replaces one server software with another just because they both use the same port.
I want more control over what happens, Debian takes away control and attempts to think for me which is not appreciated in server context.
It swings both ways too, right now Fedora is annoying me with its nano-default-editor package. Meaning I have to first uninstall this meta package and then install vim, or it'll be a package conflict. Don't try and think for me what editor I want to use.
yxhuvud
> I actually prefer the RHEL policy of leaving packages the way upstream packaged them
Unless something has changed in the last 10 years that has passed since I last used anything RHEL-based, there are definitely no such policy.
steeleduncan
> I actually prefer the RHEL policy of leaving packages the way upstream packaged them
I don't think RHEL is the right choice if this is your criteria. Arch is probably what you are looking for
mrweasel
I don't think that's true for Red Hat, but it is true for Slackware.
If you want packages that works just like the upstream documentation, run Slackware.
Debian does add some really nice features in many of their packages, like a easy way to configure multiple uWSGI application using a file per application in a .d directory. It's a feature of uWSGI, but Debian has just package it up really nicely.
ahoka
"I actually prefer the RHEL policy of leaving packages the way upstream packaged them"
Are you kidding now? Red Hat was always notorious of patching their packages heavily, just look download an SRPM and have a look.
cess11
Pretty much everyone has had nano as default for ages, at least that's how it seems to me from having had to figure out which package has script support and installing vim myself after OS install for a long time.
And RedHat does a lot of fiddling in their distributions, you probably want something like Arch, which is more hands-off in that regard. Personally, I prefer Debian, it's the granite rock of Linux distributions.