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

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


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

Reply to: