Bump github.com/contribsys/faktory from 1.9.4 to 1.10.0 in /src

[dependabot]

Bumps github.com/contribsys/faktory from 1.9.4 to 1.10.0.

Release notes

Sourced from github.com/contribsys/faktory's releases.

1.10.0

Notable changes can be found in the changelogs:

• Faktory
• Faktory Enterprise

Filename	SHA256
faktory-1.10.0-1.aarch64.rpm	4fe63349e2c57bf9ec3bdbbcf2ba056ebb1e9d56fabd2a392e893eaaf9cf6bdf
faktory-1.10.0-1.x86_64.rpm	a25f5796901a5e34f1ae29575c39ae6da557d98ca070ab1b449d67704689ce09
faktory_1.10.0-1_amd64.deb	8c7a078965346738f65593af17631125290f595cf8aaab9666cea54c7eb7e509
faktory_1.10.0-1_arm64.deb	da4df665f6046a525af56e86a4fd2e7d0f3975a80b8d8dc5fec19fcf830aae70
faktory-ent_1.10.0.macos.amd64.tbz	de48eacdb14ae190003699b5b0d16aabe905b78faa60787e85369aa17bd2e97c
faktory-ent_1.10.0.macos.arm64.tbz	cd59c3a8c8bcc63b4c9f116c4f4c26f39331ea8597a3c63f7099af895578cfd3

Verify with shasum -a 256 <filename>.

Installation | Full docs

The Faktory Enterprise macOS packages are bare binaries which can replace the faktory binary installed by Homebrew. You are welcome to use either to trial the commercial functionality before purchase but they may not be used in a production environment without a license. Linux DEB packages and Docker images are available upon purchase.

Unpack them with tar xvf faktory-ent-*.tbz; cp ./faktory /usr/local/bin.

Note the amd64 builds are for x86_64 processors (Intel, AMD). arm64 builds are for ARM (Gravitron, Apple Silicon, etc) processors.

Changelog

Sourced from github.com/contribsys/faktory's changelog.

1.10.0

• SECURITY Clients could push jobs with queue names colliding with other key names in Redis. All queues are now prefixed with q: inside Redis.
• SECURITY Clients could send malformed protocol requests which cause Faktory to crash, leading to a DDOS. Faktory now recovers any Go panics when processing commands.
• SECURITY Running the bare faktory binary on Linux used /tmp/redis.conf to start Redis which an attacker could gain write access with a TOCTOU attack, leading to a misconfigured Redis. Faktory now writes redis.conf to the storage directory which is not world-writeable.
• AMD64 build now uses GOAMD64=v3 which requires a 2013+ Intel chip.

Commits

• b2d89a6 Remove deprecated ZRangeByScore usage
• f3042ea Update dependencies
• 2f9296f verify queue name migration is working
• 72b1b0a Update README.md with forum
• cf9073f fix queue prefix when fetching to prevent double prefixing
• 6ee6494 Add changes, bump
• 3bcfe25 Merge branch 'queue_prefix'
• 0b6d21b Handle panics in command-handling goroutines, preventing input from crashing ...
• b069453 Adjust how we write redis.conf to avoid TOCTOU and config hijack
• 4fef599 Prefix all queues with q: to prevent queue name collision with other keys i...
• Additional commits viewable in compare view

Most Recent Ignore Conditions Applied to This Pull Request

Dependency Name	Ignore Conditions
github.com/contribsys/faktory	[>= 1.9.3.a, < 1.9.4]

[Farjaad]

@dependabot rebase

[Farjaad]

@dependabot rebase

[Farjaad]

Our Faktory servers are all on Faktory Enterprise 1.9.1, not 1.10.0. This client bump is still safe to merge ahead of the server upgrade:

• No client changes. The only differences in client/ between 1.9.4 and 1.10.0 are lint cleanup (conn.Close() → _ = conn.Close() in client.go and pool.go) and the version string. There are no exported API or wire-protocol changes. Everything we use (Open, NewJob, Batch, UniqueUntil, and expiry, via faktory_worker_go v1.7.0) is unchanged.
• 1.10.0's changes are server-side. All three security fixes are in the server: the q: queue-key prefix, panic recovery on malformed commands, and the redis.conf location. The queue-prefix migration only renames keys inside the server's Redis. Clients still use the same queue names over the wire, so a 1.10.0 client works against both 1.9.1 and 1.10.0 servers.
• Indirect bumps aren't in the binary. BurntSushi/toml and go.uber.org/atomic are pulled in only by golangci-lint (go mod why), not by the runner.
• Verified. CI test passes, and go build, go vet and go test ./... pass locally on this branch.

The server upgrade is tracked separately in opslevel-kubernetes (!684 staging, then !685 prod and tenants). This PR and the server upgrade can ship in either order.