I was recently asked about whether signed commits would have prevented the #xz attack. The tl;dr is "no."

It's very important that the non #infosec community understands what a #digitalsignature does and doen't do. The notion that there's a #silverbullet for every technical, social, or trust problem is part of what makes #cybersecurity so hard to implement well.

#OpenPGP signatures rely on the system clock for setting the timestamp of a signature when signing the metadata and content of a commit. The author and committer dates can both legitimately differ from the timestamp of the signature for a number of reasons, or be made exactly the same rather trivially.

#Git history is a directed acyclic graph, not a cryptographic #blockchain, so a commit is just the delta between objects in the current treeish and the parent treeish in the graph. The signed metadata includes the current parent's SHA hash, but there's nothing stopping you from moving commits around and re-signing the new commits. If you couldn't do this, then you couldn't rebase, squash, do non-fast-forward merges, or cherry-pick.

This doesn't mean you can forge someone else's signature without access to their key material, but the attack wasn't the result of forged metadata or account impersonation. Signing wouldn't prevent commits by someone with commit access to the repository; it would just show that commits associated with Jia Tan were also signed by Jia Tan's private key. That provides no useful security control here. This was not a Git problem.

@todd_a_jacobs Good write-up. It's unfortunate that people don't understand the thing things you said, which leads me to wonder if people using the tools are qualified to use the tools.

Or, maybe it should give hope for the people who *want* to understand. I'm stuck somewhere between crotchety old developer telling people to get off my lawn and senior dev who is happy junior devs get a chance to learn. :)

@knowprose Part of the challenge is that OpenPGP is complex, and the #UI (even the graphical ones) can only do so much to simplify what is fundamentally a very technical set of operations. To be honest, even I find some of the recent changes to @GnuPG (which I've been using for decades) have forced me to re-read the manuals and change how I interact with the tool.

That's not a criticism of the developers, who are amazing people donating their work for free to the community. It's just a reality when dealing with cryptographic operations that don't rely on a central authority like #SMIME does.

If you think about it, most people don't even really understand how electricity works, but we depend on it for light, heating, computing, cooking, and lots of other stuff. People understand light switches, at least at a pragmatic level. That doesn't mean they know how to generate or distribute the stuff. The same is true of combustion engines; most people just put gas in the car and get their oil changed from time to time.

Computing and #cybersecurity are really the only domains I know of where we typically expect users to be experts for some reason. It's a natural tendency for those of us who were in on it all from the beginning, but it's not actually a reasonable expectation. It's an odd sort of bias, and one that I think #infosec people are all prone to. I fall prey to it myself sometimes, and often have to remind myself that what seems self-evident to me is pretty much voodoo and cargo-culting for most of society. Being aware of that inherent bias is essential for good #threatmodeling and developing good #securitycontrols.

@todd_a_jacobs @knowprose @GnuPG The "s" in https is a counter example. Most folks don't really know how it works, but they know why it's there. And it's become so ubiquitous they don't bother to look any more.

@pcalvin @todd_a_jacobs @GnuPG that's a very good example.

I guess I take for granted the knowledge accrued while these technologies began and evolved. Sobering to consider.