Update eniz1806/vaults3 Docker tag to v4.4.77 #429

2026-09-30T22:01:43+02:00

renovate-bot commented

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

This PR contains the following updates:

Package	Update	Change
eniz1806/vaults3	patch	`4.4.76` → `4.4.77`

⚠️ Warning

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

Release Notes

Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)

`v4.4.77`

Compare Source

Fixed

Object tags sent on the x-amz-tagging header were stored without being
URL-decoded (issue #61, reported by
@ETCDema). That header carries the tag set encoded
as URL query parameters, so a value containing a space, &, = or any
non-ASCII character arrives percent-encoded. The server stored it verbatim, so
Tag1=Tag%201%20value came back from GetObjectTagging as
Tag%201%20value instead of Tag 1 value. PutObject and the REPLACE form
of CopyObject were both affected. The tag set posted as XML to
PutObjectTagging was never affected.

The wrong value was written into the object's metadata, so tags stored before
this release are not repaired by upgrading. Re-apply the tags on affected
objects, see docs/UPGRADING.md.

Smaller gaps in the same header closed with it. A malformed percent-encoding is
refused with InvalidArgument rather than stored half-decoded, more than 10 tags
is refused with BadRequest as PutObjectTagging already did on the XML body,
and a literal ; is refused with InvalidTag since S3 does not permit it in a
tag and it cannot be told apart from a pair separator. A repeated key now keeps
the last occurrence, matching what the XML body has always done.
CopyObject ignored x-amz-tagging-directive, and replacing an object's
metadata silently destroyed its tags. The tag set is governed by its own
directive, independently of x-amz-metadata-directive, and VaultS3 decided tags
inside the metadata branch. That got it wrong both ways. A copy asking to replace
the metadata and saying nothing about tags dropped the source's tags instead of
keeping them, which is what aws s3 cp --metadata-directive REPLACE sends, so an
ordinary copy quietly lost every tag on the object. And a tagging directive of
REPLACE did nothing at all unless the metadata directive happened to say
REPLACE too, so a copy asking only for new tags kept the old ones. All four
combinations of the two directives now behave as S3 defines them, pinned by a test
per combination.
A multipart upload dropped almost everything the request asked for.
CompleteMultipartUpload builds the object's metadata from the upload record,
and that record only ever held the content type, so an object assembled from
parts lost its tags, its user metadata (x-amz-meta-*), Content-Encoding,
Content-Disposition, Cache-Control, Content-Language and
x-amz-website-redirect-location. Seven of the eight fields a single-shot PUT
keeps. aws-cli and the SDKs switch to multipart on their own above a few
megabytes, so this hit ordinary uploads of large files with nothing opted into.
All seven are now recorded when the upload is created and applied when it
completes, and a test pins the multipart result to a single-shot PUT of the same
headers so the two paths cannot drift apart again.

An upload already in progress when you upgrade completes normally. Its record
predates the change, so that object keeps the old behaviour and loses those
fields, the same as it would have before.

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.76` → `4.4.77` | --- > ⚠️ **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.77`](https://github.com/Kodiqa-Solutions/VaultS3/blob/HEAD/CHANGELOG.md#4477---2026-09-30) [Compare Source](https://github.com/Kodiqa-Solutions/VaultS3/compare/v4.4.76...v4.4.77) ##### Fixed - **Object tags sent on the `x-amz-tagging` header were stored without being URL-decoded** (issue [#61](https://github.com/Kodiqa-Solutions/VaultS3/issues/61), reported by [@ETCDema](https://github.com/ETCDema)). That header carries the tag set encoded as URL query parameters, so a value containing a space, `&`, `=` or any non-ASCII character arrives percent-encoded. The server stored it verbatim, so `Tag1=Tag%201%20value` came back from `GetObjectTagging` as `Tag%201%20value` instead of `Tag 1 value`. `PutObject` and the `REPLACE` form of `CopyObject` were both affected. The tag set posted as XML to `PutObjectTagging` was never affected. The wrong value was written into the object's metadata, so **tags stored before this release are not repaired by upgrading**. Re-apply the tags on affected objects, see `docs/UPGRADING.md`. Smaller gaps in the same header closed with it. A malformed percent-encoding is refused with `InvalidArgument` rather than stored half-decoded, more than 10 tags is refused with `BadRequest` as `PutObjectTagging` already did on the XML body, and a literal `;` is refused with `InvalidTag` since S3 does not permit it in a tag and it cannot be told apart from a pair separator. A repeated key now keeps the last occurrence, matching what the XML body has always done. - **`CopyObject` ignored `x-amz-tagging-directive`, and replacing an object's metadata silently destroyed its tags.** The tag set is governed by its own directive, independently of `x-amz-metadata-directive`, and VaultS3 decided tags inside the metadata branch. That got it wrong both ways. A copy asking to replace the metadata and saying nothing about tags dropped the source's tags instead of keeping them, which is what `aws s3 cp --metadata-directive REPLACE` sends, so an ordinary copy quietly lost every tag on the object. And a tagging directive of `REPLACE` did nothing at all unless the metadata directive happened to say `REPLACE` too, so a copy asking only for new tags kept the old ones. All four combinations of the two directives now behave as S3 defines them, pinned by a test per combination. - **A multipart upload dropped almost everything the request asked for.** `CompleteMultipartUpload` builds the object's metadata from the upload record, and that record only ever held the content type, so an object assembled from parts lost its tags, its user metadata (`x-amz-meta-*`), `Content-Encoding`, `Content-Disposition`, `Cache-Control`, `Content-Language` and `x-amz-website-redirect-location`. Seven of the eight fields a single-shot `PUT` keeps. aws-cli and the SDKs switch to multipart on their own above a few megabytes, so this hit ordinary uploads of large files with nothing opted into. All seven are now recorded when the upload is created and applied when it completes, and a test pins the multipart result to a single-shot `PUT` of the same headers so the two paths cannot drift apart again. An upload already in progress when you upgrade completes normally. Its record predates the change, so that object keeps the old behaviour and loses those fields, the same as it would have before. </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-30 22:01:43 +02:00

Update eniz1806/vaults3 Docker tag to v4.4.77 864aee7fa1

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

renovate-bot merged commit a85eb3af0c into main

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

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

2026-09-30 22:01:45 +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#429