Magnus Holmgren wrote:
On onsdagen den 6 mars 2013, Neil McGovern wrote: So, unfortunately the release team removed Pike entirely from the next stable release of Debian, because I said that some of the bugs fixed by 7.8.700 were "rather serious". Can you help me elaborate on that? (pike-jira.lysator.liu.se seems rather down at the moment.) Certainly 7.8.352 is better than nothing at
Browsing through the commitlogs since Sep 22nd 2009 (=7.8.352) I don't see any obvious security leaks being fixed.
Neither do I. There's the SSL renegotiation stuff, that might be considered a security problem, but it apparently didn't work anyway...
So the question indeed is, what is considered "rather serious" ?
There were a NULL-deref or two fixed and a couple of memory leaks, which I'd consider serious, but not a showstopper.
I'd say having 7.8.352 ok, having 7.8.700 is better, but when 7.8.700 is not (yet) available, having 7.8.352 is good enough.
That's my opinion as well.
Which begs another question: why is 7.8.700 not being considered in the first place? I can only imagine that it is a drop-in replacement for 7.8.352 and therefore a nobrainer to update the package.
We aim for backward compatibility, though I see that we changed the directory for installed modules to reflect the ABI in one of the early commits after 7.8.352 this was to fix a complaint by the Gentoo installer. This might affect the OS packaging system, but any Pike programs that care about where the modules are installed should query the master anyway.
I don't know of any Pike programs that work in 7.8.352, but fail with 7.8.700, that aren't broken to begin with (ie the 7.8.700 compiler might detect logic errors that the 7.8.352 compiler didn't, but these would cause runtime errors there instead).
/grubba