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. http://qa.debian.org/developer.php?login=codehelp@debian.org http://www.linux.codehelp.co.uk/ http://www.emdebian.org/ http://sourceforge.net/users/codehelpgpg/ > 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 far. > 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part