Closed CodeCharm closed 2 years ago
How about just skipping the defender message and installing it normally?
On Thu, Jun 25, 2020 at 10:02 PM Huân notifications@github.com wrote:
How about just skipping the defender message and installing it normally?
Yes, that works just fine on Windows 10 (once you tell Defender to bypass/ignore it). Assuming that you want to trust it, which I think was the issue Alan had (and that's a fair thing). I'd report any deep-sixing of the machine via Natron and Microsoft channels, since, at worst, it just shouldn't run and give some kind of error (either Natron or the OS). I've also been using it on macOS X (Mojave). Runs all the OpenFX/OFX effects I need to use.
Paul
Hi,
I don't use or test sandboxing, so can't help you there. The binary works on a normal setup.
The defender warning is a "known issue", this happens since we don't sign the installer.
I understand why the warning happens. Ignoring the warning is a lot like grabbing an ELF from the Internet and running it with sudo without checking the SHA-256 at all. You're putting a whole lot of trust into some bits without any real ability to validate that you're getting the actual thing you meant to get.
If you are okay putting that much trust into things without caring whether you can verify the authenticity, then it turns out it's your lucky day: my uncle was a bridge architect and after he died, through some clever legal maneuvering in his will, he left me the actual deed to the San Francisco-Oakland Bay Bridge, which I need to sell right away for a fraction of its real value so that my sister can get an extremely expensive operation to replace part of her spinal cord. You could make a fortune charging cars a toll to drive across it! Make me an offer.
I'm sorry -- I don't mean to be a jerk. But part of my job is telling customers that they have to be more careful about what they install, and how they can take simple steps to protect themselves.
I certainly do appreciate that code-signing certs can be expensive and that this is a FOSS app, but I am at least going to do a reasonable check on that code before I let it take control of my machine. Hopefully, the Natron contributors could someday solicit some funding or a sponsor to get a code-signing cert.
Until then: If it is safe enough to run on my base system, it really should also run correctly inside the sandbox (it's basically a Windows Container, of a sort), or else fail gracefully. Simply telling users to ignore the issue that it can take the host down when it is run in the sandbox and just install it normally -- because nobody would ever mislead me on the Internet, right? -- well, it might not be the best way to instill trust that the code will not do bad things.
Right now, the only way I'd run the setup normally on Windows is if I were to set up a VM on an isolated network. That's more trouble than it's worth for the time being, even though I really like what I'm seeing on the feature set and the demos.
I'm willing to share diagnostic logs, etc., from anyone who would like to look into this issue. I am afraid I don't have the bandwidth to learn the code well enough to troubleshoot it myself.
I understand why the warning happens. Ignoring the warning is a lot like grabbing an ELF from the Internet and running it with sudo without checking the SHA-256 at all. You're putting a whole lot of trust into some bits without any real ability to validate that you're getting the actual thing you meant to get.
But part of my job is telling customers that they have to be more careful about what they install, and how they can take simple steps to protect themselves.
A certificate will not change that. Anyone can buy a cert and sign some binaries, it does not mean they are safe. We can list checksums for the files on our website/github if wanted, but that's as far as I'm willing to take this. Paying 100$+ a year to add some magic bits to the binary so users feel safe is not something I care about.
If users wants signed binaries they can buy a cert and "donate" it to Natron, that's the only way signing will happen. Also note that certs don't always work as intended, see https://getimageview.net/2020/06/02/microsoft-defender-smartscreen-is-hurting-independent-developers/
And on a final note regarding trust: Everything in Natron is open, the code, the build process etc. Users can review/study how everything is made, you could even build your own binaries....... But if you don't trust the binaries you can't really trust the source code either, since it's the same team that does both.
Simply telling users to ignore the issue that it can take the host down when it is run in the sandbox and just install it normally -- because nobody would ever mislead me on the Internet, right? -- well, it might not be the best way to instill trust that the code will not do bad things.
I said I don't use or test sandboxing, I didn't say you should ignore the issue..... It means running Natron in a sandbox on Windows is "unsupported"/untested, It might work, or it might not. If you provide me with a error, output or something I might look into the issue.
Because NukeX NC doesn't allow plugins, I tried NukeX trial on my sandbox (Sandboxie) to make it forever, and then I installed the BorisFX Silhouette plugin for it. Everytime I ran the plugin in NukeX, it crashed.
Natron has many built-in plugins inside. Any stable and "safe" software may have a chance to crash in sandbox, even Nuke.
If you want to confirm, try the NukeX with BotisFX Silhoutte Paint trial in your sandbox. Turn on allow trial mode for plugin in NukeX preferences.
A certificate will not change that. Anyone can buy a cert and sign some binaries, it does not mean they are safe. We can list checksums for the files on our website/github if wanted, but that's as far as I'm willing to take this. Paying 100$+ a year to add some magic bits to the binary so users feel safe is not something I care about.
I would appreciate the checksums.
If users wants signed binaries they can buy a cert and "donate" it to Natron, that's the only way signing will happen. Also note that certs don't always work as intended, see https://getimageview.net/2020/06/02/microsoft-defender-smartscreen-is-hurting-independent-developers/
I read the article. It's a little misleading. But I'm trying to stay on topic -- see the bottom of this reply.
And on a final note regarding trust: Everything in Natron is open, the code, the build process etc. Users can review/study how everything is made, you could even build your own binaries....... But if you don't trust the binaries you can't really trust the source code either, since it's the same team that does both.
This issue was originally about whether it runs in the Sandbox or not. I plan to try it again with the GPU virtualized into the container -- the default behavior is that the container runs with vGPU disabled, and the container will only expose WARP features to the app.
I said I don't use or test sandboxing, I didn't say you should ignore the issue..... It means running Natron in a sandbox on Windows is "unsupported"/untested, It might work, or it might not. If you provide me with a error, output or something I might look into the issue.
I will share what happened after I try it with the vGPU enabled.
Regarding signing -- I'm currently checking with colleagues about our recommendations for the future of software delivery, and when I hear back, I will create a new feature request issue (and might even be able to contribute).
There are currently two possibilities I'm thinking about, and neither of them require $100+ magic bits.
Package the binaries for the winget package manager and publish the manifest to the winget repository. Winget is in preview, so it might change a lot before going live. All free and easily automatable.
For $19 (lifetime, not annual, and if this is what you want to do, I'll fund you that $19) get a Microsoft Partner Center account, package the app with MSIX (that might require some changes to pass the certification process), and publish it through the Microsoft Store. This is basically what the Blender Foundation does. The code is digitally signed by Microsoft for you with your publisher name.
Both of these possibility include a verification step that looks for malicious code, so having your app in either location means something more than just having a checksum.
Also, note that Apple and Microsoft try to make you believe that unsigned code is unsafe, by adding all those "Are you sure?" dialogs, but this is just wrong. You can't tell if a software is safe by its signature. You can tell by looking at its source code.
Were Facebook's certificates revoked after the Cambridge Analytica scandal?
I'm too old to get drawn into a bit-measuring contest. Non-technical users don't have the skills to choose to download and compile the source. It's a really bad idea to train them that it's okay to download anything from the Internet as long as there is a padlock on the address bar. They don't know how to make sure they are on github.com and not on githuᖯ.com (yep; those are different). I never said code signing affords total protection; I suggested that it can increase the level of protection that the OS can provide.
At the very least, someone could have suggested adding a link from the Downloads page to https://www.virustotal.com/gui/file/971a54f739da509b078864359028677e024ba400b863c88665889cf19b284318/detection, but instead, it seems like everyone just want to pile on about how much of a dope I am for thinking that any of this matters.
I'm just about done caring about even trying this program.
We have a website with download links, most users understand how that works.
Anyway, We have a request for winget support (#511), something I will look into when I get the time (end of month probably). Other than that I have no plans to sign anything.
I just wanted to try out Natron for the first time. Because the installation exe is not signed with a code-signing digital certificate, Windows Defender SmartScreen complains about running it, I opted to install version 2.3.15 in Windows Sandbox on my Surface Pro with 16GB, freshly booted, to see what would happen. The installer ran without errors, but on first launch, I saw a console window open for about 2 seconds with about 3 lines of normal-looking output, before the host (the Surface Pro) basically goes into a non-usable state and must be powered down and rebooted to recover. The primary video turned off, as well as a secondary video monitor, and does not get restored. The Sandbox normally will prevent that sort of thing from happening, so this might be an issue for Microsoft to look into, but I thought I'd let you know it happens.