Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55634 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17781 invoked from network); 27 Sep 2011 05:03:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Sep 2011 05:03:21 -0000 Authentication-Results: pb1.pair.com smtp.mail=christian.stocker@liip.ch; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=christian.stocker@liip.ch; sender-id=pass Received-SPF: pass (pb1.pair.com: domain liip.ch designates 207.126.144.147 as permitted sender) X-PHP-List-Original-Sender: christian.stocker@liip.ch X-Host-Fingerprint: 207.126.144.147 eu1sys200aog119.obsmtp.com Linux 2.5 (sometimes 2.4) (4) Received: from [207.126.144.147] ([207.126.144.147:41348] helo=eu1sys200aog119.obsmtp.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C5/B0-08680-619518E4 for ; Tue, 27 Sep 2011 01:03:19 -0400 Received: from mail-wy0-f178.google.com ([74.125.82.178]) (using TLSv1) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKToFZE4cBxszGxRsX0zqLdKPVk4D5shDk@postini.com; Tue, 27 Sep 2011 05:03:19 UTC Received: by mail-wy0-f178.google.com with SMTP id 23so7025940wyf.9 for ; Mon, 26 Sep 2011 22:03:15 -0700 (PDT) Received: by 10.216.229.145 with SMTP id h17mr5673797weq.38.1317099790388; Mon, 26 Sep 2011 22:03:10 -0700 (PDT) Received: from air11.local (84-72-44-234.dclient.hispeed.ch. [84.72.44.234]) by mx.google.com with ESMTPS id fd4sm34180802wbb.21.2011.09.26.22.03.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 22:03:09 -0700 (PDT) Message-ID: <4E81590C.1030507@liip.ch> Date: Tue, 27 Sep 2011 07:03:08 +0200 Organization: Liip AG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: PHPdev References: <4E80BD8A.5070606@liip.ch> In-Reply-To: <4E80BD8A.5070606@liip.ch> X-Enigmail-Version: 1.3.2 OpenPGP: id=0748D5FE; url=http://gpg-keyserver.de/pks/lookup?op=get&search=0xC2BAFBC30748D5FE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Question about ABI compatibility for an ext/xsl patch and an API question for the implementation From: christian.stocker@liip.ch (Christian Stocker) Hi again I just had the idea for a 4th option. Won't be less controversy, but it's backwards and forwards compatible. 4) use a php ini setting in PHP 5.3 I know, we try to avoid that as much as possible. BUT * It will only be in 5.3, not even committed to 5.4 * If you don't have the ini setting, your XSLT can't write files, the error will be pretty obvious. If you just read and transform, nothing will or has to change * Only a very very very small fraction will need to set this ini setting The code for enable writing again, which would work in 5.0 - 5.4+ looks like this. With my first proposal, I'd need much more if/else to make my code work on 5.3.8-/5.3.9+/5.4+ *** $xsl = new XSLTProcessor(); //if you want to write from within the XSLT $oldvalini = ini_set("xsl_security_prefs",XSL_SECPREFS_NONE); if (version_compare(PHP_VERSION,'5.4',">=")) { $oldval = $xsl->setSecurityPreferences(XSL_SECPREFS_NONE); } $xsl->transformToXml(...); //go back to the old setting. Better safe than sorry ini_set("xsl_security_prefs",$oldvalini); if (version_compare(PHP_VERSION,'5.4',">=")) { $xsl->setSecurityPreferences($oldval); } *** chregu On 26.09.11 19:59, Christian Stocker wrote: > Hi > > Some weeks ago I wrote a patch to disable writing from within XSLT > templates. That patch is now in 5.4 but wasn't accepted in PHP 5.3 since > it changed a struct in the header file. > > I have now I new patch which doesn't need that changing in the struct, > but I need a new .h file from libxslt. > > https://gist.github.com/3d3d3c3418236f748118 (unfinished patch, just a > proof of concept, but the basics are there) > > Can anybody tell me, if that still breaks binary compatibility for > extensions or if that would be ok? > > Then a more general question: > > There are now 2 ways to enable write access again (in 5.4). Via an > additional optional parameter to the transform methods (this works with > the patch above in 5.3 also) or via the new 5.4 only method > ->setSecurityPrefs(). The former is from a clean API point of view not > nice, adding more and more optional parameters to methods is the ticket > to hell usually. But I can't come up with a better solution for 5.3 > without breaking the ABI. And since it's somehow a security issue, I > would sleep better a lot, if we have a proper patch for 5.3 as well. > > To keep BC, I can't just delete the optional parameter again for 5.4, > that would make portable code a pain. OTOH, the way I did it know, it > breaks BC with PHP < 5.3.9, if you want to enable write access in xslt > templates in PHP 5.3.9+. If you don't need that, which is maybe 99.9% of > all cases, BC is kept for since PHP 5.0 until much after PHP 5.4 :) > > So there are 3 options > > 1) leave it like it is currently. No write protection in 5.3, only in 5.4 > 2) Have 2 ways to enable write access from 5.3.9+ and 5.4. > 3) Remove the ->setSecurityPrefs() in 5.4, so there's only one way to > enable write access again, but it's the nasty one from a clean API POV. > > For 2) and 3), code with those new options won't work anymore in 5.3.8- > (but you can check it in PHP user land and treat it differently), but > you get write protection automatically > > Again, all this will only affect a very small fraction of users, those > who legitimately wrote files from within XSLT. > > Any opinions? Me personally would like to have it in PHP 5.3 (or at > least offer a proper patch). > > chregu >