Sign Packages

[Rabadash8820]

After updating to Unity 6.3, I noticed that all of the NuGet UPM packages are being flagged as unsigned (see screenshot below). The Unity Manual has instructions for exporting/signing a UPM package. Looks like the main thing needed is a Unity Cloud Organization to associate with the package, and then run the Editor from the CLI with -upmPack.

[Rabadash8820]

@favoyang This may be an extra step to perform on the OpenUPM side, idk.

[bdovaz]

The main problem is that we need the Unity editor to sign the packages.

There is no "lightweight" tool that can perform these operations, which would be ideal.

[Rabadash8820]

Hm, a couple options come to mind:

• There is the game-ci/docker repo that maintains Docker images with Unity for use in CI builds
• The related game-ci/unity-actions defines GitHub Actions for running Unity Editor commands, though I'm not sure that it's still being maintained
• There's always Unity's official Build Automation for building Unity projects, and presumably a custom pre- or post-build script could be used to run the -upmPack command

Hopefully one or a combination of those services could be used to generate signed UPM packages of NuGets automatically. But again, I'm not sure whether it would be better this automated signing to happen in this repo or in OpenUPM.

[bdovaz]

I already know all that and have used it, it's not a problem.

What I mean is that in the registry.json file there are hundreds of packages, and each one of them has dozens or hundreds of versions.

If you look at the Unity CLI, it only allows you to sign one at a time... That is, for each package, you would have to spawn the entire Unity Editor in batch mode... You can imagine how many hours that could take.

That's why I recommend that for more professional uses, everyone set up their own UnityNuGet instance with the subset of packages they need.

And in that case, sign the packages if you need to.

And another thing, signing packages is only available in 6000.3.x+. If you sign it from that version but the package is compatible with 6000.0.x, for example, I don't know if those earlier versions of the editor will be able to read those packages.

[Rabadash8820]

If you look at the Unity CLI, it only allows you to sign one at a time. ... You can imagine how many hours that could take.

Ah, I see what you mean now. "Batch signing" would be a really nice feature for Unity to add... Maybe I can put in a request for that on Unity Discussions. Alternatively, maybe the -upmPack command calls another script under the hood, something "lightweight", like you said above, that could be batch-invoked. Idk how to figure that out without reverse engineering Unity though lol.

That's why I recommend that for more professional uses, everyone set up their own UnityNuGet instance with the subset of packages they need

Personally, I don't think this is very realistic. The whole benefit of using a service like UnityNuGet or OpenUPM is not having to manage servers. I.e., if a team wasn't going to use the public registry, it would probably be simpler just to download the DLLs from nuget.org and store them in Unity projects as managed plugins. 🤷‍♂️

I don't know if those earlier versions of the editor will be able to read those packages.

Good point. That should be easy enough to test though; just try to add a signed UPM package from disk to a pre-6.3 project and see what happens. I can probably test that myself in the next few days.

[bdovaz]

Ah, I see what you mean now. "Batch signing" would be a really nice feature for Unity to add... Maybe I can put in a request for that on Unity Discussions. Alternatively, maybe the -upmPack command calls another script under the hood, something "lightweight", like you said above, that could be batch-invoked. Idk how to figure that out without reverse engineering Unity though lol.

Historically, suggesting a feature to Unity means being ignored or takes years to be addressed... I wouldn't count on that, but rather on the reverse engineering you mention, that maybe in the Unity installation directory there is an *.exe or similar that can be called, but I don't know because they depend on Unity Cloud for signing, etc., and I don't know if that is linked to the editor.

Personally, I don't think this is very realistic. The whole benefit of using a service like UnityNuGet or OpenUPM is not having to manage servers. I.e., if a team wasn't going to use the public registry, it would probably be simpler just to download the DLLs from nuget.org and store them in Unity projects as managed plugins. 🤷‍♂️

In our case, we distribute packages that depend on NuGet packages. If we depended on the OpenUPM feed, we would have many problems because we would depend directly on OpenUPM, and if it goes down, we have no way of fixing it. Apart from that, it is processing the entire registry.json with 80% of packages that we do not use, and we are risking more problems associated with packages that are not relevant to us.

I don't know if those earlier versions of the editor will be able to read those packages.

That would be good because otherwise it's impossible; I'm not going to upgrade the packages minimum version of Unity just for this... That's why I'm reinforcing the message that for professional use, it's advisable for everyone to host their own UnityNuGet because then everyone can set the minimum version to Unity 6000.3.x, for example, and not worry about backward compatibility.

[Rabadash8820]

So I tested out installing a signed UPM in a Unity 6 project, and it worked just fine. Now that I think about it...of course it did; if it didn't, then users of the previous Unity LTS versions wouldn't be able to install the latest versions of official Unity UPM packages, so they obviously made things backwards compatible. Seems that all signing a package really does is add the new .attestation.p7m file (from the docs) to its contents.

I've brought up the batch-signing idea anyway on this Unity Discussions thread. There seem to be a few fairly active Unity engineers on that thread so hopefully they'll have answers.

It also occurred to me that signing a UPM is probably nowhere near as slow as actually building a Unity project. I wasn't able to test this locally unfortunately as I couldn't figure out how to make the command authenticate with my account that has 2FA enabled. Still, while it will obviously take some time to sign all of the existing package versions in UnityNuGet, that's a one-time operation. Signing new package versions shouldn't be too hard or slow when doing it via the command line on a CI machine from one of the above services.

[bdovaz]

We'll wait and see if they give you an answer.

Thanks for the tests, the backward compatibility makes sense, but with Unity you never know what to expect.

[Rabadash8820]

@bdovaz Looks like there was finally an answer. Sounds like there is no CLI tool currently, but they are actually working on one, and also working with OpenUPM to "ensure a signing solution is in place for future open source packages that end up on that site." Hopefully whatever solution works for them will also help UnityNuGet, when using the OpenUPM package feed.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the Stale label or comment on the issue.

[Rabadash8820]

Leaving a comment to keep this Issue alive. Based on the Unity Discussion linked above, we should be seeing a solution for bulk package signing in the next few weeks. The Unity dev said that they were in talks with OpenUPM on how to address this, so whatever solution they've come up with may automatically solve things for UnityNuGet, but we shall see...

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the Stale label or comment on the issue.