Hello Jocelyn, hello Werner, > I think this is a bad idea. You most certainly want `\version > "2.27.x"` (with 'x' a number) – there is no guarantee that code > specifically written for 2.27.1 also works in 2.27.2, for example.
Not strictly. 2.27 is development release, so it does make no guarantees on API stability. But I thing neither does probably Jocelyn want to guarantee to support each single development version out there. A development version is by definition ill suited for a platform like this, so using development version there probably only makes sense for experimental stuff anyway. > You might check what Jean has implemented for the Wiki; his setup > makes MediaWiki download (and cache) a binary for a given development > version on demand. I am absolutely not sure if this is a good idea. Running arbitrary Lilypond code is already quite a security risk, but depending on fetching binary files dependent on arbitrary user input has a huge attack potential. Also as far as I understand hacklily builds binaries from source. Also Jocelyn: Great news! One thing I have been wondering here: Lilypond is inherently unsafe due to the capability of executing arbitrary Scheme code and embedding arbitrary postscript. As far as I understand it your build system is running on isolated Docker containers, which mitigates these problems partially, but not fully (it may be totally possible to achieve a container break-out from Lilypond). This kind of leaves me wondering again if we should at some point not maybe add a switch that generally disables scheme input, and work towards eliminating most cases that require scheme. E.g. doing something like `\override X.Y.z = ##t` could without issues also read `\override X.Y.z = \true`, and it should be reasonably possible to extend the lilypond language by some kinds of programming paradigms to be able to do most music functions, callbacks and stuff in native Lilypond code. I think that would in the long run make such systems much safer. Anyway, thank you for your great work! Cheers, Tina
signature.asc
Description: This is a digitally signed message part.
