Windows installer is not signed

[nielsvanvelzen]

Describe the bug The Windows installer is not signed causing Windows to prevent running the installer (unless you click on "Run anyway", which is hidden by default)

To Reproduce

1. Use Windows (I have Windows 10 1909)
2. Go to "Windows Security" app
3. Go to "App & browser control"
4. Make sure "Check apps and files" is not off
5. Download & run installer

Note: After accepting it once the warning will not popup again

Expected behavior Ideally the installer should be signed with a trusted authority so Windows trusts the installer

Logs No logs yet available

Screenshots

System (please complete the following information):

• OS: Windows 10 1909
• Browser: -
• Jellyfin Version: 10.4.3 (same issue on 10.4.2)
• Installed Plugins: -
• Reverse proxy: None

Additional context I think a lot of users that don't have a lot of technical experience that want to use Jellyfin would just not use it after encountering this warning.

[jtc42]

My understanding is that unless you distribute via the Microsoft Store, signing certificates cost a nontrivial amount of money, and even then will only remove this warning after a certain number of installs. Is this correct? I'm having the same issue with a work project, and so far we've found no good alternative to just paying money we don't really have to make a warning go away.

Perhaps this is something for the Open Collective page?

[anthonylavado]

@jtc42 Could you share any information links you’ve got? My understanding is that yes, it’s $$$$.

[jtc42]

I came across this for an electron app, so I first got information from here: https://www.electron.build/code-signing#windows

Microsoft docs seem to focus on drivers, but it seems to be the same, see: https://docs.microsoft.com/en-gb/windows-hardware/drivers/dashboard/get-a-code-signing-certificate?redirectedfrom=MSDN

An example certificate seller: https://www.digicert.com/code-signing/

[dkanada]

@jtc42 is it a one time fee or a licensing thing that would be a yearly cost or something?

[jtc42]

I haven't looked into it for a while, but IIRC they're almost all annual cost.

We found 2 alternative solutions. One, distribute through the app store. The whole process is free, but you do have to contend with extra limitations which may be an issue for Jellyfin. The other option is to distribute through something like Chocolatey.

If anyone knows of a different solution, I'd love to know, as well as it being useful directly to Jellyfin.

[anthonylavado]

I think there's someone that bundles us in Chocolatey these days, it might be worth setting up an auto-publish of our own at some point.

I looked into the licensing, and the cheapest was something like $366 USD/yr, and that doesn't even completely remove the warning... Suddenly Apple's $99 USD/yr sounds way more reasonable

[anthonylavado]

So at this point, solving this one costs money. Here's the article I read a while ago: https://comodosslstore.com/resources/what-is-microsoft-authenticode-code-signing-certificate/

We're easily looking at at least $300/yr, and that's even if we buy three years upfront. At least there are ways to accomplish the signing using Azure DevOps, but then that means moving our custom build process there. Here's some reference on it: https://www.twelve21.io/sign-a-dotnet-core-assembly-in-an-azure-devops-build/

Some more reference: https://mkaz.blog/code/code-signing-a-windows-application/

This item will be on hold until we can come to an agreement internally on it.

Edit: I totally forgot that we currently build the Windows installer for Jellyfin on Azure, so we could in theory do this.

[anthonylavado]

Looking at this again in 2021, it's still not a great situation. Apparently we can get either a reasonably priced individual certificate, or an EV certificate. Both will sign the code, but the individual certificate requires the software to reach an unspecified download threshold before it is trusted. This counter also resets with each release, so every update we issue would require building trust again. Only the EV certificate will bypass the initial trust mechanism.

The EV certificate also requires a hardware key, which means we wouldn't be building in the cloud, which is an issue for us to release easily in a distributed fashion (since we are all remote from each other).

That said, I don't think there's any easy way of bypassing this with our traditional install method. The only thing I could think of is trying to do some sort of "installer client" that is signed, and then that goes and downloads a payload with the next thing to execute. I think this is how Emby handles it right now, and I haven't looked at Plex in a long time (though they've probably ponied up for EV and do something to handle it).

Here's a recent-ish updated page on the whole thing: https://security.stackexchange.com/questions/139347/smart-screen-filter-still-complains-despite-i-signed-the-executable-why

[joshuaboniface]

That said, I don't think there's any easy way of bypassing this with our traditional install method. The only thing I could think of is trying to do some sort of "installer client" that is signed, and then that goes and downloads a payload with the next thing to execute. I think this is how Emby handles it right now, and I haven't looked at Plex in a long time (though they've probably ponied up for EV and do something to handle it).

This would explain how a lot of modern installers work. Maybe we should do this.

[EraYaN]

You'd think some of the installer vendors have solved this problem and it "should" be fairly easy. I know that for the WiX toolset version 3 this was a build-in feature basically with a bootstrapper that didn't really change and a web repo with some files on it and some hashes, I think you could even sign the hash file. Not sure if someone has solved this for NSIS. Might be worth a look.