The unstoppable Perl release train?

Posted Mar 1, 2012 18:26 UTC (Thu) by autarch (subscriber, #22025)
In reply to: The unstoppable Perl release train? by felixfix
Parent article: The unstoppable Perl release train?

You didn't read what I wrote very carefully, nor do you know who I am.

First, I am one of the Perl gurus, though Tom C can clearly claim higher level guru status than me (on the official Perl Guru rating system I'm a 3 to the power of 𝛑, but Tom is at least a 7 to the power of 3𝛑). But hey, I did release Perl 5.15.6 (https://metacpan.org/release/DROLSKY/perl-5.15.6/), and I've worked on the Perl core a bit (mostly docs).

Second, the "Perl gurus" obviously don't all agree on what the current problem is. Tom C says one thing. Many others disagree with his assessment of the urgency of these bugs, which the article does make clear (Aristotle and RJBS are both also Perl Gurus, though I haven't calculated their exact ratings yet).

But here's the real point ...

These bugs that Tom brought up have existed for quite a while. Note that they are not all security bugs. The security bug mentioned in the article has not been disclosed, and may be something not in Tom's list. The security bug has *also* existed for a while (since 5.14 at the very least).

If we *don't* release Perl 5.16.0 in April, then the latest stable release (5.14.2) will have all of these bugs.

If we *do* release Perl 5.16.0 in April, then the latest stable release (5.16.0) will have all of these bugs.

This is why delaying the release makes no difference. No matter what we do, the latest stable release will have all of these bugs, including the unknown security bug!

The only reason to delay the release is to fix *release-blocking* bugs. These are defined as bugs which introduce *new* regressions since the last stable release. If Perl 5.14.2 didn't have these Unicode bugs, then these would probably be considered blockers, but that's not the case.

The article totally misses this point, which is one reason why I don't think the article is very good.

The unstoppable Perl release train?

Posted Mar 1, 2012 22:24 UTC (Thu) by gerdesj (subscriber, #5446) [Link] (3 responses)

Willy waving about relative guru powers is silly. Do you have any idea what the difference between 3^PI and 7^(3*PI) actually is? It makes you look daft.

Reporting on unspecified security problems in a core part of many systems seems to me a really good point to the article. I'll take an informed article with references from the grumpy ed over a comment from a participant any day. Especially an article that provides references to both sides of the argument and invites me to make my own mind up.

Cheers
Jon

The unstoppable Perl release train?

Posted Mar 2, 2012 1:04 UTC (Fri) by autarch (subscriber, #22025) [Link] (2 responses)

I was responding to someone who claimed I was unqualified to declare that the article wasn't very good.

The bit about guru levels is of course quite silly. I was joking!

The unstoppable Perl release train?

Posted Mar 2, 2012 1:33 UTC (Fri) by felixfix (subscriber, #242) [Link] (1 responses)

My main point was no more about how qualified you are than your main point was about how qualified you are.

My main point was that you first admit you don't know how important the security issue is, then claim that the security issue is not important enough to delay the release.

You can't have it both ways.

The unstoppable Perl release train?

Posted Mar 2, 2012 15:04 UTC (Fri) by autarch (subscriber, #22025) [Link]

Delaying the release won't get this security issue fixed any faster.

Also, Tom Christiansen was not suggesting that the release be delayed to fix this particular issue. He wanted it to be delayed to fix the bugs he was reporting. He is not the person who reported the security issue.

The unstoppable Perl release train?

Posted Mar 1, 2012 23:43 UTC (Thu) by jhhaller (guest, #56103) [Link] (7 responses)

Not having any bone to pick on either side, it appears to this outsider that fixing security issues are not as big of a concern than maintaining a consistent release schedule. Holding back a release because of a vulnerability gives everyone the impression that security is important and a project priority. Releasing it says we will get to it when we get to it, or that Unicode isn't thought to be important. Even if a statement was made that we are working on the bug, the release will go out shortly. but that a patch will be released shortly would be a better than only saying the release schedule is sacrosanct.

This article helped shine a light on this issue, which outsiders not watching Perl mailing lists would never have seen otherwise. If this puts enough pressure to get the bug fixed in a timely fashion, then the article served it's purpose.

The unstoppable Perl release train?

Posted Mar 2, 2012 1:08 UTC (Fri) by autarch (subscriber, #22025) [Link] (6 responses)

Holding back a release for a security issue would make sense if the security issue were not already present in the last stable release, I agree.

I'm not sure of the exact details of the security issue, but given that it was first reported 10 months ago (and was probably reported against the stable release at that time), we can assume that existing stable versions of Perl are affected.

Releasing another stable release of Perl which is affected by the same problem really doesn't make a difference, security-wise.

The unstoppable Perl release train?

Posted Mar 2, 2012 4:04 UTC (Fri) by cmccabe (guest, #60281) [Link] (1 responses)

Common sense would suggest fixing the gaping security hole before making another release. Luckily we live in an enlightened age when common sense has been replaced by "process" (formerly called "bureaucracy").

The unstoppable Perl release train?

Posted Mar 2, 2012 15:06 UTC (Fri) by autarch (subscriber, #22025) [Link]

Your assertion only makes sense if you think that making the next release and fixing the security hole are mutually exclusive. They're not.

The unstoppable Perl release train?

Posted Mar 2, 2012 14:40 UTC (Fri) by xdg (guest, #83285) [Link] (3 responses)

autarch is correct that the security issue is present in all stable releases of Perl since Unicode support was added. There are no reported exploits. Programs that follow the Perl 5 Security guidelines and the Security Implications of Unicode guidelines are unlikely to be affected.

When the issue is addressed, it will be backported to all supported Perl 5 stable release series, per the Perl 5 Support Policy. The release schedule of Perl is irrelevant. Holding up the Perl 5.16 release wouldn't get the issue fixed any faster and would merely hold up the release of other bugs fixed in the Perl 5.15 development cycle.

The unstoppable Perl release train?

Posted Mar 2, 2012 20:37 UTC (Fri) by dlang (guest, #313) [Link]

> autarch is correct that the security issue is present in all stable releases of Perl since Unicode support was added.

What is the bug? that's information that I haven't yet seen in this discussion.

The unstoppable Perl release train?

Posted Mar 4, 2012 5:27 UTC (Sun) by jmayer (guest, #595) [Link] (1 responses)

My reading of the article is different than what you "Perl guys" are reading into it: With the new release there will be "complete" Unicode support, it will be the "if you haven't used unicode before, do it now release". So if there are security problems in the unicode handling in Perl and more people start using the unicode features these problems will be in more and more programs. How many people who write Perl scripts have actually read the security guidelines - probably well below 50%. Many people I know learn mostly from examples, not from manpages.

The unstoppable Perl release train?

Posted Mar 4, 2012 19:39 UTC (Sun) by xdg (guest, #83285) [Link]

If you're reading this as "the Unicode release", then the author has (probably unintentionally) misled you. Unicode itself is a moving target and Perl has continued to make significant stride to improve how it handle Unicode semantics in the last couple releases. See Unicode Overhaul from the 5.12 release notes and Unicode in the 5.14 release notes. Perl 5.16 continues with this trend of incremental improvements.

As for how many people read the security-relevant sections of manpages, that's an issue for any language or tool. Most tools can be used insecurely, dynamic languages particularly so. I would hope that anyone writing or deploying code where security does matter would read relevant manpages.