RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
De : Brian Moon [mailto:br...@moonspot.net]
I agree here with Benjamin. The thing I have wanted in user land for
years is to be able to build a user land function that worked the way
internal functions do in terms of type checking without having to build
my own type checking system. Having internal functions convert null to a
scalar and not having user land do the same creates an inconsistency.
For example, sometimes you want to wrap/extend an internal function (you
see it a lot with json* to do encoding checking). I can't reliably take
the same input to my user land wrapper that I can send to the internal
function. I would prefer to see the same rules apply to internal and
user land.
It would be better, yes. Unfortunately, accepting or refusing null to scalar in
both is difficult. If we disable null to scalar, we potentially generate a lot
of deprecation messages for existing code calling internal functions this way.
If we enable null to scalar, we create massive future inconsistencies now and
in the future. An example :
Function foo(): string {} // OK because returns null and null accepted as
string.
My opinion, but that's only mine, is that I would favor deprecating null to
scalar, even for internal functions. It would add deprecation messages but we'd
end up with a cleaner code.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
De : Damien Tournoud [mailto:d...@damz.org] All those are due to a bug in substr(), that we see now only thanks to proper type identification. There is no reason for substr() to ever return a boolean. It really needs to be fix to always return a string. Sorry, not a bug. Documentation is clear. You get 'string|false' from substr() and send it to a function expecting 'string'. Most languages will fail on this. It worked in PHP because of implicit casting from bool to string. We just decided to deprecate this implicit cast. Now, we can discuss about substr(), whether it should always return string or not. But that's another subject. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On 28/02/15 08:40, François Laupretre wrote: My opinion, but that's only mine, is that I would favor deprecating null to scalar, even for internal functions. It would add deprecation messages but we'd end up with a cleaner code. null is a very specific 'state' for anybody working with databases. It means that no value was found. Mapping that to a default value for future processing is a job for the application rather than the data packet as returned. It ONLY needs to overridden from a default or 0 in cases where the simple default is not required, but on the whole the default 'case' is ALL that is needed. That null is also false in situations where a bool is required is also natural. It's now having to go through all the code and manually add these quite natural casts which is the problem here. It's not a bug or mistake, it just flows in the whole process. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
De : Benjamin Eberlei [mailto:kont...@beberlei.de] The funny thing is that the fix for this is: - substr($image, strrpos($image, \n) + 1) + (string)substr($image, strrpos($image, \n) + 1) Which is that sort of casting that is put forward as argument against the dual/strict mode. It is just one possible fix, but definitely not the one I would suggest, because too permissive. No controversy please, because both are valid. I would just prefer adding a test like 'if ($result===false) $result='';'. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
De : Benjamin Eberlei [mailto:kont...@beberlei.de] Interestingly functions like is_infinite(), is_dir(), is_file() all expect correct types like float or string here although from the naming convention is_something i would expect it says just false on *anything* else (which it almost does right now). Agreed. Must be modified. Even for 7.0 if it can be approved before freeze. All is_xxx functions must be checked and made more permissive on input arg (most, if not all, should probably accept any zval, minor BC break). Imho the problem is that the return values of php internal functions being string|false will lead to massive consecutive errors when passing this on to other internal unctions. Right. A side effect of the RFC is to encourage for an explicit check of false. May I say that this won't exactly lead to 'errors', as we are just deprecating usage of the implicit cast in such case. So it may lead to massive 'deprecated' messages but, apart from additional messages, behavior won't change. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
De : Damien Tournoud [mailto:d...@damz.org] But anyway, that's not even the point. The point is that return values that worked in a world of transparent type-jungling will not work in a world of stricter typing checks. Which means that we need: (1) To accept that for now casting FALSE to the empty string is the right thing to do; No. Add an explicit for false. We want programs to be cleaner, not encourage casting. until / unless: (2) We fixed all the common functions in the standard library so that they stop returning inconsistent types, in particular in the cases where it should not even be a debate what is the right thing to do (for substr, if the arguments point to an empty slice, return the empty string). That's history. Propose an RFC to fix substr() behavior (good luck :) Yes, we propose to deprecate potentially-problematic behaviors. That's not because we are running behind Anthony's RFC, as some may believe, but we sincerely think, at the end, it will bring more good than bad to PHP overall. You will have at least 5 years to fix your code. PHP is evolving. You like it or not. If you don't, you vote against the feature. That's democracy, which is not always the case for other languages. Can I say more ? François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
On 28/02/15 08:24, François Laupretre wrote: Sorry, not a bug. Documentation is clear. You get 'string|false' from substr() and send it to a function expecting 'string'. Most languages will fail on this. It worked in PHP because of implicit casting from bool to string. We just decided to deprecate this implicit cast. Now, we can discuss about substr(), whether it should always return string or not. But that's another subject. Isn't this the whole crux of the problem? The strict/coercive world fix for 'is there a string left' is to create an error which has to be handled, when workflow wise simply branching on the empty string is the correct action. I can see that some people need the empty string rather than the 'false' but THAT is the sort of thing that 'Coercive' should be handling rather than dictating that it is now an error. This is fundamental to the nature of PHP and dismissing a basic premiss 'another subject' is exactly what both 'camps' are currently doing. *I* want to maintain the ability to write code that runs in sequence, that is what a script language should do. It is NOT designed to be compiled, but processed and having to compile sections to create new functions such as exception returns which may never be used is wrong, just as trying to optimise something that may need the now optimized out element next time a bit of code is used is equally wrong. If you want the ultimate fastest performance just use C or one of the other fully compiled languages an live with the 'delay when you first run it'. Ultimately PHP works because it returns the type of object you need at the time ... fixed single types are not what PHP is ... and that is the type of PHP *I* want but I seem to be in an obsolete minority? I only need the current build of PHP7 because it puts back speed lost due to other changes but it is most definitely heading somewhere I don't want to be. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend JIT Open Sourced
On Sat, Feb 28, 2015 at 12:55 AM, Andi Gutmans a...@zend.com wrote: On Feb 27, 2015, at 11:36 AM, Anthony Ferrara ircmax...@gmail.com wrote: Dmitry, That's not to say there's anything wrong with this approach, nor that there isn't a ton we can learn from it. I think it's a fantastic research effort and plan on digging through it myself. Thank you for open sourcing it. Thanks for good words :) This work may be adopted for some specific cases. 25-30 times speedup on Mandelbrot allows usage for numeric calculation instead of C. https://gist.github.com/dstogov/12323ad13d3240aee8f1 anyone may repeat the language battle :) These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, it's possible. But I don't think it's likely. It really smells to me like bias in the testing methodology. (and the lack of an -O3 result is suspicious as well). And looking at the code, I can see why. The PHP version is writing to an internal buffer, while every other version has to write to STDOUT on every single iteration. So you are intentionally not benchmarking the output in the PHP version (you even explicitly call ob_start()) but are benchmarking it in every other version. So in fact, the PHP code does something different than the rest of the code. We actually discussed this at the time of the results. IIRC it really has nothing to do with the output mechanism, etc.. The benchmark does enough iterations and very little output that the impact there is negligible (you can test this yourself to see if I am right but I am pretty sure I am). It is due to the fact that at runtime LLVM can optimize better to the architecture than a static standard gcc build. Constraining gcc with the right architecture dependent switches upfront will also improve the gcc results. Anyway, still pretty cool to see this although it has very little impact (if any) on real world apps ala Magent, WordPress, Drupal, ... I think the important learning is that faster synthetic benchmarks have very little impact on overall application performance. Sure it can have an impact on specific algorithmic pieces of code but that’s the exception not the norm. No doubt there are other ways to write JIT including tracing JITs etc. but I do think we found that we are more bound by I/O and memory/caches than the quality of the machine code as the engine is already quite tight. And with apps consuming more and more Cloud services the I/O bottleneck issue looks grimmer than ever! :) That also comes across consistently in benchmarks of PHP 7 vs. hhvm on real-world apps - you see a JIT and non-JIT platform pretty much head to head on performance and actually on the complex stuff PHP 7 is often faster. Anyway, definitely makes sense to continue to look at these kind of opportunities down the road but PHP 7 is such a huge step-up on real world application performance I think getting that out the door is the biggest possible short-term win when it comes to performance. Looking forward to seeing folks dig into the code and have ideas down the road!! Completely agree. And have to say that these experiments with JIT leaded us to understanding of real PHP-5 bottleneck, that allowed us to make about 60% improvement on real-life in PHPNG and already near 2 times in PHP7. But LuaJIT without JIT is 4 times faster on Mandelbrot. It's a challenge... Thanks. Dmitry. Andi
Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
Hi Stas,
On Sat, Feb 28, 2015 at 1:53 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
I have no intention to change current include/require syntax, except
adding
2nd parameter.
This is a bit misleading since include is not a function, so there's no
1st parameter. Instead, it's a syntax construct. Of course, syntax
construct's grammar can be changed, though I'm not sure if that wouldn't
lead to unexpected effects in the parser. But maybe not.
Although it is variable length parameters, we already have echo.
I'll check it see if Zend has problem with 2nd parameter when I write patch.
Bigger issue is that if somebody is knowledgeable enough in security to
go and change their code to use this option, why they aren't
knowledgeable enough to fix their includes so this option is not required?
The root cause of the issue here is preciseness of the setting.
I think you agree that current allow_url_include=Off with INI_SYSTEM is
not precise at all.
We need to consider local and remote wrapper separately.
We may better to consider removing all remote wrapper support from
include/require.
It's rarely used and user can execute remote script easily with PHP. e.g.
eval(readfile('http://host/script')).
That said, one other possible solution is disallow most local wrappers for
include/require
and restrict script file extension. AFAIK, phar and user wrappers are the
exception
for allow_url_include=Off, but there may be others. If we remove most
local wrapper
support(php://input, user wrappers, etc) from include/require, we don't
need 2nd parameter. i.e.
include('phar://phar_file.phar/script_in_phar.php'); // Requires .phar
extension to load PHP script from phar.
This requires users to change filename. Therefore, I propose to check
wrapper type
by 2nd parameter, but filename extension check works also. I don't mind to
use
this option.
There may be users that uses local wrapper to encrypt script files, etc. We
need
research if disabling most wrappers for include/require have problem or
not.
If there are other ideas, I appreciate it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
Hi Rowan,
On Sun, Mar 1, 2015 at 3:46 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 28/02/2015 02:37, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for removing allow_url_include INI option. [1]
During Script only include RFC[2] discussion, stream wrapper issue is
raised.
I was thinking this issue as a separate issue, but it seems others are
not.
I'm not convinced by the argument that because phar://blah looks like
a URL, allowing it makes allow_url_include broken. Perhaps it would be
better named allow_remote_include, but it corresponds to masking out your
PHP_STREAM_REMOTE flag further down, which is the more important
protection. If you want to be able to disable phar:// access, you could add
something like allow_local_stream_include for that case without breaking BC.
allow_local_stream_include is one possible solution. It has the same
problem with allow_url_include.
Yes, the global vs local setting issue is distinct from the question of
is phar://blah a URL?
I think your question is about remote/local resource.
Is phar:// local resource? It's yes.
Is phar:// URL/URI? I think it depends how people understand URL/URI.
file:// is considered URI/URL even if it's local resource.
We need to control these flags more precisely. That's the reason why I
proposed 2nd parameter for include.
If flags are globals, we cannot control them as it should.
I agree with this part. Global settings are always harder to work with,
and in this case more dangerous, than something more local.
URL and URI is the same for most users, I think. (It differs, but their
usage is mostly the same) Not
many users expect to work something like
include('new_wrapper://some_file_with_special_content/some_how_php_script_is_accecible_suddenly');
I'm not sure most users would look at that and think that's a URL or
that's a URI. They'd think that's some funky syntax for including a file
from inside an archive.
PHP allows too many wrappers for include/require. We may be better to
disable almost all wrappers.
Phar remains as problematic wrapper. Solution would be adding way to load
script precisely.
e.g. Restrict filename extension, specify URL/URI prefix.
Note: We need to have either, specific file name for scripts or script
loader must be specific for wrapper to be used.
Attackers can write malicious user stream wrapper as back door. Then
upload attack file and takeover
server. The wrapper will be hard to distinguish if it's legitimate or not.
Attack file can be any kind of
format. It's impossible to detect as malicious file. URL formed script
(stream wrapper) is very flexible/handy/
hard to be detected tool for attackers.
I'm not really clear how this is a back door. At worst, it seems to be a
form of obfuscation, like the classic eval(base64_decode()) etc, since
it makes the intention of the uploaded file less obvious. But you've still
got to activate the stream wrapper, upload the file, and convince the
script to include it.
Nice attribute of attack with wrapper is actual attack code can be hidden
in other data files.
The data file may have any kind of form. This makes detection a lot harder.
Remote resource is extremely danger. Local resource is very dangerous
also. Current phar:// wrapper
implementation spoils file extension and .. (double dot) protection
that is deployed by many PHP codes
already. User wrapper seems allowed for include(), so malicious user
wrapper can help attackers to
exploit PHP servers.
Relying on the fact that no uploaded file can have a name ending .php,
and that therefore any file ending .php is safe to include, seems like a
very naive check, best remedied with user education. It's also only
exploitable if they rely on the include_path setting, rather than prefixing
the input with an expected directory (since
'/var/www/my_app/modules/phar://foo.phar/bob.php' would not be loadable).
Right. '/var/www/my_app/modules/phar://foo.phar/bob.php' is invalid.
However, relative path is allowed...
Using Stas' exploit example
php chump.php phar://../cuteponies.gif/pwnd.php
This is executes attack code.
Similarly, the only sensible way I know to protect against .. is to
call realpath() or similar, which would simply return false for anything
beginning phar://, regardless of what path it then pointed to.
This is interesting idea for mitigation. Thank you.
I'm also not at all clear what you mean by caller and callee
responsibilities; surely the difference is just between a global option
(ini_set()) and a local one (extra argument)? And in what way does Option
#2 require more changes than Option #1, since they both require the
argument to be present whenever a stream wrapper is used?
First question is answered in previous comment.
What I don't understand is who is
Re: [PHP-DEV] [VOTE] Expectations
Am 28.02.2015 um 20:08 schrieb Patrick Schaaf:
Am 28.02.2015 19:32 schrieb Crypto Compress
cryptocompr...@googlemail.com mailto:cryptocompr...@googlemail.com:
class BankAccount {
function Add($amount) {
assert($amount 0);
// ... code block ...
}
}
Now the programmer implementing code block to gracefully handle
$amount 0 has a problem. There is no way to (Unit)test failing path
on development machine. Code after assertion is never called for
failing contitions. What to do?
Put the assert AFTER handling the always-to-be-done validation, of
course. Doesn't make sense otherwise.
Patrick
if ($amount 0) { ...code block... }
// else {
throw new WrongAmountEx();
// }
Frankly i can't see any point in using assertion after checked
expression thus duplicate the expression. It's simple a bug. As
situation is clearly wrong, throw/exit/die and change code flow as
desired. This is not the conditionally unreachable code case i argue
about.
Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
On 28/02/2015 02:37, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins
rowan.coll...@gmail.com mailto:rowan.coll...@gmail.com wrote:
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for removing allow_url_include INI option. [1]
During Script only include RFC[2] discussion, stream wrapper
issue is
raised.
I was thinking this issue as a separate issue, but it seems
others are not.
I'm not convinced by the argument that because phar://blah looks
like a URL, allowing it makes allow_url_include broken. Perhaps it
would be better named allow_remote_include, but it corresponds to
masking out your PHP_STREAM_REMOTE flag further down, which is the
more important protection. If you want to be able to disable
phar:// access, you could add something like
allow_local_stream_include for that case without breaking BC.
allow_local_stream_include is one possible solution. It has the same
problem with allow_url_include.
Yes, the global vs local setting issue is distinct from the question of
is phar://blah a URL?
We need to control these flags more precisely. That's the reason why I
proposed 2nd parameter for include.
If flags are globals, we cannot control them as it should.
I agree with this part. Global settings are always harder to work with,
and in this case more dangerous, than something more local.
URL and URI is the same for most users, I think. (It differs, but
their usage is mostly the same) Not
many users expect to work something like
include('new_wrapper://some_file_with_special_content/some_how_php_script_is_accecible_suddenly');
I'm not sure most users would look at that and think that's a URL or
that's a URI. They'd think that's some funky syntax for including a
file from inside an archive.
Attackers can write malicious user stream wrapper as back door. Then
upload attack file and takeover
server. The wrapper will be hard to distinguish if it's legitimate or
not. Attack file can be any kind of
format. It's impossible to detect as malicious file. URL formed script
(stream wrapper) is very flexible/handy/
hard to be detected tool for attackers.
I'm not really clear how this is a back door. At worst, it seems to be
a form of obfuscation, like the classic eval(base64_decode()) etc,
since it makes the intention of the uploaded file less obvious. But
you've still got to activate the stream wrapper, upload the file, and
convince the script to include it.
Remote resource is extremely danger. Local resource is very dangerous
also. Current phar:// wrapper
implementation spoils file extension and .. (double dot) protection
that is deployed by many PHP codes
already. User wrapper seems allowed for include(), so malicious user
wrapper can help attackers to
exploit PHP servers.
Relying on the fact that no uploaded file can have a name ending .php,
and that therefore any file ending .php is safe to include, seems like
a very naive check, best remedied with user education. It's also only
exploitable if they rely on the include_path setting, rather than
prefixing the input with an expected directory (since
'/var/www/my_app/modules/phar://foo.phar/bob.php' would not be loadable).
Similarly, the only sensible way I know to protect against .. is to
call realpath() or similar, which would simply return false for anything
beginning phar://, regardless of what path it then pointed to.
I'm also not at all clear what you mean by caller and callee
responsibilities; surely the difference is just between a global
option (ini_set()) and a local one (extra argument)? And in what
way does Option #2 require more changes than Option #1, since they
both require the argument to be present whenever a stream wrapper
is used?
First question is answered in previous comment.
What I don't understand is who is the caller and who is the callee.
All I can see in your examples is global setting enabled at point X,
and exploited at point Y; there is no caller/callee relationship
between those points.
Option #2 will be much more complex than Option #1, since it
introduces types of wrapper, force users to have class method return
wrapper type and pass flags around functions to handle wrapper types
correctly. There may be more.
Why does the user have to pass flags around? I would have thought the
vast majority of cases will be replacing require
'phar://foo.phar/bar.php'; with either require
'phar://foo.phar/bar.php', 'phar://'; or require
'phar://foo.phar/bar.php', PHP_STREAM_LOCAL. The burden of upgrading is
basically identical.
The only difference would seem to be the fairly rare scenario of
implementing a custom stream wrapper, and then using it for script
includes, and that would require only a single implementation of
getType() on the stream wrapper, which doesn't seem that complex.
I used
Re: [PHP-DEV] [RFC] UString
On 28/02/2015 06:48, Joe Watkins wrote: Morning internals, This is just a quick note to announce my intention to ready this RFC for voting next week. I know I'm a little late maybe, I was real sick most of last week, so couldn't do anything useful. A couple of us intend to fix outstanding issues on github and those raised here, tidy the RFC and open the vote for 7. I would ask anyone interested to scan through this thread and announce concerns that are not mentioned asap. I still think this class is trying to do several jobs, and not doing any of them very well, and I fear that people will see this class and expect it to solve problems which it actually ignores. Here are some concrete use cases I would like a simple interface to solve for me: - Take text from an ISO 88592-2 data source, pass it through generic text filters, and pass it to a UTF-16 data target. - Given a long string of Unicode text, give me a valid UTF-8 string which fits into a buffer with fixed byte size; i.e. give me the largest number of whole code points which fit into that number of bytes once encoded. - As above, but without stripping diacritics off the last character of the resulting string, i.e. give me the largest number of whole graphemes which fit. - Split a string into equal sized chunks of readable characters (graphemes), regardless of how many bytes or code points each chunk contains. UString currently falls short of all of these: - I can specify my input encoding (in the constructor or helper method, over-riding a static default, which is equivalent to ext/mbstring's global setting), but not my output encoding (there is no method to ask for a byte representation other than a string cast, which by definition has no parameters). - I can ask for a fixed number of code points, but don't know how many bytes these will take until I cast to a UTF-8 string. - I can't manipulate anything at the grapheme level at all, even though this is the most meaningful level of operation in most cases. Things it does do: - a handful of methods give meaningful international text support: toUpper(), toLower(), trim() - some methods could be done on byte strings if I ensure they're all in UTF-8: replace(), contains(), startsWith(), endsWith(), repeat() - there may be limited situations where I want to dive into the code points which make up a string, although I can't think of many: $length, pad(), indexOf(), lastIndexOf(), charAt(), replaceSlice() - remaining methods avoid me creating invalid UTF-8, but don't help me much with real-life text: chunk(), split(), substring() - I can ask what codepage my Unicode string is in; I don't even understand what this means I think an efficient OO wrapper around ICU is a great idea, but more thought needs to go into what methods are exposed, and how people are going to use them in real code. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: desty
VCS Account Rejected: desty rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Expectations
Am 28.02.2015 19:32 schrieb Crypto Compress cryptocompr...@googlemail.com
:
class BankAccount {
function Add($amount) {
assert($amount 0);
// ... code block ...
}
}
Now the programmer implementing code block to gracefully handle $amount
0 has a problem. There is no way to (Unit)test failing path on
development machine. Code after assertion is never called for failing
contitions. What to do?
Put the assert AFTER handling the always-to-be-done validation, of course.
Doesn't make sense otherwise.
Patrick
Re: [PHP-DEV] [VOTE] Expectations
Am 21.02.2015 um 04:10 schrieb Yasuo Ohgaki:
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
cryptocompr...@googlemail.com mailto:cryptocompr...@googlemail.com
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific environment.
Joe, your argumentation is around how (not) to use exceptions. I
can see your point and it's valid.
My point is about not to implement exceptions at all.
If exceptions are not intended to be caught, they don't need to be
thrown (even if the context is different).
If exceptions are not thrown and not caught, we can use error in
dev and some easing severity (warning, zero cost nothing) in prod.
Freely adapted from Murphy: If assertion exception can be catched,
it will be even in production.
Assertion is only for development and testing.
We need errors or exceptions during development and testing, but
not in production. Therefore, errors/exception should not be catched
by code in general. Isn't assertion nature?
I don't insist not to enable assertion in production environment.
There might be software that needs extreme reliability and stability.
For these softwares, it makes sense to enable assertions and catch
errors/exceptions to do some cleanups.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net mailto:yohg...@ohgaki.net
Hi Yasuo,
sorry for the late answer. My point is about throwing exceptions
(assert.exceptions=1). I think it is wrong to allow to change code-flow
by ini-setting and in current context it is wrong to throw exceptions
altogether. Let's assume this code example in dev-mode with exceptions:
class BankAccount {
function Add($amount) {
assert($amount 0);
// ... code block ...
}
}
Now the programmer implementing code block to gracefully handle
$amount 0 has a problem. There is no way to (Unit)test failing path on
development machine. Code after assertion is never called for failing
contitions. What to do? Delete assertion is out of question. Disable
zend.assertions on development machine seems to be the wrong way too.
The only way to handle this is to disable exceptions
(assert.exceptions=0) so expected code flow is restored. This, if
allowed to be changed, should be at least the default.
IMO ability to run and test code broadly outweighs provides stacktrace
by default argument and for some reason i fear assert.exceptions=1 will
be the only case soon.
cryptocompress
Re: [PHP-DEV] [RFC] Design by Contract - Vote only RFC
Hi!
Hi all,
https://wiki.php.net/rfc/introduce_design_by_contract
This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
Please comment if you have any for this RFC.
I don't see why the first one needs any vote. It is supposed to be
implemented as an extension, so why not go and implement an extension,
and put it in PECL, and then propose it for core inclusion, if it proves
popular?
As for the second one, do we really need the syntax change that would
just move asserts to before { instead of after? If we already have
zero-cost asserts, why just not use them?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV][RFC][VOTING] Context Sensitive Lexer
Hi, Since no more issues appeared on discussion, the voting for the Context Sensitive Lexer is now open. The voting will close in exactly 14 days counting from now: RFC: https://wiki.php.net/rfc/context_sensitive_lexer#votes Since so few people participated on discussions, if you decide to vote no please share your motives on the mailing lists by replying to this thread. This will collaborate to the RFC process and can lead to improvements on possible follow up RFCs. Acknowledgments to Bob Weinand for all the advice and cooperation. Thanks, Márcio.
[PHP-DEV] [RFC] Design by Contract - Vote only RFC
Hi all, https://wiki.php.net/rfc/introduce_design_by_contract This is vote only RFC for 2 competing Design by Contract(DbC) RFCs. Please comment if you have any for this RFC. I'll post RFC discussion for actual proposals soon. Please keep discussion only about how vote should be done. Thank you. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Design by Contract - Vote only RFC
Hi Stas,
On Sun, Mar 1, 2015 at 12:32 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
https://wiki.php.net/rfc/introduce_design_by_contract
This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
Please comment if you have any for this RFC.
I don't see why the first one needs any vote. It is supposed to be
implemented as an extension, so why not go and implement an extension,
and put it in PECL, and then propose it for core inclusion, if it proves
popular?
It's possible option with PHP7's AST.
As for the second one, do we really need the syntax change that would
just move asserts to before { instead of after? If we already have
zero-cost asserts, why just not use them?
Assertion only DbC has limitations.
- Invaliants
- Postconditions
Without native DbC support, it ends up with messy code which is harder to
read. Less code readability decreases maintainability. Therefore, it
increases chance
of bugs. This is the reason why there are languages/extensions for DbC in
other
languages.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Expectations
Hi Crypto,
On Sun, Mar 1, 2015 at 3:32 AM, Crypto Compress
cryptocompr...@googlemail.com wrote:
sorry for the late answer. My point is about throwing exceptions
(assert.exceptions=1). I think it is wrong to allow to change code-flow by
ini-setting and in current context it is wrong to throw exceptions
altogether. Let's assume this code example in dev-mode with exceptions:
class BankAccount {
function Add($amount) {
assert($amount 0);
// ... code block ...
}
}
Now the programmer implementing code block to gracefully handle $amount
0 has a problem. There is no way to (Unit)test failing path on
development machine. Code after assertion is never called for failing
contitions. What to do? Delete assertion is out of question. Disable
zend.assertions on development machine seems to be the wrong way too. The
only way to handle this is to disable exceptions (assert.exceptions=0) so
expected code flow is restored. This, if allowed to be changed, should be
at least the default.
IMO ability to run and test code broadly outweighs provides stacktrace by
default argument and for some reason i fear assert.exceptions=1 will be
the only case soon.
I understand that removing assert conditions may seem to increase bugs in
code.
Wrong usage of assertion actually creates bugs. I agree.
However, assertion is not for production checks, but development time
checks.
Code example you're presented requires caller to make sure $amount 0
condition
is met. Unit tests has to make sure $amount 0 condition is kept without
assertion.
Assertion (as well as DbC) helps to make sure if conditions/expectations of
callee
are fulfilled by caller. Since caller must fulfill condition in the first
place, removing
assertions should not be problem under production environment and
production
codes execute faster.
Under structured programming, developers tend error condition check
responsibility
to callee, just like your example. Use of assertion is DbC style
programming
which forces error condition checks to caller. It changes why of thinking
and
these changes may be difficult to adopt for some developers, but the basic
idea is simple enough to be understood by all developers. I hope.
What good about DbC is it can achieve both robust development and faster
execution at the same time if it is used _properly_. I understand your
concern.
Developers must think what/where is the error condition check
responsibility.
Without this, the result can be fatal. Even if assertion/DbC has cons, its
pros
outweigh cons, IMHO.
Assertion/DbC
- Promotes caller to validate inputs. Input validation is the most
important for secure code.
- Underlying simple APIs that are called many times can omit various
condition checks in production. (Faster execution)
- Prevents wrong usage of API during development by assert failure.
- Makes developers to think where/how to implement defense in depth
properly. (Since no assertion checks in production, developers have to
think where/how to implement additional systematic defense in their code.
This is good for better security.)
I fully agree that users can misuse. We must make effort that users
understand
proper usage and idea behind assertions/DbC.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require
Hi all, On Thu, Feb 26, 2015 at 7:06 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Vote for script only include/require RFC is started. This RFC closes one of the fatal security hole in PHP programs with simple patch. https://wiki.php.net/rfc/script_only_include https://github.com/php/php-src/pull/ Vote ends 2015/3/12 It seems there are misunderstandings about the issue and the protection. If you would like to vote no, please read the RFC carefully. If you find fatal reason to reject this RFC, it is about arbitrarily code execution and file exposure, so please let us know the reason why. If you have question, please ask. It seems I had better to address stream wrapper issues at the same time even though it's big enough issue. I'll merge https://wiki.php.net/rfc/allow_url_include into this RFC and make this RFC Under Discussion state. For those who have voted already, please vote again when RFC is ready to vote again. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI
Hi!
The root cause of the issue here is preciseness of the setting.
I think you agree that current allow_url_include=Off with INI_SYSTEM is
not precise at all.
It is precise - it's doing exactly what it meant to do, separate local
wrappers from remote ones.
We need to consider local and remote wrapper separately.
We may better to consider removing all remote wrapper support from
include/require.
That's exactly what this setting is doing.
It's rarely used and user can execute remote script easily with PHP.
e.g. eval(readfile('http://host/script')).
This setting is indeed rarely used and not recommended to enable, but
since it's off by default, I assume anybody enabling it knows what they
are doing.
for allow_url_include=Off, but there may be others. If we remove most
local wrapper
support(php://input, user wrappers, etc) from include/require, we don't
need 2nd parameter. i.e.
As I previously noted, php://input is considered remote already. As for
others, I'm not sure why we would want to remove them.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Design by Contract - Vote only RFC
On 1 March 2015 at 03:32, Stanislav Malyshev smalys...@gmail.com wrote:
I don't see why the first one needs any vote. It is supposed to be
implemented as an extension, so why not go and implement an extension,
and put it in PECL, and then propose it for core inclusion, if it proves
popular?
Agree
As for the second one, do we really need the syntax change that would
just move asserts to before { instead of after? If we already have
zero-cost asserts, why just not use them?
Agree
@yasuo. The votes are closed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi all, I made vote only RFC and started discussion for voting https://wiki.php.net/rfc/introduce_design_by_contract Please feel free to correct/improve it. I added note to our RFCs https://wiki.php.net/rfc/dbc --- This RFC is part of “Design by Contract Introduction” RFC https://wiki.php.net/rfc/introduce_design_by_contract There is alternative implementation proposal by “Definition” https://wiki.php.net/rfc/dbc2 https://wiki.php.net/rfc/dbc2 This RFC is part of “Design by Contract Introduction” RFC https://wiki.php.net/rfc/introduce_design_by_contract This RFC is an alternative approach to “Native DbC support” RFC. http://wiki.php.net/rfc/dbc I understand there are things to resolve, but RFCs are good enough to start discussions. I'll post discussion mail shortly. If you find anything, have any comments or any show stopper, please let me know. Thank you! -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data
Hi all, There are too many things that I would like to improve ;) https://bugs.php.net/bug.php?id=69127 This bug is known fatal bug for session module. I proposed lazy_destroy to fix this before, but it declined. I think the name was wrong. With the proposal, session module destories session data with lazy manner, but it's actually precise manner. i.e. Session module and browser is _not_ synced, so destroy must be done async manner (~= lazy manner. For example, delete session data 60 seconds later). The reason why session_regenerate_id(true) fails is it deletes session data immediately even if session and browser is not in sync. Session and browser cannot sync because there is no means in HTTP/Cookie. Is there any other better idea for this? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
