Re: [PHP-DEV] Question about ABI compatibility for an ext/xsl patch and an API question for the implementation
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about ABI compatibility for an ext/xsl patch and an API question for the implementation
This sounds like the best approach actually.
On Sep 27, 2011, at 7:03 AM, Christian Stocker christian.stoc...@liip.ch
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
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question about ABI compatibility for an ext/xsl patch and an API question for the implementation
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about ABI compatibility for an ext/xsl patch and an API question for the implementation
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
