4 ms·

I'd be interested in knowing, how do you assess whether something is a "trusted source" or not?

coldtea 11y ago
The same way we trust people. By reputation and familiarity. If something is from e.g. Red Hat or a large project repository like Apache, it's more trusted than a random website with some unknown tarball... If many people in websites and forums say "don't trust this program", well, don't trust it. Etc.
- raesene6 11y ago
  Ahh but that's one of the hardest pieces of the trust puzzle. On the internet, how do you know who's who. you download a package from npm. Who wrote it, what's their background, where do they work? What are their security practices like, what are the security practices of the hosting company? so we say Redhat/Apache are more trusted sure, that's one of the reasons that I dislike curl|bash from random sites, there's no way of assessing trust in that software or its origin...
  - coldtea 11y ago
    >On the internet, how do you know who's who. you download a package from npm. Who wrote it, what's their background, where do they work? What are their security practices like, what are the security practices of the hosting company? Check the npm package's ratings, and the github repository watchers and stars. Try to find and read a few posts (and their comments) on the package. The more respected the source (e.g. HN comments vs comments on Digg), the better.
    - raesene6 11y ago
      that's not a bad mechanism (if a bit time consuming) for personal usage, but wouldn't likely work for corp. use.. Even there though all it does is move the problem one step away. Most npm packages have dependencies (and quite a few of them), you have no way of knowing whether the author of the main package did the checks you describe for their dependencies...
      - coldtea 11y ago
        >Even there though all it does is move the problem one step away. Most npm packages have dependencies (and quite a few of them), you have no way of knowing whether the author of the main package did the checks you describe for their dependencies... That's the nice thing: you don't need to. You just need to trust that the main package works well enough -- and you get that from the fact that it is in widespread use (many downloads, watchers, stars, posts, etc).
        raesene6 11y ago
        errrm and if a dependency is untrustworthy it can execute code on your system at install time... the fact that no-one else is checking and you are therefore in the same boat as other compromised people might not be that much of a consolation
        coldtea 11y ago
        The thing is, if thousands use it, then you'd know if it's unsafe... Beyond that, yeah, nothing is absolutely certain in life except death and taxes...
        tamana 11y ago
        This assumption fails in the network connected world where a program can download custom instructions after installation.
        coldtea 11y ago
        It doesn't fail, it's still as usable as ever -- just not infallible, which nothing is anyway. The dynamics of something with a larger user base being more trustworthy don't change because we're on the internet. It's a simple network (no pun intended) effect. If the program "can download custom instructions after installation" then a large user base still means that users will be bound to find it sooner or later (and make it public/fix it) and it makes it less likely to be you (because you're 1 from 200,000 downloading it, not 1 of 20 or 200).
nailer 11y ago
Binaries and some websites are signed with a verified legal entity. This is what the Debian guys standing in a circle holding their passwords are doing at your Linux event. It's also why when you visit github it says 'GitHub, Inc [US]' in your browser's address bar. Heads up: I work on the latter.
- raesene6 11y ago
  Sure but SSL identification is a very small part of the process of having a "trusted source". There is, I'm sure, malicious software hosted on github, so I can download things from that trusted source and still have trouble. there is insecure software hosted on github, again there's no protection based on hosting company. If a developer who hosts a repository on github has their credentials compromised, their software may become malicious. Also as an end-user (particularly a non-paying one) I have no visibility of Githubs own security policies and practices, so assessing the level of trust placed there is tricky. The debian model has more checks and balances (i.e. it's harder to get from one set of compromised creds to a malicious package in a production repo.) but still not perfect...
- rmc 11y ago
  > This is what the Debian guys standing in a circle holding their passwords are doing at your Linux event. Passports, surely? :P
  - nailer 11y ago
    Passports indeed. Sorry, autocorrect.

The same way we trust people. By reputation and familiarity. If something is from e.g. Red Hat or a large project repository like Apache, it's more trusted than a random website with some unknown tarball... If many people in websites and forums say "don't trust this program", well, don't trust it. Etc.

raesene6 11y ago
Ahh but that's one of the hardest pieces of the trust puzzle. On the internet, how do you know who's who. you download a package from npm. Who wrote it, what's their background, where do they work? What are their security practices like, what are the security practices of the hosting company? so we say Redhat/Apache are more trusted sure, that's one of the reasons that I dislike curl|bash from random sites, there's no way of assessing trust in that software or its origin...
- coldtea 11y ago
  >On the internet, how do you know who's who. you download a package from npm. Who wrote it, what's their background, where do they work? What are their security practices like, what are the security practices of the hosting company? Check the npm package's ratings, and the github repository watchers and stars. Try to find and read a few posts (and their comments) on the package. The more respected the source (e.g. HN comments vs comments on Digg), the better.
  - raesene6 11y ago
    that's not a bad mechanism (if a bit time consuming) for personal usage, but wouldn't likely work for corp. use.. Even there though all it does is move the problem one step away. Most npm packages have dependencies (and quite a few of them), you have no way of knowing whether the author of the main package did the checks you describe for their dependencies...
    - coldtea 11y ago
      >Even there though all it does is move the problem one step away. Most npm packages have dependencies (and quite a few of them), you have no way of knowing whether the author of the main package did the checks you describe for their dependencies... That's the nice thing: you don't need to. You just need to trust that the main package works well enough -- and you get that from the fact that it is in widespread use (many downloads, watchers, stars, posts, etc).
      - raesene6 11y ago
        errrm and if a dependency is untrustworthy it can execute code on your system at install time... the fact that no-one else is checking and you are therefore in the same boat as other compromised people might not be that much of a consolation
        coldtea 11y ago
        The thing is, if thousands use it, then you'd know if it's unsafe... Beyond that, yeah, nothing is absolutely certain in life except death and taxes...
        tamana 11y ago
        This assumption fails in the network connected world where a program can download custom instructions after installation.
        coldtea 11y ago
        It doesn't fail, it's still as usable as ever -- just not infallible, which nothing is anyway. The dynamics of something with a larger user base being more trustworthy don't change because we're on the internet. It's a simple network (no pun intended) effect. If the program "can download custom instructions after installation" then a large user base still means that users will be bound to find it sooner or later (and make it public/fix it) and it makes it less likely to be you (because you're 1 from 200,000 downloading it, not 1 of 20 or 200).

nailer 11y ago

Binaries and some websites are signed with a verified legal entity. This is what the Debian guys standing in a circle holding their passwords are doing at your Linux event. It's also why when you visit github it says 'GitHub, Inc [US]' in your browser's address bar. Heads up: I work on the latter.

raesene6 11y ago
Sure but SSL identification is a very small part of the process of having a "trusted source". There is, I'm sure, malicious software hosted on github, so I can download things from that trusted source and still have trouble. there is insecure software hosted on github, again there's no protection based on hosting company. If a developer who hosts a repository on github has their credentials compromised, their software may become malicious. Also as an end-user (particularly a non-paying one) I have no visibility of Githubs own security policies and practices, so assessing the level of trust placed there is tricky. The debian model has more checks and balances (i.e. it's harder to get from one set of compromised creds to a malicious package in a production repo.) but still not perfect...
rmc 11y ago
> This is what the Debian guys standing in a circle holding their passwords are doing at your Linux event. Passports, surely? :P
- nailer 11y ago
  Passports indeed. Sorry, autocorrect.