Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why GNU/Linux Viruses Are Fairly Uncommon

gnu.org

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#101

Post by zzzcpan »

est31 wrote: post #99
lacampbell wrote: post #73

Earlier quoted context omitted.

All the npm cases I can think of have been in javascript code, not 'binaries'. So that wouldn't have prevented any of them.

Fair point. For Javascript there is no binary step so it has to be in the source code. In compiled languages, this is different: you can hide it in the binary, and finding it there is much harder than checking the source code VCS history. So without reproducible builds, compiled package managers would be in an even worse situation than Javascript, at least what ability to review the uploaded packages is concerned. Ul…

It makes absolutely no difference when binary packages are compiled on a trusted build farm, i.e. like everyone does already.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#102

Post by zzzcpan »

est31 wrote: post #37
zzzcpan wrote: post #36

Earlier quoted context omitted.

Reproducible builds can't prevent hidden malware. They don't do much at all for security.

They can't prevent it but they can help it become visible. Without reproducible builds, nobody has an easy way to verify that a specific binary corresponds to a specific deemed safe bit of source code. There can still be source code based attacks by upstream maintainers of course. In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be muc…

> In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be much worse.

This is incorrect. It wouldn't make a single difference.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#103

Post by commandlinefan »

Godel_unicode wrote: post #58
commandlinefan wrote: post #55

Except that now everybody insists that you should be using package managers like apt and yum instead.

Who are these people? In the Python community, no project ever used yum/apt. Their versions of basically every package (where they even have it) are hilariously out of date with what you should use. They are frequently missing major security fixes, in addition to the usual functionality ones. My understanding is that this applies to most other languages as well. To say nothing of docker base images and popular docker…

> are hilariously out of date

Well that's exactly the problem I run into with most packages (even outside of programming dependencies like Python libraries), but if ./configure, make, make install fails for any reason, the first google hit on the error message is "why are you trying to install this from source? Use the repos, that's what they're for"...

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#104

Post by acdha »

IcePic wrote: post #83
acdha wrote: post #50

Earlier quoted context omitted.

The distributions don’t have unlimited resources and the community can be a real deterrent: look at how much crap the systemd developers get every time they fixed a decades-old problem and then the angry mob shows up to complain about having to learn something new. I’ve been hoping that we’ll get there for a couple decades but SELinux was quite the reminder that when faced with work a lot of people will just turn off…

Oh, try calling in for support on that $1+M CommercialDatabase(tm) installation and tell them SELinux is turned on, or any other similar super expensive software. The 1st line will happily tell you that the most prized data you were willing to pay huge amounts for can't be protected by something so .. easy as SELinux. They will not take your ticket until you turn it off and try again, and to your great surprise they…

Yes - things like that are a huge problem. For a field which often calls itself engineering I’m frequently disappointed by how many significant calls are based on superstition rather than analysis.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#105

Post by Godel_unicode »

majewsky wrote: post #96
Godel_unicode wrote: post #66

Earlier quoted context omitted.

The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters. Built artifacts as exist on disk in the repo are a relatively small piece of that. > None of those package repositories are maintained by a limited set of curators. It's always interesting to me how few people seemingly know this. Python package maintainers realize how easy it is to add pa…

I don't like when "Reflections on trusting trust" is used as an excuse to throw the hands in the air and not doing anything. Sure, it's not perfect, but the reproducible-builds people are doing important work that makes it considerably harder to inject malware into distribution repos.

The hard part about the security of built artifacts is not building them, it's auditing the source looking for bugs. Reproducible-builds doesn't audit the source, but many act like they think it does. Added to this is the host of other security issues with the chain between the developers keyboard and your system. This solves none of them, but many act like they think it does.

Therefore, in my view it provides a smallish real benefit and a large moral hazard.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#106

Post by Godel_unicode »

commandlinefan wrote: post #103
Godel_unicode wrote: post #58

Earlier quoted context omitted.

Who are these people? In the Python community, no project ever used yum/apt. Their versions of basically every package (where they even have it) are hilariously out of date with what you should use. They are frequently missing major security fixes, in addition to the usual functionality ones. My understanding is that this applies to most other languages as well. To say nothing of docker base images and popular docker…

> are hilariously out of date Well that's exactly the problem I run into with most packages (even outside of programming dependencies like Python libraries), but if ./configure, make, make install fails for any reason, the first google hit on the error message is "why are you trying to install this from source? Use the repos, that's what they're for"...

That doesn't match my experience at all; people usually realize that there are tons of reasons not to use the repo version. Perhaps you want a newer Python than the crusty old one that comes with 18.04. perhaps you want to test something that doesn't exist in the repos (the horror!). Docker and Elastic both recommend using their repos or building from source rather than using the geriatric versions in the Ubuntu repos.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#107

Post by Godel_unicode »

necovek wrote: post #81
Godel_unicode wrote: post #58

Earlier quoted context omitted.

Who are these people? In the Python community, no project ever used yum/apt. Their versions of basically every package (where they even have it) are hilariously out of date with what you should use. They are frequently missing major security fixes, in addition to the usual functionality ones. My understanding is that this applies to most other languages as well. To say nothing of docker base images and popular docker…

I am the one saying that: for any Python packages in Ubuntu main, use them. Why worry about tracking security issues of all your dependencies, when you can have that done by distribution's security team (Ubuntu pledges to patch all security bugs).

Are you a Python developer? How do you deal with the Ubuntu versions being different than the PyPI versions?

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#108

Post by nextos »

swdunlop wrote: post #38
nextos wrote: post #5

Earlier quoted context omitted.

Nix/Guix are quite cool to tackle this. They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries. Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there. There's e.g. Vulnix that scans for CVEs [1]. [1] https://github.com/flyingcircusio/vulnix

NixOS (and NixPkgs) is great, but there are still plenty of binary only packages from difficult to build projects like PhantomJS in the ecosystem. It takes a serious commitment to build complex projects in Nix and maintain them. (edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...

You can also build regular packages, no matter how complicated they are, by spanning an FHS environment. That's sort of a sandbox that simulates a regular Unix environment with whatever dependencies you need in the usual places (/bin, /usr, ...).

Of course, you loose some Nix advantages. But it's a great way to get a regular Unix environment for one-off things or desperate cases.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#109

Post by swdunlop »

baroffoos wrote: post #65
swdunlop wrote: post #38

Earlier quoted context omitted.

NixOS (and NixPkgs) is great, but there are still plenty of binary only packages from difficult to build projects like PhantomJS in the ecosystem. It takes a serious commitment to build complex projects in Nix and maintain them. (edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...

Should you really be installing programs that are impossible to build? Also phantomjs is discontinued.

That's a great question, but it does not invalidate the point that there is nothing about Nix that states that binary packages cannot and do not happen.

Re: Why GNU/Linux Viruses Are Fairly Uncommon

#110

Post by necovek »

Godel_unicode wrote: post #107
necovek wrote: post #81

Earlier quoted context omitted.

I am the one saying that: for any Python packages in Ubuntu main, use them. Why worry about tracking security issues of all your dependencies, when you can have that done by distribution's security team (Ubuntu pledges to patch all security bugs).

Are you a Python developer? How do you deal with the Ubuntu versions being different than the PyPI versions?

Are you a Python developer?[1] How do you deal with your project depending on an older version of a package with pip?

Basically, it's just like that (but instead of specifying your version in requires.txt/setup.py, you just install a package with a particular version). You've got an older library version that gets automatic security updates but does not break backwards compatibility (or it's a bug in the distro).

Ubuntu/Debian packages manage dependencies as well, so for anything you install from the "archive" (distribution's repository), you get compatible dependencies as well, so you can further reduce number of packages you need to pull in with pip. It's a bit of a bother if you've got two sources of dependencies, but if you can get free security updates and no backwards compatibility breakage for 5 years (Ubuntu LTS guarantee for packages in main), it's a small price to pay (though it certainly depends on the use case as well).

And luckily, Python + PyPI are _not_ JavaScript + NPM: with Python, you get a large standard library, and as you do not always need the latest and greatest of everything, you will not have hundreds, if not thousands of dependencies that you get with JS+NPM.

[1] Your first tongue-in-cheek question is, imho, totally inappropriate. If I misunderstood and it was not meant in a sarcastic way, I apologize for attempting to return the favour. :) Even then, your second question is totally valid and should have been sufficient if you honestly care.

Post reply on HN