fix broken func test in SignatureUtilityTests

[kartheekp-ms]

Bug

Fixes: NuGet/Home#8937
Regression: No

Fix

Details: A func test to generate a signed package with no certificate usage is working in only net472 platform but fails in all the netcore platforms. As per my conversation with @dtivel, I came to know that package signing libraries for net472 platform were built by NuGet team where as for netcore platforms we rely on dotnet libraires. It looks like modifying net472 NuGet libraries to fix this func test is not a good long-term solution. Hence submitting this PR to split the failing func test into 2 where one test generates a signed package with no certificate usage on net472 platform and other test verifies the package content across all the platforms. @heng-liu - thank you for developing the new build infrastructure where signed packages generated by various func tests are uploaded to a container and downloaded later for verification purposes.

Testing/Validation

Tests Added: Yes

[dtivel]

A couple problems:

• This test naming scheme is cryptic. It's not clear how this was generated, what it means, or how I would generate a new name successfully.
• caseName is confusing; don't we already have a test case name with VerifySignaturesAsync_PreGenerateSignedPackages_AuthorSigned_TimeStampedWithNoSigningCertificateUsage_Throws?
• Two files are expected to have the same string literal for everything to work successfully.

[kartheekp-ms]

Discussed few possible options with @dtivel

• Build case names dynamically using a builder design pattern. The problem with this approach is it will be hard to search for case names during design/compile time.
• Use string constants for case names but we can't avoid duplicates values (if created unintentionally).

@dtivel suggested to use enum that can help solve above drawabacks.

[rrelyea]

Should we add single quotes, or similar, around the {0}, to better handle the long name, with potential spaces? What do we usually do?

[rrelyea]

is this comment about "2 folders" will be created still true. it isn't clear to my why that is true. should the comment be enhanced?

[rrelyea]

these enum values didn't give me a clue about the purpose...the summary helps. Perhaps better enum name or value names could make it more obvious??

[dtivel]

How about:

public enum TestPackages
{
    Package1
}

You could be fancier than Package1 and do what you did before and embed more scenario information in the name. I would avoid trying to encode everything in the name (e.g.: "ATNOCERTIFICATE" for "Author signed with Timestamp with No Certificate in the timestamp signature").

My issues with the previous approach were:

• It's not easy to understand the string. ("A" and "T" are not common abbreviations and "NOCERTIFICATE" is vague about which certificate and how it is missing.)
• It's not easy to enforce uniqueness in string values. (It's possible that another test could use the same string and overwrite/use another test package.)
• There are rules around these string literals which are not easily enforced. (The same string literal needs to be used on both the package generation side and the package consumption side.)

An enum makes a good alternative and the member names don't matter too much. You could have an XML doc comment on the member which describes the package requirements in detail:

public enum TestPackages
{
    /// <summary>
    /// This package is author signed with a timestamp.
    /// The timestamp signature does not include the signing certificate.
    /// Certificates are otherwise trusted and valid.
    /// </summary>
    Package1
}

[rrelyea]

nit: netcore is about to be ".net 5"...
in a few years, netcore will be an old fashioned term.

[zkat]

how should we be distinguishing between legacy framework and .net "core" going forward, then?

[dtivel]

One type per file, so FolderNames in FolderNames.cs and TestFolderNames in TestFolderNames.cs

[dtivel]

How about:

public enum TestPackages
{
    Package1
}

You could be fancier than Package1 and do what you did before and embed more scenario information in the name. I would avoid trying to encode everything in the name (e.g.: "ATNOCERTIFICATE" for "Author signed with Timestamp with No Certificate in the timestamp signature").

My issues with the previous approach were:

• It's not easy to understand the string. ("A" and "T" are not common abbreviations and "NOCERTIFICATE" is vague about which certificate and how it is missing.)
• It's not easy to enforce uniqueness in string values. (It's possible that another test could use the same string and overwrite/use another test package.)
• There are rules around these string literals which are not easily enforced. (The same string literal needs to be used on both the package generation side and the package consumption side.)

An enum makes a good alternative and the member names don't matter too much. You could have an XML doc comment on the member which describes the package requirements in detail:

public enum TestPackages
{
    /// <summary>
    /// This package is author signed with a timestamp.
    /// The timestamp signature does not include the signing certificate.
    /// Certificates are otherwise trusted and valid.
    /// </summary>
    Package1
}