develooper Front page | perl.perl5.porters | Postings from August 2016

[perl #128800] base.pm broken in Perl 5.24.1 rc2

Thread Previous | Thread Next
From:
Chris Travers via RT
Date:
August 2, 2016 17:02
Subject:
[perl #128800] base.pm broken in Perl 5.24.1 rc2
Message ID:
rt-4.0.18-2586-1470157342-890.128800-15-0@perl.org
On Tue Aug 02 09:47:32 2016, xsawyerx@cpan.org wrote:
> Chris, while I understand the objections you have and I appreciate
> this adds possible complications for you, I think you're missing
> background and you are making incorrect assumptions.

We fixed our complications after several hours of debugging.  My concern is that this is going to break *a lot* of codebases out there and frankly it is *very difficult* to know in advance which ones they will be.

And it makes it harder to determine how secure a system is for the administrator but adds very little complexity for an attacker.  The patch makes systems less comprehensibel, adds complex to troubleshoot bugs, and leaves systems with --- AT BEST --- a reason to have a false sense of security. 
> 
> You are both making assumptions on us not considering things you have
> (surprise, we have...) and on how easy it would be to solve the
> problem the way you suggest - which ignores backwards compatibility
> assurance, different security mechanisms across a multitude of
> operating systems and file systems, and even code complexity relating
> to magical entries in @INC.

That's why I suggested a need for a system-wide fallback, which is what Debian wisely did.  It enables sysadmins to test their systems, enable the additional security features if and when helpful.
> 
> I intend to reject this ticket unless I find a reasonable objection.

Two quick points:

1.  If you are going to change behavior of core modules, it needs to be clearly documented, along with information relating to expected new error conditions and how to fix them.  This as not been done and AT A MINIMUM you could treat this as fixed by changing the documentation and loudly announcing likely breakage in advance of release.  If you would reject even that modest requirement, then I don't know what to tell you.  But at a minimum if you won't restore behavior, then the alternative would be to heavily document *all* expected breakage from this change including error messages and document solutions.

2.  As I see it, my concern stands that sysadmins still are the only ones capable of resolving this and only locally currently, and so I will do my best to make sure that the IT professional community understand both the problem and how to prevent it as an attack vector without assuming the safety of any modules.  I assume you would agree that this is not anything like a fix that system administrators can rely on for the safety of their systems and so I would hope you would understand that full disclosure is, really, the best that we can do.

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=128800

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About