LWN: Comments on "Securing Git repositories with gittuf"

Securing Git repositories with gittuf

mathstuf — Tue, 14 May 2024 22:56:15 +0000

> Even "just have somebody trusted sign off that a CI run happened" would be a vast improvement over the current situation. You can't store a local record of the things that Github runs or its artifacts (at least, not in an accessible and automated way), and Github's UX appears to drop this information after some time.

The merge commit message is a perfect place to capture information like CI results (e.g., `Tested-by` means everything passed, `Acked-by` could mean "builds worked, but tests failed") and who reviewed it (since tagging individual patches would invalidate hashes and CI results). You can see an example here: https://gitlab.kitware.com/vtk/vtk/-/commit/7f0be0798c32b...

Securing Git repositories with gittuf

apoelstra — Sun, 12 May 2024 21:39:38 +0000

>Signing is the obvious way to record the result but how do you actually guarantee that anything actually ran locally?

Even "just have somebody trusted sign off that a CI run happened" would be a vast improvement over the current situation. You can't store a local record of the things that Github runs or its artifacts (at least, not in an accessible and automated way), and Github's UX appears to drop this information after some time. Meanwhile for the tests that I run locally, I record these using some ad-hoc git-notes based thing that is hard to share with others and makes it very easy to lose track of records because I didn't take the time to create a principled append-only searchable global log out of it.

The result is that, when I receive a bug report about a branch that hasn't been updated in months (or years), and when I go to build it, I have no idea what compiler version or environment it was tested on, what suite of tests were run and at what time and by whom, etc etc.

Same for signoffs on merges. Here Github works pretty well, at least if you have some local mapping from commit IDs to pull request numbers, but it still makes me nervous that I need to trust Github to store a record of ACKs forever. (Maybe gerrit is sufficient to address this issue? I don't know because the value proposition hasn't been big enough for me to learn it it, let alone encourage my team members to follow.)

So without even touching on the trust/security aspect of things, this project is something I'm very interested in. Just to have an audit log about what happened to my project and when (at least, according to me or other people I trust).

Securing Git repositories with gittuf

LtWorf — Fri, 10 May 2024 17:02:31 +0000

Lower entry barriers might mean 100x more jia tan :D

Securing Git repositories with gittuf

mb — Fri, 10 May 2024 16:34:29 +0000

Yes. That is no contradiction.

No amount of code signing, authorization process, signing-offs and higher entry barriers are going to prevent another Jia Tan.
That is basically impossible to prevent.

However, more people and *lower* entry barriers significantly increase the chance of *detecting* another Jia Tan.
Scaring people away with useless processes is going to make us more vulnerable in the end.

Securing Git repositories with gittuf

Wol — Fri, 10 May 2024 16:12:10 +0000

> Or they want me to have branch protection and code revisions. Cool… except who should review my code? Most other contributors just changed a few lines here and there. The suggestion to fix this is "find more people".

You mean people like Jia Tan ... <snigger>

Cheers,
Wol

Securing Git repositories with gittuf

LtWorf — Fri, 10 May 2024 13:29:37 +0000

Well I think the entire point of OpenSSF is to shove compliance to some sort of rules down the throats of developers.

I've actually tried to implement their scorecard thing for my project "typedload".

For example, you need to pin dependencies, because a new version might introduce vulnerabilities… but you also need to update the pin all the time for old security vulnerabilities. Also, if you never read the code of the dependencies, what is the point of pinning to a specific version? Nobody has vetted it any more than a newer version (I always use latest mypy in the CI).

They want me to have a "dependency update tool"… the project only depends on python, and certainly doesn't vendor it.

Or they want me to have branch protection and code revisions. Cool… except who should review my code? Most other contributors just changed a few lines here and there. The suggestion to fix this is "find more people".

I work for a security company and we have fewer requirements than that :D

Anyway, this thing being sponsored by OpenSSF makes me think their goal is to enforce these rules onto open source, so that eventually proprietary stuff will only run the secure™ (is on github, runs their scorecard) open source software and will automatically be compliant without extra vetting of the dependencies.

The hilarious thing is that you can write an "rm -rf /" in your code and still be 100% compliant with everything. Because the idea that you can evaluate security of a project just basing on some abstract rules, without actually reading the code is wrong to begin with.

Securing Git repositories with gittuf

weal — Fri, 10 May 2024 11:24:02 +0000

Just imagine being a beginner and trying to learn git with all this extra stuff on top. It reminds me of jobs where I have had to spend a week doing some esoteric configuration just to get setup to get started. You just know the project is going to be a frustrating experience.

This sounds like a typical "make work" project to keep us all busy. To make us into "experts" and "specialists" in this New Thing.

I can understand that in certain situations "compliance" (whatever that means) is worth it, and in those cases they can hire someone for that purpose and use tools that stay out of my way as a dev. The vast majority of projects will be harmed by tools like this for having "too many cooks in the kitchen".

Securing Git repositories with gittuf

taladar — Fri, 10 May 2024 07:58:46 +0000

Honestly, this all sounds quite vague in how it plans to actually achieve any of those assurances. Signing is the obvious way to record the result but how do you actually guarantee that anything actually ran locally?

I also really don't see anything close to 100% of the dependencies out there use this kind of workflow with rules consistent enough to be useful at the point where the project using a couple of dozen of them wants to present some guarantees of their own.

Securing Git repositories with gittuf

LtWorf — Fri, 10 May 2024 07:12:42 +0000

I'm a firm believer that if anyone asks for the boring compliance stuff that makes coding miserable and that we must use at our normal jobs, they must be prepared to at least donate relevant amount of money.

I personally intend to shut down requests to enforce this stuff (should I receive any) unless they come with sponsoring, and I invite everyone else to do the same.

Securing Git repositories with gittuf

Heretic_Blacksheep — Thu, 09 May 2024 20:41:07 +0000

It's intended to be a first step in enforcing more fine grained logistical policies that big projects may wish to use for accountability & attestation along with partially automating the review process of commits. It's for larger projects needing team access controls. Ex: Bob from the UI team may not have legit access to the back end code folders, so why did he just push a 4 line function call to a new library? Should be a red flag for review or an automatic reject for insufficient access rights.

This wouldn't have solved the intentional XZ social engineering issue, and won't solve the problem of having the manpower to review new commits. But, it should give a bit more logistical control versus vanilla git it seems.

The manpower issue is only going to be solved with better (and free/cheaper/easier-to-use) behavior modeling tools. There's just not enough skilled man hours on this planet to review every bit of code for the near infinite varieties of malicious behavior or just plain old "weird machines".

Signed pushes

jnareb — Thu, 09 May 2024 13:25:45 +0000

> Another feature that Lynch mentioned for the future is signed pushes, but he said that "is not the top priority" because it is not yet supported by any of the Git forges.

Though signed pushes are not supported by any (major?) Git forge, they are supported by kernel.org via **Kernel.org Transparency Log Monitor** https://tlog.linderud.dev/

Securing Git repositories with gittuf

k3ninho — Thu, 09 May 2024 09:35:43 +0000

>[a question in Q&A] wondered whether gittuf could allow developers to run CI tests locally and just submit proof that they had been run to save on costs

Don't just do it to save on costs running tests at all, do it to save you from failing pipelines when 'trust me this works locally' doesn't work in the CI/CD pipelines. Remember the principle behind 'did you test your changes locally?' -- this attestation would shorten some feedback loops.

K3n.

Securing Git repositories with gittuf

tzafrir — Thu, 09 May 2024 06:16:39 +0000

I'm not sure I understand the model and how it works with distributed development.

What would it take to fork (hard-fork) a project?

Securing Git repositories with gittuf

pj — Thu, 09 May 2024 01:39:43 +0000

Glad to see someone's trying to drag more functionality that's currently only in forges into the repo. I'd love to see git gain some of the functionality that fossil has, like a standard issue tracker and wiki. Maybe even a review API/tool that would make a 'reviewed-by' tag a bit more well-defined.