Code Signing

[Perksey]

This enables code signing for all DLLs, EXEs, and more whose filenames start with Silk.NET

NuGet requires the code signing certificate to be registered with them. By default, all code signing certificates are registered under the dotnetfoundation organisation. However, we'd have to add that organisation as an owner of every single one of our packages to do that, current and future, which is not a process that can be automated today.

I've asked for help in dotnet-foundation/projects#147

[HurricanKai]

Consider raising this with NuGet support.

[Perksey]

This isn't a NuGet issue. The only thing NuGet could do to improve the situation is allow automation of ownership modification, which will require API additions and will take months to get triaged, and then presumably more months to get implemented.

The issue is that we can't reasonably add dotnetfoundation as an owner of our packages because of how many there are and how great the odds are that a new one will occasionally pop up when we generate our bindings.

I presented possible workarounds in the issue linked.

[Perksey]

Update (for the record): some emails have been flung about within Microsoft to try and move these packages over to dotnetfoundation from the backend. No updates as of yet.

[Perksey]

Some updates:

• The NuGet team have said that, if we really needed, they could do some database-side changes but would prefer to make a more elegant tool in their next sprint or two so that they can better facilitate transfers like these.
• As such, as a workaround we've just added code-signing certificate to the Silk.NET organisation until such a time comes that we can get all the packages co-ownered to dotnetfoundation.
• This can now be merged.

[HurricanKai]

Assuming the description is ment to be just the name.

[Perksey]

Assuming the description is ment to be just the name.

So says the example pipelines :)