Bug#764744: unblock: libmojolicious-perl/5.48+dfsg-1
Hi,
On Sun, Oct 12, 2014 at 10:47:31PM +0100, Adam D. Barratt wrote:
> 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.
Okay.
> > > 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.
As I said on IRC yesterday I do not think it affects mojolicious directly.
The API returned a list if it was called in a list context (returning multiple
values).
The developers changed the API to always return as if it was called in a scalar
context (just one value). Their intention here was to avoid surprises.
If someone wants multiple values it is possible, there is a new API for that.
> > > - 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.
gregor herrmann checked the packages depending on Mojolicious (in the previous
mail) none of them had problem related to this. Some of them had problems
because of the newer version. (see that mail for details)
He updated so one package remains, but that is an already known issue.
Regards,
Tamas
--
CSILLAG Tamas (cstamas) - http://cstamas.hu/
Reply to: