Notepad++ v8.8.7 Release Candidate

donho

@PeterJones
I don’t remember that I’ve got this issue before.
Is https://download.notepad-plus-plus.org/ considered no more a safe URL by SmartScreen since when Notepad++ being signed by “non-legit” certificate?

xomx

@donho

Yes, it’s the Zone.Identifier ADS. One can always tell if look carefully at the UAC File Origin: field:

But I’m concerned here about something else. I wonder if/why we couldn’t overcome this “not-enough-reputation-for-the-SmartScreen” by the help of that new GlobalSign OV-cert. When I clicked on the UAC “Show information about the publisher’s certificate”, the only cert I see there is the N++ own self-signed cert - could you confirm? Maybe that’s the problem. The v8.8.7rc installer has both the N++ and GlobalSign one (I checked) but maybe for the UAC/SmartScreen is somehow relevant only one of them?

So how about another RC2 test with only the GlobalSign cert?
Or try to switch the order of your current signing (1st GlobalSign, 2nd N++ or vice versa).
Maybe then it wouldn’t trigger the SmartScreen (even with the Zone.Identifier ADS)…

donho

@xomx said in Notepad++ v8.8.7 Release Candidate:

So how about another RC2 test with only the GlobalSign cert?

Here you go:

With GlobalSign 1st, Notepad++ Root 2nd:
https://download.notepad-plus-plus.org/repository/8.x/8.8.7.RC2/

Only with GlobalSign:
https://download.notepad-plus-plus.org/repository/8.x/8.8.7.RC3/

For my tests, both don’t make any difference.

donho

https://download.notepad-plus-plus.org/repository/8.x/TEST4/

On my tests of 3 files downloaded from the above directory:

npp.8.8.1.Installer.x64.exe - Signed with digcert
vlc-3.0.21-win64.exe - Signed, downloade from the official website
npp.8.8.5.Installer.x64.exe - Signed with NppRoot

After downloading them from https://download.notepad-plus-plus.org/,

npp.8.8.1.Installer.x64.exe & vlc-3.0.21-win64.exe have no ADS, npp.8.8.5.Installer.x64.exe has Zon.Identifier ADS
3 of them are lauched without SmartScreen.

So I would say the release 8.8.7 just need the time to gain the trust.

xomx

@donho

I’ve got the same SmartScreen(SS)-triggering results with all the RC 1, 2 ,3 (in my testing VM, w/o internet access):

That’s unfortunate. Every info source about the SS I checked state that there is only one 100% way how to not trigger it in this situation - the EV-cert. For the new OV-cert there is a period in which it has to gain the reputation. I found an interesting real data about - if they can be trusted, installers with the new N++ OV-cert will need ~18 days and about ~430 app installations (the more installations, the fewer days and vice versa) before this annoying SS dlg disappears.

So to prevent another “is-it-really-safe?!” shitstorm from the users we can:

sacrifice ourselves and manually install and click on all our comps with active SS and internet connection (and ask also the Community users to do the same), before triggering the v8.8.7 for autoupdate
or you can try the 2nd advice for the app-owners in the MS FAQ: “Apply for a Windows Logo (To learn more visit the Windows Logo Program page on MSDN)”. But IDK what that would entail and if it would be 100% reliable against the SS.
or be proactive and submit new N++ installers to MS for analysis, try to use the 3rd “Software Developer - SW providers wanting to validate detection of their product” link from: https://www.microsoft.com/en-us/wdsi/filesubmission

donho

@xomx
“sacrifice ourselves” is a big word :)
We enjoy coding, making the application work, editing the documents, building the community & helping users - so we are here to have fun, not to sacrifice ourselves. At least, that’s how I see it.

It’s really not a big deal to have SmartScreen temporally, knowing it will disappear soon.
So I’d rather keep doing what I enjoy in this project, let the time resolve the issue, and avoid dealing with Microsoft’s annoying administrative task.

PeterJones

@donho ,

Additional datapoint: I had left my installed copy with having run either RC2 or RC3 yesterday, and when I ran today, I noticed that Plugins Admin wasn’t showing up. I double-checked, and none of the exe or dll had the MotW Zone.Identifier, but it wasn’t showing up. I reran the RC1 installer, and Plugins Admin showed up again.

I tried RC2 installer, and Plugins Admin disappeared, and RC1 fixed it.
I tried RC3 installer, and Plugins Admin disappeared, and RC1 fixed it.

I think there’s a mismatch in your safety check for Plugins Admin if someone uses RC2 or RC3 (or, at least, that’s my experience). So if you still release on Monday, please make sure you release from RC1 (or create an RC4 that is internally consistent again).

donho

@PeterJones
The binaries of below link was modified, now it should be OK.
https://download.notepad-plus-plus.org/repository/8.x/8.8.7.RC/

In short, the signing order of the first binary set in the above link is nppRoot then globalSign. The 2nd binaries set with signing order globalSign then nppRoot replaced the 1st binaries set. Then I realized the same issue you have discovered. So I ajusted the script to generate the 3rd binaries set (nppRoot then globalSign), and replace the 2nd binaries set with the 3rd one.

Why does signing order matter:
The Notepad++ internal component SecurityGuard checks only the first certificates it found in WinGUp & nppPluginList to compare the subject name, certificate number, etc… It should be enhanced, and I will work on it in the future.

The binaries in 8.8.7.RC directory should be good now.
Sorry for the inconvenience.

Snabel42

@donho can confirm that for me with this RC there is no download warning or SmartScreen triggered

xomx

@donho said in Notepad++ v8.8.7 Release Candidate:

The binaries of below link was modified, now it should be OK.
https://download.notepad-plus-plus.org/repository/8.x/8.8.7.RC/

Today used installer from the above link and I’ve got:

donho

@xomx
Well spotted!

With the signtool, I passed the argument /as to signed with both the first certif and the 2nd one - that makes the duplication signature on binaries when the script runs morn than 1 time.

I just fixed the script to pass /a to sign with the first certif and /as with the 2nd one.

More info:

/a          Select the best signing cert automatically. SignTool will find all
            valid certs that satisfy all specified conditions and select the
            one that is valid for the longest. If this option is not present,
            SignTool will expect to find only one valid signing cert.


/as         Append this signature. If no primary signature is present, this
            signature will be made the primary signature instead.

The explanation is not explicite for /a. In my experience, usage of this parameter removes all the signatures before signing with the certificate.

The problem of signature duplication is fixed in RC2:
https://download.notepad-plus-plus.org/repository/8.x/8.8.7.RC2/

edit: with some tests, it turns out that the argument /a does nothing for the first signing - without /a it still removes all signatures before signing.