Proposal to Surface Sponsorship Information in the CLI

[kalebfik]

Rendered Spec

[kalebfik]

@dotnet-policy-service agree company="Microsoft"

[nkolev92]

Looks pretty good to me.

Just final details to iron out during the meeting.

[donnie-msft]

Great progress! I know this doc has gotten edited with many iterations of feedback. I think it needs to be consolidated a bit and structured so that it highlights your key design ideas.

[donnie-msft]

I think this is fine. We could only show this for --verbosity detailed or something.
No strong opinion from me.

[donnie-msft]

For --vulnerable, we output a list of sources here. Perhaps we should do the same and then in the "projects" below we could only list sources which have sponsors? This would reduce noise in the output while still providing the list of sources we checked against.

(note, in this case the local package feed could be listed as an enabled source, but we wouldn't query it since it's local and therefore not able to provide Registration)

"sources": [
    "https://data.nuget.org/v3/index.json",
     "C:/Program Files (x86)/Microsoft SDKs/NuGetPackages/"
  ],

[donnie-msft]

FYI, Mentioned above that we may want to only list sources here that support Sponsorship metadata in Registration.

[donnie-msft]

We group by top level & transitive for --vulnerable.

I propose that we remove "sources" and replace it with topLevelPackages & transitivePackages.
This proposed grouping is now project->top/transitive -> source providing 1 or more sponsor -> packageId which has 1 or more sponsor.

{
  "projects": [
    {
      "path": "/path/to/Contoso.App.csproj",
      "topLevelPackages": [
        {
          "source": "https://api.example.org/v3/index.json",
          "sponsorablePackages": [
            {
              "id": "Contoso.Tools",
              "urls": [
                "https://github.com/sponsors/contoso"
              ]
            },
            {
              "id": "Contoso.Utility",
              "urls": [
                "https://github.com/sponsors/contoso"
              ]
            }
          ]
        },
        {
          "source": "https://www.myget.org/F/contoso/api/v3/index.json",
          "sponsorablePackages": [
            {
              "id": "Contoso.Utility",
              "urls": [
                "https://buymeacoffee.com/contoso"
              ]
            }
          ]
        }
      ],
      "transitivePackages": [
        {
          "source": "https://api.example.org/v3/index.json",
          "sponsorablePackages": [
            {
              "id": "Contoso.Tools.OpenApi",
              "urls": [
                "https://github.com/sponsors/contoso"
              ]
            }
          ]
        }
      ]
    }
  ]
}

[zivkan]

If we assume most sources will accurately mirror the source of truth, then we could de-duplicate lists and I think that'll make the average size go down. Something like:

{
  "packages": [
    {
      "package": "Contoso.Utility",
      "sponsorUrls": [
        {
          "sources": [ "feed1", "feed2" ],
          "urls": [ "https://whatever", "https://something" ]
       }
    }
   ]
}

This way the only time that sponsorUrls is an array with length != 1 is when a source disagrees about the complete list. But it avoids duplicating the package name, and the URL list

[donnie-msft]

Sounds fine to me IFF package source mapping is disabled.

Should we go ahead and use nuget.org in the example?

Suggested change

	Consider specifying another package source with `--source <SOURCE>`.
	Consider specifying an additional package source that provides sponsorship metadata, for example: `--source https://api.nuget.org/v3/index.json`.

[zivkan]

The text output didn't propose grouping by project, and I don't think the json should either. This is a format specific for sponsor, not a shared format. If we think it's useful for customers to know which projects a package is used by, when getting sponsorship info, I think adding a projects array to a package object makes more sense.