Golang Github Package References

[Mucas Schlack]

Hello Everyone,

I would like to install a Golang Github package, but I do not want to keep referencing the installed package in the "imports" section of the code - for security reasons, and because I want my code to be able to run without those references. Does anyone know if there is a way to do this?

For example: 

import (    

"log"    

"net/http"    

"github.com/installed-package?"

)

So, how can I remove the "github.com/installed-package"  reference above and still be able to run the package?

Regards,

Snot-Bag

[Brian Candler]

This question makes no sense to me.  If your code actually *uses* "github.com/installed-package" then it will fail to build or run without it.  On the other hand, if it doesn't use it, then just remove the import (the compiler will complain about unused imports anyway)

I also don't know what you mean by "keep referencing" (you only need to import it once in a given source file), nor the "security reasons" you mention.

Can you be more specific about what exactly you're trying to do?  Can you point to the real code in question?

[Robert Engels]

The op is trying to say, they wrote the code using github.com/robaho/fixed but then they decide they want to use a fork of fixed (maybe it is being maintained better, performance enhancements, etc) but they don’t want to change all of their code. 

Can they use a replace directive to point at the fork?

I’m uncertain - because the package references in the fork would all need to change ? (unless it used relative references which are discouraged). 

I think that is the problem. 

On Dec 5, 2022, at 5:36 AM, Brian Candler <b.ca...@pobox.com> wrote:

This question makes no sense to me.  If your code actually *uses* "github.com/installed-package" then it will fail to build or run without it.  On the other hand, if it doesn't use it, then just remove the import (the compiler will complain about unused imports anyway)

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1a747ce2-8cbc-496d-a3bb-65211315e024n%40googlegroups.com.

[Mucas Schlack]

Ok,

The package code in question looks like this: -

import (
	"context"
	"encoding/json"
	"flag"
	"fmt"
	"io"
	"log"
	"net/http"
	"net/http/httputil"
	"net/url"
	"os"
	"time"
	"github.com/go-oauth2/oauth2/v4/generates"
	"github.com/go-oauth2/oauth2/v4/errors"
	"github.com/go-oauth2/oauth2/v4/manage"
	"github.com/go-oauth2/oauth2/v4/models"
	"github.com/go-oauth2/oauth2/v4/server"
	"github.com/go-oauth2/oauth2/v4/store"
	"github.com/go-session/session"
	) 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. Snot-bag

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/JqHFwcFQDdI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3F50C814-566E-4C72-B836-D669130FFE8D%40ix.netcom.com.

[Brian Candler]

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.

[Peter Galbavy]

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