[Kalium]

OK. Let's not talk about potential threats. That's the language of fear, control, and paralysis. It's the language of liars and demagogues and exaggerations.

Let's talk about risks and goals. The language of opportunities.

An approach of `curl | bash` takes a needless amount of risk to accomplish its goals. It can do far too many things, of which it actually needs to do a small subset. It offers a lot of opportunity for bad things to happen to seize the opportunity for the things we want. Maybe there are ways to do the same things, to get the same ends, without taking on so much risk.

How do you feel about this subject?

[sanbor]

Good question. The specific problem that I'd like to tackle is sharing code as safe as possible.

The happy path is that you have some code to share and I want to get it exactly as you wrote it.

Right now the current issues with just using GitHub to share your code are the following:

1. GitHub app gets hacked and let's someone else do a commit (like the rails hack mentioned above).

2. GitHub employee modifies files in prod servers.

3. GitHub cloud provider gets hacked

4. State actor with lots of resources MITM GitHub.com domain and internet traffic and you fetch something else.

I think all this problems could be solved if:

1. Git enforces that all commits must be signed.

2. There is a decentralized list of usernames and keys.

This feature doesn't exists in git but it would be great if you could run `git clone` and it rejects the cloning if not all commits and tags has been signed.

But what If someone hacked GitHub to add a commit and she or he signed the commit. We need some kind of CA to only accept signed commits from the right people.

So there should be a fixed list of committers allowed in the repo and git would have to enforce that as well.

Then you have the problem that if all public keys are stored in GitHub then you almost get back to all the problems again of GitHub getting hacked. It would be great to have as many copies of usernames and public keys as possible. Something like a blockchain would be a good fit.

To recap, by having a decentralized system of users and public keys, and making git validate that the commits are signed and from the right people, we could have a much more reliable way of sharing code.

Additionally, we could have an "audit" system on top of all this were users can review code and mark it as "good". Then if you have a repo with a tagged version that has 5 reviews you can hope that it's pretty safe to run that version. Because it's a single system of usernames, you can check who are the reviewers.

It might be a bad idea to `curl | bash` a script from an stranger but at least you remove the risks of your code being delivered by a third party.

[Kalium]

> To recap, by having a decentralized system of users and public keys, and making git validate that the commits are signed and from the right people, we could have a much more reliable way of sharing code.

I can see that you've put some thought into this. I can also see you don't generally spend most of your time thinking about security. This is not a bad thing! Most people don't!

But it does occasionally show up in sloppy thinking about system design, such as when you reflexively conflate a commit being signed by a key with a commit being from the person who is expected to own that key. It means you didn't stop and think about how to integrate rapid key revocation in case of compromise, or how to rotate keys over time.

Or how social review systems tend towards unreliability, as reviews are left by those who are not experts and users trust aggregate numbers from such. How meaningful is a 4.5-star average from five reviewers on a cryptography library, if the reviewers are five random people whose expertise you know nothing about and are ill-equipped to judge?

[tomatopeel]

Have you looked at git-ssb?

https://git.scuttlebot.io/%25q5d5Du%2B9WkaSdjc8aJPZm%2BjMrqg...

[sanbor]

I haven't. Thanks for sharing!