Live data from Hacker News

Why does Debian change software?

blog.liw.fi

131–140 of 210 posts

Re: Why does Debian change software?

#131
post #16

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/po…

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”.

Re: Why does Debian change software?

#132
post #16

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/po…

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.

Re: Why does Debian change software?

#133
post #57
post #55

Earlier quoted context omitted.

Yeah, NixOS for all servers (homelab + dedicated remote ones) and Arch on desktop.

Arch is a minefield on this regard tbh

Arch has been bliss for me. I'm heavy on Flatpaks and primarily use Arch as a base operating system with very minimal config changes.

Re: Why does Debian change software?

#134
post #73
post #4

Debian 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.

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

Unfortunately that is not entirely true.

For example, when closing firefox on OpenSUSE Leap 15.6, "pingsender" is launched to collect telemetry:

https://imgur.com/a/k3Nnbbj

It has been there for years. It is also on other distros.

Re: Why does Debian change software?

#135
post #66

Earlier quoted context omitted.

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.

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.

The crazy thing is that after this incident they restored the uninitialized usage and retained it there for the next half decade. It wasn't as mild as being a risk of future compilers destroying the universe: it made valgrind much less useful on essentially all users of OpenSSL, exactly what you want for security critical software.

(meanwhile, long before this incident fedora just compiled openssl with -DPURIFY which disabled the bad behavior in a safe and correct way).

Re: Why does Debian change software?

#136
post #9

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...

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).

> It's not clear why openssl never adopted the patch

OpenSSL already had an option to safely disable the bad behavior, -DPURIFY.

Re: Why does Debian change software?

#137
post #4

Debian 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.

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.

Re: Why does Debian change software?

#138
post #42

Earlier quoted context omitted.

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 beli…

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…

I didn't ask for you to second-guess my software. I didn't ask you to ship modified (potentially broken and/or substantially different in opinionated ways) versions of my software under the same name.

If you're going to do that, then you should actually let people know. Otherwise don't do it. It's not about "but the license allows it", it's about what the right thing to do is.

Debian has given me the most grief of any Linux distro by far. Actually, Debian is the only system I can recall giving me grief. Debian pushes a lot of work to the broader ecosystem to people who never asked for it.

I didn't choose to be associated with Debian, but I have no choice in the matter. You did choose to be associated with the packages you maintain.

So don't give me any of that "but my unpaid time!". Either do the job properly or don't do it at all. Both are fine; no maintainer asked you to package anything. They're just asking you to not indirectly push work on them by shipping random (potentially broken and/or highly opinionated) patches they're never even told about.

Re: Why does Debian change software?

#139
post #108
post #86

Earlier quoted context omitted.

> Telemetry contains personal data by definition. No. Please look up the definition of "telemetry" and "personal data". The latter always refers to an identifiable person.

Virtually all anonymization schemes are reversible, so “identifiable” isn’t carrying any weight in your definition. “Person” isn’t either, unless the software knows for sure it’s not being uses by a person.

[deleted]

Re: Why does Debian change software?

#140
post #129

Earlier quoted context omitted.

IPs are PII. You hit the server, and your anonymity is breached.

Yes, so the vendor must not store it. Something along those lines is usually said in the privacy policy. If you don't trust the vendor to do that, then do not opt-in to sending data, or even better, do not use the vendor's software at all.

Sometimes, we have to or we simply want to run software from developers we don't know or entirely trust. This just means that the software developer needs to be treated as an attacker in your threat model and mitigate accordingly.

I would argue that users can't inherently trust the average developer anymore. Ideas about telemetry, phoning home, conducting A/B tests and other experiments on users, and fundamentally, making the software do what the developer wants instead of what the user wants, have been thoroughly baked in to many, many developers over the last 20 or so years. This is why actually taking privacy seriously has become a selling point: It stands out because most developers don't.

Post reply on HN