usebruno
Windows blocking installs of 1.40.0
I have checked the following:
- [x] I have searched existing issues and found nothing related to my issue.
This bug is:
- [x] making Bruno unusable for me
- [ ] slowing me down but I'm able to continue working
- [ ] annoying
Bruno version
1.40.0
Operating System
Windows 11 Enterprise 10.0.22631
Describe the bug
Windows is preventing installations of 1.40.0 at the moment. See attachment.
.bru file to reproduce the bug
Try to install application on a recent version of Windows when downloaded from the bruno site.
Screenshots/Live demo link
This is a feature of Windows and its smart screen feature. When you download files from an external source, especially zip files, executable files, installers, etc, Windows adds something called an “Alternate Data Stream” to the file, more commonly known as “Mark of the Web”.
After downloading the file, right click the file and choose properties. If you trust the file, check the little “Unlock” checkbox and hit ok. You can run it normally then.
Trusted certs for signing files helps but in general this is a Windows decision and most likely more stringently enforced inside an enterprise.
I can replicate this for 1.40.0. Point to note that this isn't happening for the 1.39.1 release in the same system where I tried to open the 1.40.0 application. Issue seems to be specific for the latest 1.40.0 release
Our Windows Signing Certificate got expired earlier this month and we are using a new Certificate for Windows Code Signing. I believe it will take some time for the warning to go away as Windows Defender would trust the new certificate after a certain number of installs.
It's still happening on all Bruno installs post 1.39.1. It presents an issue in corporate environments where you do not necessarily have the ability to override these OS features that block installs. I've reported several times that the install is "safe" to Microsoft, although not sure how many times MS expect it to be reported as safe, or how much merit they give my reports. It's a real shame as >=v2.0.0 dramatically improves the OAuth 2.0 workflow.
Apologies @deenairn
We are working on upgrading to an EV certificate via Digicert for Code Signing as well as submitting to MS Defender to unblock this issue. This is planned to be completed within the next 2 weeks.
Hey @deenairn, @mattisking, @j0hnrj,
We have fixed this issue on our latest versions by adding the DigiCert EV Code Signing certificate to sign our .exe file. Can anyone confirm whether the bug is still present on the machine? Otherwise, we think the issue is good to close
Closing this issue.
@deenairn @mattisking @j0hnrj Please reopen if this issue persists.