This addresses the biggest holdout I had so far: verifying that tagged releases don't change from underneath you, by checking against a Certificate Transparency-like local log of all encountered module versions and their hash.
As I understand it, go verify checks the local go.modverify file against all transitive dependencies. It might be valuable to also check those against the dependencies' go.modverify files as well (if present), to make sure everyone is on the same page on what each version represents.
Comments
I found myself getting lost among the various posts by rsc and the resulting HN discussions, I hope this helps someone else too.
All of the posts in this series on vgo are listed here: https://research.swtch.com/vgo. There will be at least one more, a FAQ on Friday.
And the most popular HN discussions about them (in chronological order):
https://news.ycombinator.com/item?id=16421966 (Go += Package Versioning)
https://news.ycombinator.com/item?id=16431299 (Semantic Import Versioning)
https://news.ycombinator.com/item?id=16433425 (Minimal Version Selection)
You can also click on the (swtch.com) behind the link to see all other posts linking to that site:
https://news.ycombinator.com/from?site=swtch.com
This addresses the biggest holdout I had so far: verifying that tagged releases don't change from underneath you, by checking against a Certificate Transparency-like local log of all encountered module versions and their hash.
As I understand it, go verify checks the local go.modverify file against all transitive dependencies. It might be valuable to also check those against the dependencies' go.modverify files as well (if present), to make sure everyone is on the same page on what each version represents.