Make verify command consider default nuget.config file and nuget.config option #4396

erdembayar · 2022-01-08T00:28:38Z

Bug

Fixes: NuGet/Home#10774
Fixes: NuGet/Home#10011

Regression? Last working version:

Description

Currently both nuget verify and dotnet nuget verify command ignore nuget.config file content. So, this makes trustedSigners section, specially allowUntrustedRoot value ignored for verify command for both default nuget.config and passed nuget.config option. Also dotnet nuget verify doesn't even has pass nuget.config option yet.
This PR add followings:

dotnet nuget verify command doesn't ignore nuget.config file, detect broken/missing tags.
Takes allowUntrustedRoot value into account for certificates with untrusted root from trustedSigners section in nuget.config file (It's default nuget.config or passed nuget.config option)
Add pass nuget.config option for dotnet nuget verify

Follow up issue: https://github.com/NuGet/docs.microsoft.com-nuget/issues/2632

PR Checklist

PR has a meaningful title
PR has a linked issue.
Described changes
Tests
- Automated tests added
- OR
- Test exception
- OR
- N/A
Documentation
- Documentation PR or issue filled https://github.com/NuGet/docs.microsoft.com-nuget/issues/2632
- OR
- N/A

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

zivkan · 2022-01-10T22:38:13Z

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

@@ -58,10 +60,16 @@ public async Task<int> ExecuteCommandAsync(VerifyArgs verifyArgs)
                        _defaultFingerprintAlgorithm)).ToList();

                var verifierSettings = SignedPackageVerifierSettings.GetVerifyCommandDefaultPolicy();
+                var trustedSignersSection = verifyArgs.Settings.GetSection(TrustedSignersSectionName);


This is not backwards compatible because the obsolete constructor you added will have Settings as null, and therefore this code will throw a NullReferenceException.

Perhaps have a re-read of https://github.com/NuGet/NuGet.Client/blob/dev/docs/nuget-sdk.md#types-of-compatibility as a refresher to different types of compatibility.

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyArgs.cs

nkolev92

What's considered default nuget.config here?

wrt current working directory?

src/NuGet.Core/NuGet.CommandLine.XPlat/Commands/Signing/TrustedSignersCommand.cs

kartheekp-ms · 2022-01-11T01:43:32Z

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

+                SettingSection trustedSignersSection = verifyArgs.Settings?.GetSection(TrustedSignersSectionName);
+                List<TrustedSignerItem> trustedSigners = trustedSignersSection?.Items.Select(c => c as TrustedSignerItem).Where(c => c != null).ToList();
+                IEnumerable<KeyValuePair<string, HashAlgorithmName>> allowUntrustedRootList = trustedSigners?
+                    .SelectMany(c => c.Certificates)
+                    .Where(c => c.AllowUntrustedRoot)
+                    .Select(c => new KeyValuePair<string, HashAlgorithmName>(c.Fingerprint, c.HashAlgorithm));


nuget.exe verify command spec specifies that -ConfigFile option from NuGet.Config file is used for only repository signature verification. This makes me think that verify command should not apply all the settings from the NuGet.Config file while verifying package signature.

I posted this comment in another issue but here are the default settings used by Verify command. I would check with @dtivel and @heng-liu just to make sure required options are read from the NuGet.Config file.

Setting Verify Command default setting

AllowUnsigned ❌

AllowIllegal ❌

AllowUntrusted ❌

AllowIgnoreTimestamp ❌

AllowMultipleTimestamps ✔️

AllowNoTimestamp ✔️

AllowUnknownRevocation ✔️

ReportUnknownRevocation ✔️

VerificationTarget Targets unknown, Author and Repository signatures

SignaturePlacement Primary, Counter signatures

RepositoryCountersignatureVerificationBehavior IfExists (Verify a signature if it exists)

RevocationMode Online unless "NUGET_CERT_REVOCATION_MODE" environment variable is set

Sure, let's wait for Damon to clarify for us. Mean time I looked at dotnet nuget verify spec. It does have --config file section. Should we implement according to it? Somehow it doesn't say anything about repository signature verification.

--configfile The NuGet configuration file. If specified, only the settings from this file will be used. If not specified, the hierarchy of configuration files from the current directory will be used.

@JonDouglas
Hi. I know it happened very long time ago. Could you be able to check if discrepancy between 2 specs? I couldn't see any other spec contributors from spec file.

@aortiz-msft
Fyi: Should we ignore --configFile option? How about NuGet.config file current working directory?

@kartheekp-ms
Could you able to clarify your comment about #10011? I'm bit confused now. Shouldn't #10011 already be closed or at least P3 priority item based on your above comment since nuget.config file is ignored?

This makes me think that verify command should not apply all the settings from the NuGet.Config file while verifying package signature.

What are the main concerns here? There should be a way to specify what configuration file is applied & if not, defaulting to the user location given it applies to all operations. If in a directory that contains a solution/project, they are overridden by solution level config settings.

I didn't find anything in nuget verify command spec, but found a wiki (not sure if it's still up to date though): https://github.com/NuGet/Home/wiki/NuGet-Verify-Command#config-file-for-repository-signature-verification, saying that verify command will take the config file option.

@kartheekp-ms
Could you able to clarify your comment about #10011? I'm bit confused now. Shouldn't #10011 already be closed or at least P3 priority item based on your above comment since nuget.config file is ignored?

My message in that comment is, the behavior of nuget.exe verify and dotnet nuget verify command should match once we add an option to accept config file. The reason is we try to maintain parity between nuget.exe and dotnet commands. I agree with Nikolche's comment (next to mine in the same issue) because the changes would impact both the commands because the code base is shared.

The reason is we try to maintain parity between nuget.exe and dotnet commands.

I see people in the NuGet team keep saying this, but the dotnet cli intentionally distanced itself from the older msbuild.exe, including changing defaults to make more sense given the decade(s) that passed since msbuild/nuget.exe was first created. Some examples are most commands changing default verbosity from normal to minimal, and changing from Microsoft/cmd.exe style /arg arguments to GNU style -a and --arg style. So, by design, the dotnet CLI is not 100% compatible with the older tools. A third example is that msbuild.exe does not do an implicit NuGet restore (the -restore argument), whereas the dotnet CLI does.

I agree with reading nuget.config files, and think it's a bug that nuget.exe verify didn't. But I don't like seeing "make dotnet nuget the same as nuget.exe" used as any justification since I think we can improve customer experience with the newer tool.

@kartheekp-ms, the current version of that spec is misleading. NuGet 4.6.0 delivered author signing, while NuGet 4.7.0 delivered repository signing. I think that the engineer who worked on repository signing updated the verify spec, which already supported author signatures, with such single-feature focus that the changes read like the command has a behavioral difference between author- and repository-signed packages. A previous version of the spec doesn't have this problem. Based on this information, I don't see any concern around the verify command applying settings from the NuGet.Config file incorrectly while verifying package signatures. Do you? The verifier settings are not changing with this PR.

@erdembayar, as part of this work can you please update https://github.com/NuGet/Home/wiki/NuGet-Verify-Command/ to not sound like it works only for repository signatures? As an example,
Config file for repository signature verification should be "Config file for signature verification".

nkolev92

Code looks fine to me.

Sounds like @kartheekp-ms has behavior concern.

I'll be happy to take a look again when that's figured out.

dtivel · 2022-01-12T14:56:18Z

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

+                SettingSection trustedSignersSection = verifyArgs.Settings?.GetSection(TrustedSignersSectionName);
+                List<TrustedSignerItem> trustedSigners = trustedSignersSection?.Items.Select(c => c as TrustedSignerItem).Where(c => c != null).ToList();
+                IEnumerable<KeyValuePair<string, HashAlgorithmName>> allowUntrustedRootList = trustedSigners?
+                    .SelectMany(c => c.Certificates)
+                    .Where(c => c.AllowUntrustedRoot)
+                    .Select(c => new KeyValuePair<string, HashAlgorithmName>(c.Fingerprint, c.HashAlgorithm));


You should be using TrustedSignersProvider.GetAllowListEntries(...) instead, which will do this for you and get the "owners" that you didn't.

Advice: try to find out how existing code does it before implementing something new.

dtivel · 2022-01-12T14:59:16Z

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

+                SettingSection trustedSignersSection = verifyArgs.Settings?.GetSection(TrustedSignersSectionName);
+                List<TrustedSignerItem> trustedSigners = trustedSignersSection?.Items.Select(c => c as TrustedSignerItem).Where(c => c != null).ToList();
+                IEnumerable<KeyValuePair<string, HashAlgorithmName>> allowUntrustedRootList = trustedSigners?
+                    .SelectMany(c => c.Certificates)
+                    .Where(c => c.AllowUntrustedRoot)
+                    .Select(c => new KeyValuePair<string, HashAlgorithmName>(c.Fingerprint, c.HashAlgorithm));


@kartheekp-ms, the current version of that spec is misleading. NuGet 4.6.0 delivered author signing, while NuGet 4.7.0 delivered repository signing. I think that the engineer who worked on repository signing updated the verify spec, which already supported author signatures, with such single-feature focus that the changes read like the command has a behavioral difference between author- and repository-signed packages. A previous version of the spec doesn't have this problem. Based on this information, I don't see any concern around the verify command applying settings from the NuGet.Config file incorrectly while verifying package signatures. Do you? The verifier settings are not changing with this PR.

@erdembayar, as part of this work can you please update https://github.com/NuGet/Home/wiki/NuGet-Verify-Command/ to not sound like it works only for repository signatures? As an example,
Config file for repository signature verification should be "Config file for signature verification".

erdembayar · 2022-01-18T23:43:25Z

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

+                // trustedSigners section >> allowUntrustedRoot set true are considered here.
+                verificationProviders.Add(new SignatureTrustAndValidityVerificationProvider(trustedSignerAllowUntrustedRootList));
+
+                // List of values passed through --certificate-fingerprint option are considered here.


For verify action repository signing allow list not considered.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageExtractor.cs

Lines 1019 to 1029 in b8fe2a0

if (repositorySignatureInfo != null && repositorySignatureInfo.RepositoryCertificateInfos != null)

{

var repositoryAllowList = RepositorySignatureInfoUtility.GetRepositoryAllowList(repositorySignatureInfo.RepositoryCertificateInfos);

verificationProviders.Add(new AllowListVerificationProvider(

repositoryAllowList,

repositorySignatureInfo.AllRepositorySigned,

Strings.Error_NoRepoAllowList,

Strings.Error_NoMatchingRepositoryCertificate));

}

erdembayar · 2022-01-18T23:55:52Z

I see a lot of tests that are ran on the dotnet nuget verify, nuget verify are duplicated.

Can we test the core functionality with the VerifyCommandRunner rather than tests that kick off new processes? And only then add some E2E tests.

I really appreciate how thorough your tests are, but we also need to make sure we're not repeatedly testing the same.

We expect dotnet nuget verify and nuget verify work exactly same, that is why I tried make tests look same for them. But they have different command syntax so testing them separately worth, besides I don't see VerifyCommandRunner specific tests, not sure time costs of setting up new one.

dtivel · 2022-01-19T12:50:28Z

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

@@ -50,6 +50,9 @@ public async Task<int> ExecuteCommandAsync(VerifyArgs verifyArgs)
                    return packages;
                });

+                var clientPolicyContext = ClientPolicyContext.GetClientPolicy(verifyArgs.Settings, verifyArgs.Logger);


Use explicit type instead of var.

Sure, addressed.

dtivel · 2022-01-19T12:56:33Z

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

+                // nuget.config >> trustedSigners section read
+                IReadOnlyList<TrustedSignerAllowListEntry> trustedSignerAllowList = TrustedSignersProvider.GetAllowListEntries(verifyArgs.Settings, verifyArgs.Logger);
+


Previously, I recommended using TrustedSignersProvider.GetAllowListEntries(...) directly (instead of ClientPolicyContext.GetClientPolicy(...)). My reasoning was that ClientPolicyContext.GetClientPolicy(...) already does 2 things:

Determine the signature validation mode.

Fetch the allow list using TrustedSignersProvider.GetAllowListEntries(...).

...and that you only need # 2. However, with your latest changes, we're now setting signature validation mode --- which is fine, provided that we have good test coverage.

Make sure you delete this statement and replace trustedSignerAllowList with clientPolicyContext.AllowList.

test/NuGet.Clients.FuncTests/NuGet.CommandLine.FuncTest/Commands/VerifyCommandTests.cs

dtivel · 2022-01-19T14:07:39Z

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs

+                      new AllowListVerificationProvider(
+                          trustedSignerAllowList,
+                          requireNonEmptyAllowList: clientPolicyContext.Policy == SignatureValidationMode.Require,
+                          emptyListErrorMessage: Strings.Error_NoClientAllowList,
+                          noMatchErrorMessage: Strings.Error_NoMatchingClientCertificate));


1 level of indentation is 4 spaces.

dtivel · 2022-01-19T14:10:14Z

test/NuGet.Core.Tests/NuGet.CommandLine.Xplat.Tests/Utility/XPlatUtilityTests.cs

+            List<string> configPaths = settings.GetConfigFilePaths().ToList();
+            Assert.True(configPaths.Count > 1);
+            // Assert user default nuget.config is loaded
+            Assert.True(configPaths.Contains(baseNugetConfigPath));


Put that comment in the code.

dtivel · 2022-01-19T14:40:19Z

test/TestUtilities/Test.Utility/SimpleTestSetup/SimpleTestSettingsContext.cs

@@ -191,5 +192,20 @@ public void AddNetStandardFeeds()

            Save();
        }
+
+        // Simply add any text as section into nuget.config file, adding large child node into nuget.config via api is tedious.
+        public static void AddSectionIntoNuGetConfig(string path, string content, string parentNode)


Creating a utility method to simplify/deduplicate code is great. Trying to create a general-purpose utility method with only 1 scenario in use is risky.

Should this method guard against adding a section when a like-named section already exists?

Thank you for your feedback.
I added guard preventing this scenario, please check now. But I didn't add unit test for asserting it, since we don't have specific file for adding test for test utility itself. Alternatively, I could add one DotnetVerifyTests.cs, but not sure if it's correct thing to do.

test/NuGet.Core.FuncTests/Dotnet.Integration.Test/DotnetVerifyTests.cs

erdembayar · 2022-01-21T00:45:43Z

I see a lot of tests that are ran on the dotnet nuget verify, nuget verify are duplicated.
Can we test the core functionality with the VerifyCommandRunner rather than tests that kick off new processes? And only then add some E2E tests.
I really appreciate how thorough your tests are, but we also need to make sure we're not repeatedly testing the same.

We expect dotnet nuget verify and nuget verify work exactly same, that is why I tried make tests look same for them. But they have different command syntax so testing them separately worth, besides I don't see VerifyCommandRunner specific tests, not sure time costs of setting up new one.

@nkolev92 @dtivel
I created follow up issue https://github.com/NuGet/Client.Engineering/issues/1389 for creating unified testing for both nuget verify and dotnet nuget verify, after that we can cleanup duplicate tests.

nkolev92 · 2022-01-21T00:59:17Z

Sure, but that makes this PR harder to review as we're dealing double the code.

…onfig

test/TestUtilities/Test.Utility/SimpleTestSetup/SimpleTestSettingsContext.cs

dtivel · 2022-01-21T17:51:20Z

src/NuGet.Core/NuGet.Commands/PublicAPI/net472/PublicAPI.Unshipped.txt

+NuGet.Commands.PackCollectorLogger.PackCollectorLogger(NuGet.Common.ILogger innerLogger, NuGet.ProjectModel.WarningProperties warningProperties, NuGet.Commands.PackCommand.PackageSpecificWarningProperties packageSpecificWarningProperties) -> void
+NuGet.Commands.PackCommand.PackageSpecificWarningProperties
+NuGet.Commands.PackCommand.PackageSpecificWarningProperties.PackageSpecificWarningProperties() -> void
+static NuGet.Commands.PackCommand.PackageSpecificWarningProperties.CreatePackageSpecificWarningProperties(System.Collections.Generic.IDictionary<string, System.Collections.Generic.HashSet<(NuGet.Common.NuGetLogCode, NuGet.Frameworks.NuGetFramework)>> noWarnProperties) -> NuGet.Commands.PackCommand.PackageSpecificWarningProperties


The public API changes in your latest commit look accidental. Please confirm.

This one is ok, it happened because I resolved merge conflicts by merging to dev branch instead of rebasing the dev branch (with rebase if file has conflict on early commit, then it is very time consuming to resolve in all subsequent commits same), final compare you wouldn't see it.

kartheekp-ms · 2022-01-21T22:52:34Z

test/NuGet.Core.FuncTests/Dotnet.Integration.Test/DotnetVerifyTests.cs

+        [InlineData("true", true)]
+        [InlineData("true", false)]
+        [InlineData("false", true)]
+        [InlineData("false", false)]


Looking at this implementation https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Boolean.cs#L82, I think we can simply call allowUntrustedRoot.ToString() wherever we need "true/false" as strings without allocation additional strings.

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch 4 times, most recently from b73afcc to 4c17651 Compare January 8, 2022 01:23

erdembayar marked this pull request as ready for review January 8, 2022 01:36

erdembayar requested a review from a team as a code owner January 8, 2022 01:36

erdembayar requested review from dtivel, heng-liu and kartheekp-ms January 8, 2022 01:37

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch 3 times, most recently from be350d2 to f555e35 Compare January 10, 2022 18:39

zivkan reviewed Jan 10, 2022

View reviewed changes

src/NuGet.Core/NuGet.Commands/VerifyCommand/VerifyCommandRunner.cs Outdated Show resolved Hide resolved

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch from 6910e0f to 896a0a9 Compare January 10, 2022 20:41

zivkan reviewed Jan 10, 2022

View reviewed changes

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch 2 times, most recently from 0d841d7 to 448dbb3 Compare January 10, 2022 23:34

nkolev92 reviewed Jan 11, 2022

View reviewed changes

src/NuGet.Core/NuGet.CommandLine.XPlat/Commands/Signing/TrustedSignersCommand.cs Show resolved Hide resolved

kartheekp-ms requested changes Jan 11, 2022

View reviewed changes

nkolev92 reviewed Jan 11, 2022

View reviewed changes

jeffkl added the Merge next release PRs that should not be merged until the dev branch targets the next release label Jan 11, 2022

erdembayar requested review from aortiz-msft and JonDouglas January 11, 2022 19:03

dtivel reviewed Jan 12, 2022

View reviewed changes

erdembayar marked this pull request as draft January 13, 2022 18:03

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch 5 times, most recently from 828a3da to 8ec6ad7 Compare January 15, 2022 01:18

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch 3 times, most recently from dd6b6dd to 4baba17 Compare January 18, 2022 23:36

erdembayar commented Jan 18, 2022

View reviewed changes

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch from 4baba17 to 1ebb2df Compare January 19, 2022 00:21

Address comments about tests

328ef60

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch from 1ebb2df to 328ef60 Compare January 19, 2022 02:03

dtivel reviewed Jan 19, 2022

View reviewed changes

Address comments Damon

fad5bb9

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch from 5a7ee62 to fad5bb9 Compare January 19, 2022 21:32

Detect duplicate xml element being added.

f5f0313

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch from 37a01aa to f5f0313 Compare January 19, 2022 21:51

erdembayar requested a review from dtivel January 19, 2022 21:51

Clean up

b96d082

erdembayar added 3 commits January 20, 2022 17:46

Address test reviews.

87846fd

Merge branch 'dev' into dev-eryondon-10774-DotnetVerifyNotUsingNugetC…

0e2dd8b

…onfig

Merge branch 'dev' into dev-eryondon-10774-DotnetVerifyNotUsingNugetC…

1352e50

…onfig

dtivel reviewed Jan 21, 2022

View reviewed changes

Add parameter name

0d243bd

dtivel approved these changes Jan 21, 2022

View reviewed changes

kartheekp-ms approved these changes Jan 22, 2022

View reviewed changes

Remove NU3018 checking due to MAC issue NuGet/Home#11519.

c26dade

erdembayar force-pushed the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch from 978f91a to c26dade Compare January 22, 2022 02:08

erdembayar requested a review from nkolev92 January 24, 2022 17:55

nkolev92 approved these changes Jan 25, 2022

View reviewed changes

erdembayar merged commit 0e5d9bd into dev Jan 26, 2022

erdembayar deleted the dev-eryondon-10774-DotnetVerifyNotUsingNugetConfig branch January 26, 2022 16:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make verify command consider default nuget.config file and nuget.config option #4396

Make verify command consider default nuget.config file and nuget.config option #4396

erdembayar commented Jan 8, 2022 •

edited

Loading

zivkan Jan 10, 2022

nkolev92 left a comment

kartheekp-ms Jan 11, 2022 •

edited

Loading

erdembayar Jan 11, 2022 •

edited

Loading

erdembayar Jan 11, 2022 •

edited

Loading

erdembayar Jan 11, 2022

erdembayar Jan 11, 2022 •

edited

Loading

JonDouglas Jan 11, 2022

heng-liu Jan 11, 2022

kartheekp-ms Jan 11, 2022 •

edited

Loading

zivkan Jan 11, 2022

dtivel Jan 12, 2022

nkolev92 left a comment

dtivel Jan 12, 2022

dtivel Jan 12, 2022

erdembayar Jan 18, 2022 •

edited

Loading

erdembayar commented Jan 18, 2022

dtivel Jan 19, 2022

erdembayar Jan 19, 2022

dtivel Jan 19, 2022

erdembayar Jan 19, 2022

dtivel Jan 19, 2022

erdembayar Jan 19, 2022

dtivel Jan 19, 2022

dtivel Jan 19, 2022

erdembayar Jan 19, 2022 •

edited

Loading

erdembayar commented Jan 21, 2022

nkolev92 commented Jan 21, 2022

dtivel Jan 21, 2022

erdembayar Jan 21, 2022

kartheekp-ms Jan 21, 2022

Setting	Verify Command default setting
AllowUnsigned	❌
AllowIllegal	❌
AllowUntrusted	❌
AllowIgnoreTimestamp	❌
AllowMultipleTimestamps	✔️
AllowNoTimestamp	✔️
AllowUnknownRevocation	✔️
ReportUnknownRevocation	✔️
VerificationTarget	Targets unknown, Author and Repository signatures
SignaturePlacement	Primary, Counter signatures
RepositoryCountersignatureVerificationBehavior	IfExists (Verify a signature if it exists)
RevocationMode	Online unless "NUGET_CERT_REVOCATION_MODE" environment variable is set


	if (repositorySignatureInfo != null && repositorySignatureInfo.RepositoryCertificateInfos != null)
	{
	var repositoryAllowList = RepositorySignatureInfoUtility.GetRepositoryAllowList(repositorySignatureInfo.RepositoryCertificateInfos);

	verificationProviders.Add(new AllowListVerificationProvider(
	repositoryAllowList,
	repositorySignatureInfo.AllRepositorySigned,
	Strings.Error_NoRepoAllowList,
	Strings.Error_NoMatchingRepositoryCertificate));
	}

		// nuget.config >> trustedSigners section read
		IReadOnlyList<TrustedSignerAllowListEntry> trustedSignerAllowList = TrustedSignersProvider.GetAllowListEntries(verifyArgs.Settings, verifyArgs.Logger);

Make verify command consider default nuget.config file and nuget.config option #4396

Make verify command consider default nuget.config file and nuget.config option #4396

Conversation

erdembayar commented Jan 8, 2022 • edited Loading

Bug

Description

PR Checklist

Choose a reason for hiding this comment

nkolev92 left a comment

Choose a reason for hiding this comment

kartheekp-ms Jan 11, 2022 • edited Loading

Choose a reason for hiding this comment

erdembayar Jan 11, 2022 • edited Loading

Choose a reason for hiding this comment

erdembayar Jan 11, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erdembayar Jan 11, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kartheekp-ms Jan 11, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nkolev92 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erdembayar Jan 18, 2022 • edited Loading

Choose a reason for hiding this comment

erdembayar commented Jan 18, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erdembayar Jan 19, 2022 • edited Loading

Choose a reason for hiding this comment

erdembayar commented Jan 21, 2022

nkolev92 commented Jan 21, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erdembayar commented Jan 8, 2022 •

edited

Loading

kartheekp-ms Jan 11, 2022 •

edited

Loading

erdembayar Jan 11, 2022 •

edited

Loading

erdembayar Jan 11, 2022 •

edited

Loading

erdembayar Jan 11, 2022 •

edited

Loading

kartheekp-ms Jan 11, 2022 •

edited

Loading

erdembayar Jan 18, 2022 •

edited

Loading

erdembayar Jan 19, 2022 •

edited

Loading