I would like to see a web of trust model in Go libraries. I import a library with no dependencies and spend a couple of hours auditing it. It looks good, so I sign that commit hash. Someone who trusts me can used that version with less concern. If other people also audit the same library and sign it, it gets even more trustworthy.
I can audit a library with no dependencies in a couple of hours; the problem is that many libraries have deep dependency trees.
I’d even be happy to do an audit-for-hire, that comes with insurance. Something more reasonable than current audit costs, but surely we can crowd source a solution.
I_quote_Seinfeld_a_lot@sh.itjust.works
on 09 May 10:21
collapse
Is vendoring really going to help? Vendor or not, you need to review your deps’ code.
Go’s go.sum should already protect against malicious changes in upstream packages, no?
You’re right that it’s crucial to review dependencies. Vendoring does help, in a few ways:
It makes obvious your dependency tree. It’s easy to import badger and think you’re “only” adding one dependency, only to pull in 135 additional packages. Yes, you see it in the go.mod; yes, you see it in the go import output. But pulling it into a vendor directory is qualitatively different - your project directory size blows up, and it makes it viscerally clear the amount of code you have to review - not just all of badger, but all 135 of its indirect dependencies.
It’s just a little safer. In theory, the Go ecosystem should be just as immutable and resistant to changeling injection as non-vendored dependencies, but there’s always the chance someone finds an attack vector. Not so with vendored dependencies: there is no chance a user will ever get any other version of a library than the one you’ve vendored.
Remote libraries can disappear. This isn’t a security concern, but if a library deletes or relocates their repository, and you haven’t vendored it, you’re SOL. If it’s merely moved to another VCS host, you have to re-audit the whole codebase, even if the only thing that changed was the project URL.
You have to audit all the dependencies anyway, which means downloading all of them. That’s easier to do from a vendor directory.
When you change a version of a dependency, it can have a cascading effect: the dependency could change the version of one of its dependencies, which could change the versions of several of its dependencies. That’s much less obvious when all that changes is go.mod and go.sum, than when you commit and see a hundred file changes in your vendor directory
And when the dependency tree does change, it’s far easier to audit; hg diff will show you what code changed in the dependencies, whereas go.mod will only tell you which packages changed. You can use your regular code review process to audit. With non-vendored dependencies, you have to go in, one by one, and hg diff -r old-dep-tag:new-dep-tag every dependency. It is far, far harder to do with non-vendored dependencies.
I have always been opposed to vendoring, even when it briefly was becoming the standard package management before go mod; but we can’t have nice things in this world because of the human refuse doing these kinds of exploits, and vendoring is the suspenders for your security belt.
What I want is a robust static analysis auditing tool like govulncheck, but which looks for intentionally malicious code and not just programming SNAFUs. I’d be more comfortable not vendoring if such a thing existed, but I’m not aware of one and not certain it’d win the perpetual security arms race. It would certainly be hell maintaining such a tool.
I_quote_Seinfeld_a_lot@sh.itjust.works
on 09 May 15:11
collapse
All true, but regarding #1: the size of the go.sum and all the indirect deps in the go.mod are also telling me a lot already :)
threaded - newest
Vender your dependencies.
I would like to see a web of trust model in Go libraries. I import a library with no dependencies and spend a couple of hours auditing it. It looks good, so I sign that commit hash. Someone who trusts me can used that version with less concern. If other people also audit the same library and sign it, it gets even more trustworthy.
I can audit a library with no dependencies in a couple of hours; the problem is that many libraries have deep dependency trees.
I’d even be happy to do an audit-for-hire, that comes with insurance. Something more reasonable than current audit costs, but surely we can crowd source a solution.
Is vendoring really going to help? Vendor or not, you need to review your deps’ code.
Go’s go.sum should already protect against malicious changes in upstream packages, no?
You’re right that it’s crucial to review dependencies. Vendoring does help, in a few ways:
vendordirectoryhg diffwill show you what code changed in the dependencies, whereas go.mod will only tell you which packages changed. You can use your regular code review process to audit. With non-vendored dependencies, you have to go in, one by one, andhg diff -r old-dep-tag:new-dep-tagevery dependency. It is far, far harder to do with non-vendored dependencies.I have always been opposed to vendoring, even when it briefly was becoming the standard package management before go mod; but we can’t have nice things in this world because of the human refuse doing these kinds of exploits, and vendoring is the suspenders for your security belt.
What I want is a robust static analysis auditing tool like
govulncheck, but which looks for intentionally malicious code and not just programming SNAFUs. I’d be more comfortable not vendoring if such a thing existed, but I’m not aware of one and not certain it’d win the perpetual security arms race. It would certainly be hell maintaining such a tool.All true, but regarding #1: the size of the go.sum and all the indirect deps in the go.mod are also telling me a lot already :)
Oh, absolutely. I think it’s just more visceral with vendoring.