11 ms·

> It turns out that Ubuntu uses a modified version of accountsservice that includes some extra code that doesn’t exist in the upstream version maintained by fre

> It turns out that Ubuntu uses a modified version of accountsservice that includes some extra code that doesn’t exist in the upstream version maintained by freedesktop. I guess next time people ask why I like a distro like Arch that doesn't insert its own junk into upstream code over Debian/Ubuntu/et al, I'll have a new example handy to cite.

symlinkk 6y ago
Yeah I hate it when distros do this. Does Debian actually change upstream significantly? I thought they kept things fairly vanilla. I know Fedora patched in VAAPI support on Firefox before it was merged into the Mozilla codebase. I can’t think of a worse piece of software to patch, the last thing I want to be running untested code on is my web browser.
- jasonjayr 6y ago
  Most of the Debian changes I've seen consist of changing default paths to match Debian's standards, backporting security changes (esp if a version bump changes functionality), and support 'conf.d' directories so packages can drop-in configuration files, and remove them easily.
  - ClumsyPilot 6y ago
    > "backporting security changes (esp if a version bump changes functionality" Thats not a trivial matter, its a potential source of many issues
    - marcosdumay 6y ago
      It's also a source of many solutions. There are really no perfect option here. Upstream and distro developers have different goals, and it's up to you to decide what you should adopt.
      - jhardy54 6y ago
        Opinion: the 'perfect solution' is to keep up with upstream and avoid backporting. It takes more work, but it reduces the separation between distro and upstream.
        tsimionescu 6y ago
        That's definitely not ideal for users, though. Forced updates every 6 months is annoying to most people. Forced updates every day or so would be annoying to basically everyone.
        bipson 6y ago
        Running Fedora since I-don't-even-remember-when (around 2008?) and I was never annoyed (unless I try to run CUDA and the like, because they rely on e.g. an ancient GCC etc.). In particularly it was a significant improvement over the annoyances of Ubuntu, and I am still angry when thinking about the brief period I was maintaining a bunch of servers running Debian. Really unnecessarily difficult - particularly updating/upgrading and trying to clear the mess their systemd approach caused, in particular missing unit files for popular services (I think it was the isc-dhcp-server).
        tsimionescu 6y ago
        But this means that you are happy to upgrade all of your computer every six months or whatever Fedora's cadence is. Most people are definitely not happy to do so, because updates mean changes to stuff that works, and most people hate it when stuff that already works changes beneath them. This is of course even worse if you are not the end-user but are trying to ship an appliance to your customers. Why would you want to update the entire appliance OS in the field fo all of your customers just to ship a security patch, instead of sticking with the same base OS on already released appliances?
        bipson 6y ago
        Hm, let's dissect. Upgrade schedule for Fedora is twice a year, yes. Goes by without any issues, stuff still works. There is change and then there is change. Yes, I understand that some things don't need to change, and why do they always have to. Do I need my Desktop to still resemble 3.11 because "Why did it ever change"? - No. Some things in life simply change and they always have. I try to keep up where change is necessary. And if I would be shipping appliances to customers, why should I have "forced updates" of any kind outside of my control? I would never sell anything without my own repos, quality control, etc. Do you seriously sell Debian devices to anyone and support them, if anything outside of your control breaks? I seriously don't understand the argument. And if I ship software of any kind that relies on some libraries, I have to maintain it, of course. This includes going with the major releases. If this is embedded hardware, where there simply are only two or three updates in its lifetime, everything is different of course, but how on earth would I then have forced updates from RedHat??
    - eikenberry 6y ago
      Yes, but the alternative is un-patched security issues. Non-trivial but important.
      - jhasse 6y ago
        No the alternative can also be to live with functionality changes.
        eikenberry 6y ago
        New functionality means new bugs and breaking changes to old functionality. Sometimes the trade-off is worth it, but don't like being forced to update when it isn't.
    - eeZah7Ux 6y ago
      It's the whole point of having a distribution. If I wanted an endless stream of new vulnerabilities I can just use upstream software.
  - jhasse 6y ago
    Note that "bugfixes" are most of the time considered as a functionality change.
- girst 6y ago
  Regarding Fedora's Firefox: The Fedora Firefox mainainers, Martin Stransky and Jan Horak, are also the main maintainers of the Linux/GTK parts of Firefox. The VAAPI patches you've mentioned are (afair) mostly-if-not-all Martin's work. So he's not applying some rando's "untested" patches.
  - symlinkk 6y ago
    But the patches weren’t in Firefox’s codebase, so they didn’t go through the typical Firefox QA process including the Nightly, Beta, etc process. I’m not saying those guys don’t know what they’re doing, obviously they are experts. But I would prefer to trust but verify (not just trust).
- npsimons 6y ago
  > Does Debian actually change upstream significantly? I thought they kept things fairly vanilla. IME, they do keep things fairly vanilla, and I speak as someone who has run Debian since . . . I wanna say 2002? Plus I've done kernel dev work, and Debian's kernel patches ain't nothing compared to what RedHat used to do.
  - freedomben 6y ago
    I maintain a custom/forked driver[1] and support both Fedora/RHEL/CentOS and Ubuntu, and while Ubuntu has gotten much better, in years past I actually had to manage Ubuntu specific branches because they were so hacked up with custom patches from Canonical. I would spend more time fixing Ubuntu weirdness than I would all other distros combined. It's gotten much better the past several releases though, so thank you to Canonical for that :-) The various RPM flavors keep their kernels vanilla enough that I can mostly just rebase on top of linux-stable, and it's been that way since I started 7 years ago (according to github). Arch is the winner. I've never had to make a custom patch for Arch. Disclaimer: I work for Red Hat but opinions are my own [1]: https://github.com/FreedomBen/rtl8188ce-linux-driver https://github.com/FreedomBen/rtl8188ce-linux-driver
    - npsimons 6y ago
      Fair enough, but I don't put Ubuntu in the same class as Debian, because while they may share many base packages in common, I do seem to remember them patching the kernel more than Debian, and usually stuff that would break my kernel dev too. Hence another reason I'm not on Ubuntu.
      - freedomben 6y ago
        Agreed. On a related but different note it does seem like Debian gets (unfairly) painted with light generated by Ubuntu. I run Debian on some machines and most of the issues I have with Ubuntu are not problems on Debian (such as: Snap obsession and forcing, Abandoned/system-wrecking PPAs that are hard to recover from, etc)
- lmm 6y ago
  > Does Debian actually change upstream significantly? I thought they kept things fairly vanilla. No, they radically change things to match their standards. E.g. look at their tomcat package which explodes it all over the filesystem.
  - gspr 6y ago
    What is a distribution if not a collection of software that obey the same standard? Without the latter, all you have is a burlap sack full of software. Hardly a distribution. Fine if that's what you want, but it's not what Debian is.
    - lmm 6y ago
      A distribution is by definition distributing something that already exists, so I think distributions that stick close to upstream are more in the spirit of the concept. I also think Debian's approach has shown itself to produce something less reliable on the whole. Of course if you prefer the Debian approach, knock yourself out.
      - gspr 6y ago
        For those of you that don't like that terminology: let's just use the words that Debian itself uses, namely "the universal operating system". What is an operating system if not a collection of software that follow a standard so as to interoperate? > I also think Debian's approach has shown itself to produce something less reliable on the whole I think the opposite. Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example.
        lmm 6y ago
        > Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example. Debian's patches to cdrecord introduced so many bugs that they eventually ended up driving the original author away from open source. I think I remember something about the python 2 -> 3 transition being harder on Debian because of changes they've made? The packaged Tomcat on Debian is so different that every time I've seen someone running Tomcat they've installed it manually instead. Debian has essentially given up on packaging Hadoop. Some of their criticisms of its build process are certainly valid, but others seem to be an unreasonable expectation that everything will build exactly the way Debian expects. E.g. if I'm understanding correctly, they essentially take the position that they won't package anything built with Maven, on frankly spurious grounds. Debian tends to end up with very outdated versions of anything from an ecosystem that uses large numbers of small libraries, or, basically, anything that isn't written in C or Perl. E.g. Python libraries are typically a long way out of date (even compared to other distributions), and Debian's package management tends to be less compatible with Python's built-in tools like pip than other distributions (e.g. Debian is more likely to rename a Python library, in my experience, which then breaks reverse-dependencies on that library or leads to having two incompatible copies of it installed). So people running Python programs on Debian tend to end up with either a difficult-to-manage mix of system and non-system dependencies, or multiple parallel installs of Python. You could say that Debian offers a reliable platform and it's the users' fault for installing these unreliable things on top of it. But an OS exists to run applications, not the other way around, and I find that in practice Debian's approach means users are forced to step outside the managed parts of it much more than with other distributions, and it handles it less well when they do, making for setups that are less reliable in practice. Put it this way: the "add-on repository" culture is a lot stronger in Debian/Ubuntu than in other distributions, and I think that's actually a weakness rather than a strength.
- Fnoord 6y ago
  When you use Nix, and Nix does it, you like it when they do it, cause else they software doesn't work (Nix doesn't use default FHS).
sneak 6y ago
A lot of the Debian patches are also things like removing phone-home, expiration timers, remote code exec via autoupdate, and other upstream nonsense that shouldn’t be in packages in the first place.
- npsimons 6y ago
  Yeah, IME, Debian is about the least invasive distro. Their patches tend to be a) minimal and b) only make things better.
  - stock_toaster 6y ago
    Except for that one time[1]. [1]: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number...
    - npsimons 6y ago
      Oof. I'd forgotten about that one. Tend to make things better, tend to. Just points out when you're doing systems level software development, how careful you must be. Also, don't just blindly "fix things" because a tool complains. Understanding of warnings and error messages are important.
    - deschutes 6y ago
      This comment sums my thoughts on that issue: > Using uninitialized data as entropy source is an AMAZING idea in first place. “Fixing” or “unfixing” doesn’t make it any better.
      - deknos 6y ago
        uuh, no. perhaps it was initialized with zeros before. or with highly structured data. uninitialized data is not the same as external noise. i am rather glad, they think of that, it was a shame, that they oversaw this.
    - josefx 6y ago
saagarjha 6y ago
Generally I like the patches, they tend to be sane and not get in the way. Except for the random things it does to GRUB…
bananamerica 6y ago
I don’t think it makes sense to put Debian and Ubuntu in the same group here
- lmm 6y ago
  After the Debian SSH key bug I'd say it makes all the sense in the world.
  - stouset 6y ago
    That was twelve years ago. Do you think equally-bad bugs haven’t made it into upstream projects directly? Hell, many downstream patches exist to fix security bugs.
    - lmm 6y ago
      > That was twelve years ago. It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical software, still does not have any dedicated security review of those patches, still leaves it up to individual maintainers to decide whether and how to clear these things with upstream, and still thinks all of this is fine. > Do you think equally-bad bugs haven’t made it into upstream projects directly? Honestly, I can't think of a single equally-bad bug in "normal" code, only in medical devices / industrial controllers / etc.. Cloudbleed wasn't this bad. Bumblebee deleting /usr wasn't this bad. It really was a uniquely awful bug.
      - deknos 6y ago
        > It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical software, still does not have any dedicated security review of those patches, still leaves it up to individual maintainers to decide whether and how to clear these things with upstream, and still thinks all of this is fine. It's not fine, but when the upstream authors do not regard or consider requirements of downstream projects, what can you do? like with the example of phonehome features? arch and other distros are only possible, because for a long time, debian and other distros kept nagging the upstream authors for missing features or "nonfeatures". if debian wouldn't exist, i bet, arch had to patch much more itself.
achiang 6y ago
As mentioned elsewhere, the worse bug was in upstream, unpatched gdm. It's been a very long time since I worked on a distro (former Canonical employee here) but every distro carries patches of some sort.
- jfindley 6y ago
  I think there's a bit of a distinction between patches that add functionality not accepted by upstream (as here) vs the more typical distro patches which do things like replace bundled libs with shared ones, fix locations for things like TLS bundles, that sort of thing. These can still break things, but much less frequently. I haven't been a distro packager in many years, but my recollection is that in other distros (debian, fedora, arch, etc) patches that add new functionality would generally not be considered okay unless accepted by upstream. I'd be interested to learn the rationale for not upstreaming this patch before including it.
- pknopf 6y ago
  Yup. Even Arch.
  - galangalalgol 6y ago
    What about slackware? Its been a couple decades but I used to get my kernel source from linux direct and never had problems.
    - ldarby 6y ago
      With respect to upstream patching, Slackware is similar to Arch, it has a few, but generally tries to stick to upstream. Kernel is unpatched though.
- zaarn 6y ago
  Arch's policy is to minimize patches. I think the linux kernel runs on about 2-3 patches on average per release, most other packages aren't much more either. The policy "minimal patches & close-to-default" is in my experience usually a great one to avoid package maintainer issues.
wander_homer 6y ago
What? Are you maybe talking about the extent of downstream patching? Because Arch Linux does insert it's own "junk" into upstream, but probably to a lesser extent than Ubuntu or maybe Debian.
- veeti 6y ago
  Compare: https://git.launchpad.net/ubuntu/+source/accountsservice/tree/debian/patches https://git.launchpad.net/ubuntu/+source/accountsservice/tre... https://github.com/archlinux/svntogit-packages/blob/f17cbb1cbc8274b2f94d173c87229ec9e688bffc/trunk/ https://github.com/archlinux/svntogit-packages/blob/f17cbb1c...
  - GlitchMr 6y ago
    Just to be clear, because it's non-obvious, Arch Linux has a single patch (not stored in .patch file however), but all things considered it's very simple. sed -i '/dbus_conf_dir/s/sysconfdir/datadir/g' meson.build This likely is needed for the package to build to begin with.
  - wander_homer 6y ago
    I'm not sure what this supposed to demonstrate. I literally said that Arch Linux probably applies downstream patches to a lesser degree than Ubuntu. My point was that the person I responded to made it sound as if Arch Linux doesn't do any patching, which is obviously false since they have dozens if not hundreds of packages with downstream patches.
- eeZah7Ux 6y ago
  What you call "junk" in Debian are security and stability fixes.
deknos 6y ago
if only upstream projects wouldn't be so stubborn sometimes, to accept pull requests or requirements, because downstream projects might have valid requirements. then that would be not needed.
yrro 6y ago
For the record, the patch (0010-set-language.patch) is not present in the accountsservice package in Debian, neither in unstable, (0.6.55-3) testing (0.6.55-3), nor stable (0.6.54.2). https://sources.debian.org/src/accountsservice/0.6.55-3/debian/patches/ https://sources.debian.org/src/accountsservice/0.6.55-3/debi... https://sources.debian.org/src/accountsservice/0.6.45-2/debian/patches/ https://sources.debian.org/src/accountsservice/0.6.45-2/debi... The changes that fix both vulnerabilities can be viewed here: https://git.launchpad.net/ubuntu/+source/accountsservice/commit/debian/patches/0010-set-language.patch?h=ubuntu/focal-updates&id=7bfa70006b90b76ccb43bfed30463594857591ae https://git.launchpad.net/ubuntu/+source/accountsservice/com... Personally I question the logic of having accounts-daemon grovel through pam_env's config files in the first place. This isn't an API, it's an implementation detail! It just seems like a bad idea, even ignoring the vulnerability which anyone who isn't an absolute expert on the semantics of real/effective/saved UIDs & how to safely change them could have made. https://www.usenix.org/conference/11th-usenix-security-symposium/setuid-demystified https://www.usenix.org/conference/11th-usenix-security-sympo... (the famous Sendmail vulnerability therein is actually the _opposite_ of the accountsservice problem... sendmail _should_ have set the real uid as well as the effective uid, so that its effective uid could never be changed back to 0). LWN has an excellent series of articles about thedesign of UNIX, one of which explains the problems with setuid: https://lwn.net/Articles/416494/ https://lwn.net/Articles/416494/

symlinkk 6y ago

Yeah I hate it when distros do this. Does Debian actually change upstream significantly? I thought they kept things fairly vanilla. I know Fedora patched in VAAPI support on Firefox before it was merged into the Mozilla codebase. I can’t think of a worse piece of software to patch, the last thing I want to be running untested code on is my web browser.

jasonjayr 6y ago
Most of the Debian changes I've seen consist of changing default paths to match Debian's standards, backporting security changes (esp if a version bump changes functionality), and support 'conf.d' directories so packages can drop-in configuration files, and remove them easily.
- ClumsyPilot 6y ago
  > "backporting security changes (esp if a version bump changes functionality" Thats not a trivial matter, its a potential source of many issues
  - marcosdumay 6y ago
    It's also a source of many solutions. There are really no perfect option here. Upstream and distro developers have different goals, and it's up to you to decide what you should adopt.
    - jhardy54 6y ago
      Opinion: the 'perfect solution' is to keep up with upstream and avoid backporting. It takes more work, but it reduces the separation between distro and upstream.
      - tsimionescu 6y ago
        That's definitely not ideal for users, though. Forced updates every 6 months is annoying to most people. Forced updates every day or so would be annoying to basically everyone.
        bipson 6y ago
        Running Fedora since I-don't-even-remember-when (around 2008?) and I was never annoyed (unless I try to run CUDA and the like, because they rely on e.g. an ancient GCC etc.). In particularly it was a significant improvement over the annoyances of Ubuntu, and I am still angry when thinking about the brief period I was maintaining a bunch of servers running Debian. Really unnecessarily difficult - particularly updating/upgrading and trying to clear the mess their systemd approach caused, in particular missing unit files for popular services (I think it was the isc-dhcp-server).
        tsimionescu 6y ago
        But this means that you are happy to upgrade all of your computer every six months or whatever Fedora's cadence is. Most people are definitely not happy to do so, because updates mean changes to stuff that works, and most people hate it when stuff that already works changes beneath them. This is of course even worse if you are not the end-user but are trying to ship an appliance to your customers. Why would you want to update the entire appliance OS in the field fo all of your customers just to ship a security patch, instead of sticking with the same base OS on already released appliances?
        bipson 6y ago
        Hm, let's dissect. Upgrade schedule for Fedora is twice a year, yes. Goes by without any issues, stuff still works. There is change and then there is change. Yes, I understand that some things don't need to change, and why do they always have to. Do I need my Desktop to still resemble 3.11 because "Why did it ever change"? - No. Some things in life simply change and they always have. I try to keep up where change is necessary. And if I would be shipping appliances to customers, why should I have "forced updates" of any kind outside of my control? I would never sell anything without my own repos, quality control, etc. Do you seriously sell Debian devices to anyone and support them, if anything outside of your control breaks? I seriously don't understand the argument. And if I ship software of any kind that relies on some libraries, I have to maintain it, of course. This includes going with the major releases. If this is embedded hardware, where there simply are only two or three updates in its lifetime, everything is different of course, but how on earth would I then have forced updates from RedHat??
  - eikenberry 6y ago
    Yes, but the alternative is un-patched security issues. Non-trivial but important.
    - jhasse 6y ago
      No the alternative can also be to live with functionality changes.
      - eikenberry 6y ago
        New functionality means new bugs and breaking changes to old functionality. Sometimes the trade-off is worth it, but don't like being forced to update when it isn't.
  - eeZah7Ux 6y ago
    It's the whole point of having a distribution. If I wanted an endless stream of new vulnerabilities I can just use upstream software.
- jhasse 6y ago
  Note that "bugfixes" are most of the time considered as a functionality change.
girst 6y ago
Regarding Fedora's Firefox: The Fedora Firefox mainainers, Martin Stransky and Jan Horak, are also the main maintainers of the Linux/GTK parts of Firefox. The VAAPI patches you've mentioned are (afair) mostly-if-not-all Martin's work. So he's not applying some rando's "untested" patches.
- symlinkk 6y ago
  But the patches weren’t in Firefox’s codebase, so they didn’t go through the typical Firefox QA process including the Nightly, Beta, etc process. I’m not saying those guys don’t know what they’re doing, obviously they are experts. But I would prefer to trust but verify (not just trust).
npsimons 6y ago
> Does Debian actually change upstream significantly? I thought they kept things fairly vanilla. IME, they do keep things fairly vanilla, and I speak as someone who has run Debian since . . . I wanna say 2002? Plus I've done kernel dev work, and Debian's kernel patches ain't nothing compared to what RedHat used to do.
- freedomben 6y ago
  I maintain a custom/forked driver[1] and support both Fedora/RHEL/CentOS and Ubuntu, and while Ubuntu has gotten much better, in years past I actually had to manage Ubuntu specific branches because they were so hacked up with custom patches from Canonical. I would spend more time fixing Ubuntu weirdness than I would all other distros combined. It's gotten much better the past several releases though, so thank you to Canonical for that :-) The various RPM flavors keep their kernels vanilla enough that I can mostly just rebase on top of linux-stable, and it's been that way since I started 7 years ago (according to github). Arch is the winner. I've never had to make a custom patch for Arch. Disclaimer: I work for Red Hat but opinions are my own [1]: https://github.com/FreedomBen/rtl8188ce-linux-driver https://github.com/FreedomBen/rtl8188ce-linux-driver
  - npsimons 6y ago
    Fair enough, but I don't put Ubuntu in the same class as Debian, because while they may share many base packages in common, I do seem to remember them patching the kernel more than Debian, and usually stuff that would break my kernel dev too. Hence another reason I'm not on Ubuntu.
    - freedomben 6y ago
      Agreed. On a related but different note it does seem like Debian gets (unfairly) painted with light generated by Ubuntu. I run Debian on some machines and most of the issues I have with Ubuntu are not problems on Debian (such as: Snap obsession and forcing, Abandoned/system-wrecking PPAs that are hard to recover from, etc)
lmm 6y ago
> Does Debian actually change upstream significantly? I thought they kept things fairly vanilla. No, they radically change things to match their standards. E.g. look at their tomcat package which explodes it all over the filesystem.
- gspr 6y ago
  What is a distribution if not a collection of software that obey the same standard? Without the latter, all you have is a burlap sack full of software. Hardly a distribution. Fine if that's what you want, but it's not what Debian is.
  - lmm 6y ago
    A distribution is by definition distributing something that already exists, so I think distributions that stick close to upstream are more in the spirit of the concept. I also think Debian's approach has shown itself to produce something less reliable on the whole. Of course if you prefer the Debian approach, knock yourself out.
    - gspr 6y ago
      For those of you that don't like that terminology: let's just use the words that Debian itself uses, namely "the universal operating system". What is an operating system if not a collection of software that follow a standard so as to interoperate? > I also think Debian's approach has shown itself to produce something less reliable on the whole I think the opposite. Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example.
      - lmm 6y ago
        > Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example. Debian's patches to cdrecord introduced so many bugs that they eventually ended up driving the original author away from open source. I think I remember something about the python 2 -> 3 transition being harder on Debian because of changes they've made? The packaged Tomcat on Debian is so different that every time I've seen someone running Tomcat they've installed it manually instead. Debian has essentially given up on packaging Hadoop. Some of their criticisms of its build process are certainly valid, but others seem to be an unreasonable expectation that everything will build exactly the way Debian expects. E.g. if I'm understanding correctly, they essentially take the position that they won't package anything built with Maven, on frankly spurious grounds. Debian tends to end up with very outdated versions of anything from an ecosystem that uses large numbers of small libraries, or, basically, anything that isn't written in C or Perl. E.g. Python libraries are typically a long way out of date (even compared to other distributions), and Debian's package management tends to be less compatible with Python's built-in tools like pip than other distributions (e.g. Debian is more likely to rename a Python library, in my experience, which then breaks reverse-dependencies on that library or leads to having two incompatible copies of it installed). So people running Python programs on Debian tend to end up with either a difficult-to-manage mix of system and non-system dependencies, or multiple parallel installs of Python. You could say that Debian offers a reliable platform and it's the users' fault for installing these unreliable things on top of it. But an OS exists to run applications, not the other way around, and I find that in practice Debian's approach means users are forced to step outside the managed parts of it much more than with other distributions, and it handles it less well when they do, making for setups that are less reliable in practice. Put it this way: the "add-on repository" culture is a lot stronger in Debian/Ubuntu than in other distributions, and I think that's actually a weakness rather than a strength.
Fnoord 6y ago
When you use Nix, and Nix does it, you like it when they do it, cause else they software doesn't work (Nix doesn't use default FHS).

sneak 6y ago

A lot of the Debian patches are also things like removing phone-home, expiration timers, remote code exec via autoupdate, and other upstream nonsense that shouldn’t be in packages in the first place.

npsimons 6y ago
Yeah, IME, Debian is about the least invasive distro. Their patches tend to be a) minimal and b) only make things better.
- stock_toaster 6y ago
  Except for that one time[1]. [1]: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number...
  - npsimons 6y ago
    Oof. I'd forgotten about that one. Tend to make things better, tend to. Just points out when you're doing systems level software development, how careful you must be. Also, don't just blindly "fix things" because a tool complains. Understanding of warnings and error messages are important.
  - deschutes 6y ago
    This comment sums my thoughts on that issue: > Using uninitialized data as entropy source is an AMAZING idea in first place. “Fixing” or “unfixing” doesn’t make it any better.
    - deknos 6y ago
      uuh, no. perhaps it was initialized with zeros before. or with highly structured data. uninitialized data is not the same as external noise. i am rather glad, they think of that, it was a shame, that they oversaw this.
  - josefx 6y ago

saagarjha 6y ago

Generally I like the patches, they tend to be sane and not get in the way. Except for the random things it does to GRUB…

bananamerica 6y ago

I don’t think it makes sense to put Debian and Ubuntu in the same group here

lmm 6y ago
After the Debian SSH key bug I'd say it makes all the sense in the world.
- stouset 6y ago
  That was twelve years ago. Do you think equally-bad bugs haven’t made it into upstream projects directly? Hell, many downstream patches exist to fix security bugs.
  - lmm 6y ago
    > That was twelve years ago. It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical software, still does not have any dedicated security review of those patches, still leaves it up to individual maintainers to decide whether and how to clear these things with upstream, and still thinks all of this is fine. > Do you think equally-bad bugs haven’t made it into upstream projects directly? Honestly, I can't think of a single equally-bad bug in "normal" code, only in medical devices / industrial controllers / etc.. Cloudbleed wasn't this bad. Bumblebee deleting /usr wasn't this bad. It really was a uniquely awful bug.
    - deknos 6y ago
      > It was a predictable result of Debian policy, which Debian did not see fit to change. Debian still patches upstream sources including security-critical software, still does not have any dedicated security review of those patches, still leaves it up to individual maintainers to decide whether and how to clear these things with upstream, and still thinks all of this is fine. It's not fine, but when the upstream authors do not regard or consider requirements of downstream projects, what can you do? like with the example of phonehome features? arch and other distros are only possible, because for a long time, debian and other distros kept nagging the upstream authors for missing features or "nonfeatures". if debian wouldn't exist, i bet, arch had to patch much more itself.

achiang 6y ago

As mentioned elsewhere, the worse bug was in upstream, unpatched gdm. It's been a very long time since I worked on a distro (former Canonical employee here) but every distro carries patches of some sort.

jfindley 6y ago
I think there's a bit of a distinction between patches that add functionality not accepted by upstream (as here) vs the more typical distro patches which do things like replace bundled libs with shared ones, fix locations for things like TLS bundles, that sort of thing. These can still break things, but much less frequently. I haven't been a distro packager in many years, but my recollection is that in other distros (debian, fedora, arch, etc) patches that add new functionality would generally not be considered okay unless accepted by upstream. I'd be interested to learn the rationale for not upstreaming this patch before including it.
pknopf 6y ago
Yup. Even Arch.
- galangalalgol 6y ago
  What about slackware? Its been a couple decades but I used to get my kernel source from linux direct and never had problems.
  - ldarby 6y ago
    With respect to upstream patching, Slackware is similar to Arch, it has a few, but generally tries to stick to upstream. Kernel is unpatched though.
zaarn 6y ago
Arch's policy is to minimize patches. I think the linux kernel runs on about 2-3 patches on average per release, most other packages aren't much more either. The policy "minimal patches & close-to-default" is in my experience usually a great one to avoid package maintainer issues.

wander_homer 6y ago

What? Are you maybe talking about the extent of downstream patching? Because Arch Linux does insert it's own "junk" into upstream, but probably to a lesser extent than Ubuntu or maybe Debian.

veeti 6y ago
Compare: https://git.launchpad.net/ubuntu/+source/accountsservice/tree/debian/patches https://git.launchpad.net/ubuntu/+source/accountsservice/tre... https://github.com/archlinux/svntogit-packages/blob/f17cbb1cbc8274b2f94d173c87229ec9e688bffc/trunk/ https://github.com/archlinux/svntogit-packages/blob/f17cbb1c...
- GlitchMr 6y ago
  Just to be clear, because it's non-obvious, Arch Linux has a single patch (not stored in .patch file however), but all things considered it's very simple. sed -i '/dbus_conf_dir/s/sysconfdir/datadir/g' meson.build This likely is needed for the package to build to begin with.
- wander_homer 6y ago
  I'm not sure what this supposed to demonstrate. I literally said that Arch Linux probably applies downstream patches to a lesser degree than Ubuntu. My point was that the person I responded to made it sound as if Arch Linux doesn't do any patching, which is obviously false since they have dozens if not hundreds of packages with downstream patches.
eeZah7Ux 6y ago
What you call "junk" in Debian are security and stability fixes.

deknos 6y ago

if only upstream projects wouldn't be so stubborn sometimes, to accept pull requests or requirements, because downstream projects might have valid requirements. then that would be not needed.

yrro 6y ago

For the record, the patch (0010-set-language.patch) is not present in the accountsservice package in Debian, neither in unstable, (0.6.55-3) testing (0.6.55-3), nor stable (0.6.54.2). https://sources.debian.org/src/accountsservice/0.6.55-3/debian/patches/ https://sources.debian.org/src/accountsservice/0.6.55-3/debi... https://sources.debian.org/src/accountsservice/0.6.45-2/debian/patches/ https://sources.debian.org/src/accountsservice/0.6.45-2/debi... The changes that fix both vulnerabilities can be viewed here: https://git.launchpad.net/ubuntu/+source/accountsservice/commit/debian/patches/0010-set-language.patch?h=ubuntu/focal-updates&id=7bfa70006b90b76ccb43bfed30463594857591ae https://git.launchpad.net/ubuntu/+source/accountsservice/com... Personally I question the logic of having accounts-daemon grovel through pam_env's config files in the first place. This isn't an API, it's an implementation detail! It just seems like a bad idea, even ignoring the vulnerability which anyone who isn't an absolute expert on the semantics of real/effective/saved UIDs & how to safely change them could have made. https://www.usenix.org/conference/11th-usenix-security-symposium/setuid-demystified https://www.usenix.org/conference/11th-usenix-security-sympo... (the famous Sendmail vulnerability therein is actually the _opposite_ of the accountsservice problem... sendmail _should_ have set the real uid as well as the effective uid, so that its effective uid could never be changed back to 0). LWN has an excellent series of articles about thedesign of UNIX, one of which explains the problems with setuid: https://lwn.net/Articles/416494/ https://lwn.net/Articles/416494/