Re: webapps in stable release cyles Was: flashplugin-nonfree in Debian
Hi ! Le Wednesday 22 April 2009 09:07:58 Jan Wagner, vous avez écrit : I've requested a slot at DebConf to discuss this into detail, though feel free to start a discussion already on debian-devel. sorry for coming around with another issue. While reading your comment without giving any details about your ideas, I don't know if our problem maybe related, sorry if not. There are many packages, which are frequently removed from testing right before the release, cause of (potential) security issues and not getting in worries with the security team. Other packages may be obsoleted by upstream and lose their support. This is often the case for web applications. We had something in mind we summarized at http://wiki.debian.org/Proposals/Webapps. I also believe this is an interesting proposal. Additionally, even though webapps upstream can provide a bugfix release with only security-related fixes, due to the nature of the security issues in webapps, this can also mean hudge changes which are not easy at all to review for a security upload. This is was the case for the latest security upload of mediawiki (version 1:1.12.0-2lenny3). However, I wonder if this would need yet another archive, or just an update of a policy, either in backports.org or volatile.. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: webapps in stable release cyles Was: flashplugin-nonfree in Debian
Hi Romain, On Wednesday 22 April 2009, Romain Beauxis wrote: However, I wonder if this would need yet another archive, or just an update of a policy, either in backports.org or volatile.. DUNNO for volatile, but the ftp-master of bpo, which is actually doing the main work clarified, that don't like to be responsible for PHP based packages, which is the most potential languages of the applications which matches the criterias. With kind regards, Jan. -- Never write mail to w...@spamfalle.info, you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.1 GIT d-- s+: a- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part.
Re: webapps in stable release cyles Was: flashplugin-nonfree in Debian
[Dropping -release and -volatile] Jan Wagner wrote: Hi Romain, On Wednesday 22 April 2009, Romain Beauxis wrote: However, I wonder if this would need yet another archive, or just an update of a policy, either in backports.org or volatile.. DUNNO for volatile, but the ftp-master of bpo, which is actually doing the main work clarified, that don't like to be responsible for PHP based packages, which is the most potential languages of the applications which matches the criterias. I think the situation is more or less (please pay attention to that, will clarify later) that maintainers don't feel like doing the necessary work to fix the issues as they are found. I'm in no way saying that they are lazy or irresponsible, web apps are by nature more exposed to security threads than most other kind of apps; at times upstreams are not helpful, at times upstream lacks the necessary knowledge, at times it is the maintainer, at times they are both, at times it is the scripting language as well. But any app that won't be properly supported should not be shipped in a stable release, and proposing yet another repository doesn't feel like the right solution. Instead, in the perfect situation, maintainers should learn more about the language of the application, the security implications, detecting and fixing security issues, etc. so that they take care of their packages. The goal is to work towards improving, not just giving up by creating another dump repo. And since there are cases where it is not feasible or even doable to work towards improving the security of the app because of upstream, those cases should be re-considered and probably better removed. Re-writting is not always a bad idea. (No need to reply with messages such as who is going to re-write it?; please remain focused on the topic.) Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: webapps in stable release cyles Was: flashplugin-nonfree in Debian
Le Wednesday 22 April 2009 12:35:12 Raphael Geissert, vous avez écrit : [Dropping -release and -volatile] Jan Wagner wrote: Hi Romain, On Wednesday 22 April 2009, Romain Beauxis wrote: However, I wonder if this would need yet another archive, or just an update of a policy, either in backports.org or volatile.. DUNNO for volatile, but the ftp-master of bpo, which is actually doing the main work clarified, that don't like to be responsible for PHP based packages, which is the most potential languages of the applications which matches the criterias. I think the situation is more or less (please pay attention to that, will clarify later) that maintainers don't feel like doing the necessary work to fix the issues as they are found. I'm in no way saying that they are lazy or irresponsible, web apps are by nature more exposed to security threads than most other kind of apps; at times upstreams are not helpful, at times upstream lacks the necessary knowledge, at times it is the maintainer, at times they are both, at times it is the scripting language as well. But any app that won't be properly supported should not be shipped in a stable release, and proposing yet another repository doesn't feel like the right solution. Instead, in the perfect situation, maintainers should learn more about the language of the application, the security implications, detecting and fixing security issues, etc. so that they take care of their packages. The goal is to work towards improving, not just giving up by creating another dump repo. And since there are cases where it is not feasible or even doable to work towards improving the security of the app because of upstream, those cases should be re-considered and probably better removed. Re-writting is not always a bad idea. I think you have a wrong view, probably due to the fact that you don't maintain or develop webapps (I might be wrong, please apologize in this case). Security issues in webapps are very very different than for other software. Web technologies imply the combined use of a lot of different protocols, software, etc.. For instance, there are security issues in webapps that are in fact due to the combination of both the browser's bad implementation, including software we don't actually maintain such as IE, PHP features and the web server options, being specific to apache, say. I have mentioned in my previous email the latest security upload of mediawiki, did you just look at it ? I gave this example precisely because mediawiki upstream release management is one of the most serious I know in webapps. And even though they fix issues with care, and their code is surely very good, then this ends up with *huge* security patches. Or, are you claiming that we should rewrite mediawiki ? Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: webapps in stable release cyles Was: flashplugin-nonfree in Debian
[Don't CC me, thanks] Romain Beauxis wrote: Le Wednesday 22 April 2009 12:35:12 Raphael Geissert, vous avez écrit : I think you have a wrong view, probably due to the fact that you don't maintain or develop webapps (I might be wrong, please apologize in this case). I do not maintain any web app *in Debian*, but I do develop and maintain web apps. I don't see the point in making such probably right statements. Security issues in webapps are very very different than for other software. Web technologies imply the combined use of a lot of different protocols, software, etc.. I don't see think they very very different just because they use different protocols, software, etc. I did say: [...] web apps are by nature more exposed to security threads than most other kind of apps [...] For instance, there are security issues in webapps that are in fact due to the combination of both the browser's bad implementation, Which is handled by proper input sanitising, not trusting what the user submits. PHP features and the web server options Which can deal with, either by aborting if a given setting is used, or by normalising. being specific to apache, say. Which is a bug in the server, not in the web application; and attempting to fix or workaround it on the latter just makes the web app more b0rken and often introduces more bugs. I have mentioned in my previous email the latest security upload of mediawiki, did you just look at it ? I did look at it I gave this example precisely because mediawiki upstream release management is one of the most serious I know in webapps. And even though they fix issues with care, and their code is surely very good, then this ends up with *huge* security patches. Or, are you claiming that we should rewrite mediawiki ? The issue was mostly caused by a design error (or should I say because it was not quite the best design so that it doesn't sound too rough? and no, I don't and won't claim that my software designs are good or the best; just in case somebody wanted to troll.) Just because there are a set of big patches it doesn't mean that the app should be rewritten (or parts of it, I should have said on my first email.) I was thinking more about wordpress when I wrote that part; because IMHO that's the best that could happen to it. On mediawiki's case there's a huge advantage, because like you said, it is well supported and it is developed seriously (at least compared to the vast majority of PHP apps), and patches are available quickly, which is hard or even impossible to accomplish on an app where fixing one bug exposes four more. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: webapps in stable release cyles Was: flashplugin-nonfree in Debian
Le Wednesday 22 April 2009 18:52:48 Raphael Geissert, vous avez écrit : I gave this example precisely because mediawiki upstream release management is one of the most serious I know in webapps. And even though they fix issues with care, and their code is surely very good, then this ends up with *huge* security patches. Or, are you claiming that we should rewrite mediawiki ? The issue was mostly caused by a design error (or should I say because it was not quite the best design so that it doesn't sound too rough? and no, I don't and won't claim that my software designs are good or the best; just in case somebody wanted to troll.) Just because there are a set of big patches it doesn't mean that the app should be rewritten (or parts of it, I should have said on my first email.) I was thinking more about wordpress when I wrote that part; because IMHO that's the best that could happen to it. On mediawiki's case there's a huge advantage, because like you said, it is well supported and it is developed seriously (at least compared to the vast majority of PHP apps), and patches are available quickly, which is hard or even impossible to accomplish on an app where fixing one bug exposes four more. Well, I am sorry if I hurted you. The matter is that I do not believe it is a correct answer to point fingers at various developpers and claim they are not doing the thing right. It is always better when it comes with a concrete argument. Idealy, I would like as you that things are done the right way. However, my experience and, as I can see from the proposal, the one of others contradict this fact. Pragmatically speaking, requiring the same workflow for fixing security fixes and producing uploads for webapps is rather different than for other type of software. I you want to show that the fault has to be put on the upstream maintenance of the packagers, then you better come with a real explanation of how they should do it and not only general ideas about the way it should be done.. That is why I showed the example of mediawiki. The security issue was basically a wrong handling of MIME types in internet explorer. As you said, the upstream maintainers did some input sanitizing cleanups. However, this ended whith a *whole* new class for fixing this, plus all the required changes to make it work, which apparently spread into a lot of various classes and cases. The full patch can be seen here: http://svn.debian.org:80/viewsvn/pkg- mediawiki/mediawiki/lenny/debian/patches/CVE-2008-5249_CVE-2008-5250_CVE-2008-5252.patch?revision=92view=markup Now, to me this has not much to do with what we characterize as security patches. It is indeed very hard, if not impossible to check wether this will have undesirable side effects, or is minimal. However, I fail to see how this could have been done otherwise, and I feel that pretending this is a minimal security update is somehow not very different than simply upgrading to the latest upstream release, considering the size of the patch... Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: webapps in stable release cyles Was: flashplugin-nonfree in Debian
Hi Romain (and others) On Thu, 23 Apr 2009 09:23:24 am Romain Beauxis wrote: Le Wednesday 22 April 2009 18:52:48 Raphael Geissert, vous avez écrit : I gave this example precisely because mediawiki upstream release management is one of the most serious I know in webapps. And even though they fix issues with care, and their code is surely very good, then this ends up with *huge* security patches. Or, are you claiming that we should rewrite mediawiki ? The issue was mostly caused by a design error (or should I say because it was not quite the best design so that it doesn't sound too rough? and no, I don't and won't claim that my software designs are good or the best; just in case somebody wanted to troll.) Just because there are a set of big patches it doesn't mean that the app should be rewritten (or parts of it, I should have said on my first email.) I was thinking more about wordpress when I wrote that part; because IMHO that's the best that could happen to it. On mediawiki's case there's a huge advantage, because like you said, it is well supported and it is developed seriously (at least compared to the vast majority of PHP apps), and patches are available quickly, which is hard or even impossible to accomplish on an app where fixing one bug exposes four more. Well, I am sorry if I hurted you. The matter is that I do not believe it is a correct answer to point fingers at various developpers and claim they are not doing the thing right. It is always better when it comes with a concrete argument. Idealy, I would like as you that things are done the right way. However, my experience and, as I can see from the proposal, the one of others contradict this fact. Pragmatically speaking, requiring the same workflow for fixing security fixes and producing uploads for webapps is rather different than for other type of software. I you want to show that the fault has to be put on the upstream maintenance of the packagers, then you better come with a real explanation of how they should do it and not only general ideas about the way it should be done.. That is why I showed the example of mediawiki. The security issue was basically a wrong handling of MIME types in internet explorer. As you said, the upstream maintainers did some input sanitizing cleanups. However, this ended whith a *whole* new class for fixing this, plus all the required changes to make it work, which apparently spread into a lot of various classes and cases. The full patch can be seen here: http://svn.debian.org:80/viewsvn/pkg- mediawiki/mediawiki/lenny/debian/patches/CVE-2008-5249_CVE-2008-5250_CVE-20 08-5252.patch?revision=92view=markup Now, to me this has not much to do with what we characterize as security patches. It is indeed very hard, if not impossible to check wether this will have undesirable side effects, or is minimal. However, I fail to see how this could have been done otherwise, and I feel that pretending this is a minimal security update is somehow not very different than simply upgrading to the latest upstream release, considering the size of the patch... Let me try to clarify what Raphael is trying to bring across (and which is my opinion as well): The problem with many of the webapps is that maintainers didn't consider the following things before bringing the package into testing/stable: - the package has to be maintained for a long time (stable-security and oldstable-security) and this should be discussed with upstream, too many upstreams do not want to maintain old versions for such a long time. - it is the maintainer's responsibility to get security updates out (yes, the security team often NMUs, but maintainer interaction is most welcome and whenever I email a certain maintainer, I expect that he either knows the code and can answer my concerns or at least engages in a discussion with upstream, mostly behind the curtain). It happens too often that I have to go to upstream right away, because there is no point in talking to the maintainer or that I am left alone with a big chunk of unknown code to me, which nobody is willing to analyze (sometimes upstream doesn't even know the debian maintainer). - the security threads are more complex, so a certain amount of time has to be dedicated to testing/fixing these issues, rather than to unstable/experimental development. (Yes I know, this is boring work and not too rewarding, but it's neccessary). - ... possible other points I forgot to mention. (Unfortunately, I have no idea how to guarantee these points in the first place, other than taking the maintainer's word for it). If these requirements are not met, then a maintainer should reconsider, whether the package should be in debian or maybe ask for a bigger team (without having the usual 20 co-maintainers, who are just in the field for the sake of it). Romain, this is in no way directed to you or anyone else in particular
