| Summary: | New requirements for scripts.g.o | ||
|---|---|---|---|
| Product: | Gentoo Infrastructure | Reporter: | Ian Leitch (RETIRED) <port001> |
| Component: | Dev box issues | Assignee: | Gentoo Infrastructure <infra-bugs> |
| Status: | RESOLVED LATER | ||
| Severity: | normal | CC: | hadfield, security-audit |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Ian Leitch (RETIRED)
2005-07-07 13:11:23 UTC
Last I checked, most "frameworks" don't come with their own http server. I'd like to better understand why this is the only way scripts.g.o can possibly be written. I'm very leery and uncomfortable about installing an untested, unknown web server on a production server. OK, Python frameworks that come with a HTTP server: CherryPy Twisted Zope Webware Aquarium Cymbeline Karrigell SkunkWeb Snakelets Snakeskin One of the main reasons some frameworks use their own server, is so that the Python interpreter remains running in memory and thus vastly improving response times. Initialy we were using straight CGI with our own "home grown" templating engine and session handling. It was clear from early on that the time it took to process a request and generate a response was pretty slow, even for simple pages. The next step I took was to investigate FastCGI (whos implementation requires a server running sperate of the web server to keep the interpreter running in memory anyway) though through conversation with experienced people and its lack of support in newer Python web frameworks, it was clear FastCGI was showing its age. So, with around 2,500 lines of code and no clear direction nor want to start from scratch with a different framework, I began work on our own framework that would make it easy for us to continue development with minimal disruption and in a style we were happy with. We all agree that this site has the potential to become very popular, not just within Gentoo (we plan to release a generic version sometime in the future). Our changing between web technologies reflects our desire to "get it right first time", we don't want to end up with something we'll need to rewrite later on, nor something other organisations won't want to use. The way in which we are writing GLSR allows us to keep it clean and clearly laid out, we will be able to maintain it easily and expand upon it without needing to rewrite large portions. I do appreciate your concerns for security, though, I believe your concerns are _partialy_ unfounded. The server code does not use any eval() or exec() statements in dangerously exposed areas, and only where absolutely necessary. Meaning malicious arbitary code execution exploits will be near impossible (unless Python itself contains the exploit). The server will also be guarded against DoS attacks through the use of code that monitors the average time used to process a request and the frequency of requests being spawned. The server will also be able to run inside a chroot. Needles to say, no code will be made public without long and vigorous testing periods. While you make some good points, I'd rather you try and make this work through apache using some type of fast cgi (mod_fcgid perhaps). What were the main issues doing it this way? I really don't care if its going to give us a few extra MB of ram to be used. I would rather administrate it via apache. Also, why do you need to use the newest python for this? When is this version expected to hit stable? Cheers- FastCGI still requires an application server running to handle the requests received from the web server. It is still subseptable to similar attacks. The framework server can be run behind apache using mod_rewite, which in a sense is similar to FastCGI. You'll still have control over request throtling etc, it just adds a little extra overhead to the total request processing time. Adding support for FastCGI to the framework would require a lot of work and is not something I am willing to do. GLSR uses decorators which are a new feature in 2.4. 2.4 is the version recommended by upstream. The only reason it is still unstable in portage is because of the long testing period it is undergoing to make sure it doesn't break portage in any combination of arch/cflags/etc. I believe it is going to be made stable very soon. you should have discussed these proposed design decisions with infra first to make sure we can support them. From long ago, you know that infra has specific requirements regarding supported technologies. If you want this HTTP server installed, you need to do two things: 1) have carpaski or ferringb do a code review once it's finished to make sure it passes muster with them. 2) have the gentoo security audit team review the http server that you want to install to make sure they don't see any issues with it. I'm happy to meet those requirements. The code isn't ready for review yet, so resolving this bug as LATER. Will reopen when it is. To be clear, #1 above refers to the GLSR code, not the HTTP server code. |