ntfy: Add version 1.25.2

[kzshantonu]

• [ x ] I have read the Contributing Guide.

[rashil2000]

Manifest is fine but the archive is giving me a Trojan alert (Windows Defender)

[binwiederhier]

Oh my. Why would that be?! I just built this today (https://github.com/binwiederhier/ntfy/releases). Maybe because Windows hasn't seen it before? It's not signed or anything, maybe that's it?

[binwiederhier]

Okay, so the description is actually correct: It does allow executing commands (https://ntfy.sh/docs/subscribe/cli/#run-command-for-every-message), which is part of the appeal. So I'm not quite sure how to "fix" this...

[kzshantonu]

5/59 https://www.virustotal.com/gui/file/599803d469822e5288a6dc9e0c0eae960bd4af7a070d9aa9296b4888491ff00d

[binwiederhier]

This is the code that's likely causing this alert: https://github.com/binwiederhier/ntfy/blob/main/cmd/subscribe.go

[rashil2000]

You could try signing the release binaries, though I'm not sure if that'll fix the problem entirely

[tech189]

Microsoft Defender isn't flagging the zip or the exe for me. Even when manually scanning them.

[rashil2000]

It's still flagging for me on Windows 11 Build 22621.1

[binwiederhier]

I can look at this when I have some time, maybe later this week. I opened a ticket to track it. binwiederhier/ntfy#269

However, fundamentally this is what the subscribe command does. Idk how to overcome this, since it's a feature

[binwiederhier]

Apparently it is common for Go binaries to be flagged by virus scanners, so common that they dedicated a FAQ item to it: https://go.dev/doc/faq#virus

There's also a 5 months young Reddit post about it: https://www.reddit.com/r/golang/comments/rism9x/why_does_windows_defender_still_flag_gobinaries/

The bottom line is: There's nothing I can do about it. I manually re-read the code of subscribe.go, and it's injecting the environment variables from the remote message, NOT the command. So those scanners are all wrong.

I understand if that means you cannot accept the binary, and I'm okay with that. It's sad, but I'll like (and so will the ntfy users). You've certainly had this case before, what do you suggest?

[rashil2000]

Thank you for taking the time to look into this.

Just as an info, Scoop's installation of this package proceeds successfully. The warning arises when you try to run the binary after installation.

I built the binary locally (make cli-windows-amd64) and it works fine.

In these cases we usually ask users to just add an exception for the particular package in the antivirus settings. Users still require a baseline level of trust in order to add the exception, and hence I'd ask the authors to set up a CD/workflow in the repo to create and upload release binaries transparently and automatically (I see currently the releases are created and uploaded by the author himself).

[binwiederhier]

I can add a CI pipeline to build and upload. I wanted to do that anyway (binwiederhier/ntfy#36), so this is just one more reason to do it.

[binwiederhier]

The latest release is now entirely deployed from GitHub Actions:

• https://github.com/binwiederhier/ntfy/releases/tag/v1.25.0
• https://github.com/binwiederhier/ntfy/runs/6714244651?check_suite_focus=true
• https://github.com/binwiederhier/ntfy/blob/main/.github/workflows/release.yaml

If you scroll down there's a step "Print build results and checksums" which will contain the checksums from the built artifacts.

[rashil2000]

Turns out the latest release doesn't get flagged; the 1.24.0 release stopped getting flagged too. It's a bit intermittent:

@kzshantonu can you update the PR to the latest release?

[rashil2000]

/verify

[github-actions]

All changes look good.

Wait for review from human collaborators.

ntfy

• Description
• License
• Hashes
• Checkver
• Autoupdate
• Autoupdate Hash Extraction