DonationCoder.com Software > Skwire Empire
Release: sWeather (tray-based weather app)
Deozaan:
Jotti shows only a single false-positive for v1.8.2:
https://virusscan.jotti.org/en-US/filescanjob/2ouelcotx0
skwire:
I've been aware of sWeather for a number of years and am sure that skwire is a trustworthy developer, but is it possible that this file has been tampered with or are these all just false positives?-leftdisconnected (September 08, 2019, 12:40 AM)
--- End quote ---
I just downloaded it and checked its SHA-256 hash against my local copy. If you're downloading it from my DonationCoder site, it has not been tampered with.
SHA-256 hash: 33A19E4117DE230A0E9CBCF692BEEB4FEDC4075C8CA3001E91BB8C1AF1334779
Thank you for taking the time to write. These are false positives that come and are due to the language my applications are written in (AutoHotkey/AHK). In the past, as a test, I've written a single line AHK script and compiled it:
--- Code: Autohotkey ---F1:: ExitApp
That's it...one hotkey to exit the script. Even that wouldn't come up clean on VirusTotal. I know it's only my word, but I can state that there is no malware in any of my
applications that are downloaded directly from my site. That said, I cannot vouch for the various software repository sites that list my software as some of them wrap my software into their adware-bundled installers. This perturbs me, but there is little I can do about it. For the record, I do not submit my software directly to any of these types of sites; they pick my programs up automatically.
Years ago, when the AV companies were a lot fewer, I used to contact them about stuff like this. Things would get fixed but, due to the AV updates, false positives would, inevitably, occur again. I got tired of dealing with it, so now I just shrug and trust that my body of work speaks for itself. I know it sounds terribly apathetic, but fighting it just isn't worth the cycles anymore. Cheers.
leftdisconnected:
I just downloaded it and checked its SHA-256 hash against my local copy. If you're downloading it from my DonationCoder site, it has not been tampered with.
SHA-256 hash: 33A19E4117DE230A0E9CBCF692BEEB4FEDC4075C8CA3001E91BB8C1AF1334779
Thank you for taking the time to write. These are false positives that come and are due to the language my applications are written in (AutoHotkey/AHK).-skwire (September 08, 2019, 11:21 AM)
--- End quote ---
Thanks for the awesome response and verification. Your response and hash check serve as a record for future concerns, at least with this release. My hash indeed matches the one you've provided. It might be useful to list this hash in the download area on your official website, but this can convey false verification if a website is hacked (hackers may change the displayed hash to match their infected package).
I've also written AHK scripts and am aware that A/V tends to be scared of it, but was concerned for the following reasons:
1. 8+ engines still triggering more than 6 months after the release, including Microsoft's (though local Defender does NOT trigger).
2. No other posts asking about false positives with this release (there are usually lots).
I've been involved with a few projects and authors generally find that detectors "calm down" after seeing the same executable for weeks or months with no related impact (via whatever metrics are used). We also tend to have tons of questions about false positives, which inevitably surge with each new release, even for signed code (which rather undermines much of what I'm about to say ;) ).
Years ago, when the AV companies were a lot fewer, I used to contact them about stuff like this. Things would get fixed but, due to the AV updates, false positives would, inevitably, occur again. I got tired of dealing with it, so now I just shrug and trust that my body of work speaks for itself. I know it sounds terribly apathetic, but fighting it just isn't worth the cycles anymore. Cheers.
--- End quote ---
That's entirely understandable :up:. There are so many AV brands and engines that correcting false positives is an impossible task. Almost no one bothers with this anymore unless they're Mozilla or someone like that and in that case they're hopefully squashing those issues before mainstream release. However, I posted due to the combination of both a relatively mature release and no other false positive posts associated it. Thanks for clearing this up.
There are limits to what you are willing and able to do as an independent developer, but signing your code with your own certificate would be a possibility. If you keep the same signing cert over many years, it builds up a reputation to match your own. In other words, if you've signed it with a cert that has been established to be yours, then interested users can extend your reputation to your cert.
I've seen other projects that create a new signing cert for every major code release and that's just a waste of time and effort. With code signing, we want as long a certificate lifetime as possible to build its reputation. Sure, we can sign our new certs with our old one to create a chain of trust, but there's no reason that a modern signing certificate shouldn't be trustworthy for at least 5 years. Just MHO.
I'm not suggesting that you must sign your code as it's an extra hassle and 99% of users will never bother to check it anyway. Still, I'm a terribly unskilled programmer that mostly just creates bad scripts that nobody else needs, yet I sign anything I release. Even if only 1 user actually verifies it, that's a chance for someone to find out that my website/repository has been hacked, etc. After initial setup, each signature takes seconds to do.
I sound like a salesman here, but I'm not trying to convince you to do this. I'm just rambling about it for anyone who might be interested. OpenPGP is not a perfect system and I understand if developers don't believe that it's worth the effort. For example, most of the time I must download the signing cert from the very same website that I downloaded both the package and the signature from, which basically brings us back to the vulnerability of simply listing the hash; that's why long-term signing certs are so valuable.
Thank you so much for your time and attention and for creating and maintaining such useful software.
On a side note, I find it interesting that I can report my own post as SPAM :P . vvvvvv
mouser:
Welcome to the site, leftdisconnected :Thmbsup:
Your suggestions and reasoning are very reasonable. :up:
For installers, I highly encourage signing with a digital certificate; and with executables it makes a difference in how Windows displays them, and can definitely make people feel safer using them.
Your point about "It might be useful to list this hash in the download area on your official website, but this can convey false verification if a website is hacked (hackers may change the displayed hash to match their infected package)." is valid; for small scale websites that's pretty darn unlikely though. And one good alternative solution would be to post a hash value on a different server (like this forum), from the one hosting the file. Whether it's worth the hassle is another matter.. It does at least increase the likelyhood that someone would discover a tampered file sooner rather than later, which is always good.
Brothbeard:
I've noticed recently that the temperature reported via the Yahoo API is running up to two hours behind, which renders the app a bit pointless. E.g. it is presently 12:26 BST and the last provider update was 11:00 BST. Sweather is reporting 15C and other apps are reporting 17C. Refreshing doesn't help. Any ideas anyone?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version