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

Re: RFS: daloradius (updated package)

On Thu, 2007-12-27 at 11:51 +0100, liran tal wrote:
>         > 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.
> This applies to any and every other package that exist in Debian.

Not true. Since when do internet-visible servers run KDE or Gnome ? Even
if installed, these binaries are not run on such a server. Security
involves packages that are run on remote servers, primarily. Desktop
packages have less need for security - it's more about preventing data
loss, not overwriting configuration files, etc..

> So this is exactly what I said before - packages in Debian are
> dependent
> upon how secure they are?

For packages where:
1. the language is already known to be vulnerable (PHP) and/or
2. where the package is intended to be run on remote servers,
the answer is "yes" - packages are not uploaded to Debian if there are
known security issues and maintainers are not sponsored if the sponsor
is unable to get rapid, accurate and useful answers to all and any
enquiries relating to security.

I don't mind if other enquiries take a little time or need explanations.
I do care if security enquiries are ignored or avoided, as here.

>  What makes anyone the judge of which package
> is better secured than another?

The maintainer, the BTS and the security team. In the case of sponsored
NEW packages, this tends to be mostly down to the sponsor. So in this
case, me. You might not like that but it is still true. You need to
provide accurate and precise security information without delay for any
sponsor to be able to work with you.

>  Apache is a package available in Debian, 
> do you really want me to bring up all the vulnerabilities that were
> discovered
> in it? 

How many have not been fixed? Are you really comparing a few hacks in
PHP with the most common web server application on the internet?
Comparing one developer with the cast of thousands who review the apache
code? Do you *know* how arrogant that makes you sound?

> 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". 

Well, it is my judgement - as sponsor - and it is your responsibility
(as maintainer) to provide all the evidence that the sponsor needs. My
assessment was, and is:
1. daloradius is PHP and despite repeated requests, the maintainer has
refused to provide information on how the known weaknesses in PHP have
been overcome within the daloradius codebase.
2. Without security information, it is a waste of time to review PHP
code as the principle reason for PHP packages causing trouble within
Debian is the security of the codebase.
3. As maintainer, you have so far refused to provide any useful security
information on this package and I am unable to proceed with a review.
4. Without a security review, daloradius has no place in Debian.

You are not a DD. I am. I need evidence of what you have done within the
code to guard against known security problems in your chosen language so
that any upload I make is not immediately rejected by the ftp-master
team on the basis of inadequate security precautions. Such rejections
reflect badly on me, as sponsor, and I will not waste time on packages
likely to be rejected.

> 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.

It does to me - you'll just have to deal with that.

PHP *is* insecure, by default. Therefore, in order to have any chance of
getting any PHP package accepted by the ftp-master team and the security
team, *I* (as sponsor) must ensure that the package details exactly what
steps have been taken to handle the known security problems inherent in
the chosen language.

Without that information, it doesn't make any difference what I do or
say - the package will likely be rejected from Debian by the ftp-master
on the advice of the security team. You have no right of appeal on this.
Their judgement is final - provide the evidence or don't get the code
into Debian. It is as simple as that.

All I'm asking for is the evidence that you have incorporated secure
methods within the codebase. Your lack of response has to be taken as
evidence of a lack of secure code within the package. Provide the
evidence or fix the code - I have no other options here.

> Maybe because:
> 1. there are other php packages in debian, are they all 100% secure? 

Those packages have been accepted by the relevant teams on the basis
that the code did originally take steps to implement secure methods of
using PHP, that if those methods allowed security issues to arise then
the maintainer had already shown clear evidence that s/he was willing to
implement the fixes rapidly (security uploads are usually higher
priority than others) and that those fixes were actually likely to
properly fix the security issue itself. None of that evidence exists for
this package so you must provide it.

> 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.

Yes, it is. So each package has to prove that steps have been taken to
overcome the weaknesses inherent in the chosen language - or else
rewrite the package in a different language.

> 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" 

Makes no odds. It requires support from the security team and therefore
I need evidence that it is not going to add to their workload.

> 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.

No package needs to say that. What I need is evidence that this package
has implemented methods and code standards that protect against the
weaknesses of PHP *and* that *YOU* as maintainer are willing and able to
implement fixes for any remaining issues rapidly and correctly. The
package fails on both counts so far.

> 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.

Debian is not in the game of adding to the workload of those people. The
maintainer takes the majority of the burden - you. As sponsor, it falls
to me to ensure that the maintainer takes the responsibility seriously
and implements fixes rapidly and correctly. You have failed to persuade
me that you would be capable of fulfilling this responsibility.

> Again and again you are assuming, do you always judge people?

The role of sponsor is to make a judgement call on whether the package
is suitable for inclusion into Debian and whether the maintainer is
capable of fulfilling the responsibilities required. You have so far
failed to accept criticism in a manner that would encourage others to
work with you - that is my judgement of you. It is up to you to change
that judgement by your future behaviour.

> I'm wondering if you put on the stand every other guy with an RFS
> inquiry. 

Every RFS that I review, yes. Most pass with flying colours. You have,
so far, proved obstructive, argumentative and unhelpful - not just to me
but to others on this list.

> 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.

The mere fact that I replied to the RFS shows that I did have some
interest in it - my enquiry that you provided adequate evidence of
security implementations in the package has still not been answered.

I will not spend time reviewing a package without this information.

>         Yes. The reason is simple: why would I waste all this time
>         preparing 
>         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.

So you don't value my time? You think I (and other sponsors) spend all
day with nothing to do but wait for emails on this list? Dream on.


> 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? 

The point is that the maintainer needs to take all reasonable
precautions to not introduce bugs that need the attention of the
security team in the first place - trust me, they are far busier than
you. Do not wait for the security team to find the bugs - find them and
fix them before requesting sponsorship. QA and security have more than
enough to do already - do not add to their workload.

> 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". 

Not at all. If you can provide sufficient evidence then I am prepared to
change my view of the package but it will require detailed evidence of
exactly what security threats you have considered and how you have
implemented secure methods within the codebase. However, you will also
have to change your behaviour before I would be willing to sponsor your
packages with you as maintainer. The best option might be to restrict
yourself to upstream work and see if you can work with someone else as
maintainer by retitling the ITP as an RFP bug. I do not think you are
the right person to maintain this package, based on your behaviour so

> You have already made up your mind and made it very clear to everyone.

Provide the evidence that I have requested on several occasions and I
will make a judgement about whether the package has improved. However,
your continuing trolling on this list only reinforces my judgement that
you are not the right person to maintain a PHP package in Debian. Even
if the package is improved, I do not think that you should be the
maintainer because you have shown a distinct lack of ability to work
with others or respect their input and time.

> I honestly have no problem with anyone saying "hey look I have
> reviewed 
> the code and before it finds it's way into debian you really have to
> review it
> and try again later"

Before I review the code, I need evidence of what you have done to
handle the known security weaknesses in PHP. Then I can review the code
but I will not waste more time reviewing PHP code without a security
profile. I have asked you for that information in each reply I have made
in this thread.

> from the start you have rejected the package 

No. I requested information on the security implementations in the
codebase and outlined why this is not the best package to choose as the
first for a new maintainer, recommending that you tried a different
package to answer your original queries and then came back to this
package when you understood more about general Debian packaging.

> I hope for the sake of others that you will not be their Mentor,

For the record, I have had very good experiences with several
maintainers via this list. I have very good relations with half a dozen
maintainers who I mentor and sponsor on an ongoing basis. The
maintainers whom I sponsor have shown that they value my time and my
input and they are all able to handle criticism and requests for
information without trolling. I will not spoon-feed those whom I
sponsor. A maintainer is required to be able to find out the necessary
information from the guides and resources already available.

> as you are clearly not acting like one. If this is all a waste of
> time 
> for you maybe you should consider moving to a different position in
> the Debian family.

I have no intention of doing that. I intend to continue sponsoring
packages via this list and reviewing whichever RFS emails spark my
interest. It is up to you to change your future behaviour.


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: