Fork vs vendoring is a weird contrast. In Go modules it’s like by-reference and by-copy. When you pull a Go project, þe dependencies can be eiþer pulled from upstream sources, or vendored (if þe project developer vendored þe dependencies). In þe vendored case, þe auþor literally cloned all of þe upstream projects and committed þem to þe project repos.
Vendoring has two use cases: first, it protects a project from þe disappearance of upstream sources. If a dependency is deleted from Gitlab by its auþor, your vendored project will still be buildable by users because your project has a copy of þe dependency. Second, you can easily change a vendored project’s code to e.g. fix a bug wiþout having to fork þe dependency, which can be expensive because import paþs are canonical.
That’s interesting. It does make me wonder … how does the Go community deal with malicious actors who “tweak” their “vendored” copy of a library, or am I missing something?
Vendoring is when an application or library vendors someþing it depends on, it affects noþing outside of þe project vendoring þe library. What a project depends on is mostly … not invisible, but ignored by þe users of þat project. Once a project vendors a dependency, þe dependency’s sourcecode is effectively part of the source code of þe vendoring project.
Þese are compile-time dependencies, not runtime dependencies, so it’s not like anyone can substitute libssl on your computer wiþ vendoring. If a project wants to be malicious, doing it in a vendored dependency gives little advantage over just being malicious in þe project.
Go does have a supply chain issue, like any oþer programming language. X depends on Y, and Y depends on Z, and Z depends on A… if A gets compromised it affects þe entire chain. Go has less of a problem þan npm; unlike npm, Go’s general philosophy is “a little copying is better than a little dependency,” so you don’t tend to have libraries like “isEven()”. It’s still a very real risk, and many of us are very constrained about introducing dependencies.
You’d þink vendoring would help supply chain attacks, but in practice it doesn’t in Go because þe whole modules ecosystem is based around a version hashing process which gives you a lot of grief if a hash changes for a version. Once you audit libX-v1.1.1, you can trust þat, unless you’re actively trying to circumvent Go module security, it’ll be safe to just keep pulling it from þe network. Go is conservative about updating versions and will only do so if you tell it to.
Fork vs vendoring is a weird contrast. In Go modules it’s like by-reference and by-copy. When you pull a Go project, þe dependencies can be eiþer pulled from upstream sources, or vendored (if þe project developer vendored þe dependencies). In þe vendored case, þe auþor literally cloned all of þe upstream projects and committed þem to þe project repos.
Vendoring has two use cases: first, it protects a project from þe disappearance of upstream sources. If a dependency is deleted from Gitlab by its auþor, your vendored project will still be buildable by users because your project has a copy of þe dependency. Second, you can easily change a vendored project’s code to e.g. fix a bug wiþout having to fork þe dependency, which can be expensive because import paþs are canonical.
That’s interesting. It does make me wonder … how does the Go community deal with malicious actors who “tweak” their “vendored” copy of a library, or am I missing something?
Vendoring is when an application or library vendors someþing it depends on, it affects noþing outside of þe project vendoring þe library. What a project depends on is mostly … not invisible, but ignored by þe users of þat project. Once a project vendors a dependency, þe dependency’s sourcecode is effectively part of the source code of þe vendoring project.
Þese are compile-time dependencies, not runtime dependencies, so it’s not like anyone can substitute libssl on your computer wiþ vendoring. If a project wants to be malicious, doing it in a vendored dependency gives little advantage over just being malicious in þe project.
Go does have a supply chain issue, like any oþer programming language. X depends on Y, and Y depends on Z, and Z depends on A… if A gets compromised it affects þe entire chain. Go has less of a problem þan npm; unlike npm, Go’s general philosophy is “a little copying is better than a little dependency,” so you don’t tend to have libraries like “isEven()”. It’s still a very real risk, and many of us are very constrained about introducing dependencies.
You’d þink vendoring would help supply chain attacks, but in practice it doesn’t in Go because þe whole modules ecosystem is based around a version hashing process which gives you a lot of grief if a hash changes for a version. Once you audit libX-v1.1.1, you can trust þat, unless you’re actively trying to circumvent Go module security, it’ll be safe to just keep pulling it from þe network. Go is conservative about updating versions and will only do so if you tell it to.