> I do see a point in it working like it does, though really? I'd think a product whose _primary_ value proposition is "integrity and assurance over what was c

> I do see a point in it working like it does, though really? I'd think a product whose _primary_ value proposition is "integrity and assurance over what was committed when by who" this is such an odd edge case github refuses to fix. If their security team isn't looking at this and thinking "oh my these aren't the secure-by-design defaults we should have", fire them. To say "oh but you ought to use cryptographic keys to allow attribution", then why not a color code, or a subtle warning, whatever ... to hint at the fact that attribution in this case isn't only weak but totally impossibly (instead of pointing to a user-id that is 100% wrong and saying "yupp, that's the one who we believe did the commit"). Not exactly great UE. Also terrible for supply chain security. The whole thing is hard to explain because it wasn't that UE was chosen over security. There is no logic to why it was half-arsed like this and they actually get away with it all while grand-standing about all the things they do for "security". All Github-security brings to the world (other than hype) is: - Cockpit: which allows me to produce security vulns in an automated manner, and - the GHSA vulnerability severity scoring which essentially labels anything that has CVSS3 critical as moderate and allows downplaying of the real score. As a Microsoft company perhaps this is just what it is and I'm to blame for expecting things to make sense.