search

jcsteh / osara

OSARA: Open Source Accessibility for the REAPER Application
GNU General Public License v2.0
127 stars 46 forks source link

Win 10 False Positive: Osara Installer Believed to Be a Threat #387

Closed MatejGolian closed 4 months ago

MatejGolian commented 3 years ago

After today's native Win 10 virus database update, Windows thinks that some Osara installers could potentially contain viruses. As far as I can tell the builds affected by this are pre 207 and 323, but maybe there are more. This issue does not affect the Mac versions.

ScottChesworth commented 3 years ago

Confirmed. What a PITA. Is there anything that can be done about this, @jcsteh?

chrisbelle2015 commented 3 years ago

I had to tell defender to leave the .exe alone, but it took me a minute to find that, will drive some folks nuts 'grin'.

On 11/22/2020 7:13 AM, ScottChesworth wrote:

Confirmed. What a PITA. Is there anything that can be done about this, @jcsteh https://github.com/jcsteh?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/387#issuecomment-731746569, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXSWCNPUISJ5UEAAKL7BR3SREFBHANCNFSM4T6LZ5HA.

-- Evolution violates the second law of thermal dynamics, as well as ignoring much of real science.

ScottChesworth commented 3 years ago

Where is that option found, @chrisbelle2015? I just temporarily disabled real-time protection or whatever they call it here, but would rather be advising folks how they can make OSARA an exception or whatever they call that.

jcsteh commented 3 years ago

Urgh. How utterly irritating.

The only thing I can do is submit this to Microsoft for analysis, which I've now done. However, I'm not an enterprise customer, so this isn't going to get high priority. Who knows how long they'll take to get to it, if ever.

Signing OSARA builds with a code signing certificate might decrease the chances that this happens in future, but it's not a sure thing. That might also eventually get rid of the Windows Defender SmartScreen warning, but that's not a sure thing either. Those certificates cost at least US$85 for 1 year (or US$212.49 for 3 years) from here. Given that I make no money from OSARA, I can't justify that cost, and it's hard to even drum up donations for it given the lack of certainty as to whether (or at least when) it will improve things.

ScottChesworth commented 3 years ago

are there any downsides to acquiring one of those certificate whatsits? Like, does it have any impact on the automated build stuff you've put time into lately? Assuming the answer is no, I can get the ball rolling, take a punt and front the cost for the next 3 years. Even if it's not gonna be an overnight change, my thinking is that surely it'll swing in our favour at some point during that period of time right?

jcsteh commented 3 years ago

No downsides, but there are two caveats:

  1. This is only relevant for Windows. Mac signing is a separate thing and requires a paid Apple Developer membership.
  2. For security reasons, pull request builds cannot be signed. So, snapshots would be signed, but not the test builds made for specific pull requests. Presumably, users testing pull request builds are a bit more savvy, so that shouldn't be a problem, but I thought it worth noting.

That said, it does seem like a controversial use of your hard earned cash, especially given the caveats and the lack of certainty around all of this. If we had a regular donation stream, I'd definitely recommend we use some cash for this. Otherwise, I find it very hard to justify the recommendation.

ScottChesworth commented 3 years ago

it does seem like a controversial use of your hard earned cash, especially given the caveats and the lack of certainty around all of this. If we had a regular donation stream, I'd definitely recommend we use some cash for this. Otherwise, I find it very hard to justify the recommendation.

Note that I used the word "front" though, not the word pay. I'm pretty sure I'll be able to collect at least some of it back from community donations over time with a running total in my sig on RWP, could also perhaps collect a contribution toward the cost from Gianluca's GoFundMe campaign so long as you don't have any objection to that? I wouldn't mind taking a bit of a hit if those ideas don't recoup the full cost. OSARA is worth it. Potentially lightening the RSI (repetitive support irritation) is also worth it. :)

jcsteh commented 3 years ago

Microsoft just got back to me. 😲 Apparently, they have removed the false detection. However, I guess it might take some time for the update to roll out to everyone. And while they've fixed it for one file (the latest OSARA version at time of writing), it's anyone's guess as to whether future OSARA installers might be falsely detected.

ScottChesworth commented 3 years ago

I've removed my local exception and Defender doesn't seem to be scared of the latest snapshot, so guess we're good for now.

MatejGolian commented 3 years ago

Thanks Scott, good to know.

2020-11-23 14:38 GMT+01:00, ScottChesworth notifications@github.com:

I've removed my local exception and Defender doesn't seem to be scared of the latest snapshot, so guess we're good for now.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/jcsteh/osara/issues/387#issuecomment-732167163

ScottChesworth commented 3 years ago

Had another report from a user who's getting a false positive from Defender when installing OSARA pre-340. It persists after updating their Defender definitions, too. @jcsteh, can you either do the Microsoft honors or tell me how it's done?

jcsteh commented 3 years ago

It'd be good if we can verify that more than one user is seeing this. Windows Updates sometimes roll out bit by bit, so I wouldn't want to submit this and have it bounce because it turns out the latest definitions do in fact have the update.

jcsteh commented 3 years ago

For reference, I submitted the file using the Microsoft Submit a file for malware analysis page. You need a Microsoft account to do this. I submitted as a developer, but you can also choose to submit as a home user.

jcsteh commented 3 years ago

Anyone still experiencing this? I just installed OSARA on a completely different Windows 10 machine with Defender a few days ago and didn't hit this problem, which leads me to believe it's been resolved.

ScottChesworth commented 3 years ago

Just had a fresh report of OSARA 2020.1pre-387,adf0f3ae download being blocked by Windows Security when attempting to download using Firefox. I'll submit to Microsoft now.

MatejGolian commented 3 years ago

I'm wondering, Would it be possible and a good idea to also provide the option to download the built DLLs and maybe even other files like the keymap manually in addition to the installers? I was just thinking that having a fallback option would be good for cases like these, since it seems that it's just the installers Windows has problem with (thank God it's not the DLLs themselves). So, yeah, I'm suggesting something very similar to how we had it before the installers, but just as an extra option. Would it perhaps be possible to automatically bundle everything inside a ZIP file? This last thing may not actually be such a good idea - just thinking here... Anyway, what do you think?

2020-12-13 15:39 GMT+01:00, ScottChesworth notifications@github.com:

Just had a fresh report of OSARA 2020.1pre-387,adf0f3ae download being blocked by Windows Security when attempting to download using Firefox. I'll submit to Microsoft now.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/jcsteh/osara/issues/387#issuecomment-744017033

ScottChesworth commented 3 years ago

@jcsteh would have final say on this obvs, but from here, I'm not sure who it'd help. Advanced users are likely already comfortable allowing OSARA in Defender's interface, newbies probably aren't gonna be comfortable placing files manually, and tbh I'm not comfortable with anything that's likely to increase the amount of support required to get up and going.

MatejGolian commented 3 years ago

Thinking about it, you're likely right Scott. Either way it's all fine for me personally as both my download folder as well as my Dropbox one are whitelisted.

2020-12-13 20:17 GMT+01:00, ScottChesworth notifications@github.com:

@jcsteh would have final say on this obvs, but from here, I'm not sure who it'd help. Advanced users are likely already comfortable allowing OSARA in Defender's interface, newbies probably aren't gonna be comfortable placing files manually, and tbh I'm not comfortable with anything that's likely to increase the amount of support required to get up and going.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/jcsteh/osara/issues/387#issuecomment-744054886

ScottChesworth commented 3 years ago

For what it's worth, Microsoft were very quick about sorting it this time around too. Took less than an hour for them to confirm. An annoyance that I'd still like to avoid, but workable if things stay this way for a while I guess.

LeonarddeR commented 2 years ago

I haven't seen any reports of this lately. I guess we can safely close this issue. We can always reopen if it pops up again.

jcsteh commented 2 years ago

This does seem to be an ongoing issue. I did a bit more digging on Authenticode signing and found this thread. Tl;dr: it's still not a sure thing, but it looks like even though it still takes time for apps to develop a positive reputation, once they do, the certificate eventually (years?) gains a positive reputation and future apps signed by that certificate will inherently have a positive reputation:

  1. An OV certificate thumbprint takes a very long time to gain reputation (it could be years, plural!)
  2. Apps can also establish a reputation of their own, and according to Microsoft Security intelligence, once they've attained that reputation (through downloads) then SmartScreen should not flag them with a warning.
  3. An app that has established a (positive) reputation and is signed by an OV certificate whose thumbprint has not established a reputation WILL result in a SmartScreen warning.
  4. Any app, with or without an established reputation, signed with an OV certificate whose thumbprint has established a reputation will NOT result in a SmartScreen warning.
  5. Most importantly, apps establish a reputation based on downloads (and their hash), which means that updates to the app will not have the same hash (and therefore will not have /inherit a/the reputation).

Of course, a lot of this is educated guesswork on the part of developers, since Microsoft refuse to release any actual guidelines on how this stuff really works.

It feels pretty crappy to spend US$70 to US$85 a year of donations to fund this. On the other hand, it's pretty confronting for users to see these warnings.

My current feeling is that it might be worth taking a gamble and buying a certificate for a year or two to see if it helps. If it does, we can consider whether it's really worth it on an ongoing basis.

ptorpey commented 2 years ago

Considering issue #5, it doesn’t seem like there is much one can do about avoiding this problem:

“#5 Most importantly, apps establish a reputation based on downloads (and their hash), which means that updates to the app will not have the same hash (and therefore will not have /inherit a/the reputation).”

The problem only seems to occur for certain builds. Mostly there is no problem downloading the Osara builds. Don’t know why one build looks different than another from the standpoint of downloading.

Also, it isn’t too difficult to unblock the download if one is aware of the problem.

--Pete

ScottChesworth commented 2 years ago

As above, I'd fund certification if it's likely to improve the situation. I'm reading point 5 the same way Pete has though, seems like that might be a showstopper given that we're snapshot based, no?

jcsteh commented 2 years ago

Assuming this is correct (and again, it's hard to be sure because Microsoft doesn't publish real documentation), point 5 is superseded somewhat by point 4 (I feel like they're in the wrong order):

  1. Any app, with or without an established reputation, signed with an OV certificate whose thumbprint has established a reputation will NOT result in a SmartScreen warning.

The key point here is that once the certificate gets a good reputation (which takes longer than an app, potentially years), apps signed by that certificate don't need to gain their own reputation to avoid the warning.

ScottChesworth commented 2 years ago

Ah, so if I'm understanding it right, the certificate and its thumbprint are attached to you as the developer instead of OSARA itself?

jcsteh commented 2 years ago

The thumbprint identifies the signature and all snapshot builds (but not pull request builds) of OSARA would be signed with that signature. The signature would include info about me as the developer. It's tied to me only in the sense that it includes my name and because only I have the private key and thus the ability to sign things with it.

ScottChesworth commented 2 years ago

Gotcha. Sounds like it's worth a shot. I'll hit you up when you get back from your break to sort out funding.

jcsteh commented 2 years ago

I'm happy to use some of the funds Gianluca sent my way from the Christmas fundraiser. If this does work out and we want to continue this indefinitely, we'll figure out ongoing funding then.

jcsteh commented 7 months ago

I looked into this again today after more Defender nonsense.

Those [Authenticode signing] certificates cost at least US$85 for 1 year (or US$212.49 for 3 years) from here.

Well, these certificates are now USD$313.50 per year. To make matters worse, as of June 2023, you are now required to store all Authenticode certificates on a hardware token, which means we wouldn't be able to sign AppVeyor builds automatically.

SSLPoint seems to have cheaper certs at USD$179 per year which also include cloud-based signing, avoiding the issue of the hardware token. However, we still can't use this on AppVeyor. It has to be installed on a local machine and requires manual intervention.

As far as I can tell, the only thing that will work for us might be ssl.com's eSigner service, which costs USD$180 per year, plus we'd need to purchase an ssl.com Authenticode certificate for USD$129 per year, totalUSD$309 per year.

This is all utterly ridiculous.

RDMurray commented 6 months ago

I just found SignPath for Open Source projects They provide free signing with appveyor integration. It's probably worth a try? They have several projects listed that are using the service that we could reach out to regarding their experience and if it helps with Smartscreen and Defender.

I sent them an enquiry by email. I'll let you know when I get a reply.

jcsteh commented 6 months ago

Very nice find! Certainly looks like it's at least worth a shot.

You can only sign after an AppVeyor build job has completed, which might make things a bit tricky for uploading/storing signed artifacts and indexing snapshots. That also means it'll be tricky to sign the dll, though that might not be that important. Signpath supports deep signing, which unpacks, signs and repacks automatically, but I don't think NSIS is supported for that.

jcsteh commented 6 months ago

An additional restriction with SignPath open source is that all signatures need to be manually approved. That's not going to work so well given that we just distribute snapshots.

jcsteh commented 6 months ago

I'm guessing SWS and ReaPack aren't signed? How are users dealing with that?

ScottChesworth commented 6 months ago

Neither of those are signed. However, I've never seen them causing false positives here, or heard about it happening on groups where everyone is using OSARA. No clue what the difference is.

jcsteh commented 6 months ago

Ah, this is interesting. SWS downgraded to NSIS 2.46, apparently because it caused less false positives with virus scanners. Obviously, we'd still get smart screen complaints, but maybe less quarantine.

jcsteh commented 6 months ago

And ReaPack is distributed as a dll, so they don't have an installer to contend with.

ScottChesworth commented 6 months ago

How much work would it be to try the same version of NSIS that SWS are using?

jcsteh commented 6 months ago

I'm not sure. I'll look into it when I get some time/sufficient inclination. :)

jcsteh commented 6 months ago

If it's just a matter of downgrading, probably easy. However, it's possible it will break our NSIS script and we'll need to tweak it, in which case... who knows.

jcsteh commented 6 months ago

How much work would it be to try the same version of NSIS that SWS are using?

This is merged now, so I guess we'll see what happens henceforth.

jcsteh commented 4 months ago

Two months after the change. @ScottChesworth, how are we doing here? Can we close this?

ScottChesworth commented 4 months ago

I'd say we're in the clear. Since changing to earlier NSIS I've still seen Defender requiring a scan from time to time, but in all cases I've encountered the scan has completed, users have received notification of what's happening but haven't been required to take any manual action. Much much better. We do still get blocked by some browsers, but I think that's a separate issue, so closing this one. Thanks!