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=92&view=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 (the mediawiki update was great work), but it is rather a general remark. Cheers Steffen
Attachment:
signature.asc
Description: This is a digitally signed message part.