Breaking up http wrappers into their own modules.

[elliotcourant]

Right now when you import github.com/getsentry/sentry-go you also get some of the dependencies for the HTTP libraries that sentry supports. For example;

sentry-go/go.mod

Line 16 in bd116d6

github.com/kataras/iris/v12 v12.1.8

Any project that depends on sentry-go will now also depend on kataras/iris. Because of this; version of iris (or any other dependency that is imported by sentry-go to support http libraries) could include security vulnerabilities.

While it's unlikely that these vulnerabilities will cause direct problems; or even any problems at all. It still causes some oddities in GitHub's security notifications.

Right now there is CVE-2021-42576 which affects older versions kataras/iris. This was recently fixed in the latest commit kataras/iris@4853951 but even if you upgrade your go project to use that commit. You will still have the security warning from GitHub because of the side affect imports from sentry-go

$ go mod graph | grep bluemonday
github.com/monetr/monetr github.com/microcosm-cc/[email protected]
github.com/kataras/iris/[email protected] github.com/microcosm-cc/[email protected]
github.com/kataras/iris/[email protected] github.com/microcosm-cc/[email protected]
github.com/kataras/iris/[email protected] github.com/microcosm-cc/[email protected]

# ^ This shows that even though my package imports the latest version of the previously vulnerable package; there is still an a path in the dependency tree that requires an older version. An older version of iris is importing the older version of bluemonday

$ go mod graph | grep github.com/kataras/iris/[email protected]
github.com/getsentry/[email protected] github.com/kataras/iris/[email protected]

# ^ Looking further, the package that requires the older version of iris is sentry-go

So even if my project does not import or use the iris package from within sentry-go. I still have a less than secure package in my dependency tree.

This is not a big issue with this particular package; but it does make me a bit worried about other packages that could be at risk in the future further down the dependency tree.

---

As a potential solution to this; the base sentry-go package does not need to depend on any of the HTTP libraries that it supports. Instead a go module could be created within the sentry-go repo for each of those HTTP libraries. With the dependencies for those libraries being specific to that module.

This way simply importing sentry-go does not give me the dependencies for iris or any other HTTP library unless I explicitly import them.

Curious on what Sentry's thoughts are on this?

[elliotcourant]

#389 I've implemented a basic form of this in this PR. The same approach could be done for any of the http libraries that sentry-go supports.

On the current master branch:

$ go mod graph | grep bluemonday
github.com/kataras/iris/[email protected] github.com/microcosm-cc/[email protected]
github.com/microcosm-cc/[email protected] golang.org/x/[email protected]

With sentryiris as a separate module:

$ go mod graph | grep bluemonday
# Nothing

[rhcarvalho]

Splitting into multiple modules is tracked by #156.

Note however that the work involved is unfortunately more than just adding go.mod files.
It requires changes to how we do releases (proper tagging for all modules, bumping go.mod versions for all "submodules"), how continuous integration in GitHub Actions is setup (must make sure to run tests for all modules, not only the main module), and even affects how development works (multi-module support in VScode is still not a great developer experience).

So this change has implications that go beyond a few files in the repo, and is difficult / impossible to undo if something goes wrong (proxies will cache broken releases). Unfortunately we don't have the bandwidth to do that right now properly.

You can see on the Internet how other projects struggle with multi-module setups, two recent links that come to mind:

• https://togithub.com/prometheus/prometheus/issues/8513
• https://changelog.com/gotime/188

While it's unlikely that these vulnerabilities will cause direct problems; or even any problems at all. It still causes some oddities in GitHub's security notifications.

Go 1.17 finally landed module graph pruning. So now more than ever GitHub's security notifications are just producing too many false positives as it treats go.sum as a "lock file", something it is not.