On Thu, Apr 08, 2010 at 02:07:52PM +0200, Reinhold Kainhofer wrote: > Am Freitag, 2. April 2010 02:58:38 schrieben Sie: > > 1. It uses PHP, which I know nothing about. I thought this was > > Wow, I thought any CS student would definitely have heard of the most-used > scripting language on the web.
Well, CS is not computer programming. Also, I didn't say that I hadn't heard about it. (ok, I overstated the "... know nothing about" part. I meant to say that I didn't know anything more than somebody would get from a 30-second wikipedia article skim, which IMO is close enough to "nothing" :) > and the majority of all web applications is written in PHP, so > its security cannot be that bad in general... Does that apply to windows and internet explorer? Especially IE 6.0 from 5 (or whatever) years ago? Everybody uses it, after all... ;) (to people wanting to wave a banner (i.e. Valentin): you're equivalent to a 30-second wikipedia skim) > > With those factors in mind, we have a few options: > > a) Reject the patch. We say "yeah, that looks cool, but sorry, > > we can't fit it into lilypond.org and/or nobody wants to work on > > the integration / fix the remaining issues / etc". > > Once you have started using that patch, you won't accept that as a viable > option any more ;-) That search box is even better than the TOC on the left... That could be the case. Since I never use lilypond and only look at the docs when evaluating a patch, I'm not the best person to judge whether or not this would be useful. If somebody tries it out (that's why I included the earlier links to it) and gets excited, great! They can do the bulk of the work on this project, and I can review or supply hints as needed. > > b) Accept the patch, but disable it in a normal build. We > > integrate it with the rest of our build system and docs, but leave > > it as an alternate configuration option. People building the docs > > locally, > > No, that won't work. You need to have the docs installed on a web server. If somebody can build the docs locally, they can certainly set up apache. IIRC it's even installed by default in ubuntu. (if not, then it certainly wasn't hard to get it installed when I wanted to test some web stuff) > > c) Accept the patch, disable it on a normal build, enable it on > > lilynet.net (which IIRC has tons of resources), and then create a > > We can use that to check out whether there are any resource problems created > by the ajax. Definitely! > > d) Accept the patch, make it default, host it on lilypond.org. > > Unless there's a substantial amount of interest from skilled PHP > > and web security people, I do not like this option. > > The #1 security problem in general is SQL injection attacks. Since there is > no > SQL involved, we don't have that problem. More CS researchers include DoS (denial of service) as part of "security" -- so if this PHP script requires a lot of disk access or CPU power, an attacker could easily tie up the resources of the web server. Again, if somebody is running this on their own machine, I wouldn't be concerned about this. But since I don't know the details of our shared server, I'm reluctant to stick it on there. An alternative client-side solution: theoretically, we could include the index entries inside javascript, then search *that* list in javascript, and generate a list of URLs from that. This option would increate the amount of stuff to download, but the searching wouldn't touch the server disk or CPU at all. Is the increased download size worth not having to worry about server-side security? Offhand, I'm not certain it is. OTOH, I'm not certain that it isn't. > As I said in my original submission, this is just a proof of concept. If > there > is interest, one needs to tighten these things, of course. I think it's definitely interesting. I am personally enthused? No, but I'm the project curmudgeon, so I'm not *supposed* to be enthused by anything. :) I'm hoping that people *will* be interested, and will start thinking+working on this issue. Cheers, - Graham _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
