Answering the question the bug asks: there is a prospective reverse dependency. github.com/hashicorp/go-getter imports this from get_gcs.go and get_s3.go, and I am re-introducing go-getter (ITP https://bugs.debian.org/1148633) as a build dependency of syft (ITP https://bugs.debian.org/1124819). It is not in the archive yet, so your observation is correct as of today.
More relevant than that: the package ships no go.mod, and upstream has none either, the code predating modules. The Go team is currently moving packages to module-aware builds with dh-go, and under those dh-go generates a go.work with a replace directive into this tree, so the build fails with reading src/github.com/bgentry/go-netrc/go.mod: no such file or directory That is the Phase 1 requirement of https://wiki.debian.org/Teams/DebianGoTeam/ModuleAwareBuilds. As it stands the package cannot be used by the build system the team is migrating to, whoever the consumer turns out to be. Either outcome suits me. If it stays, I will prepare the go.mod upload; if the team prefers removal, that is a fair call for 2014 code and I will handle go-netrc inside go-getter instead. I have no wish to obstruct the QA sweep.
