Skip to content
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

BUG Pinned Dependency checks for nuget/.Net does not consider implicit restore #4381

Open
balteravishay opened this issue Oct 11, 2024 · 2 comments
Labels

Comments

@balteravishay
Copy link
Contributor

Describe the bug

Pinned dependencies checks for the nuget/.Net ecosystem checks for commands of form:
"dotnet resotre"/"nuget restore" only to validate if the lockfile or central-package-management is used.
however, nuget can be triggered implicitly by using the commands "build" "publish" or "test"
when used implicitly the relevant flags are input to the restore command through the explicitly run command.

Reproduction steps
Steps to reproduce the behavior:

  1. run go run main.go --repo=github.com/Contrast-Security-OSS/contrast-sdk-dotnet --checks Pinned-Dependencies --show-details
  2. the dotnet build command is not checked as unpinned

Expected behavior

the Pinned dependency checks for nuget/.Net should also look for build, publish and test commands for nuget, dotnet and msbuild commands.
if found, it should validate if "restore" (or other implicit calling of it) was already executed.
if not, it should follow the same logic of checks it has today.

Additional context
Add any other context about the problem here.

@spencerschrock
Copy link
Member

however, nuget can be triggered implicitly by using the commands "build" "publish" or "test"
when used implicitly the relevant flags are input to the restore command through the explicitly run command

if found, it should validate if "restore" (or other implicit calling of it) was already executed.

Can you clarify this interaction?

Is this build considerered pinned because the restore was done explicitly?

dotnet restore --locked-mode
dotnet build

This build is unpinned because the restore was done implicitly?

dotnet build

when used implicitly the relevant flags are input to the restore command through the explicitly run command.

This build is pinned because the restore was done implicitly, but with a flag passed?

dotnet build --locked-mode

@balteravishay
Copy link
Contributor Author

balteravishay commented Oct 15, 2024

thanks @spencerschrock for asking for more info.
The implicit restore behaviour is documented here: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-build#implicit-restore
so restore options (such as -locked-mode) are supported when restore is ran implicitly.
Hence the expectation here is that exactly the same checks that are applied for the current implementation will be applied for implicit restore. specifically:

hope this helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

2 participants