jdev - 2024-01-23


  1. moparisthebest

    Or memorize when it does and does not need done 😱

  2. moparisthebest

    lovetox: enjoy https://eqeq.js.org/

  3. moparisthebest

    Actually is python even saner there? I honestly don't know

  4. Zash

    Only Lua is sane!

  5. debacle

    Speaking of Lua (and here I go pretty off-topic): Can I easily integrate Lua as a safe interpreter in a C application? With safe as in "trust any user script, don't have any file system access, let alone network"? I did this once with Python and I had to seccomp like crazy.

  6. MattJ

    debacle: yes, it's one of its primary use cases and it's indeed much easier than Python

  7. MattJ

    Of course there are different levels of "safe" - you can trivially remove I/O access, etc. but Lua alone won't protect you from the user writing infinite loops or using loads of RAM (those things can be handled in other ways)

  8. Zash

    So 80% of the work is easy, but the remaining 80% takes some more work!

  9. Fishbowler

    I like JavaScript. No guardrails. Sure, I'll run. I might not do what you expect, but I'm certainly gonna run.

  10. Fishbowler

    The unintended bits, sure, a little weird. But at least whitespace doesn't have special meaning.

  11. MattJ

    As always

  12. debacle

    MattJ I would not fear infinite loops or RAM eating, because I would run the process with limited CPU and memory access anyway. Do you have a link to a "embedded, safe Lua" howto, maybe? TIA!

  13. debacle

    The other day, I searched for it, and only found sth., which reads "it becomes complicated" :-(

  14. Kev

    If all you're worried about is I/O etc., just embed Lua, done :)

  15. Kev

    You don't need to remove them, they're not part of the language so they're not exposed.

  16. jonas’

    is that so?

  17. Kev

    Oh, I misremember do I? Sorry.

  18. jonas’

    loadfile is I/O, technically

  19. jonas’

    dofile, too

  20. Kev

    Apologies. /me goes back to his corner.

  21. Zash

    Those are provided by libraries, you can avoid loading them or load safer wrappers or variants.

  22. MattJ

    Well yes, by default when you create a new Lua context it has nothing, you have to load in the standard library or whatever you want as an explicit step

  23. MattJ

    debacle, I suggest you start at https://lua.org/pil/24.html

  24. MattJ

    The online version of that book is free, but about an older version of Lua. If you're serious, purchasing a newer edition would be even better, but even the old version will still be 90% relevant

  25. debacle

    MattJ Thanks, I'll check that out. And then pass the task to a colleague, who will have to do the heavy lifting :-)

  26. MattJ

    debacle, notably for your use case, the next page gives a "first example", and it's the call to luaL_openlibs() that it mentions there that you will want to remove/replace in order to avoid the script having full access to the standard library

  27. MattJ

    Finally, if you want to maximize access to the standard library without exposing anything harmful, you can use a wrapper script like https://github.com/kikito/lua-sandbox where they've already done that work (e.g. replacing "dangerous" functions with versions that throw an error)

  28. MattJ

    It's only ~100 lines of code or so

  29. debacle

    MattJ Yes, we probably want math, but not io, etc. And no way to import it later :-)

  30. singpolyma

    debacle: also, while lua or guile may be great for what you want to do, depending on your needs you may also look at wasm, which also has this safe by default property but a lot more frontend languages

  31. debacle

    singpolyma Note, that we are very (very!) limited in respect to RAM and also CPU. Think of a wrist watch :-) I need to check, if one of the languages are compatible with that. E.g. Python is not :-( I'll take a look at WASM, though.

  32. singpolyma

    There are some options to precompile wasm to amd64 and keep all the security properties, but I'm not sure if that's also true of whatever your little device may have, so you may end up with an interpreter still depending

  33. debacle

    singpolyma The only libwasmsomething I found is 64 bit only. Of course, we are still on 32 bit :-) I'm looking at guile right now and I wonder, if/how I can use it without the *huge* standard library. ATM, lua looks at least smaller than guile.

  34. singpolyma

    What kind of 32bit?

  35. jonas’

    Lua is very likely the most lightweight you'll find

  36. jonas’

    it is very deep in a local minimum of useful language design

  37. singpolyma

    For sure, i didn't mean to imply lua was not a good choice, it absolutely is

  38. debacle

    singpolyma armel and armhf in Debian lingo. Pretty outdated, but good enough for e.g. XMPP ;-) Thanks to libstrophe.

  39. debacle

    I like lispy and schemy syntax better than e.g. Lua, but in that case sandbox safety and (lack of) size is all that matters.

  40. debacle

    jonas’ I'm sure, you could tell me how to integrate sed as embedded interpreter ;-)

  41. singpolyma

    Fennel

  42. MattJ

    Yep, Fennel

  43. debacle

    Never heard of https://fennel-lang.org/ before.

  44. pulkomandy

    I guess tcl and forth also go somewhere on that "small but still useful" scale of embeddable languages. But lua seems a good choice to me

  45. moparisthebest

    debacle, why not CHIP-8 :)

  46. praveen

    hi I'd like to get a wiki.xmpp.org account, preferred username Praveen

  47. praveen

    Alex, Ge0rG Guus

  48. praveen

    I'd like to add a project idea to https://wiki.xmpp.org/web/Google_Summer_of_Code_2024#Project_Ideas

  49. Ge0rG

    praveen: roger. can you PM me your email address for the account?

  50. praveen

    Ge0rG, ok

  51. praveen

    sent

  52. akshay

    Hi, I'd like an account too. Praveen and I are from the Prav team. User:Akshay email: akshay@learnlearn.in

  53. Ge0rG

    Error> jdev@muc.xmpp.org/praveen: cancel: Private messages are disabled praveen: can you directly xmpp-send it to georg@yax.im instead?

  54. praveen

    Ge0rG, same as my jid praveen at debian.org

  55. Ge0rG

    akshay: The user account for Akshay (talk) has been created.

  56. Ge0rG

    praveen: The user account for Praveen (talk) has been created.

  57. Ge0rG

    the two of you should have received an initial password

  58. praveen

    Ge0rG, thanks

  59. debacle

    pulkomandy Yes, it seems we'll go for Lua 5.3. I used to use Forth *a lot* and hope, that I never have to do it again :-) Tcl was OK. As most people I used it for GUIs with Tk. Still, I didn't like it much.

  60. Alex

    thanks Ge0rG, for taking care. Was out for a while

  61. MattJ

    debacle: out of curiosity, why not 5.4?

  62. jonas’

    debacle, I seem to recall that 5.3 was the most nasty when looking at memory performance.

  63. debacle

    MattJ jonas’ We build more or less on Debian 10, which has 5.1, 5.2, and 5.3. In a future step, we can try to backport 5.4, if that is much better, esp. memory-wise. I guess, that Lua is easy to (cross-) compile?

  64. moparisthebest

    debacle: beware runaway memory usage with 5.3, they broke the GC

  65. moparisthebest

    Also 5.2 but not 5.1 iirc, good luck

  66. debacle

    moparisthebest I see, so we will go with 5.1, and see later, if we can backport it.

  67. debacle

    This is all so OT for jdev, sorry, sorry!

  68. moparisthebest

    Not really, we only know this because of memory craziness in prosody on those versions, where else would you come across such things :D

  69. MattJ

    debacle: yes, should be trivial to backport 🙂