6 ms·

You can't trust open source repos either; you can only verify them. And is anyone really reading all of the code they run before they run it? With all of its t

You can't trust open source repos either; you can only verify them. And is anyone really reading all of the code they run before they run it? With all of its third-party dependencies? I don't think open source repositories are safer because they're open source, but precisely because there is no commercial benefit to shoveling BS into them. In fact, with the bigger commercial open source software, you often do see crap you don't want being included as a means to funnel users into commercial channels.

jacquesm 12y ago
Yes, that's an excellent point, I highly doubt anybody verifies what they install end-to-end. We all put a lot of trust in reputations and a couple of checksums.
- TeMPOraL 12y ago
  Trust is fundamental to society, having a civilization is impossible without it. We shouldn't expect people to verify everything all the time.
seanwilson 12y ago
You also need to verify that the binary you run is the same source code and be able to identify malware in source code that may be very well hidden. This isn't remotely practical and for even simple software. The only practical solution I can see is proper sandboxing of applications so you don't need to trust them in the first place.
- jacquesm 12y ago
  That's probably where we're headed. Hypervisors running single-application kernels talking via message passing over some networking protocol to display servers and other virtualized hardware.
  - TeMPOraL 12y ago
    Am I the only one who thinks this reality sucks? Everything locked down, no way to tweak or repurpose any of your software. I know, there are bad actors out there, etc. but shouldn't there be a limit for destroying utility of things in the name of security?
    - code_duck 12y ago
      Why would proper sand boxing limit tweaking or repurposing of software? (I must admit I'm not sure exactly what you mean by that). It just limits apps interactions with each other and the OS environment.
      - jacquesm 12y ago
        You answered your own question: > It just limits apps interactions with each other and the OS environment. That makes a whole slew of modifications and tricks harder and/or impossible without having access to the sourcecode of the software, which is (on windows at least) not rare at all. Any kind of interaction not explicitly allowed is then forbidden and the sandboxing will be a lot harder to overcome than two apps on the same machine talking to each other using a third. Maybe some kind of unified app-to-app messaging protocol can take care of this, similar to how linux systems uses 'dbus' and the likes.
        TeMPOraL 12y ago
        Exactly this. I still remember the times when if I needed to change something in an application, I could just write to its process memory directly. Those were fun times... What I want is to retain the ability to repurpose the software on my terms. To move data in and out of the software whether software's authors like it or not. It's becoming harder each day, as more and more tools move to the cloud and turn into apps. I'm happy we still have userscripts in the browser but how long will it take before they get banned too? This problem has many names. "War on General-Purpose Computation" is one of them, but I suppose the "professionalization of programming" is another. How long will it take before you'll need an engineering license to be allowed to use a compiler, or work with a Turing-complete language?
aw3c2 12y ago
Actually, I do trust them and I do not verify them. So far I have had only good experiences.
tristor 12y ago
I haven't done this in most cases, but for some systems this is a practical action to take (embedded system, minimal software, security sensitive). The reality is any modern OS + apps for "basic" functions is far too complex and has too many SLOC in too many disparate languages for any one person to be able to reliably verify it all. Knowing that the very simple basic functionality of all the code you plan to run on an embedded device is secure though is still an achievable objective.

jacquesm 12y ago

Yes, that's an excellent point, I highly doubt anybody verifies what they install end-to-end. We all put a lot of trust in reputations and a couple of checksums.

TeMPOraL 12y ago
Trust is fundamental to society, having a civilization is impossible without it. We shouldn't expect people to verify everything all the time.

seanwilson 12y ago

You also need to verify that the binary you run is the same source code and be able to identify malware in source code that may be very well hidden. This isn't remotely practical and for even simple software. The only practical solution I can see is proper sandboxing of applications so you don't need to trust them in the first place.

jacquesm 12y ago
That's probably where we're headed. Hypervisors running single-application kernels talking via message passing over some networking protocol to display servers and other virtualized hardware.
- TeMPOraL 12y ago
  Am I the only one who thinks this reality sucks? Everything locked down, no way to tweak or repurpose any of your software. I know, there are bad actors out there, etc. but shouldn't there be a limit for destroying utility of things in the name of security?
  - code_duck 12y ago
    Why would proper sand boxing limit tweaking or repurposing of software? (I must admit I'm not sure exactly what you mean by that). It just limits apps interactions with each other and the OS environment.
    - jacquesm 12y ago
      You answered your own question: > It just limits apps interactions with each other and the OS environment. That makes a whole slew of modifications and tricks harder and/or impossible without having access to the sourcecode of the software, which is (on windows at least) not rare at all. Any kind of interaction not explicitly allowed is then forbidden and the sandboxing will be a lot harder to overcome than two apps on the same machine talking to each other using a third. Maybe some kind of unified app-to-app messaging protocol can take care of this, similar to how linux systems uses 'dbus' and the likes.
      - TeMPOraL 12y ago
        Exactly this. I still remember the times when if I needed to change something in an application, I could just write to its process memory directly. Those were fun times... What I want is to retain the ability to repurpose the software on my terms. To move data in and out of the software whether software's authors like it or not. It's becoming harder each day, as more and more tools move to the cloud and turn into apps. I'm happy we still have userscripts in the browser but how long will it take before they get banned too? This problem has many names. "War on General-Purpose Computation" is one of them, but I suppose the "professionalization of programming" is another. How long will it take before you'll need an engineering license to be allowed to use a compiler, or work with a Turing-complete language?

aw3c2 12y ago

Actually, I do trust them and I do not verify them. So far I have had only good experiences.

tristor 12y ago

I haven't done this in most cases, but for some systems this is a practical action to take (embedded system, minimal software, security sensitive). The reality is any modern OS + apps for "basic" functions is far too complex and has too many SLOC in too many disparate languages for any one person to be able to reliably verify it all. Knowing that the very simple basic functionality of all the code you plan to run on an embedded device is secure though is still an achievable objective.