Diff

Writing there, I was talking specifically about actions taken regarding Maltiez. The new TOS is for the ModDB as a whole, which Maltiez is no longer a part of. If Maltiez is no longer engaging in the ModDB, he also is not a member of the sub-group of Anego that is taking custodianship of his mods. If you're talking about the ModDB here, which I think you are, I'm sorry to report that there really isn't a technical solution, it would have been dishonest of them to promise one. No scan would have ever caught what Maltiez did. And "provenance" is an easy word to type but an enormous beast of a problem technologically. One that would increase the maintenance burden of every mod developer substantially, while offering fairly weak guarantees that are easy to break or misunderstand, and massively increasing the scope of the ModDB beyond what any other game does. It would require Anego running their own automated build system, banning multiple types of completely-valid strategies for building mods just to keep their own sanity, and dealing with all the abuse and maintenance burden that entails. Again, all while offering very weak protections. Be happy to yap more about that but I think this post is long enough for now.

This is true regardless. Fired, hired, short of executing him there's no way to be safe from the spectre of Maltiez. It's the internet, you could be Maltiez right now. And there are people out there worse than him. Anyone on the planet could slurp up one of the many, many dead-but-popular mods with 10s of thousands of downloads, upload a REDUX version updated to 1.22, slurp up those 10s of thousands of downloads for themselves and steal everyone's bitcoinc. This is the nature of the moddb. It's the nature of downloading software off the internet. Obviously, that doesn't mean we should do nothing when these cases are revealed. But if you're seeking safety, there was never any here. They have taken steps to stop the problem. It won't and can't happen again. His code is being reviewed, the code he's working on is low-risk and mostly documentation. I understand if you would rather them part ways, but practically there's no safety difference. Maltiez has been publicly tarred and feathered, he has lost control of all of his passion projects and, as anti-social as he can be, will likely never be able to re-engage with a community he spent a lot of time with. It's fine if you think that's not enough, or if you think things should be handled differently. I also think aspects should have been handled differently. But I disagree with your framing as simply free maintenance with no other consequence.

These claims are confusing and very off-base. The Mod API is not the perfect position to recreate this in main code. It's really confusing that you would say this, because the Mod API would in fact be the single worst place for it. The API is mostly data types and glue, and it's all public on GitHub. Not much business logic you could hide anything in. If he's in the modding API, to be honest that's mostly going to be just documentation. There's so little relation to supply-chain situations like NPM that I struggle to understand what possible connection you're drawing. I can see the connection when it comes to the ModDB. Anyone can upload any old nonsense to NPM. Anyone can upload any old nonsense to the ModDB. A fault in a dependency spreads through that. That makes sense. It makes no sense to try and apply it to Vintage Story itself. Anything that enters VS's codebase undergoes code review by at least a minimum of Tyron, and a mix of others. When they review, they're looking for correctness, they're looking for style, they're looking for bugs. When the code you're supposed to be writing is just a list of available properties and plain-English explanations for what each is, it's going to be really obvious if all of a sudden you start scanning all loaded assemblies for matching CRCs and queuing up timers that submit random input events, disconnects, and crashes.

??? 1367 (CNC) + 1314 (URL Radio) = 2681.

You're absolutely right, they would not have. But your thought experiment is not the reality they find themselves in and that does make a meaningful difference.

Really appreciate this, I can also confirm after taking a look at this that URL Radio does contain obfuscated code and would have set off ConfigLib. That brings us up to 2 confirmed mods caught in the crossfire between Maltiez and the cheat mod dude. Only weird thing I can't explain is that it kept happening after removing the radio. ConfigLib doesn't have any sort of memory, so don't know what's up with that. Right with you on (1) just because I like FOSS, (2) unfortunately isn't really easily possible. I just built two identical copies of one of my mods. Same computer, same compiler, same versions of everything, byte-for-byte identical source, but different checksums on the compiled DLL.

Hadn't seen that one floating around, but your gut feeling is right. To accidentally corrupt a save, just crash mid-save... But AdditionalStuff.cs only crashes in multiplayer games, where the client isn't the one handling saving at all. And the same line that bails out on single-player games also bails out if it's not running on the client side. No accidental save corruption should be possible.

I also wish the false positives had been mentioned. In truth, we don't know how widespread these false positives were. Mods are third-party code of unknown quality, and mods do just crash. Null Reference Exceptions in particular are the classic mystery meat crash, and they're the kind of crash that ConfigLib provoked. We do have at least one confirmed case of a mod caught in the crossfire, Caves N Caverns, due to it obfuscating its code. Speculating a touch, if CNC's 1000 downloads were enough to blow the lid off this, it does suggest that false positives were not common... But I feel that's the limit on how far you can reasonably minimize this issue. Ultimately, we don't know how widespread the false positives really were, and that itself is part of the problem. In a vacuum of information, a lot of crashes are now getting pinned on ConfigLib. Is it true? Were these crashes also mixed with random game inputs and disconnects, all consistently between 2-9 minutes after assets loaded? We don't know. Nobody that's claiming ConfigLib kicked their cat is going that far into depth with it. And the announcement only continues that vacuum of information. I'm personally fine overall with the VS team's current path forward, but that's the complaint I have with the announcement.

Wait a minute, I was saying this from my first post here, how did you even convince yourself I'm lying when I agreed with you? Meanie. >:(

I could really reflect your request for half-reasonable claims here... These are not at all similar situations. NPM, PyPi, and Go are the exact same story as the ModDB. Entirely unreviewed by anyone except the users. Go is especially egregious to include because it doesn't even have a centralized repository of any kind, you can upload to any public URL on the entire internet as long as it responds the way the Go expects. Linux distros are a closer analogy to this, and there are instances of maintainers going evil. But in the instances I'm aware of, they were trusted maintainers who didn't get their contributions reviewed at all, so we're back to being unreviewed here. We're not talking about the ModDB, which Maltiez is no longer present on. We're talking about the main VS codebase. Every line of code that gets submitted to VS gets reviewed by Tyron. These are flatly not the same situations, so yes, a one-person validation turns it into "no-chance" by virtue of it being a binary difference between "completely unreviewed" and "reviewed by a minimum of one person but sometimes more." How are you going to smuggle "accidentally" setting ClientMain to null past anyone with functioning eyes, let alone eyes that are scanning for multiple criteria?

He's an employee. An employee can be a tricky thing to shed depending on your locality. Not everywhere allows you to snap employees out of existence at the drop of a hat. And the damage he can do is quite limited. You can't really sneak code like that past review, and every line of code (from any employee) is reviewed for behavior, correctness, and style. Apparently by Tyron himself. There really is no chance of it happening again.

Genuine question, what are you seeking here? What would you feel is appropriate compensation for your videogame crashing intentionally? He is no longer on the ModDB. He is no longer capable of uploading any mods at all. He is not and has never been capable of merging code into main directly.

Reproducible builds are unfortunately notoriously thorny. And so is automatically building other people's projects. Even solving both of those, there are some holes here that reduce the trust guarantee. If public source is not required, and source is not being reviewed, then you can just as easily upload evil source and the system will attest faithfully that your evil source is accurate to your evil DLL. This also doesn't stop someone from uploading private evil source to the ModDB that conflicts with what's in the public repo, but matches the evil DLL.

This thing specifically you claimed was happening with no hedging. There is no evidence of that happening and it is quite a claim to make without evidence. You laid this claim out specifically as if it were a concession on your part, an uncontested point to build off. It's not. Your misunderstanding is not a strawman.

I'm not interested in misrepresenting you or strawmanning you, that was not my intent. I will admit I'm not sure how I have managed to give you that poor impression. I never claimed it wasn't excluded from Git, so I'm not sure how I "lied," either. But I would be interested in continuing the discussing if you ever change your mind.

Wasn't intending to talk down to you, I included that bit for the benefit of the other fellows in here who don't know and are asking similar questions. We have no way of knowing until a statement has been made. We have no way of knowing even after that if we think ill of Anego. We have no way of knowing anything our computers do can ever be trusted if we want to get philosophical about it. We have no evidence that this thing, which you claimed is happening, has happened. That is an ass-pull far greater than claiming "We have no evidence of that." Can't be linked, it doesn't have a public home. It's excluded from Git. You know this, I know this. For accessing it, I recommend a decompiler. I like Rider, ILSpy is also cool. It's hiding in the "SettingsBuilder" class in the Yaml decoder's namespace. If you want it uploaded directly here, just say so and check back in a few hours. I accidentally left my laptop disconnected from Tailscale this morning when I left the house.

In that case I understand how you came to that conclusion. Those are two separate statements regarding two separate events. All code that goes into the game is reviewed, this is a standard software development procedure just to catch bugs and unintended behavior. As far as the mods, Maltiez let at least some people on the team know about his anticheat code inside his own mods, but not the full extent. There were no modifications to the core game API. And we can be relatively confident about that. If he inserted supporting anticheat code in the core game... why didn't the anticheat code it was supposedly supporting actually make use of it? It used normal methods, and I can think of nothing in there that would even benefit from being included in the game. As others have noted, the anticheat code predates him advising on the game. No statements, comments, or public evidence indicate that any anticheat code was added to the game, or any supporting functions or features to enable the anticheat code in Maltiez's mods. For accessing AdditionalStuff.cs, I can only recommend a decompiler. I like Rider, ILSpy is also cool. It's hiding in the "SettingsBuilder" class in the Yaml decoder's namespace.

Woah now, friend, where is any of this coming from? And that is a genuine question, I would very much appreciate knowing where you came to this understanding. No API changes were made to the game to support this anticheat behavior. No core game code was modified at all in relation to this issue, the responsible code was contained entirely within the affected mods. Maltiez's code, while well-hidden under the bones of a dependency, was not obfuscated. The additions were confined to one source file on top of what was checked into Git, "AdditionalStuff.cs." It's relatively short and its operations can be well-understood quickly.

You can decompile if you want, sometimes that's necessary. But if all you need is worldgen, it's all on GitHub: Anego Studios It's not open source, so I can't speak on licensing.

Maltiez's code wasn't obfuscated, just hidden under the bones of a bundled dependency. Hidden well. Even knowing it existed, it took me a while to find it. But once found, it's easily read. We can speak confidently about what the code did and didn't do. From my own research into it, the summary in the OP is pretty comprehensive. It mentions things I have found in the code myself and that I've seen missing from other summaries of the mod's behavior.

Wouldn't have avoided this unfortunately. Making it a dedicated, separate mod would have made it laughably easy to bypass. Patching out the checks of an anticheat mod like that is something you could accomplish following the generic "Quickstart" Harmony tutorial with 0 modding experience. It only works if you don't know it's there. Shouldn't have been done at all, but doing it any other way would have been pointless.

You seem more level headed, hello. It was missing from the public repository, it was only added during the build process and only present in the compiled releases. The code did take action to prevent itself from being spotted as the cause of the crashes, yes. It did conceal itself, absolutely. The meaningful difference is not in the past, it's now. Now that it's been revealed, we can reliably analyze it and talk about it confidently. We can speak authoritatively on what it did, what it didn't do, what effects it had, what unintended effects were possible, and what is just breathless, uninformed speculation that people are running away with. I think you misunderstand me as trying to defend/excuse Maltiez or say that this is "better" somehow. It's not. It's just useful.

They don't? They can be comorbid when you are writing bad code, but that general comorbidity goes out the window when you're writing code to intentionally produce certain effects. We know what his code did. We can disassemble and analyze it. Its effects were obscured but the code is not obfuscated. I'd love to have even more evidence of AI-riddled code being bad, but there is no evidence of that here in what you've presented and I couldn't find any myself when I went looking where you indicated I'd find it.

Yes, we know about the stability issues, that's literally what the code was designed to do. You claimed people were making claims of performance improvements. Your screenshots do not back you up. "No need to heap on made-up bullshit to dilute the actual bullshit" has always been my point.

Wouldn't read much into that without hard numbers to back it. Placebo effect's strong when performance is in question. Reflection (the type of code needed for code to analyze itself at runtime) is relatively slow, but not *that* slow. I'm also, like, not seeing that on the ModDB myself. Who's saying it? What are they saying? I see one comment related to performance and it's just: