Talk:LuaSandbox

Good evening. The new enterprise distributions are shipping with Lua 5.3. Any chance for an upgrade to support this version?

Thanks  :)

Please see T178146, there are currently no plans to move away from 5.1.

I can't find any instructions how to install this specific version of lua. (I was trying download and run make but it has some error) is there any documentation for how to get everything up and running?

No, it's not possible currently.

For anyone who is on Plesk hosting, or considering to move to Plesk, and is sad to miss out on all the wonderfulness that is Lua because of shared hosting restrictions and what not, don't give up but please vote for the following feature request:

https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/46899301-add-luasandbox-for-mediawiki

Lua/Scribunto is not only incredibly useful, but may become one of few viable alternatives when Parsoid has made the move to parallel parsing and extensions like Variables and Arrays are no longer guaranteed to work.

Let's not 'miss the boat' and please make your voice heard.

I tried to install LuaSandbox under windows using the pre-built DLLs. It turns out that the lua5.1.dll DLL should not be kept in the same place as the extension, but in the PHP directory itself (where php.exe is located).

Hello there, I would like to know if LuaSandbox is compatible with Openlitespeed? I'm running a private MediaWiki site and want to shift to Openlitespeed so want to confirm if LuaSandbox will work on Openlitespeed.

Thank you

LuaSandbox is compatible with PHP 8.1.

Hello,

do you have a date for php 8.1 support?

cordially

LuaSandbox should already be compatible with PHP 8.1. Are you running into any issues?

Hello,

My reverence was not up to date, everything is now good :)

Thanks

May I know where I can get luasandbox extension for windows? and the installation or build step for windows.

Hello,

do you have a date for php 8 support?

cordially

The version of LuaSandbox in Git supports PHP 8.0 if you'd like to try it out. We are working towards a 4.0 release soon, but still have a bit more work to do. See https://gerrit.wikimedia.org/r/c/mediawiki/php/luasandbox/+/654962/.

Can anybody review the fix for a memory leak: https://gerrit.wikimedia.org/r/c/mediawiki/php/luasandbox/+/628088?

I wonder what paused-PHP to PHP counted: yes (0.1s of 0.2s) instead of the expected paused-PHP to PHP counted: yes (0.2s of %fs) in the paused-PHP to PHP counted test (timer.phpt) under php 7.4 could mean.

That test had passed for a change I introduced (https://gerrit.wikimedia.org/r/c/mediawiki/php/luasandbox/+/626884/2#message-4a6b5fa8c1ec0e6e5f34d1ebf4cbd8881a86a119) in my build but not at https://integration.wikimedia.org.

Already in Phabricator as T213437, no need to split the discussion. "The devs" would be happy to fix the bug, but first someone needs to both reproduce and debug it. We've been unable to do the former, and it seems Jeblad refuses to try to do the latter.

Luasandbox gives a sigsegv on at least amd64 but the devs refuses to accept it. After testing on several OS and versions of the OSes, both in host and client, I am pretty sure it is consistent. I have not tested on other archs, but feel free to do so.

If you must do extensive testing, then try to avoid the luasandbox, use the standalone solution.

Having several competing systems that all messes with the stack is not very safe. I wrote a pretty long report where and how it sigsegv, but when devs started to demand I should provide "proof", I got feed up and deleted it.

Someone else should do the investigation, perhaps the dev will belive them. In the mean time hope that someone find the bug and fix it, before someone find a way to exploit it.

Code throwing a sigsegv from activity on the stack is a pretty good indication of a serious malfunction, but hopefully not something that can be exploited. (Can always hope…)

Yes, I have reported the bug, and yes I have warned about this.

For what it is worth; I'm not using luasandbox myself, as I suspect this is not only an annoying bug, but a security issue. (The code manipulates the stack and gives a sigsegv, so yes, it is most likely a security issue.)

The extension throws sigsegv, but Anomie among other refuses to accept it. This is not the way to handle a bug report, and especially not a report over something that has all signs of being a security issue.

If you think it's such an important issue, why do you refuse to help debug it? Instead you're here spreading lies and FUD.

Pretty nice reply? The darn code sigsegv and when reporting it I'm being told "Instead you're here spreading lies and FUD." It is … unbelivable!

Wasted a week on trying to figure out why and how, and then got a "this bug don't exist". No I have not created this code, no it is not my responsibility to debug the darn code. I have reported the bug, and thats it.

Debugging and fixing faulty code is the responsibility of the devs who made the code, and guess who that is?