5 ms·

>Which windows package managers build from source? I thought they were all binary package managers. I think the GP meant downloading random binaries through a

>Which windows package managers build from source? I thought they were all binary package managers. I think the GP meant downloading random binaries through a web browser, as most people do on Windows. Package managers with hash verification are a million times safer than that.

robonerd 5y ago
Checking a hash is safer only if the person who commits the "known good hash" to the package repository actually verifies that goodness. If the programs developer sells out and puts malware into their official binary releases, and the package maintainer doesn't notice this, then checking hashes doesn't protect you from the malicious release.
- ramesh31 5y ago
  >If the programs developer sells out and puts malware into their official binary releases, and the package maintainer doesn't notice this, then checking hashes doesn't protect you from the malicious release. Nothing short of a full code review will save you from a malicious supply chain attack. This is currently exploding with NPM as well, so building from source doesn't save you here either. See the node-ipc debacle from a few weeks ago [0], and also my own post from last week about a malware infected NPM module [1]. The reality is that yes, the days of being able to trust anything downloaded from a stranger on the internet are pretty much over now. But known-hash package management is still a good first layer of security versus downloading random binaries from the web. [0] https://nvd.nist.gov/vuln/detail/CVE-2022-23812 https://nvd.nist.gov/vuln/detail/CVE-2022-23812 [1] https://news.ycombinator.com/item?id=30963600 https://news.ycombinator.com/item?id=30963600
  - b112 5y ago
    I appreciate what you are saying, but it was over decades ago! Node is just insane, always was, along with the curl | bash crowd. Madness.
  - ryukafalz 5y ago
    > Nothing short of a full code review will save you from a malicious supply chain attack. Nonsense. Or, at least, an oversimplication. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... Nothing short of full code review will ensure that malicious code from a dependency doesn’t get into your program at all, but the capabilities of that malicious code once it does get into your program can certainly be limited.
    - munk-a 5y ago
      I don't disagree that Javascript in general runs with a lot more permissions than should probably be given but permissions is a very hard thing to manage. So you decide to install a node package that helps retry and automatically back off requests you want to send to your server since you're working in a mobile environment that has sketchy internet reliability... it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server. Additionally, these permissions will be more comprehensible to review but they still need to be reviewed and reviewed by a party you trust. That's a tall order for the open source community when it comes to a volume of packages like npm or composer. You can logically look at lpad as a package and say "We're padding strings, we don't need to do anything with network traffic or disk reads" but building an automated system to make that evaluation and saving that evaluation in a tamperproof manner is going to be hard... and what happens if lpad starts trying to do a better job - operating correctly in left-to-right character sets and in languages where alignment is dictated by hyphens instead of blank space. Code isn't simple and while the above statement may seem hyperbolic I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk but actually fully 100% preventing that risk? You'll need to check every usage scenario on every set of hardware and go through that code with a fine toothed comb.
      - ryukafalz 5y ago
        > it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server If you're expecting to have to craft ACLs program-wide for that package, then sure, that's going to be hard. That's more coarse-grained than what I'm talking about here though. Imagine, if you will, a programming environment where modules you load don't have any authority to access the network, filesystem, etc unless you pass them in. They're just not in scope. In such a language, the default way to grant HTTP access might look like this in pseudo-Python: http = require("http") myMaliciousLibrary = require("myMaliciousLibrary", http=http) Now, this library has the problem you mentioned; it can make arbitrary outgoing HTTP requests, meaning it can send any metrics it collects to an ad server. It can't access the filesystem because the filesystem isn't in scope either, so what it can collect is limited, but still more access than it needs. So here's one way you might fix that (obviously highly simplified/incomplete in its implementation): class ProxyHTTP(origin="https://example.com", http): def __init__(origin="https://example.com"): self.allowed_origin = origin def get(origin, path="/"): return http.get(self.allowed_origin, path) http = require("http") myMaliciousLibrary = require("myMaliciousLibrary", http=ProxyHTTP(origin="https://good-site.example.com", http)) Now, this version of myMaliciousLibrary gets an object that looks like the http library it would normally use; it just happens to ignore the origin parameter that the library passes to it and uses the one it was initialized with instead. Now, that library can make requests to good-site.example.com, but if it tries to make a request to adserver.evil.com, it'll go to good-site.example.com instead. (You might also imagine a version of ProxyHTTP that just throws an error if the request's origin isn't the same one it was initialized with, or isn't in a list it was initialized with.) Most of today's programming languages aren't strict enough to enable this of course; JavaScript isn't there yet for example, and most other languages aren't even close to being able to do this. But that's mostly because they don't provide strict enough encapsulation, not because they're lacking some complex security enforcement mechanism. > I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk I just think people are accepting way more risk than they realize, given the number of dependencies in modern applications and the amount of access each of those dependencies have. It feels crazy that any one of those dependencies in any application could exfiltrate massive amounts of sensitive data from any machine it happens to run on.
mike_hearn 5y ago
Hash verification does nothing as SSL is protecting ordinary downloads from MITM attacks already. Actually, binary package managers are arguably strictly less safe than getting the binaries directly from upstream because you've just introduced a (literal) "man in the middle", who might have their own agendas and their own need to monetize. Like, for example ... SourceForge did. In a different context these MITM attacks can go wrong even when they're genuinely trying to be helpful, as we may remember when Debian accidentally patched out important code from a core encryption library and caused everyone to get the same SSH keys. Generally for security you want to reduce the number of middlemen who can tamper with things, unless those middlemen are explicitly adding some sort of security value by pre-tasting the apps. So, Apple app reviewers: yes. Linux distro maintainers: sorta sometimes. Homebrew, winget etc: no. It's all automated.
- noasaservice 5y ago
  Explain to me how SSL tells me so I know which is the right site: https://www.vlcdownload.com https://www.vlcdownloads.com https://www.videolan.com https://www.vlc.com https://www.downloadvlc.com https://www.videolan.org https://www.videolan.co.uk https://sourceforge.net/projects/vlc/ In linux/Mac, I can "sudo apt install vlc", "sudo yum install vlc", or "sudo brew install vlc". I know I'm getting a valid and good software delivery. It just works. No malware. No sketchy websites. No malware packages. On Windows, well, you feelin lucky?
  - yurymik 5y ago
    Now we have `winget install VideoLAN.VLC` :)
    - sharken 5y ago
      Which is sadly not as intuitive as 'choco install vlc', WinGet really needs to support aliases to become widely used. Chocolatey does have it's quirks though, there is both a '7zip' and a '7zip.install' package, it's not intuitive what the difference is.
  - 5y ago
hassancf 5y ago
Isn’t the following better than current windows package managers? a) Download file.EXE binary from somewhere b) run: certutil -hashfile file.EXE (which spits out hash value) c) search for hash value obtained at step “b” on a site like: virustotal.com : it tells you if malware is detected d) run: file.exe (if no malware detected) I honestly couldn’t find a better method on MS Windows. Other suggestions?
- abetancort 5y ago
  Go to Github directly and find the VLC repository from there everything is straightforward. Forget Sourgeforge, it jumped the shark years ago.

robonerd 5y ago

Checking a hash is safer only if the person who commits the "known good hash" to the package repository actually verifies that goodness. If the programs developer sells out and puts malware into their official binary releases, and the package maintainer doesn't notice this, then checking hashes doesn't protect you from the malicious release.

ramesh31 5y ago
>If the programs developer sells out and puts malware into their official binary releases, and the package maintainer doesn't notice this, then checking hashes doesn't protect you from the malicious release. Nothing short of a full code review will save you from a malicious supply chain attack. This is currently exploding with NPM as well, so building from source doesn't save you here either. See the node-ipc debacle from a few weeks ago [0], and also my own post from last week about a malware infected NPM module [1]. The reality is that yes, the days of being able to trust anything downloaded from a stranger on the internet are pretty much over now. But known-hash package management is still a good first layer of security versus downloading random binaries from the web. [0] https://nvd.nist.gov/vuln/detail/CVE-2022-23812 https://nvd.nist.gov/vuln/detail/CVE-2022-23812 [1] https://news.ycombinator.com/item?id=30963600 https://news.ycombinator.com/item?id=30963600
- b112 5y ago
  I appreciate what you are saying, but it was over decades ago! Node is just insane, always was, along with the curl | bash crowd. Madness.
- ryukafalz 5y ago
  > Nothing short of a full code review will save you from a malicious supply chain attack. Nonsense. Or, at least, an oversimplication. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... Nothing short of full code review will ensure that malicious code from a dependency doesn’t get into your program at all, but the capabilities of that malicious code once it does get into your program can certainly be limited.
  - munk-a 5y ago
    I don't disagree that Javascript in general runs with a lot more permissions than should probably be given but permissions is a very hard thing to manage. So you decide to install a node package that helps retry and automatically back off requests you want to send to your server since you're working in a mobile environment that has sketchy internet reliability... it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server. Additionally, these permissions will be more comprehensible to review but they still need to be reviewed and reviewed by a party you trust. That's a tall order for the open source community when it comes to a volume of packages like npm or composer. You can logically look at lpad as a package and say "We're padding strings, we don't need to do anything with network traffic or disk reads" but building an automated system to make that evaluation and saving that evaluation in a tamperproof manner is going to be hard... and what happens if lpad starts trying to do a better job - operating correctly in left-to-right character sets and in languages where alignment is dictated by hyphens instead of blank space. Code isn't simple and while the above statement may seem hyperbolic I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk but actually fully 100% preventing that risk? You'll need to check every usage scenario on every set of hardware and go through that code with a fine toothed comb.
    - ryukafalz 5y ago
      > it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server If you're expecting to have to craft ACLs program-wide for that package, then sure, that's going to be hard. That's more coarse-grained than what I'm talking about here though. Imagine, if you will, a programming environment where modules you load don't have any authority to access the network, filesystem, etc unless you pass them in. They're just not in scope. In such a language, the default way to grant HTTP access might look like this in pseudo-Python: http = require("http") myMaliciousLibrary = require("myMaliciousLibrary", http=http) Now, this library has the problem you mentioned; it can make arbitrary outgoing HTTP requests, meaning it can send any metrics it collects to an ad server. It can't access the filesystem because the filesystem isn't in scope either, so what it can collect is limited, but still more access than it needs. So here's one way you might fix that (obviously highly simplified/incomplete in its implementation): class ProxyHTTP(origin="https://example.com", http): def __init__(origin="https://example.com"): self.allowed_origin = origin def get(origin, path="/"): return http.get(self.allowed_origin, path) http = require("http") myMaliciousLibrary = require("myMaliciousLibrary", http=ProxyHTTP(origin="https://good-site.example.com", http)) Now, this version of myMaliciousLibrary gets an object that looks like the http library it would normally use; it just happens to ignore the origin parameter that the library passes to it and uses the one it was initialized with instead. Now, that library can make requests to good-site.example.com, but if it tries to make a request to adserver.evil.com, it'll go to good-site.example.com instead. (You might also imagine a version of ProxyHTTP that just throws an error if the request's origin isn't the same one it was initialized with, or isn't in a list it was initialized with.) Most of today's programming languages aren't strict enough to enable this of course; JavaScript isn't there yet for example, and most other languages aren't even close to being able to do this. But that's mostly because they don't provide strict enough encapsulation, not because they're lacking some complex security enforcement mechanism. > I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk I just think people are accepting way more risk than they realize, given the number of dependencies in modern applications and the amount of access each of those dependencies have. It feels crazy that any one of those dependencies in any application could exfiltrate massive amounts of sensitive data from any machine it happens to run on.

mike_hearn 5y ago

Hash verification does nothing as SSL is protecting ordinary downloads from MITM attacks already. Actually, binary package managers are arguably strictly less safe than getting the binaries directly from upstream because you've just introduced a (literal) "man in the middle", who might have their own agendas and their own need to monetize. Like, for example ... SourceForge did. In a different context these MITM attacks can go wrong even when they're genuinely trying to be helpful, as we may remember when Debian accidentally patched out important code from a core encryption library and caused everyone to get the same SSH keys. Generally for security you want to reduce the number of middlemen who can tamper with things, unless those middlemen are explicitly adding some sort of security value by pre-tasting the apps. So, Apple app reviewers: yes. Linux distro maintainers: sorta sometimes. Homebrew, winget etc: no. It's all automated.

noasaservice 5y ago
Explain to me how SSL tells me so I know which is the right site: https://www.vlcdownload.com https://www.vlcdownloads.com https://www.videolan.com https://www.vlc.com https://www.downloadvlc.com https://www.videolan.org https://www.videolan.co.uk https://sourceforge.net/projects/vlc/ In linux/Mac, I can "sudo apt install vlc", "sudo yum install vlc", or "sudo brew install vlc". I know I'm getting a valid and good software delivery. It just works. No malware. No sketchy websites. No malware packages. On Windows, well, you feelin lucky?
- yurymik 5y ago
  Now we have `winget install VideoLAN.VLC` :)
  - sharken 5y ago
    Which is sadly not as intuitive as 'choco install vlc', WinGet really needs to support aliases to become widely used. Chocolatey does have it's quirks though, there is both a '7zip' and a '7zip.install' package, it's not intuitive what the difference is.
- 5y ago

hassancf 5y ago

Isn’t the following better than current windows package managers? a) Download file.EXE binary from somewhere b) run: certutil -hashfile file.EXE (which spits out hash value) c) search for hash value obtained at step “b” on a site like: virustotal.com : it tells you if malware is detected d) run: file.exe (if no malware detected) I honestly couldn’t find a better method on MS Windows. Other suggestions?

abetancort 5y ago
Go to Github directly and find the VLC repository from there everything is straightforward. Forget Sourgeforge, it jumped the shark years ago.