3 ms·
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
by 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 agoNo, 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.
- Joel_Mckay 2y agoIn general, the apparent use-case and actual unintended impact on OS security must be clear. There is also always extreme suspicion regarding "security" widgets that touch the web browser, shell, or email programs. Normally, after something like CVE-2023-35866 is noted, a package maintainer may assume the project is a liability given the history. If an application requires a 3 page BS explanation about how to use a footgun without self-inflicted pwning... it seems like bad design for a posix environment. People that attempt an escalation of coercion with admins usually get a ban at minimum. Deception, threats, and abuse will not help in most cases if the maintainer is properly trained. https://www.youtube.com/watch?v=lITBGjNEp08 https://www.youtube.com/watch?v=lITBGjNEp08 Have a nice day, =3
- palata 2y ago> No, they alter and modify the software as they see fit. Well yeah, but you choose the maintainers that do it the way you prefer. In your care you say you like Arch better, because they "patch less" (if I understand your feeling). Still they do exactly what you describe they should do: write a recipe, build it and ship a binary. You can even go with Gentoo if you want to build (and possibly patch) yourself, which I personally like. > Here's one of the recent examples: [...] Doesn't seem like it supports your point: the very first comment on that Reddit threads explains what they did: they split one package into two packages. Again, if you're not happy with the way the Debian maintainers do it, you can go with another distro. Doesn't change the fact that if you use a distro (as opposed to building your own from scratch), then you rely on maintainers.