Loading
Commits on Source 30
-
Ravi Kumar authoredThe charset conversion library needs a fix that cannot be published upstream ahead of this change. Vendoring the module and pointing go.mod at the local copy lets the fix ship in the indexer binary. The copy is removed once a patched version of the library is released. The source is v1.0.2 unmodified apart from gofmt, which the repository format check requires. Nested modules fall outside ./..., so make test runs the vendored module's own suite explicitly.
-
Ravi Kumar authored
ConvertToUtf8 passed len(utf16Buffer), a byte count, to ICU as the destination capacity for ucnv_toUChars, which counts UChars. ICU was told the buffer was twice its real size and wrote past the end of it for any input between the real and the claimed capacity. A commit author name has no size limit, so an ordinary push reaches this. It is a security fix for an out-of-bounds write with attacker-controlled contents. c_bridge.c also returned early on conversion failure without calling ucnv_close, leaking a converter. In convertFromUtf16 that path was already reachable, since UTF-8 output larger than utf8Buffer sets U_BUFFER_OVERFLOW_ERROR. In convertToUtf16 the overstated capacity kept it unreachable until now. Both are closed here. The new tests cover one UChar below, exactly at, and one above the buffer capacity, and assert that nothing is written past the end. The at-capacity case reports U_STRING_NOT_TERMINATED_WARNING, which isSuccess must keep treating as success. References https://gitlab.com/gitlab-org/gitlab/-/work_items/627435
-
Ravi Kumar authored
The tests derived the buffer's UChar capacity with a literal 2 while the conversion call used unsafe.Sizeof, so the two could drift. Cgo is unavailable in test files, so the constant has to live beside the production code for both to share it.
-
Ravi Kumar authored
Both conversion stages can overflow, but only the first was covered. Three-byte BMP characters expand past utf8Buffer while staying inside the utf16 capacity, which reaches the second stage's error return.
-
Ravi Kumar authored
The directory is a nested module, so lint and coverage skip it while it is in place. Record that, and the steps to remove it, for whoever does the upstream cleanup.
-
Mayra Cabrera authoredfix: reject charset conversion input larger than the buffer See merge request https://gitlab.com/gitlab-org/security/gitlab-elasticsearch-indexer/-/merge_requests/1 Merged-by:
Mayra Cabrera <mcabrera@gitlab.com> Approved-by:
John Mason <jmason@gitlab.com> Co-authored-by:
Ravi Kumar <rkumar@gitlab.com>
-
John Mason authored -
Mawreen Dela Cruz authoredchore(release): security release v5.14.12 See merge request https://gitlab.com/gitlab-org/security/gitlab-elasticsearch-indexer/-/merge_requests/2 Merged-by:
Mawreen Dela Cruz <mdelacruz@gitlab.com> Approved-by:
-
John Mason authored
`glab api` exits non-zero on any failure, so an expired or revoked TAG_CREATOR_TOKEN took the `else` branch of the tag-existence check. The job logged "Tag vX doesn't exist, will create it" -- a false conclusion -- and then failed on the create with an invalid_token error. Assert authentication once, immediately after `glab auth login`, and fail with a message naming the credential and how to rotate it. The success path is unchanged: a valid token still skips creation when the tag exists, and still creates it when it does not.
-
John Mason authored
The `version_tag` job's tag-existence check treats every `glab api` failure as "tag absent", because `glab api` exits non-zero on any error. An expired TAG_CREATOR_TOKEN therefore took the `else` branch: the job printed "Tag vX doesn't exist, will create it" -- a false conclusion -- and then died on the create with an opaque `invalid_token` error. Three consecutive weekly releases failed this way. The previous revision of this branch guarded with `glab api user`. Measured in the pinned CI image (registry.gitlab.com/gitlab-org/cli:v1.55.0), that closes the expired-token case but not a token that still authenticates while having lost access to this project: `GET /user` returns 200 and the tag read returns 404 Project Not Found, which is indistinguishable from a missing tag. Probing `GET /projects/$CI_PROJECT_ID` instead is the same single call and strictly dominates -- it fails on both, and the message says it is not a missing tag. Verified by running the job's real script steps, parsed out of this file with yaml.safe_load, inside the pinned image, under a glab shim that refuses every mutating call. Four cases: invalid token, valid token with the tag absent, valid token with the tag present, and valid token against an unreadable project. 14/14 assertions pass. Two controls establish the assertions are load-bearing rather than vacuous. Against the unpatched file, the four invalid-token and four unreadable-project assertions fail. Against the previous `glab api user` revision, the four unreadable-project assertions fail. The six success-path assertions pass in all three arms, so the change alters the failure path and nothing else. Not verified: no `version_tag` job has run on a runner. The job only runs on the default branch with a VERSION file present, so it cannot execute on this MR's pipeline; the first real exercise is the next weekly release after merge. Related: #203
-
Dmitry Gruzd authored -
Dmitry Gruzd authored
-
Dmitry Gruzd authored
-
John Mason authored
The project probe proves read access only. A token downgraded to `read_api` scope, or a role downgraded to Reporter, passes the probe, gets a legitimate 404 on the tag read, and dies on the create with an opaque error -- the original misleading-failure symptom this job was changed to remove. Wrap the create in the same `if !` shape as the probe, behind one `credential_error` helper so read and write report identical guidance, and name the scope/role-downgrade case explicitly.
-
John Mason authored
`version_tag` had no `retry:` and `default:` sets only `tags:`, so the read probe turned a transient gitlab.com 5xx into a failed release. `retry: 2` absorbs it; the job is re-entrant, so a retry after the tag was created takes the "already exists" branch. The probe's eight comment lines are cut to three plus a link to the parent issue, per the repo's AGENTS.md Code Style pass -- CI-file prose drifts, a link does not.
-
John Mason authored
docs: improve merge request template See merge request !934 Merged-by:
GitLab Duo <gitlab-duo@gitlab.com> Co-authored-by:
Dmitry Gruzd <dgruzd@gitlab.com> -
Siddharth Dungarwal authoredci: distinguish an auth failure from a missing tag in version_tag See merge request !930 Merged-by:
Siddharth Dungarwal <sdungarwal@gitlab.com> Approved-by:
John Mason <john@gitlab.com>
-
John Mason authored
The security repo cut v5.14.12 (4100165b) with the sirt_7308 ICU buffer fix on Sep 4, while the weekly release on canonical independently cut a v5.14.12 (4e3c0ccf) without it on Sep 8. The fix was later ported to canonical as cherry-picks and released as v5.14.14, so the two mains have identical content but no shared tip, which blocks the release tooling's canonical/security divergence check. This merge brings the security-side commits in by SHA so security/main becomes an ancestor of canonical/main and the mirror can fast-forward again. The resulting tree is identical to canonical main before the merge: conflicts in VERSION (5.14.14), CHANGELOG.md and third_party/icu/convert_test.go were all resolved to canonical's side, which already carries the fix. Co-Authored-By:
Claude Opus 5 (1M context) <noreply@anthropic.com>
-
Mawreen Dela Cruz authored
fix: reconcile canonical and security main history See merge request !937 Merged-by:
-
John Mason authored
The weekly release job derives the next version from tags reachable from main. A security release is tagged in the security repository first and stays private until it ships, so it is invisible to `git describe` and git-cliff. This released v5.14.12 twice (!929) and proposed v5.14.13 a second time (!936), and left canonical and security main diverged. release_create_mr now checks the proposed tag against both repositories and fails closed. The security check needs a new SECURITY_REPO_READ_TOKEN CI/CD variable with read access to the security project; GitLab returns 404 for a private project the token cannot see, so the job proves access first. version_tag now fails when the tag exists on a different commit instead of skipping, and no longer runs outside the canonical project. The security project has no TAG_CREATOR_TOKEN, so every main push there has failed at this job, and a bot tagging in security is how the two repositories end up with the same version on different commits.
-
John Mason authored
Two defects in the version_tag guard added by the previous commit, both found in review. `glab api` writes the response body to stdout on a non-2xx too, so TAG_JSON was `{"message":"404 Tag Not Found"}` on the normal path where the tag does not exist. `[ -n "$TAG_JSON" ]` took the exists branch on every new release, EXISTING_SHA parsed empty, and the job exited 1 with `already exists at <unparsed>`; the create branch was unreachable and `retry: 2` repeated the failure. Branch on the command's exit status instead. Exact-SHA equality also failed on every ordinary main push. version_tag has no `changes: [VERSION]` gate, so it runs on all of them, and between releases VERSION names a tag on the earlier release commit. Accept a tag that is reachable from this commit and refuse one that is not, using /repository/merge_base so the answer does not depend on fetch depth. A security collision is off this lane and still fails closed. An unparseable tag or merge_base read fails closed rather than creating. In release_create_mr, the http_status helper now ends in `|| true` so a transport failure reaches the `could not check ... (HTTP 000)` arm instead of aborting the job under `set -e`, retries connection-level blips, and sends the token as a Bearer header, which accepts OAuth-style tokens where PRIVATE-TOKEN does not. doc/process.md: describe the ancestry rule, and drop the remedy that said to edit the release MR, which does not exist when the check fails. Verified against the live API in registry.gitlab.com/gitlab-org/cli:v1.55.0: missing tag creates, tag reachable from HEAD is a no-op, tag at HEAD is a no-op, tag off-lane fails closed, unreadable merge_base fails closed. The pre-fix code was run as a control and failed the first two. The release_create_mr checks were run for a free version, a taken version, an unset token, a 401 on either token, and an unresolvable host. -
John Mason authored
ci: refuse release versions already tagged in canonical or security See merge request !938 Merged-by:
-
Release Token authored
-
Dmitry Gruzd authored
chore(release): automated weekly release v5.14.15 See merge request !939 Merged-by:
Dmitry Gruzd <dgruzd@gitlab.com>
Approved-by: Dmitry Gruzd <dgruzd@gitlab.com>
Co-authored-by: GitLab ES Indexer Release Bot <gitlab-es-indexer-release-bot@no-reply.gitlab.com>
-
Dmitry Gruzd authored
-
Ravi Kumar authored
docs: document draft MR CI skipping See merge request !941 Merged-by:
Dmitry Gruzd <dgruzd@gitlab.com> -
Arturo Herrero authored -
Ravi Kumar authored
fix: delete stale chunks after incremental runs Closes #205 See merge request !942 Merged-by:
Pam Artiaga <partiaga@gitlab.com> Reviewed-by:
Arturo Herrero <arturo.herrero@gmail.com>
-
Arturo Herrero authored
-
Ravi Kumar authored
chore(release): release v5.14.16 See merge request !945 Merged-by: