It's the method they used to create the proof that's in question here. They claim their amazing product did it, and therefore you should buy their product because will do amazing things for you too!

If we are changing to sha256 because sha-1 is broken, how can we trust all those mappings and signatures?? This makes it even more confusing as to why this change is being made

Git moved to a modified SHA-1 (let's call it SHA-1′) back in 2017 which prevents the particular attack described in SHAttered, so the SHA-1′ object names and signatures can be trusted for now. But the known collision attack on the underlying algorithm makes it more likely for SHA-1′ to be broken in the future too. Researchers could find variations or improvements of the weaknesses used in SHAttered to attack SHA-1′ as well. In other words, there are no known practical collision attacks, but there are known avenues of reasearch that could lead to practical collision or second-preimage attacks being discovered.

The idea, then, is to migrate all git history to a stronger hash before that happens. If we waited until an attack was found, it'd be too late; all git history would be suspect forever into the future (disregarding extensive auditing), even if a stronger hash was used retroactively. Full SHA-256 doesn't have known practical collision attacks, and it doesn't even have known research avenues likely to lead to practical collision attacks, so is considered more future-proof than SHA-1′.

This idea of future-proofing is common in cryptography. For example RSA-1024 keys are now considered practical to factorize (with a supercomputing cluster and a few months), but that's okay, because, foreseeing the possibility, "everyone" switched to RSA-2048 or stronger a decade ago. Now we're adopting new key algorithms to protect against possible quantum computing attacks in the future.

Yes, I understand all that. The original author points out that completely ditching sha-1 will be a huge pain, very costly, and won't meaningfully improve security. You responded by saying we aren't completely ditching sha-1, which seems to lend credence to the argument that sha-1 is still safe enough to use. That's where I'm confused. Having two hashes for each object in a git repo, a sha-1 and a sha256, is not the same as wholesale deleting your rsa-1024 keys and replacing them with rsa-2048. If I'm only looking at the sha-1 and all my tools only look at that, then the sha256 isn't helping me. Is it?

Ah, the plan is to eventually completely ditch SHA-1, but only after "everyone" has already converted to SHA-256, which is hopefully before SHA-1′ is broken. See sections Object names on the command line and Transition plan from the link in my top-level comment.

If you trust the sha-256, you know the commits you have and their ancestors are not evil. So, the sha-1s for those commits can be trusted.

You should also check the mapping table's sha-256 hash, to know that it's not evil.

If you later get an evil commit trying to masquerade as one of those, Git will presumably notice that there are two commits with the same sha1 in the same repo, and bail loudly.

A proprietary LLM developed to run these proprietary tools might just maybe have guards in place to prevent it from telling you any details about what it's doing, lest you learn enough to not need that LLM

You are absolutely correct. The whole reason LLMs kinda suck at chip design (compared to say, writing react apps) is because chip designers are and have always been hyper paranoid about protecting their designs. The tools from Synopsis and the like are also very heavily protected. Nobody even feels safe discussing tips and tricks or problems and solutions for using the tools in public forums, we're all pretty sure that's forbidden in the software license agreements.

We don't even have any cloud solutions for chip design because of this paranoia. Nobody trusts anyone else with their chip designs. Instead we all build private compute farms to run our simulation and synthesis jobs. Every new company that wants to build chips has to reimplement the infrastructure to do it from scratch. It's kind of ridiculous.

So they are working with OpenAI to create an LLM that is trained on how to "expertly" use Synopsis tools. This is:

- Synopsis admitting that their tools are very difficult to use (not a flex)

- Synopsis doubling down on keeping their tools as expensive and proprietary as possible (not letting all LLMs train to use their tools, just this GPT-Synopsis LLM)

- OpenAI announcing a new (very not open) business model where you can pay them to create an exclusive proprietary LLM that can help people use your crappy product

Just amazing :-|

UPDATE: just realized that this LLM can also suggest that you buy more licenses of Synopsis tools since that will be the limiting factor to your productivity once this LLM makes everything else better. Yay.

In my twenty years of being a netizen I have never been more concerned about the future of computing. Giving a handful of incredibly shady corporations humanity's future seems really unwise.

And yet execs at those shady companies are terrified that any hobbyist will be able to recreate their core IP in a weekend.

If we don't need to migrate repos to sha256 them why do we need to change git to use sha256?

You keep the old repo for archival purposes and work with the new one.

The wording, "Where does the money go," strongly suggests a fix supply of money, which not true.

LVT is just another form of attempted centralized control of the market and it will be just as susceptible to government corruption, cronyism, lobbying, etc.

Is this the same project, or a different project that does the same thing. I took a quick glance at both and the descriptions are very similar

The idea here is you get to work, but you don't have to work.