-
Notifications
You must be signed in to change notification settings - Fork 1
security: fix 4 HIGH Dependabot alerts #38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
mostronatorcoder
wants to merge
1
commit into
main
Choose a base branch
from
security/fix-dependabot-alerts
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
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
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
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 specifyingaws-lc-sysat0.38.0, the build includes version0.37.1, which is below the intended security threshold.Switch to exact-version pins (
=0.11.14and=0.38.0) to enforce deterministic resolution:Proposed diff
📝 Committable suggestion
🤖 Prompt for AI Agents
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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-syson Windows using CMake and VS Build Tools, C11 compiler feature detection fails because the build system does not pass/std:c11tocl.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 foraws-lc-sysgiven 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):
[dependencies.aws-lc-sys]block fromCargo.tomlto restore Windows builds.[dependencies.quinn-proto]pin (or remove it too, since Cargo.lock already resolves 0.11.14 — it's harmless either way).aws-lc-sysDependabot alerts (#6,#7,#8) in the GitHub security UI with a note such as:nostr-sdkdependency for a version that picks up a compatibleaws-lc-rs/aws-lc-syspairing.The security risk from retaining
aws-lc-sys 0.37.1is 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