Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55692
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain liip.ch designates 207.126.144.129 as permitted sender)
Message-ID: <4E89E2B9.7060202@liip.ch>
Date: Mon, 03 Oct 2011 18:28:41 +0200
Organization: Liip AG
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: PHPdev <internals@lists.php.net>
References: <4E80BD8A.5070606@liip.ch> <4E81590C.1030507@liip.ch>
In-Reply-To: <4E81590C.1030507@liip.ch>
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)



On 27.09.11 07:03, Christian Stocker wrote:
> 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

So, here's a patch for PHP_5_3 with this approach

https://gist.github.com/1259520

can anyone confirm, that this is ok to be put in PHP_5_3 branch?
(regarding ABI change and maybe similar issues I was not thinking about)

chregu


> 
> 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
>>
>