4 ms·

I feel more safe using Arch, compared to Debian. Debian adds so much of their patches on top of original software, that the result is hardly resembles the origi

I feel more safe using Arch, compared to Debian. Debian adds so much of their patches on top of original software, that the result is hardly resembles the original. Arch just ships original code almost always. And I trust much more to the original developers, than Debian maintainers.

palata 2y ago
> And I trust much more to the original developers, than Debian maintainers. Then that's a good reason not to use Debian indeed. Whatever the distro you choose, you give your trust to its maintainers. But that's also a feature: instead of trusting random code from the Internet, you can trust random code from the Internet that has been vetted by a group of maintainers you chose to trust. Which is a bit less random, I think?
- Joel_Mckay 2y ago
  Debian standardized the vetting process for maintainers, validation environments, and shenanigans could be attributed to individual signatures rather quickly. If you ever want a laugh, one should read what Canonical puts the kids though for the role. One could get a job flying a plane with less paperwork... Authenticated signed packaging is often a slow process, and some people do prefer rapid out-of-band pip/npm/cargo/go until something goes sideways... and no one knows who was responsible (or which machine/user is compromised.) Not really random, but understandably slow given the task of reaching "stable" OS release involves hundreds of projects... =3
  - palata 2y ago
    Yeah I think that's what I was trying to say. With a distro, you get some kind of validation by maintainers. With unvetted package managers, you just get something from somewhere.
- vbezhenar 2y ago
  I don't trust in any validation by the maintainers. There's too much code even in small projects. Big projects are oceans of code. Maintainers maintain too much packages to be able to understand even a little bit of changes. So, no, I don't trust it. It would require a specialized team of engineers for every single project to analyze changes in new versions. It just does not happen. Best they can do is to follow developer's instructions to build a binary artefact and upload it somewhere. May be codify those instructions into a (hopefully) repeatable script like PKGBUILD.
  - palata 2y ago
    > Best they can do is to follow developer's instructions to build a binary artefact and upload it somewhere. May be codify those instructions into a (hopefully) repeatable script like PKGBUILD. I don't understand; isn't this exactly what maintainers do? They write a recipe (be it a PKGBUILD or something else) that builds (maybe after applying a few patches) a package that they then distribute. Whether you use Arch or Debian, you trust that the maintainers don't inject malware into the binaries they ship. And you trust that the maintainers trust the packages they distribute. Most likely you don't personally check the PKGBUILD and the upstream project.
    - vbezhenar 2y ago
      No, they alter and modify the software as they see fit. Here's one of the recent examples: https://www.reddit.com/r/debian/comments/1cv30gu/debian_keepassxc_maintainer_removes_browser/ https://www.reddit.com/r/debian/comments/1cv30gu/debian_keep... And that's applied to a lot of packages. Sometimes it leads to frustrated users who directly come to frustrated developers who have no idea what they're talking about, because developers did not intend software to be patched and built this way. Sometimes this leads straight to vulnerabilities. Sometimes this leads to unstable software, for example when maintainer "knows better" which libraries the software should link to.
      - yjftsjthsd-h 2y ago
        > Here's one of the recent examples: https://www.reddit.com/r/debian/comments/1cv30gu/debian_keepassxc_maintainer_removes_browser/ https://www.reddit.com/r/debian/comments/1cv30gu/debian_keep... They used an official build option to not ship a feature by default, and have another package that does enable all features. If that's your best example of > Debian adds so much of their patches on top of original software, that the result is hardly resembles the original. then I'm inclined to conclude that Debian is way more vanilla than I thought.
freedomben 2y ago
I love Debian, but this is a genuine deal that many people don't know about. It also compounds if you're on Ubuntu as sometimes Canonical adds their own patches too. If you're just using Debian as a base OS to serve your own software, it doesn't matter as much but still does somewhat. It's not unusual for Debian-specific patches to be applied by the package maintainers in order to fix build errors, mismatched dependencies, etc. Most of the time those patches are harmless, but sometimes they are not. There have been security vulnerabilities for example that only existed in the Debian-based package of software. No distro is perfect and I don't intend this as a criticism of Debian (as they have legitimate reasons for doing what they do), and no distro (not even Arch) ships everything without any patches, but in my years of experience I've bumped my head on this in Debian several times.
- progval 2y ago
  > There have been security vulnerabilities for example that only existed in the Debian-based package of software. Any examples more recent than CVE-2008-0166?
  - freedomben 2y ago
    Currently on mobile and going from memory, but I remember having to push out quick patches for something around 2020-ish or late 2010s? The tip of my tongue says it was a use-after-free vuln in a patch to openssl, but I can't remember with confidence. I'll see if I can find it once I get home. Worth noting lest I give the wrong impression, I don't think security is a reason to avoid Debian. For me the hacked up kernels and old packages have been much more the pain points, though I mostly stopped doing that work a few years ago. As a regular user (unless you're compiling lots of software yourself) it's a non-issue
    - Joel_Mckay 2y ago
      In general, most responsibly reported CVE allow several weeks for the patch fixes to propagate into the ecosystems before public disclosure. Once an OS is no longer actively supported, it will begin to accumulate known problems if the attack surface is large. Thus, a legacy complex-monolith or Desktop host often rots quicker than a bag of avocados. =3

palata 2y ago

> And I trust much more to the original developers, than Debian maintainers. Then that's a good reason not to use Debian indeed. Whatever the distro you choose, you give your trust to its maintainers. But that's also a feature: instead of trusting random code from the Internet, you can trust random code from the Internet that has been vetted by a group of maintainers you chose to trust. Which is a bit less random, I think?

Joel_Mckay 2y ago
Debian standardized the vetting process for maintainers, validation environments, and shenanigans could be attributed to individual signatures rather quickly. If you ever want a laugh, one should read what Canonical puts the kids though for the role. One could get a job flying a plane with less paperwork... Authenticated signed packaging is often a slow process, and some people do prefer rapid out-of-band pip/npm/cargo/go until something goes sideways... and no one knows who was responsible (or which machine/user is compromised.) Not really random, but understandably slow given the task of reaching "stable" OS release involves hundreds of projects... =3
- palata 2y ago
  Yeah I think that's what I was trying to say. With a distro, you get some kind of validation by maintainers. With unvetted package managers, you just get something from somewhere.
vbezhenar 2y ago
I don't trust in any validation by the maintainers. There's too much code even in small projects. Big projects are oceans of code. Maintainers maintain too much packages to be able to understand even a little bit of changes. So, no, I don't trust it. It would require a specialized team of engineers for every single project to analyze changes in new versions. It just does not happen. Best they can do is to follow developer's instructions to build a binary artefact and upload it somewhere. May be codify those instructions into a (hopefully) repeatable script like PKGBUILD.
- palata 2y ago
  > Best they can do is to follow developer's instructions to build a binary artefact and upload it somewhere. May be codify those instructions into a (hopefully) repeatable script like PKGBUILD. I don't understand; isn't this exactly what maintainers do? They write a recipe (be it a PKGBUILD or something else) that builds (maybe after applying a few patches) a package that they then distribute. Whether you use Arch or Debian, you trust that the maintainers don't inject malware into the binaries they ship. And you trust that the maintainers trust the packages they distribute. Most likely you don't personally check the PKGBUILD and the upstream project.
  - vbezhenar 2y ago
    No, they alter and modify the software as they see fit. Here's one of the recent examples: https://www.reddit.com/r/debian/comments/1cv30gu/debian_keepassxc_maintainer_removes_browser/ https://www.reddit.com/r/debian/comments/1cv30gu/debian_keep... And that's applied to a lot of packages. Sometimes it leads to frustrated users who directly come to frustrated developers who have no idea what they're talking about, because developers did not intend software to be patched and built this way. Sometimes this leads straight to vulnerabilities. Sometimes this leads to unstable software, for example when maintainer "knows better" which libraries the software should link to.
    - yjftsjthsd-h 2y ago
      > Here's one of the recent examples: https://www.reddit.com/r/debian/comments/1cv30gu/debian_keepassxc_maintainer_removes_browser/ https://www.reddit.com/r/debian/comments/1cv30gu/debian_keep... They used an official build option to not ship a feature by default, and have another package that does enable all features. If that's your best example of > Debian adds so much of their patches on top of original software, that the result is hardly resembles the original. then I'm inclined to conclude that Debian is way more vanilla than I thought.

freedomben 2y ago

I love Debian, but this is a genuine deal that many people don't know about. It also compounds if you're on Ubuntu as sometimes Canonical adds their own patches too. If you're just using Debian as a base OS to serve your own software, it doesn't matter as much but still does somewhat. It's not unusual for Debian-specific patches to be applied by the package maintainers in order to fix build errors, mismatched dependencies, etc. Most of the time those patches are harmless, but sometimes they are not. There have been security vulnerabilities for example that only existed in the Debian-based package of software. No distro is perfect and I don't intend this as a criticism of Debian (as they have legitimate reasons for doing what they do), and no distro (not even Arch) ships everything without any patches, but in my years of experience I've bumped my head on this in Debian several times.

progval 2y ago
> There have been security vulnerabilities for example that only existed in the Debian-based package of software. Any examples more recent than CVE-2008-0166?
- freedomben 2y ago
  Currently on mobile and going from memory, but I remember having to push out quick patches for something around 2020-ish or late 2010s? The tip of my tongue says it was a use-after-free vuln in a patch to openssl, but I can't remember with confidence. I'll see if I can find it once I get home. Worth noting lest I give the wrong impression, I don't think security is a reason to avoid Debian. For me the hacked up kernels and old packages have been much more the pain points, though I mostly stopped doing that work a few years ago. As a regular user (unless you're compiling lots of software yourself) it's a non-issue
  - Joel_Mckay 2y ago
    In general, most responsibly reported CVE allow several weeks for the patch fixes to propagate into the ecosystems before public disclosure. Once an OS is no longer actively supported, it will begin to accumulate known problems if the attack surface is large. Thus, a legacy complex-monolith or Desktop host often rots quicker than a bag of avocados. =3