Why does Debian change software?
209 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
gus_
Unfortunately that is not entirely true.
For example, when closing firefox on OpenSUSE Leap 15.6, "pingsender" is launched to collect telemetry:
It has been there for years. It is also on other distros.
diggan
Did someone report/open a issue about it? Maybe it's as simple as them not being aware of it.
winternewt
I wouldn't think the Firefox license allows them to do that. I thought only binaries built by Mozilla could use the FF brand.
rmccue
Indeed, Mozilla only recently allowed Debian to use the brand for their modified version: https://en.wikipedia.org/wiki/Debian%E2%80%93Mozilla_tradema...
akdev1l
That’s the reason for a while we had IceWeasel
pabs3
This is unfortunately not part of Debian Policy yet, and there are still lots of privacy issues of different severities in Debian.
diggan
I don't use Debian for servers nor personal computers anymore, but the fact that they themselves host a page explaining potential privacy issues with Debian makes me trust them a lot more, and feel safer recommending it to others when it fits.
pabs3
Thats just a wiki page, written by myself and a bunch of other Debian members/contributors. Don't read too much into it :)
keysdev
What are you using instead now? Nixos?
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.
jchw
To be fair, we (Nixpkgs maintainers) do remove or disable features that phone home sometimes even though it's not policy. That said, it would be nice if it was policy. Definitely was discussed before (most recently after the devbox thing I guess.)
sshine
Discord downloads stuff every single time I start it. So there is definitely not a policy to remove this behaviour.
And yes, good point, this was indeed discussed when devbox enabled AI training by default. It somehow seems like there is more than one category of phoning home at play here, since it is obviously tolerated in other cases.
pabs3
I'm glad that opensnitch is available in Debian trixie too, to mitigate the issues that Debian has not found yet.
binaryturtle
Why can't I get GNOME stop calling home? (on a Debian installation) Each time I fire up my Debian VM with GNOME here on my OSX host system Little Snitch pops up because some weird connection to a GNOME web endpoint. One major pet peeve of mine.
LtWorf
You can ask the gnome team if they'd accept a patch. They might be of the idea that patching stuff out is bad.
28304283409234
Please send patches.
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:
hedora
The maintainer’s responses in that thread are really frustrating. They just keep describing the bug as though the package’s behavior is acceptable.
I wonder what debian’s process is for dealing with such maintainers.
I hope they make “no phone home” actual policy soon.
ryandrake
Infuriating. The developer is just making excuses and refusing to address the users' actual concern. And why are they phoning home in the first place? What is this critical use case that requires this intrusion?
"This daily count of users is what keeps us working on the project, because otherwise we have feel like we are coding into a void."
guappa
It's not guaranteed that they manage to catch all the software that does this though :D
phoe-krk
Any such leftover behavior is going to be a reportable and fixable bug then.
guappa
I'm not sure it's explicitly in the policy or if any team can decide what to do…
hulitu
> It's not guaranteed that they manage to catch all the software that does this though :D
It is really hard to run netstat. Or tcpdump. /s
JohnFen
This is one of my favorite things about Debian.
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.
RetroTechie
> There is a lot of political stuff in there related to standards.
To be fair, in Debian's case politics come with the territory. Debian is a vision of what an OS should be like. With policies, standards & guidelines aimed at that, treating the OS as a whole.
That goes well beyond "gather packages, glue together & upload".
Same goes for other distributions I suppose (some more, some less).
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.
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.
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
If you go to https://tracker.debian.org/ for any package, it lists patches that need to be sent upstream.
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.
kragen
It was plausibly the worst computer security bug in human history, but by the same token, it's hard to see it as indicating a systemic problem with either Debian or OpenSSL. When we're dealing with a once-in-history event like that, where it happens is pretty random. It's the problem of inference from a small sample.
SAI_Peregrinus
On the other hand it exposed that OpenSSL was depending on Undefined Behavior always working predictably. Something as simple as a GCC update could have had the same effect across far more systems than just Debian, with no patch to OpenSSL itself.
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).
nullc
> It's not clear why openssl never adopted the patch
OpenSSL already had an option to safely disable the bad behavior, -DPURIFY.
aragilar
In one of two cases I believe? I wonder what would have happened if both calls ended up being wrapped, if the bug would have taken even longer than it did to be found...
t312227
hello,
as always: imho (!)
i remember this incident - if my memory doesn't trick me:
it was openssl which accessed memory it didn't allocated to collect randomness / entropy for key-generation.
and valgrind complained about a possible memory-leak - its a profiling-tool with the focus on detecting memory-mgmt problems.
instead of taking a closer look / trying to understand what exactly went on there / causes the problem, the maintainer simply commented out / disabled those accesses...
mistakes happen, but the debian-community handled this problem very well - as in my impression they always do and did.
idk ... i prefere the open and community-driven approach from debian anytime over distributions which are associated to companies.
last but not least, the have a social contract.
long story short: at least for me this was an argument for the debian gnu/linux distribution, not against :))
just my 0.02€
hedora
But why patch it in debian, and not file an upstream bug?
It’s doubly important to upstream issues for security libraries: There are numerous examples of bad actors intentionally sabotaging crypto implementations. They always make it look like an honest mistake.
For all we know, prior or future debian maintainers of that package are working for some three letter agency. Such changes should be against debian policy.
master_crab
If it involves OpenSSL, I will give the benefit of the doubt to everyone else first over OpenSSL.
Why? Heartbleed.
LtWorf
As some other comments say, the patch was posted to OpenSSL and someone said it was fine. They later said it wasn't a proper review.
jbverschoor
What would that have to do with phoning home?
rmccue
As someone who maintained a (PHP) library that Debian distributed, it fucking sucked that they made source modifications. There were a number of times where they broke the library in subtle ways, and there was little to no indication to users of the library that they were running a forked version. I also never had any contact from them about the supposed "bugs" they were patching.
diggan
> it fucking sucked that they made source modifications
As a maintainer, I can certainly understand how it feels like that, I'd probably wouldn't feel great about it either. As a user, I'm curious what kind of modifications they felt were needed, what exactly did they change in your library?
rmccue
The library I was maintaining (SimplePie) was an RSS feed parser which supported every flavour of the RSS/Atom specs. Because of the history of those particular formats, there were a huge number of compatibility hacks necessary to parse real-world data, and cases where the "spec" (actually just a vague page on a website) was inaccurate compared to actual usage.
This was a while ago (10+ years), but my recollection is that someone presumably had reported that parts of the library didn't conform to the spec, and Debian patched those. This broke parsing actual feeds, and caused weeks of debugging issues that couldn't be replicated. Had they reported upstream in the first instance, I could have investigated, but there was no opportunity to do so.
dgb23
That sounds very careless. Not only does this break an obviously deliberate feature, it also violates the robustness principle. Whether one likes it or not, it’s a guiding principle for the web. Most importantly this „fix“ was bad for its users.
Good intentions, but unfortunately bad outcome.
There was a somewhat recent discussion on here on how OS projects on GitHub are pestered by reports as well. Some athors commented that it even took away their motivation to publish code.
It’s always the same mechanism isn’t it. The „why we can’t have nice things“ issue. Making everything at least slightly worse, because there are people who exploit a system or trust based relationship.
diggan
Ah, that sounds like a terrible solution from Debian's side, and very unexpected. Sure, patching security/privacy issues kind of makes sense (from a user's POV), but change functionality like that? Makes less sense, especially if they didn't even try to get the changes upstream.
bityard
First I want to say that I love Debian. They have a great distro that is simple and quite frankly a joy to use, and manage to keep it all going on basically nothing but volunteer effort.
However, I do believe that in certain areas, they give too much freedom to package maintainers. The bar for being a package maintainer in Debian is relatively low, but once a package _has_ a maintainer--and barring any actual Debian policy violations--that person seems to have the final say in all decisions related to the package. Sometimes those decisions end up being controversial.
Your case is one example. Package maintainers ideally _should_ work with upstream authors, but are not required to because a LOT of upstream authors either cannot be reached, or actively refuse to be bothered by any downstream user. (The source tarball is linked on their home page and that's where their support ends!) I don't know what the solution is here, but there are probably improvements that could and should be made that don't require all upstream authors to subscribe to Debian development mailing lists.
parasti
Have had a similar experience as the upstream of a free game. They also sometimes forwarded those bugs to us.
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.
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.
dfedbeef
You run another distro that does things better?
yoyohello13
Fedora? Arch Linux? I have massive respect for the Debian maintainers, but I've had way fewer problems on those Distros.
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).
jmmv
I spent years packaging software (mostly Gnome 2.x) for NetBSD. I almost-always tried to upstream the local patches that were needed either for build fixes or improvements (like flexibility to adapt to non-Linux file system hierarchies or using different APIs).
It was exhausting though, and an uphill battle. Most patches were ignored for months or years, with common “is this still necessary?” or “please update the patch; it doesn’t apply anymore” responses. And it was generally a lot of effort. So patches staying in their distros is… “normal”.
arp242
Another issue is that these manpages can become outdated (and/or are downright wrong).
Overall I feel it's one of those Debian policies stuck in 1995. There are other reasonable ways to get documentation these days, and while manpages can be useful for some types of programs, they're less useful for others.
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.
guappa
Wow 1 instance. Ok. World ending.
null
yoyohello13
I respect the hell out of Debian and am grateful for everything they do for the larger ecosystem, but this is why I use Arch. It's so much easier just to refer to the official documentation for the software and know it will be correct. Also, I've never really encountered a situation where interop between software is broken by just sticking to vanilla upstream. Seems like modifying upstream is just a ton of work with so many potential breakages and downsides it's not really worth it.
bityard
You seem to be implying that Debian makes large significant changes to upstream software for the sake of integration with the rest of the OS and that Arch makes none at all. Neither of these is true.
yoyohello13
I understand it's a spectrum, but I lean toward minimal possible changes to upstream.
LtWorf
Also if that means the program won't run at all? Or a bug that has a patch to fix it doesn't get fixed? Or a device that could be supported is instead not supported?
I've made patches to a bunch of stuff to improve kde on mobile/tablets. After short or very long time they do get merged, but meanwhile people (like me) who own a tablet can actually use the software.
Why wait several months or even years?
frainfreeze
> Debian avoids including anything in the main part of its package archive it can’t legally distribute...
Related: netadata to be removed form Debian https://github.com/coreinfrastructure/best-practices-badge/i...
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.
Affric
I have phrased it as the author has phrased it.
What gives you the idea I think Debian are any more prone to mistakes than anyone else? It’s one of the two distros I use at home. I admire the devs a great deal.
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)?
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.
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
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.
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.
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.
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.
anthk
OpenBSD too, but for security and proper POSIX functions vs Linuxisms, such as wordexp.