Live data from Hacker News

Why does Debian change software?

blog.liw.fi

201–210 of 210 posts

Re: Why does Debian change software?

#201

Earlier quoted context omitted.

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.

I'm on the market for a decent laptop. Don't want to side-line the thread, but is Arch supported decently on, say, Dell or any "enterprise grade" laptops?

If in doubt, search the Arch forums for posts about the model you consider to buy. Best case: Some threads come up, but all problems could be solved. Worst case: No threads, or a lot of threads about obscure errors.

Re: Why does Debian change software?

#203
post #193
post #110

Earlier quoted context omitted.

To be fair, we (Nixpkgs maintainers) do remove or disable features that phone home sometimes even though it's not policy. That said, it would be nice if it was policy. Definitely was discussed before (most recently after the devbox thing I guess.)

Discord downloads stuff every single time I start it. So there is definitely not a policy to remove this behaviour. And yes, good point, this was indeed discussed when devbox enabled AI training by default. It somehow seems like there is more than one category of phoning home at play here, since it is obviously tolerated in other cases.

What I mean is, it definitely isn't explicit policy to remove features that phone home; but, it is sometimes still done at the package maintainer's discretion. For things that are unfree all bets are off. (Removing or interfering with such code may be against the license.)

Re: Why does Debian change software?

#204
post #189
post #186

Earlier quoted context omitted.

As I said, new kernels zero the pages, an uninitialized area is likely to be zeroed or be rather deterministic.

Which is fine. It's not a bug if it's zero. There's just no point going out of your way to set it to zero when you're only going to xor a bunch of random values into it anyway.

The whole issue was caused because it was always zero because the patch zeroed it (:

Can you please read about the issue before commenting more?

Re: Why does Debian change software?

#205
post #196

Earlier quoted context omitted.

>But a distribution is neither an "app store", nor does it "insert itself" between the user and the software. Just scroll up to the second comment in the thread right now by the user rmccue . Given that Debian doesn't give the user any indication of the fact that it even has modified an upstream piece of software it's obviously perfectly possible for them to insert themselves without you even knowing it. And in that…

> Given that Debian doesn't give the user any indication of the fact that it even has modified an upstream piece of software Debian also doesn't give any indication that we haven't modified an upstream piece of software. Modifying software is a central thing to do in the FOSS world. If the user wants to know if anything was was modified, and if so what, then the source is of course freely available. > it's obviously…

>Of course! You chose to run Debian. Debian is entirely upfront about this!

Okay, then going back to the beginning of the argument and the comparison you denied is accurate. If merely choosing Debian is sufficient reason enough for the user to assume that Debian as the distributor acts as a middleman in all sorts of ways, how exactly is that different from an app store?

After all you choose to buy an iPhone or use the Google Play store, so if the argument is that consent, given exactly once invalidates any concern, that applies to any platform, nobody's ever been held at gunpoint to install an operating system.

I think what would help is indeed if maintainers make significant changes that the user is informed about that very visible during the installation process.

Re: Why does Debian change software?

#206
post #199
post #57

Earlier quoted context omitted.

Arch is a minefield on this regard tbh

Hey, I might be too late to the party, but I'd love to get some more info to your comment. Imagine me: I'd consider myself a Linux noob, although I probably aren't anymore. I use Arch Linux for about 3 years now as my daily driver. I'm not young anymore - I didn't grew up with computers - I don't have it in my blood. I don't have formal education in anything computer and have never worked in the field. During Covid I…

Well, with packages you want various filtering steps to happen before they make it into users' systems. Or layers of security that make it harder for a system to be compromised.

Let's take a look at the xz incident, then at how fast rolling release distros get their packages in. That's part of the equation. Bottom line is: you're the first line of defense against potential malicious supply chain attacks. This is why Fedora is Red Hat's testing distro, why Debian has an unstable branch or why openSUSE Tumbleweed exists. Now, Arch isn't just a "testing distro", but it is, by design, more susceptible to these attacks. Thinking bleeding edge is more secure is a fallacy. It is but a consequence of assuming the source maintainers are on your side, which is usually the case, but not always. Or, assuming software is properly tested for bugs every release. If you are still doubting this, look at npm.

Furthermore, have you ever asked why you need to constantly update package signing keys? There is no central build server for Arch. Maintainers are building packages in whatever machine they are on, signing with whatever keys they have there and uploading the binary blobs. This isn't trustworthy. There is now a clean chroot process and all, but still, maintainers are still able to build the packages in their machine and upload it.

The other problem is not having any mandatory access control security policy by default (SELinux, AppArmor, etc...). You can, of course, install your own and go through the trouble of actually creating the security profiles yourself for the various packages on the system. This is in stark contrast with other distros, where not only they provide a security policy by default but their packages also ship with security profiles when needed to make sure it actually works (Fedora and openSUSE come to mind).

Finally, the AUR is cool and all, but my god are you at the mercy of whatever is put on there. Sure the PKGBUILD is super legible, but are you really checking where things are being pulled from? There is a layer of filtering being taken away here, you are the one doing your due diligence.

Now I'm sure different people have different takes on this, some might say that security policies are dumb and useless, others might prefer to be in the bleeding edge assuming the latest and greatest is safer. But take all the layers I have mentioned here, and how their non-existence on Arch could affect security. I hope to have drawn a clearer picture.

(Edit: I must say, I like Arch, I've used it a lot and when in a pinch is my go to. But I've come to appreciate how other distros approach security, and how they layer the process so they have more time to assess vulnerabilities. It is a balancing game, and I hope Arch improves on their processes, I really do.)

Re: Why does Debian change software?

#207
post #204
post #189

Earlier quoted context omitted.

Which is fine. It's not a bug if it's zero. There's just no point going out of your way to set it to zero when you're only going to xor a bunch of random values into it anyway.

The whole issue was caused because it was always zero because the patch zeroed it (: Can you please read about the issue before commenting more?

> The whole issue was caused because it was always zero because the patch zeroed it (:

No it wasn't. The patch removed the read of the randomness buffer that folded it into another buffer (the MD_Update calls) because Valgrind was warning that the buffer it was reading from had never been initialised.

> Can you please read about the issue before commenting more?

Right back at you.

Re: Why does Debian change software?

#208
post #6
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.

It's not guaranteed that they manage to catch all the software that does this though :D

> It's not guaranteed that they manage to catch all the software that does this though :D

It is really hard to run netstat. Or tcpdump. /s

Re: Why does Debian change software?

#209
post #151
post #126

Earlier quoted context omitted.

The ongoing problem with popcon is that it's known not to be accurate, but since it's the data that's available, people make decisions based on it. popcon is least likely to be turned on by: - organizations with any kind of sensible privacy policy (which includes almost everyone running more than a handful of machines) - individuals concerned about privacy popcon is most likely to be turned on by Debian developers, a…

Yeah, isn't that a shame? Wouldn't it be nice if instead of catastrophizing that telemetry data is always only ever there to spy on us, that we might assume that there are actually trustworthy projects out there? Especially for FOSS projects, which can usually not afford extensive in-house user testing, telemetry provides extremely valuable data to see how their software is used and where it can be improved, especial…

> I usually turn on telemetry for FOSS that offers it, because I hope they will use this to actually improve it.

And if they, or someone else, use this for RCE ? Asking for a friend. /s

Re: Why does Debian change software?

#210
post #196

Earlier quoted context omitted.

> Given that Debian doesn't give the user any indication of the fact that it even has modified an upstream piece of software Debian also doesn't give any indication that we haven't modified an upstream piece of software. Modifying software is a central thing to do in the FOSS world. If the user wants to know if anything was was modified, and if so what, then the source is of course freely available. > it's obviously…

>Of course! You chose to run Debian. Debian is entirely upfront about this! Okay, then going back to the beginning of the argument and the comparison you denied is accurate. If merely choosing Debian is sufficient reason enough for the user to assume that Debian as the distributor acts as a middleman in all sorts of ways, how exactly is that different from an app store? After all you choose to buy an iPhone or use th…

> If merely choosing Debian is sufficient reason enough for the user to assume that Debian as the distributor acts as a middleman in all sorts of ways, how exactly is that different from an app store?

Because you decide the power of the middleman on your system. And you have full freedom to change whatever the middleman delivers. Neither is typically true of app stores.

> After all you choose to buy an iPhone or use the Google Play store, so if the argument is that consent, given exactly once invalidates any concern, that applies to any platform, nobody's ever been held at gunpoint to install an operating system.

Pray tell, what other choices do I have in the phone market? And how are my choices in the PC market, again?

> I think what would help is indeed if maintainers make significant changes that the user is informed about that very visible during the installation process.

OK. Then I don't think Debian is for you.

Post reply on HN