Official release management process

You want to talk about Far Manager, but don't know where to turn?
Post Reply
przemoc
Posts: 38
Joined: Sat 27 Feb, 2010 20:55
Has thanked: 12 times
Been thanked: 4 times

Official release management process

Post by przemoc »

I have hard time finding information about current Far Manager official release management process. There are at least a few things that would be worth documenting, unless they already are documented - will appreciate links to such places.

1. How and who denotes builds as stable?

2. Is there a way to find out commit/tag used to build the latest stable build within git repository alone?
(builds/3.0.NNNN and ci/v3.0.NNNN.MMMM tags are not unique to stable builds)

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?)

4. Is there support for or plan to support reproducible builds?

Extra side question:
5. Could Far Manager Official Site : download be extended with SHA-256 for each file?
(it's important to have reliable source of truth, and be able to verify that file we downloaded is the file we meant to download.)

Some observations:

For instance current stable build for AMD64 aka x86-64 is:
These files have been uploaded on 2026-02-12, at least according to Last-Modified HTTP header, and seemingly created/modified on 2026-02-12, at least according to dates of files in them.
Commit itself is from 2026-02-10 02:39:07 +0000.

Let's look at assets in GH release for ci/v3.0.6644.4772 (1a4340d).
I think they come, maybe somewhat counterintuitively, not from GitHub Actions but AppVeyor based on what I see in deploy task in appveyor.yml, and Visual Studio 2022 cl + nmake are used there.
Let's narrow the scope to just 7z archive:
Far.x64.3.0.6644.4772.1a4340d7d218edd01cd5bd09b2cfe011711e0125.7z
most of the files there are dated 2026-02-10.
BTW GH release for builds/3.0.6644 (1a4340d) has no assets.

Mentioned so far archives are different, their SHA-256:

Code: Select all

0aa68d780e45d31cd74f2e9a97f9776854c7b35196f3b7c5764bb40235dd2ebf  Far.x64.3.0.6644.4772.1a4340d7d218edd01cd5bd09b2cfe011711e0125.7z
cac160b40a289f1fc5ab1032a17bf3122a22dc2efd3311b91365175e3ee9651c  Far30b6644.x64.20260212.7z
And it's not only file dates in archives that contribute to their difference. 501 files actually differ there.
When it comes to text files, most seem to differ in using LF vs CRLF line terminators.
Examples:
Addons/Colors/Descript.ion in official archive uses CR LF line breaks, in CI archive uses LF line breaks.
sqlite3.map in official archive uses LF line breaks, in CI archive uses CR LF line breaks.
etc.
There is also naming difference: arclite (GH) vs ArcLite (official).

Even without ensuring fully reproducible builds, both file dates (commit date) and line breaks (LF should be sufficient unless Far requires CRLF in particular places) could be hopefully unified among these different ways of building Far Manager.
User avatar
HaRT
Moderator
Posts: 11446
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 270 times
Been thanked: 415 times

Official release management process

Post by HaRT »

przemoc wrote: Fri 13 Mar, 2026 19:22 1. How and who denotes builds as stable?
Who? The primary maintainer. How? It's complicated.
przemoc wrote: Fri 13 Mar, 2026 19:225. Could Far Manager Official Site : download be extended with SHA-256 for each file?
(it's important to have reliable source of truth, and be able to verify that file we downloaded is the file we meant to download.)
A very minor thing compared to other legitimate issues you raise, but at least it's what I have something to say about. 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). What could give some real added protection is digitally signing the packages, but it's a totally different story.
Related discussion (in Russian).
przemoc wrote: Fri 13 Mar, 2026 19:22 so far archives are different
Related discussion (mixed Russian/English)
Last edited by HaRT on Fri 13 Mar, 2026 20:36, edited 1 time in total.
Reason: Added more links to discussions
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
John Doe
Бюрократ
Posts: 14571
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Official release management process

Post by John Doe »

przemoc wrote: Fri 13 Mar, 2026 19:22
  1. Is there a way to find out commit/tag used to build the latest stable build within git repository alone?
In short: there is no such thing as "stable" builds.
What appears as "stable" on a homepage is an arbitrary build chosen by a maintainer, often merely for a "beautiful number" reason.
Besides that, no additional "stabilizing" actions are performed.
https://t.me/FarManager — Telegram чат
User avatar
DrKnS
Posts: 6120
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 431 times

Official release management process

Post by DrKnS »

  1. How and who denotes builds as stable?
I do, using all sorts of reasons.
Including, but not limited to, "it's been a while", "I'm about to merge experimental stuff and break something, so let's have a release first" and "this particular build number looks awesome, it must go down in history".
  1. Is there a way to find out commit/tag used to build the latest stable build within git repository alone?
No.
  1. What is the origin of binaries for stable/nightly builds available at Far Manager Official Site : download?
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.
  1. Is there support for or plan to support reproducible builds?
No, but if it's achievable without much hustle - PRs are welcome.
  1. Could Far Manager Official Site : download be extended with SHA-256 for each file?
    (it's important to have reliable source of truth, and be able to verify that file we downloaded is the file we meant to download.)
It could, but it's pointless. HaRT already explained why.
These files have been uploaded on 2026-02-12, at least according to Last-Modified HTTP header, and seemingly created/modified on 2026-02-12, at least according to dates of files in them.
You don't need HTTP headers etc., the date is right there in artefact names and in the title.
Commit itself is from 2026-02-10 02:39:07 +0000.
A stable build is always the latest nightly build (as of the publishing date), just copied to a different location.
There was a commit on 10 Feb, which was built on 11th.
The next day there were no commits, but the server does not care, it just rebuilds everything every night.
So when I thought that 12 Feb is a good day for a stable build, the latest one was used.
they come, maybe somewhat counterintuitively, not from GitHub Actions but AppVeyor based on what I see in deploy task in appveyor.yml, and Visual Studio 2022 cl + nmake are used there.
Github actions is a novelty, it did not exist back then when we created appveyor-based builds.
Actions are way faster, but appveyor config has one huge advantage: it exists and works, so full migration to actions gets postponed indefinitely.
The fact that both are based on bloody YAML, which I hate with passion, does not help either.
If you do speak YAML and want to see Far releases on Actions in observable future - PRs are very welcome.
GH release for builds/3.0.6644 (1a4340d) has no assets.
builds/* are not releases.
They are just tags we create for convenience, to be able to find the relevant sources quickly.
We used this approach even before github existed, and don't plan to abandon it only because github idiotically treats any tags as releases.
When it comes to text files, most seem to differ in using LF vs CRLF line terminators.
It was supposed to be consistent. At least there are attempts to handle it here and here.
could be hopefully unified among these different ways of building Far Manager
PRs are welcome, but, in general, we're considering decommissioning farmanager.com and appveyor builds entirely in favor of github actions only.
Maintaining all this takes too much effort, not to mention that "there should be one-- and preferably only one --obvious way to do it."

Also, it's an open source project, so the key product is the source itself.
Binaries are mostly provided for convenience. We don't sign them, don't keep them indefinitely, don't spend too much time thinking about them, and they tend to get less attention than other things. In other words, PRs are welcome.
przemoc
Posts: 38
Joined: Sat 27 Feb, 2010 20:55
Has thanked: 12 times
Been thanked: 4 times

Official release management process

Post by przemoc »

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. :thumbsup:

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
HaRT wrote: Fri 13 Mar, 2026 20:26 Related discussion (mixed Russian/English)
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.
User avatar
DrKnS
Posts: 6120
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 431 times

Official release management process

Post by DrKnS »

Do you mean that server hosting farmanager.com has build environment available and you or other main Far developers use it?
The server has build tools installed. Every day it downloads the sources from github, builds them, copies the artefacts to /nightly, all without any human interaction.
can it be easily reproduced?
It uses vs build tools, usually quite outdated. Not because we love old compilers, but because updating requires time and effort.
I think it's 19.41.33923.0 at the moment.
If you manage to find exactly this version (which is probably unrealistic with the current visual studio distribution model) then yes, it should be possible to get almost the same binaries (as far as I remember, vs embeds some time stamps, so it's never exactly the same).
Post Reply

Return to “General Discussions”