mrcjkb

> Any way of nudging either of us to check, "Hey, something important about LuaRocks, check your email" in a dm

That is exactly what Vhyrro tried to do on Matrix. The room had active messages from July/August and no notice of departure, so we had no reason to assume it wouldn't reach you.

> or a message to anyone else related to LuaRocks

That's how we got the link to the Matrix/Gitter room in the first place.

> Were you a politician in another life?

No, but I've been told my great-great-grandad was :)

I'll send you an e-mail from my address and I'll ask Vhyrro to forward the original emails to you again.

> I'll just be blunt, I find this very hard to believe.

Email was the primary contact mechanism listed in the SECURITY.md file on GitHub. On your GitHub profile, you have listed links to socials (Mastodon/Bluesky/Twitter), your e-mail address, your personal website, and a video game website.

Messaging or tagging you there about an unpatched RCE would have effectively been a public zero-day disclosure, which we strictly wanted to avoid.

> Did you instruct other people not to use it within rocks.nvim?

That, too, would have been a public disclosure. All we knew at the time was that there appeared to be a second security researcher testing your site. In such situations, when there exists no perfect way to handle things, it's better not to "drop everything and panic", and to attempt *private* outreach via *defined* channels.

> statements like that make it hard for me to give you the benefit of the doubt regarding your attempts to contact me.

Rather than going back and forth on motives, how about we focus on establishing a clearer direct line of communication for the future?

> specifically the actual exploitation on the production server

Since I did not conduct the research myself, I am not in a position to comment on the technical details of it.

I guess if they did land in your junk folder, Gmail may have purged them automatically after 30 days. After not receiving an email response, Vhyrro asked in a group chat if there was any direct line of contact with you or Hisham that wasn't email. That's when someone gave us the luarocks gitter link. Apart from that, we couldn't find any alternative way of reaching you.

I don't have the exact subject line, but I assume Vhyrro used his email address that is linked on his web page. He initially tried contacting you via the e-mail address listed in https://github.com/luarocks/luarocks/blob/1c9266d6521c16e126.... Have you checked your junk folder?

I maintain Lux with Vhyrro and feel I should clarify what actually happened here... I’ve gone through our archived Matrix chat history to clear up the timeline.

On August 7th, Vhyrro messaged me after noticing someone had uploaded malicious rockspecs, `bcrcewon-1.0.rockspec` and `7e0b94029db0`, to luarocks.org. I suggested we notify you and Hisham and gave him Hisham's e-mail address (which I had in my address book, since I had been in touch with him before and based on prior experience knew you were hard to reach). Vhyrro found your Gmail address and sent you an email on August 7th:

--- > I've noticed that somebody on luarocks.org has uploaded two potentially malicious rockspecs: [...] These two packages contain luajit bytecode instead of traditional Lua code, which means they could contain some sort of sandbox escape and could have done some damage on the actual server itself, and may be worth investigating. Coincidentally, I've been researching this exploit vector myself over the past week, but in isolation and on my local docker run of luarocks-site. It's entirely plausible that luajit bytecode has some out-of-bounds read or write which could spell trouble for the real site, which is why I am writing you with such concern. I haven't dissected the bytecode yet, and so I can't test if it works, but it might be worth preemptively rolling out a fix. Maybe a check that disallows bytecode uploads? Seeing someone attempt a similar thing on the main luarocks site is not good news, so I recommend having a look on the main server to see if anything got compromised. ---

On August 14th, Vhyrro told me he had achieved full RCE (reproduced locally on his docker instance). He spent the next day cleaning up his POC to make it consistently reproducible. On August 15th, he sent you a second follow-up email to your Gmail address. We agreed to wait for a response for 2 weeks and then look for alternate channels to reach you on. On August 16th, he told me he was considering messaging Hisham because his previous email to you about the guy pentesting your site had gone unanswered. A day later, Vhyrro again asked me if we should try reaching out to you on other channels. I urged him to give it some time because we know you & Hisham maintain LuaRocks in your free time, and we don't want to contribute to FOSS maintainer burnout.

On August 20th, we joined the official luarocks matrix room (#luarocks_luarocks:gitter.im) and found your personal Matrix handle. That's when Vhyrro DM'd you on Matrix.

Finally, on September 10th, over a month after his initial warning about the live attack and weeks after his follow-ups regarding the RCE PoC, having received no response across email or Matrix, Vhyrro submitted the report to CERT/CC.

Regarding your comment on Lux: Dismissing our work as LLM "vibe coding" (it's not) and claiming we acted out of self-interest is an unfair personal attack. We did all we could to try and warn you early while giving you enough time to address a severe issue without causing unnecessary panic.

> Lua was conceived as a configuration language

That alone is a pretty weak argument.

> Trying to abstract this away behind a CLI seems like it misses the ethos of Lua.

With `lx add <package>`, you can install the package and add it to und config file in one step. And do things like fail if the package or version doesn't exist or isn't compatible with your system.

You can provide editor plugins or use LSP to give users hints if there's an update available, and use code actions to update them, etc.

> It’s also a tad strange that a package manager designed for Lua isn’t written in Lua.

Again, the fact that Lux relates to Lua is a pretty weak argument for choosing Lua as a language to write or configure it in.

Lots of Lua libraries and packages aren't written in Lua, but are built with Lua bindings. Lua (which as you yourself just mentioned was conceived as a configuration language) is a pretty poor choice for something with the scope of Lux. In fact, luarocks was recently rewritten in Teal. Lux has a Lua API (lux-lua) which means it can be embedded or used as a Lua library.

> Presumably Lua developers already have Lua installed, know Lua, and would more likely contribute to a project written in Lua.

We're not worried about finding contributors. If anything, what we need are high quality contributions. Lua developers who only know Lua are not what we're looking for.

Right, my bad. Still, being able to do more to aid the creation and maintenance of packages than just install packages doesn't make something "not a package manager".

It's just a silly pun. Search for "moon illuminance" and perhaps you'll get it :)

Lux helps you install and create/maintain packages. Linting is a useful step in the creation of packages.

Pip lets you create virtual environments. Does that mean it's an environment manager, not a package manager?

(╭ರ_•́)

That's a neat idea, but it would mean we'd have to maintain our own library. When editing with the CLI, you have to make sure you preserve comments, which the toml-edit crate does quite well.

Good thing we're not giving options for no reason other than to give options ;)

> presumably because that's what Cargo does.

Nope. We chose TOML as the default for various reasons:

- Simplicity. There are use cases for a turing complete configuration language. Lux is not one of them.

- Ergonomics. The ability to edit it using the CLI (technically, that could be possible with Lua too, but it would be a lot more complex and not a very pleasant UX).

> which, I don't know if that's the right call?

The reason we currently support importing a Lua extra.rockspec is ease of migration for complex projects, e.g. with platform-specific overrides (not yet supported by the TOML spec).

- It's not at the top level namespace, it's usually in the `vim.g` or `vim.b` namespace. There's no more namespacing than with a Lua module + function.

- global configuration variables don't have to be tables. They can be a union of `table | fun():table`, which enables laziness. [rustaceanvim does this, for example](https://github.com/mrcjkb/rustaceanvim/blob/12504405821c0587...).

- lazy.nvim's heuristics to auto-detect and invoke `setup` functions and pass "config objects" are a hack that could just as easily have been implemented around global config variables. This is a symptom of the problem, not a solution.

- If you don't need any code to require the plugin, there's also no need to keep the configuration and the code to require it in the same place.

- If a plugin is implemented correctly (by not making lazy loading the responsibility of the user), there's no need to worry about when the user sets the global variable.

- Most plugins' `setup` functions are idempotent. If you want to provide the ability to reconfigure your plugin at runtime, you can provide a `reload(opts)` function that sets the global config variable and then reinitialises the plugin. Or, you could add a metatable to the config variable that triggers a reload if the plugin has already been initialised. There's hardly ever a valid reason to force the coupling of configuration and initialisation on your plugin's users.

His use case is mini.nvim, a huge bundle of plugins where you most likely don't want each plugin initialising automatically.

He and I are on very opposite ends of the "setup spectrum", but we have found common ground, which is that you shouldn't cargo cult it: https://github.com/neovim/neovim/pull/35600/files

You don"t have to use a separate variable prefix for each config option. A plugin's config variable can just be a table/dictionary.

Neovim provides the same mechanisms as Vim for Lua plugins. The problem (and part of my motivation for writing the nvim-best-practices document) is that not enough plugins use them.

Edit: The Neovim setup antipattern is the Lua equivalent of writing Vimscript functions in autoload and asking users to call them in their configs instead of doing so automatically.

> Load the table

If it comes from an impure function, you don't know if you'll get the same result each time you evaluate it.

> Modify. Serialize to file.

And potentially lose information.

You mean my Hakyll site? It's mot meant to be :)

That doesn't seem very ergonomic - especially for the use cases we have in mind.

Lua has evolved and is used for a lot more today than it was initially created for.

You might be surprised how well that works :)

One of the motivations for Lux is to improve the nixpkgs Lua and Neovim ecosystems.

Only the `lx --help` and man pages.

We want to be able to write updated dependency specs to the manifest.

That sounds like a great idea! I've opened [an issue](https://github.com/nvim-neorocks/lux/issues/550) in our repo. Feel free to ping us there :)

The usefulness of a local Lua bundle depends on whether you're packaging a library or an application. pkg-config can search by version, so you're not going to end up trying to build a Lua 5.4 package with Lua 5.2 with Lux. If you need a reproducible Lua installation, you can configure pkg-config - That works quite well in nixpkgs, for example. Or, you can just disable pkg-config and let Lux install the correct Lua version for you. We don't provide a way to dump a Lua bundle, but in principle that would be easy to add if users request it.

Yes, we have a `lux-lua` library (which we will need to bundle with `lux-cli`) that exposes a `lux.loader` module. It uses the lockfile to resolve dependencies.

With Lua, it becomes near impossible for a program like lux to edit the manifest.

For example, how would I `lx add <dependency@version>` if the `dependencies` table might be generated by a Lua function?

Lux defaults to TOML, but if you really want Lua, it also supports an `extra.rockspec` in the project root, which shares the same format as the luarocks RockSpec format.

- There's an equivalent `lx path bin` command, but there's also a `lx run` that lets you run installed packages.

- We're still quite early on in development, so documentation and things like error messages will need fleshing out.

- We don't have luvit integration yet

- Yes, it also works with LuaJIT, either via pkg-config or by installing LuaJIT headers using the `luajit_src` crate.