As always,
HaRT, appreciate your pointers (and your response speed

which I am unable to meet

).
Thanks,
John Doe, for clarifying that stable build is not anything special.
And I'm glad to see response even from
DrKnS, touching on all points.
I won't response to everything at once now. Will return to it later.
HaRT wrote: Fri 13 Mar, 2026 20:26
A very minor thing compared to other legitimate issues you raise
Regarding extra side question, which strictly speaking should be possibly posted in
General www.farmanager.com Discussions, but it felt sufficiently related that I decided to ask it here without creating yet another topic. Whether having SHA-256 (or any other strong cryptographic hash) readily available for user consumption is a minor thing or not - is a debatable thing.
First and foremost it increases supply chain transparency, which is always good, especially for open source projects. Official download page providing checksum needs to be updated if binary has been changed, typically as part of release process.
One can notice changed hash (just by having snapshot of older version of the page) without even downloading binary.
(Believe it or not, there are applications out there that silently update binaries for unstated reasons. Typically such applications never share checksums of their binaries on their homepages.)
HaRT wrote: Fri 13 Mar, 2026 20:26
What kind of situations are those cryptographic checksums going to help prevent? For MSI/ZIP/PDB packages hosted on the same site as the HTML downloads page, what is the benefit of adding these long non-human readable strings? If a MITM can tamper with the files being downloaded, they can easily patch the checksums on the page itself too (neither is easy with SSL/TLS though).
Right now official site for Far Manager and official store for Far Manager builds indeed happen to be served from the same HTTP server, at least on the outside (it does not necessarily needs to be true inside the infrastructure as there can be reverse proxy). It's true that in such scenario compromised HTTP server or MITM attacker could serve both modified binary assets and modified HTML pages, but I disagree that from that we should infer that increasing transparency is pointless. Requiring two places to be altered may be harder to perform depending on the attack surface and method.
There are also cases where one may unknowingly live on a compromised system, where files are modified
after locally downloading/etc. Being able to check hash and verify it with known truth (assuming uncompromised HTTP server) is extremely useful. There is also plain case of bit rot and bitflips which are more common nowadays due to more sophisticated HW - without relying on filesystem having features to detect them (e.g. via internal checksums of all blocks, not just metadata), these silent corruptions can go unnoticed. If you have content and hash of it captured at the time of generation/upload, you will be able to detect it, because probability of bitflip in content and at the same time necessary bitflips in textual form of the hash to make both match is abysmally small and not realistic.
Hashes of downloadable artefacts gives verifiable integrity as long as channel where hash is shared can be trusted. This is a basic step toward supply chain transparency and usually relatively easy to add.
DrKnS wrote: Fri 13 Mar, 2026 21:53
it's pointless. HaRT already explained why.
I hope I am already convincing you it is not pointless. I will expand further:
The next step is verifiable authenticity of downloadable artefacts. This is a bit more involving. Typically done with digital signatures utilizing asymmetric cryptography, i.e. private and public keys - list of hashes is signed using private key, and public key is public, so everyone can verify the list of hashes (its authenticity and integrity, thus transitively authenticity and integrity of files those hashes are related to). Very limited number of people should have access to private key, it should be protected and it should not be stored on the same machine that serves artefacts for obvious reasons. Public key should be also stored outside, which is handled "automatically" if one relies on PGP/GPG solutions. Then even compromised HTTP server is not able to serve modified hash list, because they don't have the private key, so different key needs to be used and that would raise everyone's eyebrows if planned key change was not notified ahead of time. This is much better than serving hash, but requires additional effort and procedures. That's why I did not
start with that, even though it should be
the goal.
There is another step (previous one was done with right leg, one could say, this one can be done with left leg) verifiable authenticity of installed/executable artefacts.
HaRT wrote: Fri 13 Mar, 2026 20:26
What could give some real added protection is digitally signing the packages, but it's a totally
different story.
This is typically even more involving. It gives ability to check the state of main executable, its authenticity and integrity, which is good, but it is insufficient. It does not protect you from cases like extra malicious DLL shipped along. There is very recent example of that:
https://www.malwarebytes.com/blog/threat-intel/2026/03/a-fake-filezilla-site-hosts-a-malicious-download
Self-replying to:
przemoc wrote: Fri 13 Mar, 2026 19:22
3. What is the origin of binaries for stable/nightly builds available at Far Manager Official Site : download?
(do they come from CI/CD like AppVeyor, Azure, GitHub Actions and in which toolchain variant (like builder+compiler), or are they built manually by some developers and in what configuration?)
Based on
translated using Google Chrome's Translate to English:
ctapmex wrote: Thu 11 Apr, 2024 06:22
The build on the "website" is performed on a stable environment managed by the developers. It likely hasn't changed recently (a year or more).
The build agents on GitHub aren't stable in content. The compiler and environment versions there are updated very, very frequently. And they always have the latest versions. This is good for testing on new platforms, but bad for supporting older platforms. Plus, there's a lot of overhead for restoring the build after an update.
brings up natural follow up question:
3'. Is the stable environment managed by the developers documented anywhere and can it be easily reproduced?
that has been partially addressed:
DrKnS wrote: Fri 13 Mar, 2026 21:53
The origin is farmanager.com.
The binaries come from a
makeshift CI that uses vs build tools. You can find the exact versions in far:about.
Do you mean that server hosting farmanager.com has build environment available and you or other main Far developers use it? Or that you build it on your own machine using the scripts and simply upload artefacts to farmanager.com?
I'm not sure yet if far:about info and these build scripts are sufficient to recreate building environment that is used to create official builds.
I will reply to other points on other day, as this post is already a bit long.