11 ms·
Why does Debian change software?
- BonusPlay 1y agoNot 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 1y agoAs 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 1y agoPatching 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. https://wiki.debian.org/PrivacyIssues https://wiki.debian.org/PrivacyIssues
- alias_neo 1y agoThanks 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.
- pabs3 1y agoHomelabs are usually running software not from a distro too, so potentially more privacy issues there too. Firewalling outgoing networking, along with a filtering SOCKS proxy like privoxy might be a good start.
- twic 1y agoI understood what it meant immediately, but i think only because i already knew that Debian are infamous for doing this.
- mnw21cam 1y agoMe too. I was hoping for an explanation of why the software I have got used to and works very well and isn't broken keeps being removed from Debian in the next version because it is "unmaintained".
- TekMol 1y agoDebian will remove code that “calls home” or tries to update software in a way that bypasses the Debian packaging system. Thank god. I'm so happy that such a distro exists.
- guappa 1y agoIt's not guaranteed that they manage to catch all the software that does this though :D
- sshine 1y agoThis 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.
- Affric 1y agoBut what does Debian see as the risks of patching the software they distribute and how do they mitigate them?
- guappa 1y agoDebian 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 1y agoI 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 1y agoI 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)?
- lifthrasiir 1y agoThe 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_keys_(Debian-specific) https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_ke...
- guappa 1y agoDo 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 1y agoThat 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 1y agoIf you go to https://tracker.debian.org/ https://tracker.debian.org/ for any package, it lists patches that need to be sent upstream.
- lifthrasiir 1y agoAh, I meant more about policies and guidelines. I'm not well-versed in Debian processes so I can for example imagine that only some patches get sent to the upstream only at the maintainers' discretion. It seems that Debian at least has a policy to maintain patches separate from the upstream source though.
- JdeBP 1y agoThe 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.
- guappa 1y agoThat only happens if the project lacks a manual page or if it's really bad.
- JdeBP 1y ago"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/debian/iptunnel.8 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/iptunnel.8 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/man/en_US/iptunnel.8 https://salsa.debian.org/debian/net-tools/-/blob/debian/sid/... This sort of thing isn't a rare occurrence.
- guappa 1y agoWow 1 instance. Ok. World ending.
- pabs3 1y agoUsually 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.
- INTPenis 1y agoThis 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.
- ahoka 1y ago"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.
- steeleduncan 1y ago> 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 1y agoI 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.
- cess11 1y agoPretty 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.
- hsbauauvhabzb 1y agoDo 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?
- pabs3 1y agoThey 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.
- steeleduncan 1y ago> ... 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 1y agoThey 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 https://udd.debian.org/patches
- hsbauauvhabzb 1y agoSorry to clarify, I mean in a way that’s easily parseable. I’m not pulling down source files of every dev installed on my system to inspect raw .patch files and take the time to understand the differences. You seem to be assuming malice in an innocent question though, that’s on you.
- pjc50 1y agoThere should be a source package for every binary package, and patches are usually in a subdirectory of the package.
- gspr 1y ago> 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 https://udd.debian.org/patches.cgi
- jeroenhd 1y agoAll 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 1y agoThe patches and their explanations are listed here: https://udd.debian.org/patches.cgi?src=xscreensaver&version=6.09%2Bdfsg1-1 https://udd.debian.org/patches.cgi?src=xscreensaver&version=... Edit: can't find any that are for aesthetic reasons.
- mnau 1y ago91_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 1y agoI'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.
- sneak 1y agoIIRC it just hardcodes the release date and complains if it is more than 2 or 3 years later. It’s somewhat reasonable. I agree Debian should patch out phone-home and autoupdate (aka developer RCE). They should have left the xscreensaver local-only warning in, though. It is not a privacy or system integrity issue. jwz however is also off the rails with entitlement. They’re both wrong.
- mschuster91 1y ago
- anthk 1y agoOpenBSD too, but for security and proper POSIX functions vs Linuxisms, such as wordexp.
- commandersaki 1y agoYeah 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 1y agoI 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 1y agoSince 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 1y agoI'm using Arch and, AFAIK, it tries to use upstream code as much as possible. That's much better model IMO.
- Hackbraten 1y agoWhy do you assume Debian packagers don’t do the same?
- galad87 1y agoThe 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 1y agoYou run another distro that does things better?
- yoyohello13 1y agoFedora? Arch Linux? I have massive respect for the Debian maintainers, but I've had way fewer problems on those Distros.
- rmccue 1y agoAs 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 1y ago> 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 1y agoThe 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.
- diggan 1y agoAh, 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.
- dgb23 1y agoThat 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.
- deleted 1y ago[deleted]
- yoyohello13 1y agoI 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 1y agoYou 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 1y agoI understand it's a spectrum, but I lean toward minimal possible changes to upstream.
- LtWorf 1y agoAlso 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 1y ago> 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/issues/2153#issuecomment-2898871595 https://github.com/coreinfrastructure/best-practices-badge/i...
- 1vuio0pswjnm7 1y agohttps://lists.debian.org/debian-security-announce/2008/msg00152.html https://lists.debian.org/debian-security-announce/2008/msg00...