Bug#764744: unblock: libmojolicious-perl/5.48+dfsg-1
On Sun, 2014-10-12 at 17:49 +0200, Csillag Tamas wrote:
> Hi Adam,
>
> On Sun, Oct 12, 2014 at 04:17:04PM +0100, Adam D. Barratt wrote:
> > On Fri, 2014-10-10 at 19:45 +0100, Adam D. Barratt wrote:
> > > Yes, this appears to be a security release. However, it also represents
> > > several upstream releases worth of development, and the changes come to
> > >
> > > 186 files changed, 7164 insertions(+), 4533 deletions(-)
> > >
> > > so I'm not currently particularly keen to hurry the changes through as
> > > quickly as we ordinarily might for a security update.
> > >
> > > Even restricting the changes to lib/* still leaves us with
> > >
> > > 93 files changed, 3981 insertions(+), 3053 deletions(-)
> >
> > I was rather hoping that the above message would lead to more of a
> > discussion about the request.
>
> Sorry, maybe I misunderstood the purpose and the way of the these faster
> migration requests.
I don't believe the intention was that we couldn't ask for more
information if required, to determine what was appropriate.
> Actually when I read your mail I gave up on my request. I saw no point in
> replying.
That's unfortunate. If my mail had been intended as a "no" then I
wouldn't have left the bug open.
> > That doesn't appear to have happened so far, so some specific questions:
> >
> > - what is the real-world impact of the security issue?
>
> It looked worse when I first read about it. There is an API change to force
> application writers to be concius that they may receive a list when asking for
> url query parameters.
> http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/
> Most perl web applications/frameworks either updated their documentation,
> changed their code or both (e.g catalyst, plack).
>
> It can be okay if Mojolicious migrates after a 10 day delay.
Yeah, I saw the article and the affect on bugzilla. I agree that's not
good, but it doesn't say anything directly about the impact on
libmojolicious-perl.
> > - what is the effect of the changes on libmojolicious-perl's several
> > reverse-dependencies? (The upstream changelog mentions that the security
> > fix necessitated changing the way that existing methods operate.)
>
> That is a good question I do not know.
> (However if Mojolicious would migrate earlier the maintainers of the reverse
> dependencies would have more time before the freeze to handle the situation if
> necessary.)
They'd also be broken in testing for longer. :-) As mentioned on IRC,
the usual way the process works is that so far as possible the breakage
is identified quickly in unstable and fixed there before the package
migrates (or reverse dependencies which have not been fixed removed from
testing, depending on the circumstances).
Particularly at this stage of the cycle, we try to avoid introducing new
issues in to testing as much as possible.
Regards,
Adam
Reply to: