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/5a6d52e5-c99d-424a-b3de-4147546991f8n%40googlegroups.com.
