In brief: digital signing is hash+timestamp+certificate. It's a must for drivers and software installers in newest Windows versions.

If the installer is digitally signed then the verification (hash checking and certificate validating) can be made automatically by your antivirus (internet security) software, by the Windows, and finally by the installer itself when you run it. Providing hashes is required only when files aren't signed, f.e iso images, archives (zip, 7z, rar etc.), pictures etc.

Note that many software developers provide digitally signed archives, but such signing usually is not defined by archiving standards so 7-zip archiver always displays warning "There are some data after the end of the payload data" in such cases. There may be the same warning also for digitally signed documents, if their standard base on zip files.

You can also check timestamp of digital signature and use it to set proper file date even if the server always uses current date.

Finally, do you calculate SHA-2 hashes when you know that MD5 and SHA-1 aren't trusted any more? If not, then your checking looks like some kind of magic, fake rather than real action.

i have gone ahead and used process explorer to see what is causing this and found a thread with the file: iaStorAfsServiceApi.dll is the cause i rolled back to a precious intel sata driver but it is still present don't kow at what exact version it started really screenshot:

Usher wrote:In brief: digital signing is hash+timestamp+certificate. It's a must for drivers and software installers in newest Windows versions.

If the installer is digitally signed then the verification (hash checking and certificate validating) can be made automatically by your antivirus (internet security) software, by the Windows, and finally by the installer itself when you run it. Providing hashes is required only when files aren't signed, f.e iso images, archives (zip, 7z, rar etc.), pictures etc.

Note that many software developers provide digitally signed archives, but such signing usually is not defined by archiving standards so 7-zip archiver always displays warning "There are some data after the end of the payload data" in such cases. There may be the same warning also for digitally signed documents, if their standard base on zip files.

You can also check timestamp of digital signature and use it to set proper file date even if the server always uses current date.

Finally, do you calculate SHA-2 hashes when you know that MD5 and SHA-1 aren't trusted any more? If not, then your checking looks like some kind of magic, fake rather than real action.

While that is true, the way to achieve that check is only *after* the installation is complete. Since there is no archive here of previous versions, and I had to revert to other sources to obtain a version that actually performs what I expect it to. And having a SHA 256 / SHA 512 (which are what I am able to reasonably check on my ancient machine) are what I do myself, unless only SHA1 / MD5 are provided.

Obviously, the optimal solution would be to provide links to previous versions so there would be no need for hashes for files I obtain from here. And, in retrospect, keeping installation files has always been my method of storing, but somehow I ended up deleting my copy of the 64bit version of the installer for 6924.

Never fear, though, the one I found online was not manipulated in any way that is discernible, as the digital signature did not throw any sort of errors upon installing it.

I only mentioned it since the ongoing process has been to only keep the current version available for download, as an alternate means to allow the end user to know prior to install that the downloaded file is, in fact, the same as was originally posted here.

Nothing more.

johnlgalt wrote:While that is true, the way to achieve that check is only *after* the installation is complete.

I'm afraid we are talking about different things. What check after the installation do you mean?
You don't need to install anything to check the installer validity, just finish downloading and go to the installer folder. Hover your mouse on the installer and you'll see its basic properties, right click the installer file, select properties from the context menu and you'll see more advanced options. If the installer has neither proper version number nor certificate, it's suspected and should be scanned by antivirus/antimalware (if your security software doesn't scan all downloads automatically).

there is something sketchy about intel's RST drivers as of late:
v16.7.9.1027
v16.7.7.1023
they were the direct cause for this that dll was added in those versions above reverted to 16.7.1.1012 and all back to normal now, sorry for troubling you.

Usher wrote:

johnlgalt wrote:While that is true, the way to achieve that check is only *after* the installation is complete.

I'm afraid we are talking about different things. What check after the installation do you mean?
You don't need to install anything to check the installer validity, just finish downloading and go to the installer folder. Hover your mouse on the installer and you'll see its basic properties, right click the installer file, select properties from the context menu and you'll see more advanced options. If the installer has neither proper version number nor certificate, it's suspected and should be scanned by antivirus/antimalware (if your security software doesn't scan all downloads automatically).

My mistake - I thought you meant FDM executable was signed, not the installer itself. Whole different ballgame.

Yes, with that installer itself being signed I should be good to go.

Thanks!

The latest build of a couple days ago [2018-11-21ish] seems to run fine on my iMac with Mojave [10.14.1].

Hello,

Since updating to macOS 10.14.1 (Mojave), FDM is not downloading files correctly. For example, ZIP archives download as corrupt and most downloads are shown to over-download and never stop (eg. 430% downloaded).

Has anyone else experienced this?

IAMACLONE wrote:Has anyone else experienced this?

It looks like you are connecting through some broken proxy or other network caching/monitoring tool, see older messages:
search.php?keywords=proxy&terms=all&author=Usher&sc=1&sf=all&sr=posts&sk=t&sd=d&st=0&ch=1000&t=0&submit=Search

Usher wrote:It looks like you are connecting through some broken proxy or other network caching/monitoring tool

How so? I may have still been temporarily connected to a proxy required by my employer when I submitted a question originally. Is that what you meant?

IAMACLONE wrote:Since updating to macOS 10.14.1 (Mojave), FDM is not downloading files correctly. For example, ZIP archives download as corrupt and most downloads are shown to over-download and never stop (eg. 430% downloaded).

Hello,

I fixed the problem by reinstalling FDM on my MacBook Pro. It was a MacOS update issue, which could be isolated to just me unless someone else experienced this.
​
​[note] When I updated to Mojave 10.14.1 on my iMac and MacBook Air, the same thing happened - FDM stopped working and I had to uninstall FDM using AppCleaner (https://freemacsoft.net/appcleaner/) and then reinstall FDM on each device. Something about the latest MacOS 10.14.1 update caused issues.

FDM 5.1 works great again.

from http://www.freedownloadmanager.org/features.htm

Portable mode

If you want to use Free Download Manager on different computers, you can easily create its portable version and avoid the need to install and configure the program on each computer.

Yet there are no instructions how to do this, no link to instructions, and no reference as to if it relates to one or both versions of FDM.

thanks

Do read more carefully, please. It's clearly stated above that the portable version is "Special for version 3.9".

Just updated to v5.1.37 [build 7292) from app ?!?
Thanks

Why new FDM 5.1 builds are still provided with old Firefox WebExtension ver. 3.0.11? It may be a source of problems when updating to fdm_ffext2…