On Thu, 27 Dec 2007 09:10:14 +0100 "liran tal" <liransgarage@gmail.com> wrote: > > i.e. the problem lies within the package itself because it is an > > intrinsically difficult package to build properly and you would be best > > advised finding something else when you are only just starting out as > > maintainer. PHP is a nightmare for security problems and packaging > > problems. What I say to you is what I would say to anyone reading the NM > > guide for the first time - *don't start with PHP*! (Don't start with a > > compiled library either, they are complex in entirely different ways.) > > The NM guide does mention that libraries are not a wise choice for your > > first package but as it happened, I didn't get the chance of my own > > advice because when I started NM, I was already upstream for a library > > in Debian that needed an update. ;-) So learn from my mistakes and don't > > do things the hard way. > > > Uhm, it seems to me that the daloradius package is actually as easy > as it can be. No, it is not and the fact that you have missed this fact is evidence enough that you are the wrong person to package daloradius (or any PHP code). > It's just a bunch of .php and other related web application > scripts which should simply be copied to /usr/share. If only. These files are scripts that are to be run on an unattended, internet-visible remote server that is not under your direct control and which is likely to be attacked for a variety of nefarious reasons, often by automated bots that can spend all their runtime attacking other sites with dictionary attacks, known vulnerabilities etc.. As maintainer, *you* are responsible for ensuring that your package does not lead to a security breach on those servers - including working around known vulnerabilities in other packages. PHP is well known for security vulnerabilities. There are simple fixes and there are complex problems but the maintainer needs to be familiar with all modes of attack and possible solutions, including testing the application under stress and deliberately trying to break the package. > There's no compilation, no updating of libraries and nothing that would > seem to be complicated... If you think *that* is complicated, you are in for a shock trying to make a secure PHP package. > Maybe I'm missing something but as I see it, > the "package" should simply unpack the web application files into a > directory > and that's it. > > Please correct me if I'm wrong. Absolutely wrong, I'm afraid. Secure PHP is very difficult to achieve and maintain. The code has to be written well, designed for security from the start and maintained rigorously. The "simplicity" of PHP itself only leads to more problems because many people use PHP as their first foray into programming. As I've said before, I write PHP. I have a few bits of PHP that could have been packages and a few that I use that I could package on behalf of the upstream, *but*, the code concerned was not written with security in mind from the very start and it is almost impossible now to make it secure without rewriting every single script from scratch. >> > I'd take that as a hint that you ought to consider learning how things > > work using a different package as your starting point. > > > > I'm not going to advise you on daloradius for a couple of reasons: > > 1. I don't generally sponsor PHP anyway (I will but only if the > > maintainer convinces me that s/he has a firm grasp of the issues > > involved, which you have not done.) > > > Again, I'm either missing something or there's a misunderstanding > of what daloradius is. What kind of php security issues are there? The fact that you can even ask that question shows that PHP is the wrong language for you. Do you know how to check PHP for $_GET and $_POST vulnerabilities? Cross scripting attacks? Malicious URL and form entry processes? Corruptions and error states that would lead to security vulnerabilities? Honestly, with this admission, I could only recommend that daloradius is *NEVER* packaged for Debian as it would be fundamentally insecure, by design. You would have to show me clear and verbose evidence of a wholescale rewrite of daloradius from the ground up with clear documentation of how the new code is designed for security and evidence that none of the old code has migrated into the new package without security review. > 2. I don't think daloradius is the right package for you to maintain > > right now and therefore cannot be the right package for me to sponsor. > > Come back to it once you have learnt a lot more about Debian by > > packaging at least one different package that is not written in PHP. > > > > As far as PHP does, convenience (of programming) is very definitely the > > enemy of security. (Yes, I do write PHP, I do know at least some of the > > problems inherent in that language. No, I would not dare inflict my PHP > > on Debian as a package, I stick to the few web servers to which I have > > root access so that I can step in and rescue it when things go wrong.) > > > So the reason to reject a project is because of it's programming nature > that may be very much exploit-able and unsafe? Yes. The reason is simple: why would I waste all this time preparing daloradius for sponsoring, only for the security team to hit it with a half dozen release-critical security bugs that would see the package removed before it even migrates into testing? Security is a serious issue in Debian - it is probably the most common reason for RC bugs in packages destined for a web server. It is also the most common reason for those packages to be removed from Debian. Debian is known for good security and that is maintained by rejecting insecure rubbish like daloradius. (PHP is insecure by default and has to be secured rigorously - any PHP package that has not been designed for security is de facto insecure - and therefore rubbish - because of the choice of PHP as the language to use.) The worst thing a sponsor can do is introduce a package into Debian that is immediately removed for known security reasons. I know a bit about securing PHP and I will *not* risk uploading a PHP package that has no idea of how to be secure. It is simply too much work to try and secure a package *after* it has been written, security needs to be embedded into the fundamental design of the code. Security is the opposite of convenience and PHP is probably the most convenient scripting language for the WWW - hence the problems with PHP security. > Leave daloradius behind - forget it completely. Move on to a different, > > preferably compiled, package and restart with the NM guide. Don't even > > revisit daloradius packaging until you have had at least one non-PHP > > package successfully sponsored and bug free in Debian testing. > > > I can't leave it alone Neil, it's my baby :-) Then for £$^@ sake learn about PHP security. If you don't know what security issues even exist how can you expect to write a secure PHP project????? This is even more reason to leave daloradius behind: 1. Debian has quite enough vanity packages that only the maintainer uses. 2. This package has not been designed to be secure as you do not appear to be aware of the security problems inherent in PHP. It needs to be completely rewritten from a new, secure, design. 3. Packaging PHP is far more than just copying files. The simplest package *is* a compiled package (application). If this sounds harsh, it is meant to be harsh. It is meant as a stern rebuke of your packaging decisions and programming methods. I cannot put into text how I really feel about this RFS. What I hope to see as a result is a completely rewritten daloradius with detailed explanations of the new secure-by-design coding and clear evidence that every single line of PHP code has been rigorously reviewed for security implications and the nature of the security threats that you have considered - and make sure that list is a complete list. If you cannot do that, do not expect daloradius to ever be a Debian package. So either rewrite daloradius or move on to a different language and learn how to package a simple, compiled, application. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgphiiynP5RW7.pgp
Description: PGP signature