On Oct 18, 2011 8:51 PM, "Sumana Harihareswara" <sumanah(a)wikimedia.org> wrote: […] FWIW, when first saw Ting's mail I assumed that using an address I'd never seen before instead of his foundation address was intentional and an indication that he was not acting in his official capacity. But maybe I was reading to much into it; he can certainly clarify explicitly or make any other comments if he likes. -Jeremy

On Sun, Oct 23, 2011 at 6:55 PM, Platonides <Platonides(a)gmail.com> wrote: Tim had at the time was that Lilypond does not (or, at least, at the time did not; I haven't kept up with LilyPond development news at all) limit memory or time usage. For certain pathological (or well-crafted, if you're an attacker) inputs, the process of converting LilyPond syntax to an image with sheet music may consume a very large amount of time and/or memory. From my casual re-reading it seems that it's quite easy to write an infinite loop in LilyPond. LilyPond does have a safe mode, but it does not protect against infinite loops, nor does it claim to. Clearly, this presents a resource exhaustion / denial of service vulnerability given that certain inputs can cause the LilyPond interpreter to run forever, and any user that can edit or even preview pages can inject such inputs. So in order to run LilyPond on WMF servers and be able to feed it arbitrary user input while protecting against resource exhaustion, we need to be able to limit the amount of time and memory that each LilyPond process can use, either in LilyPond itself or in the MediaWiki extension that spawns LilyPond processes. To my knowledge, no one has volunteered for this task so far. Roan

On Sun, Oct 23, 2011 at 9:14 PM, Neil Harris <neil(a)tonal.clara.co.uk> wrote: Yes, that sort of thing is what I meant by limiting CPU/mem usage on the MW extension side. However, someone would have to actually do that, as well as cleaning up the other coding style issues that I seem to recall were floating around Extension:LilyPond in its current state. So far, I don't believe anyone has actually shown themselves willing to do that work. Roan

On Sun, 23 Oct 2011 14:42:24 -0700, Platonides <Platonides(a)gmail.com> wrote: Does that even work? I've regularly had issues with convert commands that can't get enough mem to finish and are never killed so they sit in the process list hoarding it. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Mark A. Hershberger wrote: Am I missing something? The extension has serious vulnerabilities and your answer is to install it on a public wiki? I don't see how this is even remotely helpful. The issue isn't finding people at Wikisource to try out a music module; the issue is that the extension has technical problems that need to be addressed. If people want to play around with LaTeX markup (music-related or not), there are surely a million existing venues on the Web. If, at some point in the future, after the vulnerabilities have largely been resolved, user interface/experience testing is needed, sure, setting up a demo on a labs wiki seems like a great idea. But I have no idea how you'd be at that point, at this point. MZMcBride

Mark A. Hershberger wrote: Sure. I think we agree on the underlying issue: a lack of interest by outside groups (for free). But that doesn't always need to be met by a PR campaign (though perhaps making this a coding challenge is an avenue to explore). There's plenty of money in Wikimedia's operating budget to hire someone to write a solution to this problem. It simply may require eliminating some other positions (Storyteller, Bugmeister, etc.). I think the cost is worth the benefit. And for the price of one or two positions, you could reasonably get three or four big features per year. Alternately, I think eliminating projects such as Wikisource from the Wikimedia umbrella would resolve (or largely mitigate) this issue. No Wikisource, mostly no problem. I don't think it's Wikipedia that's really clamoring for this ability, though it'd be nice there as well. More direct focus on Wikimedia's part would make underlying bugs easier to triage, surely. One option that seems to be a complete non-starter to me is enabling possibly dangerous code, even on a test environment, when the dangers are known and unresolved. I still haven't seen anything to suggest this is a good idea. Once someone has worked on the code for a while and addressed CPU and memory issues, I think a labs wiki is a great idea. But before then? Makes no sense to me. I also can't help but imagine, given only your past actions on Bugzilla, that you would take the interpretation ("a request to make machine-readable musical notation available on the WMF cluster") to mean that if such functionality became available on a labs wiki, the bug could be marked resolved. This is, of course, completely outlandish and ridiculous, but it's what I've come to expect. MZMcBride

On Sun, Oct 23, 2011 at 5:34 PM, John Vandenberg <jayvdb(a)gmail.com> wrote: According to the other thread, nope. -- John

Or we do without any servers, at the expense of older browsers: http://0xfe.blogspot.com/2010/05/music-notation-with-html5-canvas.html Magnus

On Mon, Oct 24, 2011 at 9:22 AM, Nikola Smolenski <smolensk(a)eunet.rs> wrote: It was just a general notion, not recommending a specific implementation or notation. Abc notation rendering (untested): https://code.google.com/p/abcjs/

On 24/10/11 18:23, Owen Davis wrote: If vexflow is simple, capable and safe, could it also be converted to run server-side as an image renderer, using something like node-canvas? If so, then that's potentially a solution for everyone. - Neil