[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: daloradius (updated package)

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

> 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

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

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

> 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

This is even more reason to leave daloradius behind:
1. Debian has quite enough vanity packages that only the maintainer
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

So either rewrite daloradius or move on to a different language and
learn how to package a simple, compiled, application.


Neil Williams

Attachment: pgpJbNAje6UVo.pgp
Description: PGP signature

Reply to: