Unity Core Standards: New Features and What’s Next

Hi all,

Since we launched Unity Core Standards last fall to help bring more clarity and trust to our package ecosystem, we’ve been working to deliver more security and transparency.

Keep reading to learn more about what we’ve been working on.

Unity Package Manager (UPM)

Prompts to flag unsigned packages


Example pop-up for unsigned package in Unity Package Manager

In Unity 6.4, we added a pop-up during package installation to provide users with information regarding missing or invalid signatures, to help developers make safer decisions about what they add to their projects. By leveraging cryptographic signatures, Unity enables the Package Manager to verify the origin and authorship of your tools, giving you the insights needed to confirm authenticity and package safety. This pop-up requires users to acknowledge the risk and proceed with installing unsigned packages, as well as packages that are sourced outside of Unity.

Samples View


Example of a sample preview in Package Manager

As part of our investments in making the Package Manager experience better, we also wanted to highlight that coming 6.5, we’re introducing a new Samples View within Package Manager, where all available samples across installed packages, including dependency packages, can be discovered. Developers can search, filter, view example images, see descriptions and source package information, and import the samples they need much faster.

Package Signing for more developers

Even developers who do not have packages that are a fit for the Unity Asset Store (eg. open source packages, private or custom packages) can become Core Standards compliant by signing their packages. This can be done through integrating the UPM CLI to your CI\CD workflows.

In addition, for open source projects that list on OpenUPM, there is now also an official guide for how to sign your Unity packages.

UPM Publishing

This year, UPM Publishing for the Unity Asset Store went into general availability for free packages. UPM packages provide easy setup and automated updates, as well as dependency handling for fewer project breaks and mismatches. You can learn more about Unity package types here.

Working with our community

As we continue to evolve and improve our Unity Core Standards, we’re partnering with long-standing publishers and new strategic partners to help make our package ecosystem better for all Unity users.

Below are testimonials from Tony of Pixel Crushers and Bryan and Andreas of Sirenix on how Unity Core Standards is helping to up-level the whole ecosystem.

Let us know what you think

As Unity Core Standards evolves and works to bring developers more trust and confidence in the packages they add to projects, we’d like to hear your thoughts on these improvements and what you’d like to see in future Core Standards initiatives and updates.

13 Likes

When will we be able to turn this off?

16 Likes

Could git packages get full dependency support? So one git package can depend on another

6 Likes

So you won’t give us a way to forfeit signing for our private packages? It’s really illogical that private packages need signing at all.

5 Likes

I’m struggling to understand the problem this is intended to solve.

Is Unity seeing a significant issue with malicious or compromised packages in the ecosystem today? If so, it would be helpful to understand the scope of that problem.

Is this a future path toward monetizing packages distributed outside the Asset Store?

2 Likes

Please provide an option to disable this feature so that we can still import other packages smoothly.

1 Like

hi @stonstad, as is the case with all rich ecosystems, Unity is not immune to nefarious activities in its package ecosystem, and we’ve leaned on existing industry safety practices to ensure our community has the information it needs to make informed decisions when deciding to add a new product to their projects.

hi @Laicasaane, ensuring customers who create their own packages had an easy way to sign them was a top priority for our team. Packages can easily be signed directly in the editor through the package manager’s export functionality, or by integrating a simple CI/CD step using our lightweight signing stand alone app.

1 Like

I don’t want to have to and I shouldn’t have to deal with signing my own internal packages. I don’t need and shouldn’t need to go through additional steps in what was previously a seamless process of simply committing changes to github, and hitting ‘update package’ in the package manager in other projects.

I feel like this is a feature no one asked for.

10 Likes

While I agree that this is unnecessary for private self-managed packages, it’s a welcome necessity for the ecosystem. Attacks in package management ecosystems are only increasing in frequency and we only haven’t seen them here yet because it’s relatively niche. It’ll happen sooner or later once someone realises the potential for it to affect games with large playerbases, or finds the right package to steal a load of developer tokens.
The reason to complain about this is purely about UX, not about the feature existing.

1 Like

Thanks for the reply!

Where are people downloading these nefarious Unity packages?

What stops a bad actor from using the self-signing feature in the editor to sign a nefarious package?

2 Likes

And I think if people are downloading shonky addons from shonky websites, that’s their problem and not yours. And it shouldn’t become our problem as well.

This feels like the social media bans: disproportionately affecting the wrong people while not solving the problem whatsoever.

So if these people can self sign and distribute packages through your ecosystem, then this does nothing to solve the problem while giving me more work to do for absolutely zero reason.

Are we able to cut the politician style responses and give honest answers to our questions?

10 Likes

I feel like you are purposefully being misdirection to avoid a frontal conversation about the “private package signing is redundant” problem we’re raising ever since signing was first introduced.

Let’s be clear: We’re NOT asking for a way to not sign private packages. INSTEAD we’re asking for a way to stop Unity from warning about specific unsigned packages.

6 Likes

Not sure if Unity packages will ever become this important, but my employer & project got hit twice within a month and a half by manipulated packages (dependencies) in the python and linux world ( the second one: ttps://cloudsmith.com/blog/miasma-worms-path-of-destruction ). Both times at least a full workday loss for half the project employees to run clean and verification scripts and re-generate tokens etc.
So maybe it is indeed best to make signing simply standard so furher safety can be build upon that baseline.

1 Like

I’m sorry, but this doesn’t work for me at all.

I use packages as a way to separate my own code into pseudo libraries. Core utilities, XR helpers, and so on. The only projects these packages will be used in are mine. So I think it’s pretty ridiculous to make me sign my own private packages for my own projects.

Flag them as unsigned in the package manager if you want, but at least don’t stop me from using my own packages.

If I download a package from an untrusted source and add it to my own project as an embedded package, then that’s my risk to take. Not yours.

In addition to this, there have been multiple times I’ve had to copy an Unity package in as an embedded package so I could fix a bug (or extend or anything) in it for my own use case. I’d like to be not yelled at for this.

8 Likes

So by including an encrypted file with an org name and URL we can be sure it is safe?
It does seem just like an added annoyance in general.

The idea is somewhat logical, as long as long it is ignorable, but exactly how will it make things safer?
There is no payment to allow certification as with other platforms (will there ever be?), so does it really make it any more difficult to put out a nefarious package? Are there future changes planned?

Not sure how far that is in place yet, but the idea surely is that you can have a whitelist of signatures to only accept packages through an arbitrary distribution system that are actually from the intended authors.
E.g. a hacked distribution server should not be able to send you a manipulated version of the odin package.

Could you please create a video showing that easy process?

I create packages often to transfer parts of a scene or diagnose issues and having to sign every time I do is an unnecessary step.

But if the process is minimal and transparent maybe that is not an issue. So please show us.

2 Likes

That is also no guarantee of anything. It is so easy to issue anonymous payment instruments for small amounts these days. It gets cancelled very fast, but you have already issued the files you need with a script.

1 Like

Lots of great feedback here, thank you all for taking the time.

As they’ve grown over time, all large development platforms have gone down similar route in an effort to guide safer product decisions in increasingly complex ecosystems.

These are new workflows in the Unity editor, and although we’ve done due diligence to find the right signing solutions, there is always room for improvements. @spiney199, @Laicasaane , @BlackPete , @soleron, (also open to anyone else), can you please share your package creation workflows, and help us understand the difficulties signing will add to these workflows? Or are the concerns mostly about existing libraries of packages that you would now have to somehow batch sign?

Again, thx for all the comments, I’ve picked a few essentials below.

Don’t stop me from using my own packages.

You will always be able to use your own packages. Packages signed for your organization will load without any warnings, and will be considered fully trusted in your own projects.

What stops a bad actor from using the self-signing feature in the editor to sign a nefarious package?

@DragonCoder touched on this, when signed, packages are associated to the organization that signed them. No one other than members of Organization X will be able to produce packages associated with Organization X. Any packages distributed on Unity channels (asset store, our web site) will always come from publishers whose identities have been verified.

Outside of Unity channels, can a bad actor use a fake organization and sign packages in the ecosystem using that org? Yes. There will always be risk when picking up a product in the wider ecosystem. As a first step (Unity 6.3+), Unity creators will have access to the organization name that signed this package, to help verify authenticity, and Unity will be adding additional trust signals over time to help make these decisions safer.

I’ve had to copy an Unity package in as an embedded package so I could fix a bug

you will always be able to embed packages, and as of 6.3, we’ve standardized embedding through the addition of a “Customize” menu option in the package manager (“J” section) to automatically embed a package for development.

But if the process is minimal and transparent maybe that is not an issue.

@soleron , you can now create and export signed packages directly from the package manager. There is UX for it, and that is the easiest way. if you instead use github\gitlab, there’s a great step by step on OpenUPM on how to set up signing in CI\CD, most steps you will only need to do once (like retrieving your service account token from the unity dashboard)

2 Likes