2 ms·

This is true. I do have that option. But I very rarely trust the author. Most of the time I've never heard of the author. This is a good thing, and exactly why

by rlpb 13y ago

This is true. I do have that option. But I very rarely trust the author. Most of the time I've never heard of the author. This is a good thing, and exactly why Github has been so successful. By nature, if there's something obscure that I need doing, and I find some software or software module that lets me do it, then chances are I won't know the author. This means that downloading and running the binary is suddenly a very obscure use case. It should be for you, too.

mdwrigh2 13y ago
> This means that downloading and running the binary is suddenly a very obscure use case. It should be for you, too. A rare use case for you, but definitely not an obscure one in general. Besides, trusting the author, in this case, only matters if you're willing to audit the source to verify that nothing malicious is occurring -- something I'm not going to do in general. I mean, realistically, when was the last time you audited your network drivers? your OS? your browser?
- rlpb 13y ago
  You don't have to verify the source yourself. Others can do it. I trust the Debian maintainer for my package. He's a real world person who has had his key signed by other Debian developers. The fact that the source can be verified also reduces the risk of malicious modification. It's not necessarily just the author who might be malicious, either. The author's computer where he runs his compiler might be compromised.
chimeracoder 13y ago
> This means that downloading and running the binary is suddenly a very obscure use case. It should be for you, too. That's very much not true, especially when you start dealing with corporate/enterprise systems (and remember, Go is intended as a systems programming language). Just last week I heard Eliot Horowitz (CTO of 10Gen) talking about how it's advantageous for them to use Go for parts of their product, because they can provide guarantees about the software that they're running ("Hey, you're running the exact same file as what we're providing you, not fetching dependencies separately and interpreting things on-the-fly, etc.") From a security perspective, these corporate clients have already entered into contractual agreements where they don't really care to verify that the source and binary refer to the same code. If I'm paying a third-party company to provide me with software and services, I'm trusting them to provide security at multiple levels. I'm probably not even auditing their source code myself, so the idea that they would ship us a binary that didn't match the source code is something that wouldn't even enter my mind. What I've described above is not an obscure use case. Yes, there are other things that could go wrong that statically compiled binaries can't solve, but from the point of view of a bank or a large, non-tech corporation, it's one less link that could fail in the process.
- rlpb 13y ago
  OK, I'll give you that. In an enterprise environment, a company can choose to trust specific vendors' binaries, and this often happens. However, I don't think this has much bearing on the original pain point. I'm familiar with these sorts of production environments. Running a local store of gems is standard practice already. There is little marginal cost to doing this.
megrimlock 13y ago
Could you expand on what you mean by "I very rarely trust the author"? Isn't using their work a statement of trust? Source or binary, you are still embracing their description of tasks for an automated machine to perform very rapidly. If you are wary of what they have done, it's true that source is somewhat more accessible to examine than machine code, but for any non-trivial program source is still quite expensive to evaluate.
- rlpb 13y ago
  I don't necessarily need to trust the author directly. If he provides source, and the source is known to be the true source of the binary I'm using, then the source can be checked by others, even after a problem has been detected. > Isn't using their work a statement of trust? Trust isn't absolute. I might trust an author's intentions, but not that his computer has not been compromised, for example. Being forced to provide source could be argued to keep authors honest, too.
inopinatus 13y ago
Do you trust your compiler? "You can't trust code that you did not totally create yourself." - Ken Thompson[1]. [1] "Reflections on Trusting Trust", Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763, http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html

by rlpb 13y ago

mdwrigh2 13y ago

> This means that downloading and running the binary is suddenly a very obscure use case. It should be for you, too. A rare use case for you, but definitely not an obscure one in general. Besides, trusting the author, in this case, only matters if you're willing to audit the source to verify that nothing malicious is occurring -- something I'm not going to do in general. I mean, realistically, when was the last time you audited your network drivers? your OS? your browser?

rlpb 13y ago
You don't have to verify the source yourself. Others can do it. I trust the Debian maintainer for my package. He's a real world person who has had his key signed by other Debian developers. The fact that the source can be verified also reduces the risk of malicious modification. It's not necessarily just the author who might be malicious, either. The author's computer where he runs his compiler might be compromised.

chimeracoder 13y ago

> This means that downloading and running the binary is suddenly a very obscure use case. It should be for you, too. That's very much not true, especially when you start dealing with corporate/enterprise systems (and remember, Go is intended as a systems programming language). Just last week I heard Eliot Horowitz (CTO of 10Gen) talking about how it's advantageous for them to use Go for parts of their product, because they can provide guarantees about the software that they're running ("Hey, you're running the exact same file as what we're providing you, not fetching dependencies separately and interpreting things on-the-fly, etc.") From a security perspective, these corporate clients have already entered into contractual agreements where they don't really care to verify that the source and binary refer to the same code. If I'm paying a third-party company to provide me with software and services, I'm trusting them to provide security at multiple levels. I'm probably not even auditing their source code myself, so the idea that they would ship us a binary that didn't match the source code is something that wouldn't even enter my mind. What I've described above is not an obscure use case. Yes, there are other things that could go wrong that statically compiled binaries can't solve, but from the point of view of a bank or a large, non-tech corporation, it's one less link that could fail in the process.

rlpb 13y ago
OK, I'll give you that. In an enterprise environment, a company can choose to trust specific vendors' binaries, and this often happens. However, I don't think this has much bearing on the original pain point. I'm familiar with these sorts of production environments. Running a local store of gems is standard practice already. There is little marginal cost to doing this.

megrimlock 13y ago

Could you expand on what you mean by "I very rarely trust the author"? Isn't using their work a statement of trust? Source or binary, you are still embracing their description of tasks for an automated machine to perform very rapidly. If you are wary of what they have done, it's true that source is somewhat more accessible to examine than machine code, but for any non-trivial program source is still quite expensive to evaluate.

rlpb 13y ago
I don't necessarily need to trust the author directly. If he provides source, and the source is known to be the true source of the binary I'm using, then the source can be checked by others, even after a problem has been detected. > Isn't using their work a statement of trust? Trust isn't absolute. I might trust an author's intentions, but not that his computer has not been compromised, for example. Being forced to provide source could be argued to keep authors honest, too.

inopinatus 13y ago

Do you trust your compiler? "You can't trust code that you did not totally create yourself." - Ken Thompson[1]. [1] "Reflections on Trusting Trust", Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763, http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html