feat: Update rebar config, use shotgun ~> 1.2

[matt-savvy]

Description

This version of shotgun brings in gun 2.2, which has multiple
CVEs, causing app authors to be aware and explicitly override gun
or shotgun.

Changes

Update rebar.config to use shotgun ~> 1.2.

Before

$ rebar3 tree
└─ ldclient─3.10.1 (project app)
   ...
   ├─ shotgun─1.2.1 (hex package)
   │  └─ gun─2.2.0 (hex package) <- vulnerable
   │     └─ cowlib─2.17.1 (hex package)
   ...

With this change

$ rebar3 tree
└─ ldclient─3.10.1 (project app)
   ...
   ├─ shotgun─1.2.2 (hex package)
   │  └─ gun─2.4.1 (hex package) <- ok
   │     └─ cowlib─2.17.1 (hex package)
   ...

---

Note

Low Risk
Single-line rebar dependency constraint change with no Erlang source edits; risk is limited to minor HTTP client library behavior differences in shotgun/gun.

Overview
Dependency-only change in rebar.config: shotgun moves from a pinned 1.2.1 to ~> 1.2, so rebar can resolve a newer 1.2.x release.

That pulls gun 2.4.1 (via shotgun 1.2.2) instead of gun 2.2.0, which had known CVEs and often forced downstream apps to override gun or shotgun explicitly. HTTP/SSE behavior still goes through shotgun; this is a transitive security bump, not an application code change.

^{Reviewed by Cursor Bugbot for commit 0eb2c90. Bugbot is set up for automated code reviews on this repo. Configure here.}

[kinyoklion]

Hello @matt-savvy,

Let me make sure this will work with a reasonable set of rebar3 versions. The problem is that rebar3 versions are not semantic versions. When working with hex is treats them that way, but when you use rebar you basically get the same behavior as adding ~>.

In your hex package you can override the version in the interim.

Thank you,
Ryan

[matt-savvy]

Hey @kinyoklion - yup, I'm not well versed in Rebar, so please do check.

If you do need to leave this set to a specific version, you probably at least want to use 1.2.2 so the vulnerable version of gun isn't pulled for everyone who doesn't have it overridden.

When working with hex is treats them that way, but when you use rebar you basically get the same behavior as adding ~>.

FWIW, the tree outputs (in the description) come from only running rebar3 get-deps before and after this change.

$ rebar3 --version
rebar 3.27.0 on Erlang/OTP 28 Erts 16.2

[kinyoklion]

Looks like version 3.0+ should support the syntax. So we should be good.

[kinyoklion]

Maybe we should have changed this to ~> 1.2.1 because the 1.2.1 version contained a fix that we needed to function correctly. But I think at this point it should be reasonable safe as 1.2.1 has been out about a year.

[matt-savvy]

Maybe we should have changed this to ~> 1.2.1 because the 1.2.1 version contained a fix that we needed to function correctly. But I think at this point it should be reasonable safe as 1.2.1 has been out about a year.

It should be fine, I don't know about Rebar but Mix will always use the latest available version that meets the constraints. You shouldn't ever even up with 1.2.0. But this does mean that any new minor versions (1.3.0) of shotgun will require this to be manually bumped again. Is that what you want here?