Re: [SECURITY] [DSA 2038-3] New pidgin packages fix regression
On Mon, 15 Nov 2010 13:59:01 +0100, Gerfried Fuchs wrote:
> Hi!
>
> * Thijs Kinkhorst <thijs@debian.org> [2010-11-15 13:32:16 CET]:
> > On Mon, November 15, 2010 12:24, Gerfried Fuchs wrote:
> > > * Thijs Kinkhorst <thijs@debian.org> [2010-11-13 20:37:28 CET]:
> > >> Since a few months, Microsoft's servers for MSN have changed the
> > >> protocol,
> > >> making Pidgin non-functional for use with MSN. It is not feasible to
> > >> port
> > >> these changes to the version of Pidgin in Debian Lenny. This update
> > >> formalises that situation by disabling the protocol in the client. Users
> > >> of the MSN protocol are advised to use the version of Pidgin in the
> > >> repositories of www.backports.org.
> > >
> > > There are several things with this that itch me a fair bit: The most
> > > obvious is that it's now backports.debian.org, not www.backports.org
> > > anymore, which leaves a skew view on the status of the service.
> >
> > As the (unquoted part of the) text notes, the paragraph you cite is just a
> > fascimile from the original advisory text, nothing more. This explains why
> > recent developments have not been incorporated.
>
> Right, just wanted to mention it because it would be nice to change
> that part in case another update from this or any other DSA having the
> old domain name in it would be appreciated.
>
> > > Secondly, I can't remember any information exchange between the
> > > security team and the backporters of the package. Especially in the
> > > light of the not-too-far-ago thread on debian-devel about the security
> > > support state on backports where Gilbert left a quite clear opinion (and
> > > non-disputed by other people of the security team) about the state (or
> > > rather, non-state) of security support for backports this is also a fair
> > > bit disturbing.
> >
> > For this the same goes as for the paragraph above: this relates to
> > information from the original DSA, so it's not a recent development. The
> > maintainer of pidgin provided this advice. It seems reasonable to me that
> > if the maintainer suggests this as an alternative that this can be taken
> > at face value to be a good idea for our users (i.e.: there's commitment to
> > maintain at least that package to a serious level in backports). The
> > advice is clear on the fact that this advice pertains to the pidgin
> > package specifically.
>
> Unfortunately the maintainer of pidgin in unstable is not the
> maintainer of pidgin in backports, so there is no commitment in his
> statement, at all. That's the point. There was no discussion with the
> maintainer of pidgin in backports TTBOMK.
>
> > "Gilbert" is not a part of the security team. I'm unsure why you refer to
> > him only by his last name.
>
> Because that's also the IRC nick he uses. Still, he discussed in the
> thread like he speaks for the security team, and like mentioned, there
> was no differentiation brought into the discussion by anyone else that
> would make it clear that he is neither speaking for the team nor that
> his opinion is wrong.
>
> Also, you just stated that he is not a part of the security team - that
> unfortunately doesn't get us anywhere though. Were his statements in
> that respect untrue? I would have expected at least a single message
> with respect to some-kind of official statement and not having it stand
> like it was, making it sound that his responses could be seen like the
> view-point of the team.
I didn't mean to sound as if I represented the security team in that
thread. I was simply stating my own viewpoint, which was that if
backports was to continue as an unofficial service, then I personally
was not going to spend any time researching whether issues were present
there.
Now that it is official, I personally plan to do so as much as I
can. However, the security team has no such requirement. Supporting
backports is a lot of additional work, and perhaps it would be better
to get a dedicated backports-interested team to follow the
secure-testing commits and do the research themselves. Otherwise,
you're asking the security team to sign on to more work (that they
didn't ask for and may not be interested in) without providing them any
additional resources. I don't want to speak for anyone other than
myself, but it looks like it would be very beneficial for the two teams
to have some sort of discussion on roles/responsibilities for backports.
Mike
Reply to: