Diff

I think these are reasonable takes. He indeed never denied it... not that we'd want him to. He definitely didn't regret it in the beginning and was his usual caustic self about it when confronted. He has apologized since and I don't think we can confidently say he doesn't regret doing it. Lot's happened since, and his lack of regret isn't carved in stone. If "access to code" is important to you, you may be interested to know he kinda doesn't right now. I understand if you just want him gone regardless. But if it's "access" that concerns you, he has as much access to the code as you or I do right now. He maybe has a tiny bit of additional read access to the small, obfuscated portions of the VS client, but no additional write access. He can't sneak anything in, even if he felt like it. Software development practices don't require trust, because trusting the wrong person can mean horribly bad things no matter where you go. It can also just mean your project slowly devolves into buggy spaghetti in the long run. From what people with firsthand experience have reported, VS has high standards before code gets approved and checked in.

Without some sort of complex provenance system this is far easier said than done. There's actually a lot of code that can wind up in a DLL that won't be in a source release, for legitimate reasons. Maltiez's ConfigLib DLL contains a Yaml parser (AdditionalStuff.cs hid itself inside its namespace), but it's not in the source release. Just a dependency. You can also obfuscate or not publish your source. We don't know, but someone does. Since we know that this all took place in a Discord server, if it still exists it'd be *really* interesting to see any logs of what went down. I doubt the customer support is stellar, but if you have a Discord server full of people all saying that "It has to be your fault, I disable your mod and all the crashes stop", that'll hamper new sales. Do want to say that you're 100% correct, the premise is flawed. I'm of the mind that all client-side anticheat is ultimately pointless. You're running in someone else's home, and eventually the house will win. I have written in the past that Maltiez's approach is the only one that could have worked for any amount of time. But every time I write that, I also (try to) include that it was still a bad idea from the very start. When I talk about how it is the only way that it could have worked, it's specifically to debunk the idea that it could have just been split out into its own mod. The idea's broken, but the suggestion's even more broken.

It is here:

Wow that's substantially worse than I was expecting when I went looking.

You didn't say saves, I didn't say saves either. Dorf said saves, Dorf was the person I was responding to. No legal assessment needed for the technical question of "Did this thing cause save corruption."

Don't disagree at all that this is Not Good. Unfortunately this is inherently a technical topic, and that makes it easy for misinformation to spread. The targeting mechanism is very technical and easy to telephone into a variety of incorrect things. Solutions are also very technical and people are throwing around words they don't understand and that they don't understand the complexities of. From the start to the path forward, everything's very, very technical. And a lot of people, now that they've lost trust, aren't willing to just accept "trust me, technically it all makes sense." Again "makes sense" doesn't mean "is fine" or "was a good idea." It just means that a lot of the suggestions or demands or worries are based on misunderstandings.

News story broke on discovery, its history of course goes back further, that's part of what we're all discussing. I'm not enjoying bickering over semantics. Let me know if you want to chat about something else though.

Those aren't opinions, they're facts. Well, with one tiny correction. Placed inside another library's namespace* It was found and identified at the beginning of the story. Again, the topic of discussion was a vacuum of information. Nobody's disagreeing on what the code did or how it hid itself. Those have all been identified from the beginning.

The existence of the code is the thing that broke the story. We've known about the code since it became a story, because it wasn't a story before then. It's a short file, it can be read in a single sitting, its full behavior breakdown was available same-day. There was never a info vacuum on that. What I was originally talking about when I mentioned an information vacuum was Anego needing to mention the false positives in their announcement. Not giving clear information on the scope of the false positives is the present vacuum left by their statement. Because the behavior of the code is well-understood for anyone who cares to. If you yourself are unsure how the code behaves, I recommend the breakdown in the first post of this topic. It's short and covers everything. AdditionalStuff.cs doesn't really do much.

No, smuggling malicious code only destroys trust. Not speaking on it creates an information vacuum. You know what they say. It take years.

Coming back around to this now that it's morning, what Cetasaya wrote was specifically It's pretty clear to me that they meant that the devs covered up behaviors of Maltiez's code that the players had to uncover themselves. Cetsaya really didn't mention any of the other potential issues with the announcement or with non-official Anego statements like from Vallen, they invented something new beyond any of that when they talked about the "functions of this malware that the devs have hid."

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.