Diff

No code touched the main VS codebase.

In fairness, it's good juice. Only bothered replying to things that are outright wrong, mostly about concrete technical details. If something's simply your view or your opinion I'm not going to tell you you're wrong or that you can't feel that way. If you think I'm wrong about the things I replied, I'd appreciate if you could show where a concrete thing I said is incorrect, same as I'm doing with you. He doesn't. They said this in the announcement, all code is reviewed before it's committed, nobody can just like. Add code to the codebase. That's simply not how it works. It's not like editing a text file on your computer. Code changes are gathered, submitted for review, signed off by Tyron and potentially others, and then if it passes style, quality, and correctness checks, is approved to be merged into the codebase. There's a whole process. No, again that's not how software development works. Like, there is no action that Maltiez or anyone could take to accomplish this, short of posting "Hey I don't want this" in their internal discord or slack or email or whatever. No, I just know how software development works on a basic level. I don't mean this as an insult, after all, why would a random person know this for no reason? But that's why I'm posting it here, so others can know and be a little more informed about the topic we're discussing.

That Cetasaya, by claiming otherwise, was either being hyperbolic or untruthful?

Google does this constantly, all the time... Look up the app "DT Ignite." It's an app preinstalled by many carriers that is hidden and installs additional apps on your phone at any time without your permission because it makes the carrier money.

Not by the devs, no. When I read "but they all said that before the multiple more functions of this malware that the devs have hid have come to light from players" I read that some functions of the malware were understood, requiring AdditionalStuff.cs to have already been discovered, before additional features were announced that were previously undiscovered. No such features have been unearthed. Floor's yours. What's a feature of AdditionalStuff.cs that wasn't first discovered by the community before the devs announced its existence, that the devs had also taken action to cover up?

Understandable. Not really in any way that really matters to them. Otherwise they would have taken official action against the cheat dev. Some mitigation built into the game, server side validation to catch cheating players. All they bothered to do was ask him nicely to stop. No extra oversight is needed. This process works well enough to accept open contributions from the wide open, actually-malicious internet, of course it's good enough here. You're right that it isn't a consequence, it's informational so people can be sure that Maltiez can't just sneak code in. It doesn't work that way. The consequences are separate. No, it's been pretty consistent and comprehensive since AdditionalStuff.cs was first discovered. Devs never hid aspects of its functions from the public, nor would it have been possible for them to. Anyone can disassemble a DLL. People playing telephone with the information is different from the information evolving or being discovered over time. It's a pretty short file, pretty easy to read in a single sitting.

Because it's not reasonably technically possible. Untrue, it's part of a balanced breakfast.

Not possible based on my research.

I like this a lot. Still quite the project, but at least like a theoretically manageable one. There's still a reason only massive registries bother with it all, but I like this a lot. I hadn't heard of JSR before, how is this kind of workflow relevant to them? JS/TS aren't compiled, so you always have the readable source on your computer. I scanned their page on provenance, but what benefits does all this offer them over like pulling a specific commit hash out of Git? You could still smuggle code into assets. Heck, you could smuggle code as code, I've seen some mods with native DLLs and SOs that couldn't be built from source with this kind of setup, you'd have to ship them compiled. And plenty of mods have dependencies from the open internet, cutting off net access cuts off those mods. Forcing a certain build process is also kind of a headache, but considering how ubiquitous the regular CakeBuild template is, probably not a big enough one to worry about.

Not wrong, but not usefully right. Because there is no independent review. The ModDB is unreviewed. Only time I review code from other mods is to see how they did X or Y. And if X or Y aren't "hide malware in a PNG," I'm not going to find it unless I get stupidly lucky tripping over it on my way to something else. I don't think it ultimately does stop Maltiez, because I don't think anyone would choose to dive into the SettingsBuilder class of a Yaml Serializer of a widely-used and well-trusted library that has a long history in the codebase. It doesn't offer any guarantee or assurance or even a useful hint unless there is some sort of review. And I think the false sense of security would hurt more than it helps. And I do want to remind that we already skipped past a plethora of issues by magicking reproducible builds into existence for this part of our thought experiment, ones that do themselves have deep practical and security implications. There's a reason there is no game in existence that does this. This situation is difficult. Because everyone's looking for trust. The whole ModDB ran on trust, and now that it's broken, people are looking for assurances and guarantees. But we can't compute trust back into the equation.

You know I like this idea, I actually really appreciate it, unfortunately GitHub Actions offer no guarantees. There's no secret path to the ModDB that can't be forged. Even if there were, you can just edit the GitHub action to be malicious itself and cover your tracks afterwards. It's an untrustworthy environment. Extra unfortunately, even if every problem with building and reproducing mods was solved, the guarantees offered by it are really weak. Nobody's going to look sideways at a PNG that's 204KB instead of 200KB. But in a couple easy-to-stash lines of code, you can pop a hidden DLL out of that PNG and run whatever you want, endorsed by a green checkmark that people won't understand the nuance of. And nobody's going to find those 5 lines stashed away in a dark corner of a little-used file in a messy, sprawling codebase.

I see this suggestion a lot, but it really wouldn't work. You compile the same code twice on two different computers, even twice on the same computer, you end up with two different DLLs. Just getting the code to compile is non-trivial and either wide open for abuse or harshly limiting to mod developers. The security guarantees on that are also weak enough that I'd say they'd be worse than nothing, and certainly not worth the effort it'd take to make it happen. A false sense of security is worse than no sense of security.

Yes, that is what I'm saying. When you follow normal programming review processes, you can accept code from all of the malicious people on the world wide internet and be fine. Problems creep in when code is not reviewed, or there are certain kinds of subtle security bugs that can sneak past review if it's not careful enough, but those most apply to languages that aren't C#. I wrote more about the risk profile we're actually talking about over here. tl;dr: He doesn't have direct commit access and the code he's working with doesn't like actually do much of anything. Click on the links inside that post, poke around the repository, you can see for yourself, there's nowhere to hide anything.

It's actually standard operating procedure in just about any workplace. You review code for quality, for style, for bugs. Anyone can accidentally let a bug through or make a bad assumption that will bite later, and ensuring a consistent style is absolutely worth the effort in the long run, so you should always have at least a second pair of eyes passing over things. Maltiez is definitely not a programming genius. Or a social one.

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.