Also, if you are concerned about the availability of the packages in the future, use vendoring to pull in a copy of the sources to the repo: https://go.dev/ref/mod#go-mod-vendor
Peter On Monday, 5 December 2022 at 13:35:25 UTC Brian Candler wrote: > On Monday, 5 December 2022 at 13:12:26 UTC loji...@gmail.com wrote: > >> The problem as I see it, is that when the security of the code relies on >> a package is outside the main program/executable, it can open potential >> problems of code injection; code changes or forks or if the url has moved, >> how these issues could cause the collapse of the integrity of the software. >> > > Go is a compiled language, and there are a few things you need to > understand about the compilation process. > > Firstly, there is no dynamic linking. The *source code* for those > third-party libraries is fetched at compile time, and then compiled into > your binary, and that's it. The binary is flat, containing your code and > the third-party code, all compiled together into a single blob. The binary > does not change, and at runtime no new dependencies are pulled in or > updated; there is no route for code injection. > > Secondly, using go modules, in your source code you point to the *exact* > version of the third-party module that you want to import - either using > its version number, or a git commit reference. This is stored in > go.mod/go.sum. The build of your application is reproducible. If the > third-party module author releases a new or different version of their > module, then you have to explicitly pick it up - e.g. with "go mod tidy". > > Therefore, if someone else builds your code from source, version X, then > they will get exactly the same dependencies as you had when you released > version X. > > Thirdly, the imports are really module names, not urls. Some of these > *happen* to look a bit like urls, and indeed there are mechanisms to fetch > the module source code automatically at compile time, if the module name > has the correct format. But apart from that these are not used as urls, > and certainly not as urls embedded in the binary.. > > Finally, if you are concerned about security problems, then you are right > to be aware of the versions of third-party libraries that you are using. > Of course, using newer versions of those libraries is likely to result in > fewer security holes, rather than more. Therefore you need to track them, > and when they are updated, you'll want to recompile and re-release your own > software to take advantage of the fixes. > > HTH, > > Brian. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9c9b6f0d-a59d-445d-93e9-7d7dc1547c60n%40googlegroups.com.
