fix(rust): use ERE-compatible regex in start_release.sh version check#2351
Merged
Conversation
The version check used the PCRE escape \d in an egrep pattern: REGEX_VERSION='^\d+\.\d+\.\d+$' MATCHES=$(echo "$1" | egrep $REGEX_VERSION | wc -l) egrep uses POSIX Extended Regular Expressions, which do not support \d. The pattern therefore matched nothing, every input was treated as invalid, and the script always exited with: Version "X.Y.Z" must be N.N.N This caused the 'Run start_release.sh and open a release PR' job to fail with exit code 1 even though VERSION=1.3.0 had already passed the workflow's own pre-check (which uses bash regex ^[0-9]+\.[0-9]+\.[0-9]+$). Replace \d with [0-9] so the regex actually matches N.N.N, and quote the variable expansion in egrep for safety.
Contributor
Author
kessplas
previously approved these changes
Jun 30, 2026
… crate
CI's 'no duplicate aws-lc native crate' check failed on the default
build with:
aws-lc-sys v0.41.0
└── aws-db-esdk (direct dependency)
aws-lc-sys v0.42.0
└── aws-lc-rs v1.17.1
└── aws-db-esdk (transitive via aws-lc-rs/aws-sdk-*)
Our Cargo.toml pinned the direct optional dep at aws-lc-sys = "0.41",
while aws-lc-rs 1.17.1 (which we depend on, and which the AWS SDK
crates pull in transitively) resolves aws-lc-sys 0.42. Cargo cannot
unify across a semver-major boundary, so two copies of aws-lc-sys
compile in the same build.
Beyond the ~2x native C build cost, this is also a correctness/safety
concern: the SDK's raw FFI path (aws_lc_sys_impl::*) binds to the
version WE declare, while aws-lc-rs binds to the version it pulls in,
so the raw path can drift onto a stale/vulnerable AWS-LC independently
of aws-lc-rs.
Bump the direct dep to aws-lc-sys = "0.42" so it unifies with the
version aws-lc-rs resolves to. aws-lc-fips-sys is unchanged; the fips
build was not flagged by the duplicate check.
kessplas
approved these changes
Jun 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The version check used the PCRE escape \d in an egrep pattern:
REGEX_VERSION='^\d+.\d+.\d+$'
MATCHES=$(echo "$1" | egrep $REGEX_VERSION | wc -l)
egrep uses POSIX Extended Regular Expressions, which do not support \d. The pattern therefore matched nothing, every input was treated as invalid, and the script always exited with:
Version "X.Y.Z" must be N.N.N
This caused the 'Run start_release.sh and open a release PR' job to fail with exit code 1 even though VERSION=1.3.0 had already passed the workflow's own pre-check (which uses bash regex ^[0-9]+.[0-9]+.[0-9]+$).
Replace \d with [0-9] so the regex actually matches N.N.N, and quote the variable expansion in egrep for safety.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.