On Dec 27, 2007 11:01 AM, Neil Williams <email@example.com
No, it is not and the fact that you have missed this fact is evidence
On Thu, 27 Dec 2007 09:10:14 +0100
"liran tal" <firstname.lastname@example.org
> Uhm, it seems to me that the daloradius package is actually as easy
> as it can be.
enough that you are the wrong person to package daloradius (or any PHP
Well "wrong" is a harsh word. It's all a matter of knowledge and experience.
> It's just a bunch of .php and other related web application
If only. These files are scripts that are to be run on an unattended,
> scripts which should simply be copied to /usr/share.
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.
This applies to any and every other package that exist in Debian.
> Maybe I'm missing something but as I see it,
> the "package" should simply unpack the web application files into a
> 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.
So this is exactly what I said before - packages in Debian are dependent
upon how secure they are? What makes anyone the judge of which package
is better secured than another? Apache is a package available in Debian,
do you really want me to bring up all the vulnerabilities that were discovered
I think it's absurd to rule out in a snap of a finger "your package is based on
php, I think php is not secure so I don't want it in debian".
Does it make sense to you saying "I don't want to include your package
because it uses php and php is unsecure?" because it doesn't to me.
1. there are other php packages in debian, are they all 100% secure?
and even if I would go over their code and find it to be secure, you said
for yourself that php is insecure in it's nature.
2. daloradius specifically is to be deployed in the backend servers, i.e,
to be managed by the noc crew mostly so it isn't just "out there in the Internet"
3. do you know of a web application which says "I'm 100% secure, I don't need any
silly firewalls and underlying security around me"? because I don't.
usually when these web applications are installed administrators implement
various ways to protect them - ssl, htaccess, firewalling, vpn access and I can
go on and on.
>> > I'd take that as a hint that you ought to consider learning how thingsThe fact that you can even ask that question shows that PHP is the
> > 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?
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
Again and again you are assuming, do you always judge people?
You might be up for a surprise.
I'm wondering if you put on the stand every other guy with an RFS
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.
You are obviously prejudice and I really don't understand what is making
you so bitter nor do I want to. Without showing any actual interest in the application, without commenting on the code or the use of it you have
expressed your absolute objection to even show some interest in it.
> 2. I don't think daloradius is the right package for you to maintainYes. The reason is simple: why would I waste all this time preparing
> > 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?
daloradius for sponsoring,
all this time? waste?
That's a very promising comment from somebody on the mentors list.
If this was some kernel-devel mailing list I would most certainly understand
but coming from someone whose suppose to help and sponsor new comers,
and new packages... I truly have nothing to reply on that.
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?
Oh well, I didn't know that ALL packages that find their way into
Debian are never found to be security-flawed. Not even from the start.
So the security team finds a bug, half dozen of it or more, is this not
the whole point of a development process where QA and tests are
performed and the development team is to fix them?
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
What's the point of doing that? after I'll do that you will just say
"well your code is secure but I really don't like PHP so I'm really not going
to take this RFS anywhere".
You have already made up your mind and made it very clear to everyone.