Chain of trust
Closed this issue · 5 comments
Feel free to ignore this issue, but I would like to understand what is the chain of trust of this installation method.
Why should I trust this in ANY way? What you are building here is a rootkit as a service, piped through sudo sh.
I know the immediate answer would be "If you don't trust this, do not use it", but there may be users without the expertise to understand the risks of using your product.
Would you mind to add a disclaimer to the README explaining that using your product means the user is fully trusting you not being a malicious entity?
How do you trust anything you install and run? When you install a Go binary or build it from source, do you read all of the dependencies? I can appreciate what you're saying, but it's literally the same problem with any program you run on a daily basis, there's always some degree of trust.
Well, I am trusting an organization, with a legal entity behind, such has github, google, debian, npm, rust etc.. Here I am trusting a guy named tj.
Anyway, I see your point of that there have to be some degree of trust, this is why I asked you to put a disclaimer on the README, to let people know.
NPM lets you run arbitrary post-install shell scripts, GitHub doesn't vet the dependencies of a binary you install, there are so many problems with these kinds of statements. I'm not saying people have to trust my stuff, but in that case there's a lot you shouldn't trust, it doesn't stop at the package manager.
@tj I’m wondering if you could do better than them, by being explicit with who you are trusting? Just a list of services you are using for gobinaries, and any dependencies, I think would go a long way.
Ken Thompson gave a very good lecture when he was awarded the Turing award, on this topic.
"Reflections on Trusting Trust" -[1]