Update eniz1806/vaults3 Docker tag to v4.4.75 #396

2026-09-12T22:01:27+02:00

renovate-bot commented

2026-09-12 22:01:27 +02:00

This PR contains the following updates:

Package	Update	Change
eniz1806/vaults3	patch	`4.4.74` → `4.4.75`

⚠️ Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Release Notes

Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)

`v4.4.75`

Compare Source

Fixed

Per-bucket encryption was broken on a cluster: most reads answered 503 and
one replica was written in the clear. Both reproduce on 4.4.74 and both are
fixed here. A bucket with ServerSideEncryption switched on is worth checking
after upgrading, see docs/UPGRADING.md.

An encrypted object stores the MD5 of its ciphertext as the ETag, while the
read path hands back plaintext. The clustered read compares the two to catch a
copy that has not replicated yet, so it condemned every encrypted object as
corrupt, asked another holder, was refused there for the same reason, and
answered 503 SlowDown. That check knew about SSE-C, where the customer key
makes it obvious, and never about server-side encryption. Measured on a real
three-node cluster: 1 of 8 reads succeeded before, 8 of 8 after, and 60 of 60
objects now read back byte-identical through every node.

Separately, a node decides whether to encrypt an object from its own copy of
the bucket's config, and enabling encryption writes the config and the key as
two Raft entries. A node holding only the first could not tell that state apart
from a bucket that had opted out, so it took the plaintext branch: the first
object written to a new encrypted bucket kept one replica readable on disk,
permanently, in a bucket whose whole purpose is that it is not. Enabling
encryption now waits for the cluster to apply the change before reporting
success, and a node that still cannot see the key refuses the write with a
503 instead of storing it in the clear, which the client's own retry then
satisfies. 2 plaintext replicas per 8 buckets before, 0 in 192 copies across 12
buckets after.

Added

SSE-KMS objects were unreadable on a cluster, and a per-bucket server
accepted aws:kms and then stored everything in the clear. Both are fixed
and both were present in 4.4.74.

The server decided whether an object was encrypted by asking the per-bucket key
manager, which exists whenever encryption.key is set. SSE-KMS requires that
key even though it never uses it, so the answer for every KMS bucket was "not
encrypted": the response header understated it, and the clustered read used the
same answer to decide whether to compare content, so every SSE-KMS object on a
cluster failed that comparison and returned 503. The question is now the
server's encryption mode rather than the presence of a key manager. Measured on
a three-node cluster: reads went from failing on the proxying node to 10 of 10
byte-identical through every node.

Separately, a server running per-bucket encryption accepted a bucket configured
with SSEAlgorithm: aws:kms, reported it back as KMS encrypted, and encrypted
nothing, because only a per-bucket AES256 key encrypts anything in that mode.
Every object and every replica in such a bucket was written in the clear. That
configuration is now refused with InvalidArgument rather than accepted and
ignored. Buckets already in that state hold plaintext, see docs/UPGRADING.md.

SSE-KMS also no longer demands a static encryption.key it never uses, so the
documented KMS configuration starts as written instead of refusing until an
operator invents a key. docs/CONFIGURATION.md now says plainly that the three
encryption modes are server-wide and do not combine.
Replica repair: a cluster now restores a bucket's replica count after a node
is lost for good. Copies were placed when an object was written and nothing
ever re-made them, so a node that died took its copies with it and every object
that had one there stayed a copy short, silently and indefinitely. Rebalance did
not close that gap because it answers a different question: it moves an object
when the ring says another node owns it, and skips one whose owner never
changed no matter how few copies survive. The recovery runbook in
docs/SCALING.md claimed rebalance restored replica_count after a node
replacement. It did not, and now something does.

A background scan reads metadata rather than the local disk, because metadata
still lists an object whose bytes this node has lost, which is the case worth
repairing and the one a disk walk cannot see. Each object is handled by the node
that owns it, so the work is not duplicated across the cluster. Erasure-coded
buckets are left to the erasure healer, which rebuilds them from parity.

An unreachable node is never counted as a node that lost its copy. Only a clean
"not found" from a peer is treated as a missing copy: a timeout, a refused
connection or an error is an answer the scan declines to draw a conclusion from,
so a brief partition cannot start a cluster-wide copy storm at the worst
possible moment. An object no node still holds is reported as unrecoverable and
nothing is deleted, since metadata still describes it and removing it would turn
a recoverable operator problem into real data loss.

On by default whenever a bucket keeps more than one copy, every
cluster.repair.interval_secs (600 by default, negative disables it), throttled
by repair.max_bandwidth_mbps. Run a pass now with vaults3-cli cluster repair
and see what the last one found with vaults3-cli cluster repair --status.
Helm exposes cluster.repairIntervalSecs.

Changed

Documented the dashboard search syntax. The type:, tag: and etag: filters
had never been written down anywhere, so etag: in particular was
undiscoverable, and the difference between the whole-bucket Search page, which
is capped by memory.max_search_entries, and the Files page filter, which
walks the store and is always complete, was not explained. Also records the new
folder filter in the dashboard feature list.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [eniz1806/vaults3](https://github.com/Kodiqa-Solutions/VaultS3) | patch | `4.4.74` → `4.4.75` | --- > ⚠️ **Warning** > > Some dependencies could not be looked up. Check the [Dependency Dashboard](issues/3) for more information. --- ### Release Notes <details> <summary>Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)</summary> ### [`v4.4.75`](https://github.com/Kodiqa-Solutions/VaultS3/blob/HEAD/CHANGELOG.md#4475---2026-09-12) [Compare Source](https://github.com/Kodiqa-Solutions/VaultS3/compare/v4.4.74...v4.4.75) ##### Fixed - **Per-bucket encryption was broken on a cluster: most reads answered 503 and one replica was written in the clear.** Both reproduce on 4.4.74 and both are fixed here. A bucket with `ServerSideEncryption` switched on is worth checking after upgrading, see `docs/UPGRADING.md`. An encrypted object stores the MD5 of its **ciphertext** as the ETag, while the read path hands back plaintext. The clustered read compares the two to catch a copy that has not replicated yet, so it condemned every encrypted object as corrupt, asked another holder, was refused there for the same reason, and answered `503 SlowDown`. That check knew about SSE-C, where the customer key makes it obvious, and never about server-side encryption. Measured on a real three-node cluster: 1 of 8 reads succeeded before, 8 of 8 after, and 60 of 60 objects now read back byte-identical through every node. Separately, a node decides whether to encrypt an object from its own copy of the bucket's config, and enabling encryption writes the config and the key as two Raft entries. A node holding only the first could not tell that state apart from a bucket that had opted out, so it took the plaintext branch: the first object written to a new encrypted bucket kept one replica readable on disk, permanently, in a bucket whose whole purpose is that it is not. Enabling encryption now waits for the cluster to apply the change before reporting success, and a node that still cannot see the key refuses the write with a `503` instead of storing it in the clear, which the client's own retry then satisfies. 2 plaintext replicas per 8 buckets before, 0 in 192 copies across 12 buckets after. ##### Added - **SSE-KMS objects were unreadable on a cluster, and a per-bucket server accepted `aws:kms` and then stored everything in the clear.** Both are fixed and both were present in 4.4.74. The server decided whether an object was encrypted by asking the per-bucket key manager, which exists whenever `encryption.key` is set. SSE-KMS requires that key even though it never uses it, so the answer for every KMS bucket was "not encrypted": the response header understated it, and the clustered read used the same answer to decide whether to compare content, so every SSE-KMS object on a cluster failed that comparison and returned 503. The question is now the server's encryption mode rather than the presence of a key manager. Measured on a three-node cluster: reads went from failing on the proxying node to 10 of 10 byte-identical through every node. Separately, a server running per-bucket encryption accepted a bucket configured with `SSEAlgorithm: aws:kms`, reported it back as KMS encrypted, and encrypted nothing, because only a per-bucket AES256 key encrypts anything in that mode. Every object and every replica in such a bucket was written in the clear. That configuration is now refused with `InvalidArgument` rather than accepted and ignored. Buckets already in that state hold plaintext, see `docs/UPGRADING.md`. SSE-KMS also no longer demands a static `encryption.key` it never uses, so the documented KMS configuration starts as written instead of refusing until an operator invents a key. `docs/CONFIGURATION.md` now says plainly that the three encryption modes are server-wide and do not combine. - **Replica repair: a cluster now restores a bucket's replica count after a node is lost for good.** Copies were placed when an object was written and nothing ever re-made them, so a node that died took its copies with it and every object that had one there stayed a copy short, silently and indefinitely. Rebalance did not close that gap because it answers a different question: it moves an object when the ring says another node owns it, and skips one whose owner never changed no matter how few copies survive. The recovery runbook in `docs/SCALING.md` claimed rebalance restored `replica_count` after a node replacement. It did not, and now something does. A background scan reads metadata rather than the local disk, because metadata still lists an object whose bytes this node has lost, which is the case worth repairing and the one a disk walk cannot see. Each object is handled by the node that owns it, so the work is not duplicated across the cluster. Erasure-coded buckets are left to the erasure healer, which rebuilds them from parity. An unreachable node is never counted as a node that lost its copy. Only a clean "not found" from a peer is treated as a missing copy: a timeout, a refused connection or an error is an answer the scan declines to draw a conclusion from, so a brief partition cannot start a cluster-wide copy storm at the worst possible moment. An object no node still holds is reported as unrecoverable and nothing is deleted, since metadata still describes it and removing it would turn a recoverable operator problem into real data loss. On by default whenever a bucket keeps more than one copy, every `cluster.repair.interval_secs` (600 by default, negative disables it), throttled by `repair.max_bandwidth_mbps`. Run a pass now with `vaults3-cli cluster repair` and see what the last one found with `vaults3-cli cluster repair --status`. Helm exposes `cluster.repairIntervalSecs`. ##### Changed - Documented the dashboard search syntax. The `type:`, `tag:` and `etag:` filters had never been written down anywhere, so `etag:` in particular was undiscoverable, and the difference between the whole-bucket Search page, which is capped by `memory.max_search_entries`, and the Files page filter, which walks the store and is always complete, was not explained. Also records the new folder filter in the dashboard feature list. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).

renovate-bot added 1 commit 2026-09-12 22:01:27 +02:00

Update eniz1806/vaults3 Docker tag to v4.4.75 2af4efc3bc

renovate-bot scheduled this pull request to auto merge when all checks succeed 2026-09-12 22:01:28 +02:00

renovate-bot merged commit c3d5f9e9d7 into main

2026-09-12 22:01:30 +02:00

renovate-bot deleted branch renovate/eniz1806-vaults3-4.x

2026-09-12 22:01:33 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: arnoutvw/compose-files#396