Freeciv

I forgot, could you please also change the version of the modpack for 3.0 and 3.1 to "2025_12"?
I have updated those versions with an important fix.

They included effects with references to "Experimental" AI, and I have just found that Freeciv do not load those rulesets unless it is compiled with debug enabled. I always test my releases with debug enabled to detect possible errors, but it seems I was missing the most important one... and since the release of v3.0, I guess most players have been unable to play my ruleset.

David Fernandez wrote in #note-1:

I forgot, could you please also change the version of the modpack for 3.0 and 3.1 to "2025_12"?

Updated their URLs to
https://raw.githubusercontent.com/dftec-es/civ2civ3_earth/refs/tags/v2025_12/3.0/civ2civ3_earth-3.0.mpdl
https://raw.githubusercontent.com/dftec-es/civ2civ3_earth/refs/tags/v2025_12/3.1/civ2civ3_earth-3.1.mpdl

Previously their URLs were pointing to whatever is HEAD commit of your repository. While this is generally a bad practice, it means that new installations have been getting your fixed version (but old version number, sigh) already from the very moment you pushed it to your repository.

I don't have test environment for these End-of-Life freeciv versions handy any more, so can you test yourself that installation now works?

The ruleset gives a couple of deprecation warnings about never active action enablers (when run with --warnings)

> rulesetdir civ2civ3_earth
 3: Loading rulesets.
 2: Action enabler for "Attack" is never used by any unit.
 2: last message repeated 2 times
 2: Action enabler for "Bombard" is never used by any unit.
 2: last message repeated 2 times
 2: last message repeated 1 time (total 3 repeats)

Marko Lindqvist wrote in #note-2:

David Fernandez wrote in #note-1:

I forgot, could you please also change the version of the modpack for 3.0 and 3.1 to "2025_12"?

Updated their URLs to
https://raw.githubusercontent.com/dftec-es/civ2civ3_earth/refs/tags/v2025_12/3.0/civ2civ3_earth-3.0.mpdl
https://raw.githubusercontent.com/dftec-es/civ2civ3_earth/refs/tags/v2025_12/3.1/civ2civ3_earth-3.1.mpdl

Previously their URLs were pointing to whatever is HEAD commit of your repository. While this is generally a bad practice, it means that new installations have been getting your fixed version (but old version number, sigh) already from the very moment you pushed it to your repository.

I don't have test environment for these End-of-Life freeciv versions handy any more, so can you test yourself that installation now works?

Please, keep the old URLs, pointing to the HEAD of the release branch (that I use only to upload tested versions ready to be released). This way I can release patches for each release, that I name 2025_12b, 2025_12c... and I don't need to open a ticket here to fix errors.
I have a separate master branch for the development of the ruleset.

I do have these old freeciv versions installed. Actually, when I install freeciv in my kubuntu, it installs freeciv 3.0. That is why I try to keep updated the old versions of my ruleset.

Marko Lindqvist wrote in #note-4:

The ruleset gives a couple of deprecation warnings about never active action enablers (when run with --warnings)

Yes, those warnings are ok, they appear because there are action enablers needed by some unit flags that are currently not being used by any unit, but they might be used in the future, or by players who can easely add them.

What I have missed is a warning when the ruleset references the "Experimental" ai, something warning that the ruleset won't run if debug mode is not enabled.

Marko Lindqvist wrote in #note-2:

Previously their URLs were pointing to whatever is HEAD commit of your repository. While this is generally a bad practice, it means that new installations have been getting your fixed version (but old version number, sigh) already from the very moment you pushed it to your repository.

I really liked it this way. If the Modpack installer was able to retrieve the modpack version automatically from the file .mpdl, it could work flawless, and we modders could keep the modpacks updated without assistance from you (except to add the link for new freeciv versions).

Unfortunately, I was not aware of this "Experimental" ai issue, and all my releases have included this error for the past 2-3 years, until I have fixed it this week.

From security point of view, we should pin the download URL by the specific commit hash (not even by a tag that can be moved or recreated). That way even if your repository would get compromised, the attacker could not cause malicious stuff to get installed from the repository by modpack installers.

Marko Lindqvist wrote in #note-8:

From security point of view, we should pin the download URL by the specific commit hash (not even by a tag that can be moved or recreated). That way even if your repository would get compromised, the attacker could not cause malicious stuff to get installed from the repository by modpack installers.

Yeah, I was thinking that if you keep this new url, it'd be simpler for me, if I want to fix a bug, to delete the release and create a new one with the same tag.

But if you are that worried about the security of my repository (compared to other repositories linked there), just remove the link. Anyway, this was supposed to be my last release, and people who have tried to use the modpack installer in the last 3 years have been getting a non working version of my modpack, I don't think they'll try again.

David Fernandez wrote in #note-9:

(compared to other repositories linked there)

Naturally same applies to all repositories to which modpack.list points to. Quite standard stuff in information security, really.

David Fernandez wrote in #note-9:

Yeah, I was thinking that if you keep this new url, it'd be simpler for me, if I want to fix a bug, to delete the release and create a new one with the same tag.

That would of course completely defeat the point of using URL that tries to pin specific version.

Well, the only reason why I created this repository in the first place was to be linked by the modpack installer, and to be able to update it without the need to send you every version in a pack to be uploaded to modpack.freeciv.org, as I used to do.

Without that feature, I really see no reason why to keep any URL pointed to anything other than modpack.freeciv.org, that I guess would be more secure. Why link to an external url, if you can copy the content and link to your own secure server.

I think the autonomy of modders to update their ruleset with some autonomy was worth the possible security compromises. We talked back then about the way I was going to setup my repository, and I appreciated the implicit confidence in the management of my repository.

I know it is "Quite standard stuff in information security" that everything you download from external urls is a security hazard, and the modpack installer already shows the url in case you want to check the content before installing it. But I wonder why it has not been an issue for you until now (the security issue has been obvious to me because I have been updating my ruleset without your assistance all these years).

Anyway, as I said, it was supposed to be my last release. Do as you please.
Thank you for your work on freeciv all these years, and for your support of my mod until now.

Marko Lindqvist wrote in #note-11:

David Fernandez wrote in #note-9:

Yeah, I was thinking that if you keep this new url, it'd be simpler for me, if I want to fix a bug, to delete the release and create a new one with the same tag.

That would of course completely defeat the point of using URL that tries to pin specific version.

I was trying to point the absurdity of your change...

David Fernandez wrote in #note-12:

Well, the only reason why I created this repository in the first place was to be linked by the modpack installer, and to be able to update it without the need to send you every version in a pack to be uploaded to modpack.freeciv.org, as I used to do.

Without that feature, I really see no reason why to keep any URL pointed to anything other than modpack.freeciv.org, that I guess would be more secure. Why link to an external url, if you can copy the content and link to your own secure server.

It's still much easier to just update single URL (+ version number) than copy/setup entire modpack on the new server when we want an update. E.g. for variant2 I think we should make the switch from full setup to URL-only direction.

Also, I only pointed out that "From security point of view...", i.e., presented one viewpoint, but you took it as if I had presented some final decision.

But I wonder why it has not been an issue for you until now

Well, we constantly try to improve on all fronts. So you are mad because I did not raise this issue years ago already?

Also, I was recently bitten by somewhat similar case of https://nvd.nist.gov/vuln/detail/cve-2025-30066

Marko Lindqvist wrote in #note-14:

Well, we constantly try to improve on all fronts. So you are mad because I did not raise this issue years ago already?

No, I'm mad because I recently noticed that my modpack have been non-functional for the last 3 years. But also because 5 years ago, when I was deciding how to continue the development of my ruleset, we had some kind of agreement to allow that the modpack installer includes a link to my repository.

I liked the freedom that it allowed, and I assumed the responsibility to keep my repository properly updated. But today I have realized that it was a misunderstanding, and that you were supposed to supervise every single release.

The only difference between the old url to HEAD, and the new url to TAG, is not security (the risk is the same in both cases), but in the first case I have freedom to release updates, and in the second it is not released until you give your seal of approval. It means that you are trustworthy and I'm not (even when I have been 20 years collaborating with freeciv), that is why I took it as something personal.

But I did not say that this is the last release because I'm mad, that was already planned.

Marko Lindqvist wrote in #note-11:

It's still much easier to just update single URL (+ version number) than copy/setup entire modpack on the new server when we want an update. E.g. for variant2 I think we should make the switch from full setup to URL-only direction.

As I said, a misunderstanding. When it was added the URL to my repository, I thought I was allowed to update it, and that is why I have requested several times some way to retrieve automatically the version from the .mpdl file.

If the URL is supposed to pin a certain tag frozen in time, there is no extra functionality (just a bit less work for you, that is done by the modder instead). It is a waste of a nice feature, in my opinion.

I've set the URLs to follow HEAD of "release" again. Please test that I got it right.

I'll reply your latest comment in more detail a bit later. Believe me that the want for pinned URLs is not about trustworthiness.

I appreciate that you restored the urls, but unless I find some bug in the new release, I do not plan to update it anymore. I'll test them later when I'm in linux. Thank you.

I liked the control I had over the development of my modpack when the mod installer linked to the HEAD of my repository. If it links to frozen TAGS (that I'm not supposed to change), I no longer have the control, it goes to the person who manages the mod installer, whom I need to ask permission every time I want to update my modpack. I'm not interested in working that way.

If I share the releases of my mod in the forums, and sudently one day, they say that every time I have a new release, I have to send the link to a moderator, and wait for their approval to share the link, then I will stop using that forum to share my mod, I do not care if they find it more secure. I would stop using github if they start to do the same "for security reasons".

I do not find healthy that the creators of a certain software control the mods or plugins made for that software. As an user, if I download a mod from an external repository, I assume the owner of that repository is the responsible of the security. I try to download mods or plugins that are open source, because then the users can check what they are installing themself, and the security is no so dependant on the trust to the creators. But this is my opinion, you are free to manage the mod installer as you want.

Anyway, it is a philosophycal discussion, no longer useful in this case.

All the links are working ok. I tested 3.2, 3.1, 3.0 and 2.6.
Thanks.

The main reason to have references from one software component to another pinned are reproducibility and security.

Like I said, URLs based on git tags would not fulfill security's requirements, but for that we should use URLs based on commit hashes (non-mutable references). I was more interested about the reproducibility. I.e., when we get a bug report stating that the bug happens with your ruleset, reproducing the bug might require ability to install the exact same version as the reporter. For that goal the referenced version should not change unexpectedly. The issue is made worse by the fact that version number that modpack installer shows is not updated. Thus everyone may think that two versions are the same when they in fact are not. At least the version number (if not URL) should be updated every time there's a change in the referenced modpack version, and the modpack update and version update should happen simultaneously to avoid them being out-of-sync (They still can be out-of-sync shortly for example if the user has already launched modpack installer with old version's info, but clicks install only after modpack on the server has been updated. Let's accept that for now.) Version number update is also required for someone who has already installed the modpack to know that there's an update available.

Much of this is mitigated by the fact that you're not doing constant development on the branch from which the modpack installer fetch the modpack, but updates to that branch happen only seldomly. I was not aware of this when I first changed the URL.

For the purposes of debugging older bug reports, or testing if a change in you modpack has made a difference to reproducibility of an engine bug, we need also ability to install older versions of the modpack. We can do that with the tag (or commit hash) based URLs. We just need to know what was the modpack version at the time the reporter installed the modpack.

All the time we have been talking about the URL listed in the curated modpacks listing. It has no effect on installing your modpack as a "regular" custom modpack, which you actually instruct people to do in the forum thread (pasting your URL directly to the URL box, instead of selecting the modpack from the curated list)

civ2civ3_earth is one of the rulesets which I have in my autogame testing setup, which runs autogames from all active branches almost constantly. For S3_2 I'm using the version you've provided. For S3_3 and main branch the ruleset has been updated from S3_2 version by freeciv-ruleup.

--

As for final decisions, I think I'll ask Freeciv Maintainers Team to come up with a policy regarding pinning git repository references in the curated modpacks list.

And about importance of security: Freeciv is only a game, which in my opinion is a reason take security only more seriously. People handle their bank accounts on the same computers where they play freeciv. Your bank account should not be at risk for just a game. No freeciv vulnerability should let bad actors in to ones computer.

I agree security is important, and I agree hash based urls would increase security. I agree TAG based urls would not increase security, but would increase reproducibility by your side. And I understand the current version control of fcmp is more designed for TAG based urls.

I'm still not interested to use a platform (fcmp) to publicite and handle the releases of my modpack if I have to open a ticket every time I update the mod in order to get it in sync with my repository. I appreciate and hope that you keep my modpack linked in the modpack installer list, but I do not plan to send future requests to update it. You are welcome to update it yourself, or share there the ruleup version for future freeciv versions (3.3 and later). It is GPL after all.
(I must say I find the modpack is already properly balanced, and I considered it a finished work, before this debate started).

I'd argue that in some case this policy (tag based urls) could lower the security, but the reason I started this complain was not security, but more autonomy and control for the modpack developers (instead of more control for freeciv developers granted by your suggested policy).
Example: imagine I manage a repository with a plugin for firefox, and I find a vulnerability in my code that I fix and upload inmediatly to my repository. Imagine I have to open a ticket in the mozilla issue report, explaining the vulnerability and the fix, and then wait until someone approves it to make that update available for everyone. The longer that process takes, the worst for security in this case.

In my case, imagine the current version of my modpack is broken (as it has actually happened). I update my repository as soon as possible to allow people to download the working version. Then I open a ticket here. You use to process these tickets incredibly fast (sometimes in the same day), but you might be ill, or out for vacations. I remember once, my ticket was opened for 1 month without response (you were moving to this new site). I do not complain about that, but I like to have the control over when my updates reach my users.
(I understand most people who develop open software cannot have this kind of control, but I think it is better if they are allowed to decide, and it is not sudently imposed to them).

I have been modding games all my live. I'm not talking here about freeciv alone, but about what I wish, as a modder, when a software offers a mod installer with links to 3rd party urls.

I understand you like some control over the modpacks linked in fcmp. Microsoft (or Google) would also like more control over the software that people can install in Windows (or Android), and they will argue it increases security. I do not find those policies healthy, and they would demotivate me to develop software for those platforms. I advocate for security based on open source and decentralization, as opposed to centralized control that uses to reduce usefulness and freedom.
(Sorry the long speech, feel free to ignore it).

Marko Lindqvist wrote in #note-19:

civ2civ3_earth is one of the rulesets which I have in my autogame testing setup, which runs autogames from all active branches almost constantly. For S3_2 I'm using the version you've provided. For S3_3 and main branch the ruleset has been updated from S3_2 version by freeciv-ruleup.

About that, while testing civ2civ3_earth for S3_2, I have noticed several error logs that do not caused crashes, and I have been unable to reproduce (if I reload the game the error doesn't appear again). They were always some of the following 4 errors, in case they mean something to you:

1: in handle_tile_info() [packhand.c::3320]: assertion '0 == unit_list_size(ptile->units)' failed.
1: in wonder_is_built() [improvement.c::883]: assertion '((void *)0) != pplayer' failed.
1: in get_unittype_bonus() [effects.c::1047]: assertion 'pplayer != ((void *)0) && punittype != ((void *)0)' failed.
1: in unit_virtual_destroy() [unit.c::1743]: assertion '!unit_transported(punit)' failed.