Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 35 additions & 8 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

8 changes: 8 additions & 0 deletions Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -56,3 +56,11 @@ pre-release-hook = [
"-c",
"cargo fmt --all && cargo clippy --all-targets --all-features -- -D warnings && if [ -n \"${GITHUB_TOKEN:-}\" ]; then GITHUB_TOKEN=\"$GITHUB_TOKEN\" git cliff --unreleased --github-repo MostroP2P/mostrix -o CHANGELOG.md --tag {{version}}; else git cliff --unreleased -o CHANGELOG.md --tag {{version}}; fi && if [ \"$DRY_RUN\" != \"true\" ]; then git diff --quiet CHANGELOG.md || (git add CHANGELOG.md && git commit -m \"Update CHANGELOG for version {{version}}\"); else echo \"DRY RUN: Skip git add and commit\"; fi",
]

# Security fixes for Dependabot alerts
# Force updated versions of vulnerable transitive dependencies
[dependencies.quinn-proto]
version = "0.11.14"

[dependencies.aws-lc-sys]
version = "0.38.0"
Comment on lines +62 to +66
Copy link
Contributor

@coderabbitai coderabbitai bot Mar 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

lockfile="$(fd '^Cargo.lock$' | head -n1)"
if [ -z "${lockfile:-}" ]; then
  echo "Cargo.lock not found"
  exit 1
fi

python - "$lockfile" <<'PY'
import re, sys
from pathlib import Path

lock = Path(sys.argv[1]).read_text()
targets = {
    "quinn-proto": (0, 11, 14),
    "aws-lc-sys": (0, 38, 0),
}
found = {k: [] for k in targets}

for block in lock.split("[[package]]"):
    name_m = re.search(r'(?m)^name = "([^"]+)"$', block)
    ver_m  = re.search(r'(?m)^version = "([^"]+)"$', block)
    if name_m and ver_m and name_m.group(1) in found:
        found[name_m.group(1)].append(ver_m.group(1))

def parse_semver(v):
    m = re.match(r"^(\d+)\.(\d+)\.(\d+)", v)
    return tuple(map(int, m.groups())) if m else None

bad = []
for name, min_v in targets.items():
    versions = sorted(set(found[name]))
    print(f"{name}: {versions if versions else 'NOT FOUND'}")
    for v in versions:
        p = parse_semver(v)
        if p is None or p < min_v:
            bad.append((name, v, min_v))

if bad:
    print("\nFound vulnerable/unexpected versions:")
    for name, v, min_v in bad:
        print(f"- {name} {v} < {min_v[0]}.{min_v[1]}.{min_v[2]}")
    sys.exit(2)
PY

Repository: MostroP2P/mostrix

Length of output: 186


Current Cargo.toml does not achieve deterministic pinning; lockfile shows aws-lc-sys 0.37.1 is still being pulled as a transitive dependency.

Lines 62–66 use caret requirements ("0.11.14" / "0.38.0"), which allow compatible semver ranges (e.g., >=0.38.0, <0.39.0). This cannot prevent lower versions from being selected by transitive dependencies. The lockfile verification confirms this: despite specifying aws-lc-sys at 0.38.0, the build includes version 0.37.1, which is below the intended security threshold.

Switch to exact-version pins (=0.11.14 and =0.38.0) to enforce deterministic resolution:

Proposed diff
 [dependencies.quinn-proto]
-version = "0.11.14"
+version = "=0.11.14"

 [dependencies.aws-lc-sys]
-version = "0.38.0"
+version = "=0.38.0"
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
[dependencies.quinn-proto]
version = "0.11.14"
[dependencies.aws-lc-sys]
version = "0.38.0"
[dependencies.quinn-proto]
version = "=0.11.14"
[dependencies.aws-lc-sys]
version = "=0.38.0"
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@Cargo.toml` around lines 62 - 66, Update the version specifiers in Cargo.toml
for the dependencies to exact pins instead of caret ranges: change the
quinn-proto and aws-lc-sys entries to use "=0.11.14" and "=0.38.0" respectively
so Cargo will resolve those crates to the exact versions (refer to the
dependency names quinn-proto and aws-lc-sys in the Cargo.toml to locate the
lines to modify).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

long comment for @coderabbitai , consider that window is not compiling for this reason:

That copy is what’s failing to build on Windows/MSVC:

It compiles aws-lc/tests/compiler_features_tests/.c, which expect a C11 toolchain and some GCC builtins.
MSVC’s defaults + your environment don’t provide those ("C atomics require C11 or later", alignas/alignof undefined, __builtin_bswap
undefined), and there’s also “NASM command not found”.
So the build failure is not a Rust‑level incompatibility; it’s native C test code in aws-lc-sys 0.38.0 not liking your Windows toolchain.

Given that, the most pragmatic approach right now:

Step 1 – Undo the direct aws-lc-sys override (fix your build)
In Cargo.toml, remove the manual aws-lc-sys section:

Security fixes for Dependabot alerts

Force updated versions of vulnerable transitive dependencies

[dependencies.quinn-proto]
version = "0.11.14"

DELETE this block – it’s causing the build failure on Windows

#[dependencies.aws-lc-sys]
#version = "0.38.0"
Then run cargo clean && cargo build (or cargo clippy) again; this should stop trying to build aws-lc-sys 0.38.0 and go back to the known‑working 0.37.1 that aws-lc-rs depends on.

Step 2 – Let upstream own the aws-lc-* bump
The correct security fix is for some top‑level crate to move to a safe combination of aws-lc-rs/aws-lc-sys that:

fixes the CVE, and
is known to build on Windows/MSVC.
That likely means:

Bumping nostr-sdk once they release a version that depends on a newer aws-lc-rs, or
Bumping whatever crate is pulling in quinn-proto/aws-lc-rs (if it’s not nostr-sdk).
Until that exists, any manual override like [dependencies.aws-lc-sys] = "0.38.0" is brittle and, as you’ve seen, can easily break native builds.

Step 3 – How to handle Dependabot in the meantime

Options:

Short-term, keep your build green and track the alert manually

Remove the aws-lc-sys override (Step 1).
In GitHub, for that Dependabot alert, either:
Mark it as “acknowledged / will fix later” with a note “blocked on upstream aws-lc-rs/quinn-proto update that compiles on Windows/MSVC”, or
Temporarily ignore with a time limit (e.g., 30/90 days).
If your CI runs on Linux and you really want Dependabot green now

You could keep the aws-lc-sys = "0.38.0" override only in a branch or PR that Dependabot opens, and let CI (on Linux) run that, while your local Windows dev branch doesn’t carry that override.
But that’s a bit of a workflow hack and easy to get confusing.
About the quinn-proto entry
Your Cargo.lock already shows quinn-proto 0.11.14, so the [dependencies.quinn-proto] in Cargo.toml is not required to get that version; cargo update -p quinn-proto --precise 0.11.14 would have been enough and keeps it as a transitive dep.
It’s harmless but unnecessary; you can leave it or remove it, depending on whether you like pinning that version explicitly.
Suggested concrete change
If you want a simple, low‑risk change you can apply right now:

Edit Cargo.toml and delete the aws-lc-sys dependency block.
Rebuild on Windows to confirm everything compiles again.
In GitHub:
Keep the quinn-proto bump (it already shows in Cargo.lock), which should satisfy any quinn-proto‑related Dependabot alert.
For the aws-lc-sys alert, document that you can’t yet safely move to 0.38.0 on Windows due to upstream build issues; track it as a follow‑up.
If you’d like, you can paste the exact Dependabot alert text for aws-lc-sys and I can propose a short justification note you can drop into the GitHub UI when you “acknowledge” or temporarily ignore it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arkanoider, thank you for the thorough analysis — your diagnosis is correct, and I want to explicitly update my earlier recommendation in light of this.

The MSVC/C11 build failure is a well-documented upstream issue. When building aws-lc-sys on Windows using CMake and VS Build Tools, C11 compiler feature detection fails because the build system does not pass /std:c11 to cl.exe. This is not unique to 0.38.0; the issue has been present across many aws-lc-sys versions, and NASM is required on x86-64 Windows but can be avoided using prebuilt NASM objects — meaning the environment must be properly configured to build this crate on Windows at all.

My earlier suggestion to use exact-version pins (=0.38.0) is withdrawn for aws-lc-sys given the Windows build incompatibility you've identified. Forcing the pin resolves the security alert on Linux but breaks the Windows toolchain.

Recommended path forward (aligned with your analysis):

  1. Remove the [dependencies.aws-lc-sys] block from Cargo.toml to restore Windows builds.
  2. Keep the [dependencies.quinn-proto] pin (or remove it too, since Cargo.lock already resolves 0.11.14 — it's harmless either way).
  3. Acknowledge the aws-lc-sys Dependabot alerts (#6, #7, #8) in the GitHub security UI with a note such as:

    "Blocked on upstream (nostr-sdk / aws-lc-rs) releasing a version that builds on Windows/MSVC with aws-lc-sys ≥ 0.38.0. Manual override breaks MSVC C11 build. Tracking for follow-up once upstream support is available."

  4. Track the upstream nostr-sdk dependency for a version that picks up a compatible aws-lc-rs/aws-lc-sys pairing.

The security risk from retaining aws-lc-sys 0.37.1 is real but accepting a broken Windows build is not a viable trade-off for an active project. The pragmatic path is to acknowledge the limitation and let the ecosystem catch up.


✏️ Learnings added
Learnt from: arkanoider
Repo: MostroP2P/mostrix PR: 38
File: Cargo.toml:62-66
Timestamp: 2026-03-17T08:19:52.416Z
Learning: In the MostroP2P/mostrix repository (Rust/Cargo project), directly overriding `aws-lc-sys` to >= 0.38.0 in Cargo.toml breaks Windows/MSVC builds due to a long-standing upstream issue where the build system does not pass `/std:c11` to `cl.exe`, causing `C atomics require C11 or later` errors. The correct fix is to wait for upstream crates (e.g., `nostr-sdk`) to adopt a compatible `aws-lc-rs`/`aws-lc-sys` version that builds on Windows. The `aws-lc-sys` Dependabot alerts should be acknowledged in the GitHub UI with a note about the Windows MSVC incompatibility until upstream support is available.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

Loading