You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
run go run main.go --repo=github.com/Contrast-Security-OSS/contrast-sdk-dotnet --checks Pinned-Dependencies --show-details
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.
The text was updated successfully, but these errors were encountered:
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?
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:
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:
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.
The text was updated successfully, but these errors were encountered: