On 31/05/16 02:33, Sammy Kaye Powers wrote:
BOM's should not be treated as characters and should not be sent to
the output. Is there any reason this should be considered the expected
behavior? If not, I'd like to create an RFC to change it. :)
What about
«Hello Foo!
Today is » ?
If there's a B
I don't think more than a direct SMTP transport will be needed (LMTP
perhaps?), but it seems a good idea that #29629 can finally be fixed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 21/02/16 11:42, Anatol Belski wrote:
Were you putting the snippets into a file or testing on the console? I
had an issue while testing this on the console, that some chars was
partially swallowed by terminal (which was a utf-8 terminal). When
putting into a file, the output is same for both
On 19/02/16 09:20, Anatol Belski wrote:
Could you please write back, what is the out difference between those
two commands? Thanks. Anatol
In the first case, it correctly outputs «x°11» (78 c2 b0 7a). With jit
enabled it produces «x�z» (78 c2 7a). That is, it is only outputting the
lower byte
On 19/10/15 21:43, Scott Arciszewski wrote:
(...)
If you have a keyspace of 2^32 possible output sequences like we do
from rand(), we can say that after 65,536 there is a 50% probability
of finding at least one collision.
It should go without saying, but if users have weak/common password
choic
On 19/10/15 00:59, Anthony Ferrara wrote:
I don't feel comfortable pulling against 7 this far into RC status.
Perhaps wait until after it goes gold? Or should this target 7.1? It's
not a big deal in either direction. Though it does add a side-effect,
where if it can't gather enough entropy it wil
On 15/09/15 18:23, Anthony Ferrara wrote:
Third, it ignores context. This is related to the first two, but I
think is a separate concern. An example from the taint RFC
(https://wiki.php.net/rfc/taint) is the shell-execution. If the
variable is used in the context of command, one escape function i
On 22/06/15 23:40, Anatol Belski wrote:
Hi,
Actually I was relying on that page as well. While it would be great if 5.4
branch were blocked, as we would branch 7.0 ... disregarding were it wrong or
not, IMHO 14th September should be the date. Even if the page is wrong, the
info is public, peop
On 30/04/15 00:41, Christoph Becker wrote:
Hi everybody!
I've noticed that the "Reserve Even More Types in PHP 7" RFC[1] has been
moved to "Process and Policy" with the comment "needs no impl".
However, the RFC states:
| This RFC does not fully reserve them as keywords; it only prohibits
| thei
No objections here either.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I wonder how many people use ternary operators in an associative context.
My suspicion is that little of those that do really intend PHP
associativity.
But it'd need quite a parser to detect the affected usage.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
On 11/12/14 20:44, Leigh wrote:
I actually think a generic random bytes function outside of any
cryptographic extensions would be a good idea. Even mcrypt seems like
overkill if all you want is random strings.
mcrypt_create_iv should be left as an alias to that function, even if no mcrypt
exten
On 03/12/14 10:22, Anatol Belski wrote:
I meant that as well, to the time it's merged all the TSRMLS_* thingies
should be removed. I kept them only while developed and now for the RFC so
the diff shows the only change done, otherwise it would sink in the
unrelevant stuff.
Therefore I'd rather st
Anatol Belski wrote:
Hi,
this is a long spoken topic which is now embodied in
https://wiki.php.net/rfc/native-tls . A preliminary implementation is
there as well, thus we can discuss it.
Regards
Anatol
Great!
I remember myself already wondering about that years ago.
+1
--
PHP Internals -
On 19/09/13 23:41, Adam Harvey wrote:
As for the CA bundle side of things, I wonder if this is one of those
rare times where an ini setting might make sense, as opposed to actual
bundling — that would allow distros to point to their packaged bundles
without needing to patch php-src, and we could
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's stream encryption aspects are quite poorly
documented. For example, https:// streams disable peer verification by
default. While I understand that this is necessary to provide the easiest
possible user experience for things like `file_
On 13/09/13 22:10, Lazy wrote:
Hello internals,
I'm trying to fix deadlock in an ancient php 5.2.17, php hangs on
internal libc lock.
From my understanding free is not safe to use in a signal handler, and
this seems to be the issue here.
No, it's not.
http://marc.info/?l=php-internals&m=1219
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP
(...)
What do y
On 08/08/13 20:56, Michael Wallner wrote:
As I have no Zend karma, is anybody kind enough to merge the bison
blacklist patch?
https://github.com/php/php-src/pull/402
Maybe it should be bison_version_exclude="none" so that the error
message is nicer?
--
PHP Internals - PHP Runtime Development
On 07/08/13 13:00, Leigh wrote:
On 7 August 2013 11:18, Yasuo Ohgaki wrote:
A user requested that crypt() should raise error without 2nd(slat)
parameter.
https://bugs.php.net/bug.php?id=55036
crypt() without salt generates extremely weak password hash.
The docs seem to indicate that some i
On 31/03/13 23:18, ALeX wrote:
>> JSON and serialize() are (inherently) different serialization formats with
>> different use-cases [...]
> Yes, and json requires that all strings (including the keys) has to be
> valid utf-8, and I'm sure that's not always the case (serialize can
> use binary data
On 18/03/13 14:04, Julien Pauli wrote:
> Also, AFAIR, call_user_func() doesn't work with functions using
> references in args. Julien.Pauli
AFAIK it does.
Do you have an example where it doesn't?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/u
On 15/03/13 15:19, Steve Clay wrote:
> I'm sure this question has been discussed before, so if anyone can
> point to me to links or briefly recap I'd appreciate it.
>
> Why can't we make $someCallable() always work? E.g. http://3v4l.org/FLpAq
>
> I understand the problem of $obj->foo() where ->foo
On 12/03/13 17:30, Derick Rethans wrote:
> On Tue, 12 Mar 2013, Jonathan Sundquist wrote:
>> Why would the result not preserve the time?
> Because "tomorrow" starts at midnight. You want "+1 day".
>
> cheers,
> Derick
Alternatively, $d->add(new DateInterval('P1D'));
--
PHP Internals - PHP Runtim
On 11/03/13 12:36, Christian Stoller wrote:
> Hi Stas.
>> I'm afraid it is not a good idea. allow_url_fopen is meant to protect
>> file functions (fopen and friends) from being injected with
>> user-controlled data - i.e. if you control the filesystem and you do
>> fopen() under allow_url_fopen the
On 11/03/13 12:19, Eric James Michael Ritz wrote:
> Hello everyone,
>
> I have a question about the internals of PHP, but this is not about
> advancing the development of the language, so I apologize if this is
> on the wrong list. I am choosing to post to this list because I
> believe the people
On 15/02/13 10:25, Paul Dragoonis wrote:
> On Fri, Feb 15, 2013 at 9:23 AM, Damien Tournoud wrote:
>> On Fri, Feb 15, 2013 at 9:54 AM, Pierre Joye wrote:
>>> no, MediaWiki caching modules only support APC or Wincache so far.
>> As far as I understand, O+ doesn't have any user caching support, ri
On 05/02/13 21:16, Karoly Negyesi wrote:
> new keywords is an interesting discussion to have -- it's actually the
> first real thing to discuss as far as I can see. For example that is
> something that version strings would tremendously help. You do not
> need to maintain the whole lot of behaviors
Hans-Jürgen Petrich wrote:
> Hi Terry and all
> thank you very much for your response.
>
>> The only thing that confused me about what you say that the second
>> *doesn't* grow
> Yes, about that i was [and am still :-)] also confused... why the 2nd
> one won't grow *non-stop*
>
>> so I checked and
On 03/02/13 16:27, Hans-Juergen Petrich wrote:
> The only different in the second example is the fixed body length of
> the eval()-created anoymous function.
> I wondering why the memory in the second code-example will be freed at
> some point while in the first example not.
>
> I don't think it's
On 29/01/13 15:21, Pierre Joye wrote:
> On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>> On Windows with impersonation you're actually in a better situation than
>> you are in Linux. You could hold a small pool of processes and handle as
>> many different users as you'd like.
> Works fine
On 14/01/13 05:10, Paulo Henrique Torrens wrote:
> Hi,
>
> I'm currently interested in two features I'd like to see in PHP; how do I
> proceed to request/propose them? I'd be glad to help implementing them as
> well, if necessary.
You should propose it here and then create a rfc about it in the p
On 18/12/12 15:43, Victor Berchet wrote:
> Dear all:
>
> I would like to get your feedback on implementing some more data
> structure in the PHP core.
(...)
I think this could be summarised as "allow objects as keys for arrays".
Which would give the Map behavior.
Implementing Set from that is stra
On 12/12/12 17:29, Amir wrote:
> Hi
> I searched in php.net and did not find any link that contain php none
> thread safe source code for windows.
> I have a php source that encoded with Zend Guard 5.5 and have to decode
> with Zend Guard Loader.
> note: Zend Guard Loader is NTS and didn't read TS
On 10/12/12 13:35, Christian Stoller wrote:
> Hm... I know '$date->add(new DateInterval('P15D'));' is possible, but it has
> the same problem.
>
> I have to write:
>
> $date = new DateTime()
> $date->add(new DateInterval('P' . getDaysToAddMethod() . 'D'));
>
> I think it is very hard to read. Or i
On 10/12/12 16:18, Nikita Nefedov wrote:
> So there had been at least two or three messages (subjects) about
> DateTime object and everytime there was this problem - people tend to
> take DateTime object as mutable object and it really is.
> As long as we know, it's not so good - date is immutable
On 06/12/12 13:52, Pierre Joye wrote:
> hi,
>
> On Thu, Dec 6, 2012 at 12:40 PM, Ángel González wrote:
>> On 06/12/12 09:49, Pierre Joye wrote:
>>> hi!
>>>
>>> While looking at the bug #63073, I was wondering if we could simply do
>>> not p
On 06/12/12 09:49, Pierre Joye wrote:
> hi!
>
> While looking at the bug #63073, I was wondering if we could simply do
> not pass open handles to the newly created child process.
Looking at proc_open, where there is an explicit CreateProcess (we seem
to be using the library popen for the exec()...
On 29/11/12 18:17, Anthony Ferrara wrote:
> Just pointing this out: that's NOT what this RFC recommends, and is
> NOT what's being voted on. This RFC is talking about ONLY adding
> E_DEPRECATED to core. And the way it's proposed to be done, the
> "moves-to-PECL" couldn't happen, since it's hard-cod
David Muir wrote:
> On 29/11/12 05:09, Ángel González wrote:
>> I see it as simple to show E_DEPRECATED but not when installed from
>> PECL.
>>
>> 1) Add a
>> int mysql_extension_triggers_deprecated_warning = 1;
>>
>> And use it as a conditional
On 26/11/12 22:21, Sara Golemon wrote:
> https://wiki.php.net/rfc/request-tempnam
>
> Just a bit of hand-holding for those who don't remember to clean up
> their messes.
I like it.
Also note that it's not always that people “don't
remember to clean up their messes” since there are
several tricky ca
I see it as simple to show E_DEPRECATED but not when installed from PECL.
1) Add a
int mysql_extension_triggers_deprecated_warning = 1;
And use it as a conditional for triggering the warning.
2) Copy the extension code to PECL
3) Add these changes in PECL
- If the mysql functions are not alread
On 17/11/12 17:24, Rasmus Lerdorf wrote:
> Right, that is what I meant by focusing more on the carrot than the
> stick. Many people, yourself included, don't realize the things they
> would gain switching to mysqli. We need to do a better job with that and
> perhaps even consider if there are other
On 16/11/12 17:03, Rasmus Lerdorf wrote:
> So, I am curious, why are you waiting on us for this? Is it because
> ext/mysql does everything you need and you simply have no need for any
> of the new and obviously better features in mysqli? I would have thought
> you would have switched to mysqli year
Am 14/11/12 03:26, schrieb Michael Kliewe:
> Am 14.11.2012 00:23, schrieb Ángel González:
>> So the problem really moves onto the CMS providers, do they support
>> new php versions and drop customers in shared hosting, do they delay
>> supporting the new php versions, or do th
I see several problems with deprecating ext/mysql:
- The extension is not broken. The problem is the bad usage.
It can be used safely, and good developers have been doing
so for ages, by creating php wrappers.
In magic quotes, the work has been the opposite. The developers
had been detecting the f
On 17/10/12 11:43, Pierre Joye wrote:
> It is about hi jacking discussions with totally irrelevant topics,
> repetitive, nonconstructive posts in rows, in all possible ways.
The issue is that the proposed solution (a forum) does not solve
irrelevant topics being mixed into a discussion about a dif
On 18/09/12 21:06, Pádraic Brady wrote:
> Hi Ángel,
>
> The methods all refer to literal strings, values or digits. We can't
> reasonably escape data while allowing valid markup for the current
> context since that's a contradiction by its very nature. If you needed
> to let user values drive CSS n
El 18/09/12 13:30, Pádraic Brady escribió:
> Hi all,
>
> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
> The RFC is a proposal to implement a standardised means of escaping
> data which is being output into XML/HTML.
>
> Cross-Site Scripting remains one of the most common v
On 25/08/12 00:50, Rasmus Lerdorf wrote:
> In 8859-1 no chars are invalid so anything that doesn't get encoded will
> get passed through as-is. For example the byte 0xE0 is a perfectly valid
> 8859-1 character (à), but if the page is actually UTF-8 then this
> becomes the first byte of a 3-byte UTF
El 23/08/12 18:06, Rasmus Lerdorf escribió:
> htmlspecialchars(), htmlentities(), html_entity_decode() and
> get_html_translation_table() all take an encoding parameter that used to
> default to iso-8859-1. We changed the default in PHP 5.4 to UTF-8. This
> is a much more sensible default and in th
On 20/08/12 15:12, Nikita Popov wrote:
>> You could not decorate it and rely instead on the presence of the yield
>> keyword, but parsers will thank knowing about it from the start rather
>> than realising at mid-parsing that the function is a completely
>> different beast.
> No, parsers don't care
On 20/08/12 02:01, Rasmus Lerdorf wrote:
> I would still like to understand what this generator keyword would
> actually do. I don't see how it would work. Would a function marked
> generator somehow not be allowed to return normally or to finish and not
> return anything? How could this be enforce
On 17/08/12 23:41, Sebastian Krebs wrote:
> Hi,
>
> Don't know, how complicated this is (and also someone (not me) must
> implement it, because I can't :X), but to be in sync with the
> operators the short ternary operator should be usable in conjunction
> with the assignment like the other binary
On 03/08/12 01:22, Sara Golemon wrote:
> In all seriousness, I'd love to hear how you'd do Sandboxing without
> using the tsrm context hack I used in runkit. That approach had
> nothing to do with being in PECL, it had to do with that being the
> only mechanism available to swap globals in and out
On 01/08/12 20:02, Kris Craig wrote:
> On Wed, Aug 1, 2012 at 6:13 AM, hakre wrote:
>
>> I have some simple questions about PHP 5.x End Of Life (EOL) dates:
>>
>> PHP 5.0 - Is there some official news-item or changelog entry on php.netthat
>> says at which date PHP 5.0 went End Of Life?
>>
>> PHP
On 31/07/12 22:20, Peter Lind wrote:
> On 31 July 2012 22:02, Anthony Ferrara wrote:
>> Peter,
>>
>> On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind wrote:
>>> On 31 July 2012 18:21, Anthony Ferrara wrote:
>>>
>>> *snip*
>>>
Also, be aware that BCrypt only uses the first 72 characters of the
>>
On 31/07/12 18:21, Anthony Ferrara wrote:
> Jonathan,
>
> On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron
> wrote:
>> Sure managing keys properly can be hard, simple cases:
>> $secret = MY_KEY;
>> $secret = file_get_contents('/security/key.pem');
>>
> Actually, that's not properly managing t
On 22/07/12 04:08, Kris Craig wrote:
> On Sat, Jul 21, 2012 at 3:09 AM, Andrew Faulds wrote:
>
>> If you think 1.1 =/= 1.01 you're sure using some weird version numbers.
>> Only 1.0.1 would be smaller.
>>
>> Has anyone seen these weird version ordering schemes in practise? On any
>> major projects
On 21/07/12 11:32, Pierre Joye wrote:
> hi,
>
> No, I mean version with 1.0 and not 1.0.0 are not. They are just not
> correct and confusing, as you noticed.
Then Linux 2.6.39 shouldn't have been followed by Linux 3.0
For me, 1.0 and 1.0.0 are the same thing.
It's fine if x.y is not a valid "PHP-
On 17/07/12 13:34, Alex Aulbach wrote:
>> That's more or less what I have thought.
>> If it's a string surrounded by square brackets, it's a character class,
>> else
>> treat as a literal list of characters.
>> ] and - can be provided with the old trick of provide "] as first
>> character",
>> "mak
On 16/07/12 17:32, Alex Aulbach wrote:
> I like it. I've looked in some code and found about 8
> password-generation-functions. 4 of them have more or less the same
> idea behind.
>
> The rest generates more complicated password. E.g. "minimum one
> digit", "First letter must be alphabetic". This i
On 16/07/12 16:21, Anthony Ferrara wrote:
> If this is something that's desired, I can update the password
> implementation to include this change (since it depends on a function like
> this internally)...
>
> Anthony
Looks good.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
On 16/07/12 08:04, Galen Wright-Watson wrote:
> What about an approach like PDO, where the password functions would
> generate errors by default, but could be configured to throw exceptions?
> The ugliest aspects of this idea are the requirement for another function
> (password_set_option?) and hid
On 15/07/12 22:07, Alex Aulbach wrote:
> 2012/7/14 Andrew Faulds :
>> Well... if people have poorly configured servers spitting out debug
>> info in production mode, I don't think it is our problem. It is
>> theirs.
> Do you want to make it secure or do you want to discuss?
Seems Andrew mail didn't
On 13/07/12 12:28, Ryan McCue wrote:
> Somewhat off-topic, but is there a reason why not? It seems to me that
> introducing a new API without using PHP's best method of error handling
> (IMHO) is a little silly.
I don't really trust exception throwing near password-managing functions.
Consider the
On 12/07/12 17:30, Johannes Schlüter wrote:
> Hi,
>
> On Thu, 2012-07-12 at 17:09 +0200, Jille Timmermans wrote:
>> An implementation is quite simple:
>> https://github.com/Jille/php-src/commit/31a1aa384c29487e077ccf3fd067eca188cf1201
> Without looking at the functional change itself a comment: The
On 03/07/12 18:21, Anthony Ferrara wrote:
>> 2) I'd like to be able to check wether a stored password uses an outdated
> algorithm and update the hash in that case. For that I'd need either a
> function to extract the salt from a hash to pass it to password_hash() and
> compare the result with the
On 29/06/12 14:43, Nikita Popov wrote:
> Hi internals!
>
> Anthony and me have been looking a lot at the crypt() code recently
> and noticed that there are some strange things going on in the buffer
> allocations for the sha algorithms.
>
> We did two commits to fix them up a bit:
>
> http://git.ph
On 27/06/12 18:13, Pierre Joye wrote:
> Changing default value forces code change if you have to keep a given
> hash, for one obvious side effect.
>
> If you disagree or does not like the idea, that's all fine, but you
> can't really say that it is not an argument (nothing to justify, this
> is a d
On 18/06/12 18:54, Anthony Ferrara wrote:
> Pierre,
>
>> There is sadly only state-of-art-right-now password hashing methods.
>> We have to keep that in mind :)
> That's why the crypt() return format was designed. All of the options
> that are needed to validate the hash (algorithm, cost parameter,
On 16/06/12 15:39, Pierre Joye wrote:
> However the point here is not the implementation but the APIs.
>
> To be honest I am not a big fan of providing such an API in the core
> as no matter the default implementation, it will become obsolete soon
> or later. And changing the default brings its lot
On 14/06/12 00:58, Michael Felt wrote:
> Hi.
>
> I am trying to compile php against httpd 2.4.2 - but before it gets
> interesting I think I am having a different problem.
>
> The sqlite3 embedded in ./ext/sqlite3 returns a syntax error against vac.C
> v11 compiler.
>
> data/prj/php-5.3.13/ext/sqli
On 13/06/12 05:26, Morgan L. Owens wrote:
> After reading the performance improvements RFC about interned strings,
> and its passing mention of a "special data structure (e.g.
> zend_string) instead of char*", I've been thinking a little bit about
> this and what such a structure could be.
>
> But
On 14/06/12 16:26, Peter Lind wrote:
> I would say it really depends upon the project. The salt can not only
> protect against rainbow tables and password hash collisions, if it is
> unknown to an attacker then it essentially acts to further strengthen
> the hash by vastly expanding the keyspace. S
On 11/06/12 23:12, Tom Boutell wrote:
> Can you really use setjmp and longjmp in that way safely? I thought it
> was only safe to longjmp "back," not "forward" - you can use them to
> fake exception support but that's it because you'll smash the stack
> otherwise. Something like that...
My first re
On 06/06/12 12:20, Ivan Enderlin @ Hoa wrote:
> On 05/06/12 19:35, Nikita Popov wrote:
>> Hi internals!
> Hi Nikita,
>
>> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
> I have always hoped to see the “yield” keywork introduced in
On 05/05/12 20:08, Sanford Whiteman wrote:
> This presupposes that your users don't expect embedded metadata to be
> preserved when people redownload the images.
>
> Not only do photo professionals/hobbyists expect you to keep the
> metadata, you also should leave it in for reasons of legality. Hos
On 24/04/12 18:11, Paul Dragoonis wrote:
> Happy to patch this once someone confirms this is a bug and not
> "changed behaviour" in 5.4.
>
> - Paul.
Why would such behavior change be desired?
get_magic_quotes_gpc() is kept only for compatibility with scripts which
did magic quote detection.
As suc
On 10/04/12 19:22, Chris Stockton wrote:
> Hello,
> I understand your point that you are trying to make, but forward
> compatibility I am not sure shares the same critical nature as
> backwards.
Sure, but if we can help with that when designing the feature, that's
much better, and I think would al
Hello Chris,
Chris Stockton wrote:
> I am not sure I am following you here Angel, are you confusing
> backwards and forward compatibility?
It can probably be termed both ways, depending on which version you stay.
I'm refering to the ability of a php file to work in both version 5.4
and 5.5 yet
ta
Luke Scott wrote:
>> if ( version_compare(PHP_VERSION, '5.5', '<') )
>> include_once $file;
>> else
>> require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );
> I'm fairly certain that wouldn't work either. Require and friends are
> constructs, not functions.
>
> Luke
I had assumed requi
On 09/04/12 21:17, Yasuo Ohgaki wrote:
> Please do not tell me that programmer should
> learn not to, since it's not a protection but education.
Hire a more competent programmer? If he writes such code,
he will be completely unaware of the subtleties of XSS, or how
SQL should be escaped, and his c
On 09/04/12 19:36, Luke Scott wrote:
> On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote:
>> Also, your objection - that 'require_code' is confusing - would most
>> likely be an issue for a handful of people who write autoloaders.
>> Those clean PHP class files are almost always autoloaded.
> Not rea
On 09/04/12 20:23, Chris Stockton wrote:
> Hello,
> Although I am not very interested in this feature, if it is
> implemented I like the idea of flags instead of introducing new
> keywords. Maintaining backwards compatibility would be great
> considering the benefit to the feature to be completely
On 09/04/12 13:29, Tom Boutell wrote:
> I would like to clarify what this RFC actually says. Let's try to keep
> this thread to the pros and cons of this specific proposal.
>
> The following new keyword would be introduced:
>
> require_path
I don't like the keyword name. Too confusing with the incl
On 08/04/12 14:31, Tom Boutell wrote:
> This is an attempt to protect people who have written inherently insecure
> code anyway. One should never do a dynamic require to any untrusted location,
> if ever at all, yes?
>
Obviously. But that include vulnerabilty seems a precondition to the
scenari
2012/4/8, Yasuo Ohgaki:
> 2012/4/8 Ángel González :
>> How does it help security?
>> If any, requiring '> out malicious files on apps with uploads in case there's a local
>> inclusion vulnerability somewhere.
>>
> Attackers may inject PHP script almos
On 07/04/12 22:48, Yasuo Ohgaki wrote:
> Hi,
>
> The only valid reason for removing security.
>
> Since the null byte detection for fopen, remote/local script inclusion
> became much harder than before. However, it's still possible and very
> easy compare to other languages. Script execution is cr
On 07/04/12 19:29, Rasmus Lerdorf wrote:
> On 04/07/2012 10:23 AM, Ángel González wrote:
>
>> And I like the idea of providing a function for auto escaping Turn on your default input filter and all data that comes from the user
> will automatically be escaped.
>
> -Rasmus
On 07/04/12 16:56, John Bafford wrote:
> On Apr 7, 2012, at 10:00, Tom Boutell wrote:
>> .phpc is then just a convention for naming PHP files that start out
>> with code - a convention that autoloaders should respect, just as they
>> now respect the .php convention. "The user asked for the Monkey c
On 07/04/12 17:22, John Bafford wrote:
> On Apr 7, 2012, at 10:53, John Crenshaw wrote:
>> What if you have just ONE function with a variety of options? Something like:
>>
>> execute_file('path/to/foo.php', array(
>>'require'=>true,
>>'once'=>true,
>>'begin_code'=>'>'shorttags'=>arr
On 07/04/12 16:06, Reindl Harald wrote:
> Am 07.04.2012 16:00, schrieb Tom Boutell:
>> That's a good point too.
>>
>> I think this is a better proposal:
>>
>> include_code, require_code, and require_code_once would work just like
>> include, require and require_once, except that the parser would st
On 01/04/12 14:19, Florian Anderiasch wrote:
> I'd appreciate any hints on how to tackle this serious concern.
You should launch a new thread to tackle them. You could then buy
foreign slaves to schedule them on their cores.
> Btw, in the spirit of x for hex and b for binary I thought about using
El 19/03/12 21:29, David Soria Parra escribió:
> On 2012-03-19, Kris Craig wrote:
>> The workflow page currently recommends the "git:" one for cloning (which
>> doesn't work for me, either).
> git:// is recommended when you can use it. The access is limited due to
> port limiations, but the protoc
El 20/03/12 21:45, David Soria Parra escribió:
> On 03/20/2012 09:48 PM, Ángel González wrote:
> > El 19/03/12 21:29, David Soria Parra escribió:
> >> On 2012-03-19, Kris Craig wrote:
> >>> The workflow page currently recommends the "git:" one for
> >
On 18/03/12 06:56, Tjerk Anne Meesters wrote:
> On Sun, Mar 18, 2012 at 8:12 AM, Stas Malyshev wrote:
>> Obvious solution would be to use a salt for the hash, which prevents blind
>> pre-computing of hash collisions. However, due to the fact that PHP hash
>> values can be reused in different proce
On 16/03/12 18:45, Lütfi Altın wrote:
> I want to read PHP source and help PHP for further development.
>
You don't need a svn account to read the php source. You can just
download the source from http://php.net/downloads.php#v5 view the
development version at http://svn.php.net/viewvc/php/php-src/
On 13/03/12 00:25, Stas Malyshev wrote:
> Hi!
>
>> Still, that API is likely wrong: a library function written by someone
>> completely unrelated to the main application shouldn't be echoing
>> anything through the output. And if it's not generating the html, the
>> htmlspecialchars is better done
On 14/03/12 20:42, Rasmus Lerdorf wrote:
> It is somewhat unintuitive that parse_str() is subject to the
> max_input_vars limitation and there are sites that use parse_str() to
> parse things that aren't directly coming from user query args.
> There arr two ways to solve this. We could add an optio
1 - 100 of 202 matches
Mail list logo
