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.
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
Discover plugins installed using Net tools #5990
base: dev-feature-dot-net-tool-plugin-support
Are you sure you want to change the base?
Discover plugins installed using Net tools #5990
Changes from all commits
4db9964
bd202c4
b199f4e
c48c415
859754a
2a9ed74
c573bb9
f533021
42ff98f
bbdee18
e7776f2
405a28f
7a6d5e9
c4638c4
8c51a6c
1d7ba24
425767e
668ba03
1e2e41e
a9fcab7
561db34
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
The XMLdoc for
rawPluginPaths
says:But I don't understand when the value will be null or not null, or where the value comes from, and therefore I'm having a hard time understanding why we look for .NET tool plugins only when it's empty.
Is
rawPluginPaths
the value of theNUGET_PLUGIN_PATHS
orNUGET_NETFX_PLUGIN_PATHS
environment variables when they're set?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.
Today, I've been trying to create a cred provider. I used the
nuget-plugin-*.exe
file convention, but settingNUGET_NETFX_PLUGIN_PATHS
orNUGET_PLUGIN_PATHS
to the bin directory of my project, or setting it to the full path of the exe itself, I couldn't get NuGet to use my plugin, without adding the project's bin directory to the path (and using your test branch for this feature that does execution, in addition to discovery). However, when doing this, it also discovered other cred providers I have installed, which was making debuggign my plugin much more difficult.It can be done in a follow up, but I think there should be a way to disable normal plugin discovery, and only discover plugins I want. The
NUGET_PLUGIN_PATHS
environment variable appears to do that for the older discovery method, so there should be a way for this new one as well.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.
.NET SDK recently enabled package signature verification for .NET tools. Hence, I think we can skip the
_verifier.IsValid
check because .NET tools are published as NuGet packages, which can be signed by the package author.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.
Is the suggestion to not check the validity of the package and just assume it is valid?
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.
Yes, that is correct.
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.
From my understanding, isValid checks whether the file has a valid embedded signature or not. Even though we do expect the files that come from .Net tools to have a valid signature. Isn't possible some file that was not installed by .Net tools exists in the path and it does not have a valid signature. Or it could be a .Net tools package that has been tempered with and does not have a valid signature anymore.
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.
The "embedded signature" is an authenticode signature, which is not related to signed packages.
It typically costs hundreds of dollars a year to buy a code signing certificate, putting it out of reach for most non-corporate NuGet plugin developers. Even when a developer does have a certificate available for the production code, it's typically not available during development and debugging. I hit this today while trying to develop a new plugin, and I had to hardcode
Valid
state just to be able to develop the plugin.At the very least we should add an environment variable to allow skipping the authenticode checks, so that plugin developers can actually develop. However, I'm in favour of removing the authenticode checks altogether. If someone wants to allow only signed executables to run on a Windows machine, they can configure it via group policy.
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.
Please help me understand the reasoning behind the
(fileInfo.Attributes & FileAttributes.ReparsePoint == 0)
check. My internet search suggested it is related to symbolic links, etc., but I happy to learn more.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.
You're right. I wanted to ensure the file both exists and is a real file (not a symbolic link) to minimize the risk of running malicious code. For example, imagine a symbolic link located in one of the directories listed in the user's
PATH
environment variable. The link has a name likenuget-plugin-*
, making it appear like a normal plugin, but it actually points to a malicious file in a different directory. If we run that symlink, we unintentionally execute the malicious file from the other location. We could say it is up to the user to ensure there is no malicious files in the PATH folders. However, I don't see a reason why we should leave that vulnerability open.