Prevent loading of mods with invalid names by compmstr · Pull Request #16904 · luanti-org/luanti

compmstr · 2026-02-03T00:36:29Z

Logs message to warningstream

Add compact, short information about your PR for easier understanding:

Goal of the PR:
- Stop loading mod, and log warning when an invalid name is detected in mod.conf
How does the PR work?
- Updates parseModContents to check for invalid name when loading. Logs and skips mods containing invalid characters.
Does it resolve any reported issue?
- Should fix Insufficient validation of mod.conf name #16478
Does this relate to a goal in the roadmap?
- This is a small bug fix that was listed as a good starter fix.
If you have used an LLM/AI to help with code or assets, you must disclose this.
- I have not used any LLM/AI to develop this

I realize there's already an open PR for this, but it has been inactive for a couple of weeks at this point.

To do

This PR is Ready for Review.

How to test

As documented in the issue, set up a mod with invalid characters in the name field.

ex:

name = """
haha ;]
oops
"""
description = "Mod to test bug that's being fixed"
depends = first_mod

Prior to this fix, the mod would load, and show up oddly in the mod list.

Afterwards, there is a WARN log, and the mod does not get loaded/shown.

Logs message to warningstream

SmallJoker · 2026-02-03T16:27:41Z

Alternative PR: #16719

SmallJoker · 2026-02-03T16:33:01Z

src/content/mods.cpp

 	if (info.exists("name")) {
 		spec.name = info.get("name");
 		spec.is_name_explicit = true;
+		if (!string_allowed(spec.name, MODNAME_ALLOWED_CHARS)) {


When starting Luanti in the "Start game" tab, the following warnings are logged. When I click "Configure mods", the same bunch of warnings are logged - again.

Error loading mod "xxx/games/VoxeLibre/mods/PLAYER": Mod does not follow naming conventions: Only characters [a-z0-9_] are allowed. Error loading mod "xxx/mods/worldedit-modpack/bonkers": Mod does not follow naming conventions: Only characters [a-z0-9_] are allowed. Error loading mod "xxx/mods/worldedit-modpack": Mod does not follow naming conventions: Only characters [a-z0-9_] are allowed. Error loading mod "xxx/mods/skyblock": Mod does not fo llow naming conventions: Only characters [a-z0-9_] are allowed. Error loading mod "xxx/mods/nested_modpack/modpack_a1": Mod does not follow naming conventions: Only characters [a-z0-9_] are allowed. Error loading mod "xxx/mods/nested_modpack/modpack_b2": Mod does not follow naming conventions: Only characters [a-z0-9_] are allowed. Error loading mod "xxx/mods/nested_modpack": Mod does not follow naming conventions: Only characters [a-z0-9_] are allowed.

The warnings should only logged once per mod(pack) to avoid spam.

From what I could(n't find), modpacks seem to have no naming rules defined in lua_api.md

This needs documenting.

A-z_- or a-z_- might be the best retro-fit.

Perhaps misleading PR title. Prevent loading of mods is done by mod.checkAndLog(); in ServerModManager::loadMods, where the server will not load the mods that do not obey the naming conventions.

EDIT: Whereas the naming is enforced upon server start-up, there is also lack of documentation on mod names in lua_api.md.

You'll notice that nothing else prints to the log in this function. This is by design - it would be too spammy in the main menu. You should just return false here.

Okay, should I just drop the logging altogether, or try to find somewhere to log once for mod debugging purposes?

Maybe I could add a message to deprecation_msgs, so that it gets logged out when other mod issues are.

I could also set up a new error_msgs that contains this message, as well as things like "Mod ... missing init.lua" (the other case where we skip loading a log). I could log it from within checkAndLog the same way deprecation messages are.

Look at how the missing init.lua is validated because it's the same style of issue

I got bit by the silent failure of the mod from a missing init.lua when I first tried to test this PR. Ideally we could log at least once whenever there's an error loading the mod.

I'll take another pass at this, see if I can get these to log out inside checkAndLog, since that's less spammy.

src/content/mods.cpp

Update allowed mod name characters to include A-Z (upper-case)

ModSpec::mod_load_error_msgs holds the set of errors (per file) When `checkAndLog` is called, we also log mod load errors Logging, ignoring, and erroring are all configured by a new setting (defaulted to log)

compmstr · 2026-02-03T20:28:18Z

I set up a static mod_load_error_msgs member to keep track of per-path module load errors.
When we call checkAndLog on modules, we'll also call logModLoadErrors, which will either ignore, log, or error out on module load errors. There's a new configuration, mod_error_handling that controls what we do with the error messages.
I added a flag so that we only log those errors one time, instead of logging from each module.

Error (when mod_error_handling is set to error):

Logs:

2026-02-03 15:18:25: ERROR[Main]: ModError: Mod at /home/corey/stuff/OpenSource/luanti/games/devtest/mods/bad_name2:
2026-02-03 15:18:25: ERROR[Main]: 	Mod does not contain 'init.lua
2026-02-03 15:18:25: ERROR[Main]: Mod at /home/corey/stuff/OpenSource/luanti/mods/bad_name:
2026-02-03 15:18:25: ERROR[Main]: 	Mod does not follow naming conventionsOnly characters [a-zA-Z0-9_] are allowed.
2026-02-03 15:18:25: ERROR[Main]: Check debug.txt for details.
2026-02-03 15:18:25: ACTION[ServerStop]: Server: Shutting down
2026-02-03 15:19:06: WARNING[ServerStart]: Mod at /home/corey/stuff/OpenSource/luanti/games/devtest/mods/bad_name2:
2026-02-03 15:19:06: WARNING[ServerStart]: 	Mod does not contain 'init.lua
2026-02-03 15:19:06: WARNING[ServerStart]: Mod at /home/corey/stuff/OpenSource/luanti/mods/bad_name:
2026-02-03 15:19:06: WARNING[ServerStart]: 	Mod does not follow naming conventionsOnly characters [a-zA-Z0-9_] are allowed.

compmstr · 2026-02-08T16:56:50Z

Would this be cleaner if I set up something like a ModErrors class that keeps track of these errors? Rather than include it in the existing mods.(h|cpp)? Or is this approach with the static store of messages a non-starter?

Since the errors are explicily for mods that did not get loaded, it made more sense to have this be separate from ModSpec.

compmstr · 2026-02-15T20:47:36Z

I moved this mod error handling code into a new ModErrors class, since it's explicitly for errors that stop a mod from loading. So having it stored in ModSpec made less sense, imo.

src/content/mod_errors.h

src/content/mod_errors.cpp

src/content/mods.h

Move back to original valid name characters

src/content/mod_errors.h

src/content/mod_errors.cpp

Fix error message to reflect actual allowed characters.

compmstr added 2 commits February 2, 2026 09:00

Stop loading mod if mod name is invalid

e1efcfa

Logs message to warningstream

Fix indents (should be tabs)

d8f08f3

sfan5 added the Bugfix 🐛 PRs that fix a bug label Feb 3, 2026

SmallJoker reviewed Feb 3, 2026

View reviewed changes

sfan5 reviewed Feb 3, 2026

View reviewed changes

src/content/mods.cpp Show resolved Hide resolved

compmstr added 2 commits February 3, 2026 12:42

Update docs for module name field

9ab1852

Update allowed mod name characters to include A-Z (upper-case)

Add module load error handling

817cd45

ModSpec::mod_load_error_msgs holds the set of errors (per file) When `checkAndLog` is called, we also log mod load errors Logging, ignoring, and erroring are all configured by a new setting (defaulted to log)

whitespace fixes

8c60ce8

Move mod error handling into new ModErrors class

41badce

Since the errors are explicily for mods that did not get loaded, it made more sense to have this be separate from ModSpec.

Move imports to the file where they are used

2e240e2

compmstr requested review from SmallJoker, rubenwardy and sfan5 February 17, 2026 00:25

sfence reviewed Feb 17, 2026

View reviewed changes

src/content/mod_errors.h Outdated Show resolved Hide resolved

src/content/mod_errors.cpp Outdated Show resolved Hide resolved

sfence reviewed Feb 17, 2026

View reviewed changes

src/content/mods.h Outdated Show resolved Hide resolved

sfan5 added the Action / change needed Code still needs changes (PR) / more information requested (Issues) label Feb 17, 2026

Update copyright for new files

61f1f06

Move back to original valid name characters

appgurueu reviewed Feb 17, 2026

View reviewed changes

src/content/mod_errors.h Outdated Show resolved Hide resolved

appgurueu reviewed Feb 17, 2026

View reviewed changes

src/content/mod_errors.cpp Outdated Show resolved Hide resolved

appgurueu reviewed Feb 17, 2026

View reviewed changes

src/content/mod_errors.cpp Outdated Show resolved Hide resolved

Switch to unordered_(set|map) for errors

2af97e1

Fix error message to reflect actual allowed characters.

compmstr requested review from appgurueu and sfence February 17, 2026 13:32

sfan5 removed their request for review February 19, 2026 11:38

Conversation

compmstr commented Feb 3, 2026

To do

How to test

Uh oh!

SmallJoker commented Feb 3, 2026

Uh oh!

SmallJoker Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rubenwardy Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

compmstr Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

compmstr Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

rubenwardy Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

compmstr Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

compmstr commented Feb 3, 2026

Uh oh!

compmstr commented Feb 8, 2026

Uh oh!

compmstr commented Feb 15, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

SmallJoker Feb 3, 2026 •

edited

Loading