> Or find a way to have (some of) your users have some level of trust.
Or don't execute anyone's uploads.
If you allow people to upload code, make them say it's code (via
extension *and* by putting it in an executable area).
It is not difficult to predict whether a file will be processed by PHP
On Sun, May 6, 2012 at 11:47 AM, Laruence wrote:
> On Sun, May 6, 2012 at 8:40 AM, Devis Lucato wrote:
>> Hi,
>>
>> I stumbled upon this code while working with a variable passed by
>> reference, I was wondering if someone could provide some feedback before
>> raising a ticket, just in case PHP (
On Sun, May 6, 2012 at 8:40 AM, Devis Lucato wrote:
> Hi,
>
> I stumbled upon this code while working with a variable passed by
> reference, I was wondering if someone could provide some feedback before
> raising a ticket, just in case PHP (5.3.6) is doing what it's supposed to
> do.
> In the code
Hi,
I stumbled upon this code while working with a variable passed by
reference, I was wondering if someone could provide some feedback before
raising a ticket, just in case PHP (5.3.6) is doing what it's supposed to
do.
In the code below I would expect "catch" to change the variable as
an assignm
I dealt with jpegs with injected metadata quite a bit at a previous employer.
In the end we ended up confirming the file was a proper image with the
filetype functions, then stripping the metadata using some command
line tools, and finally using a blacklist for key strings (like http://www.php.net
On Sat, May 5, 2012 1:52 pm, Ángel González wrote:
I never said it was an iron-clad technique. Only that it would be
harder to craft such an image.
If your TOU that meta-data gets stripped, so be it.
Or find a way to have (some of) your users have some level of trust.
To: Tom (?)
One doesn't al
On Sat, May 5, 2012 at 5:31 AM, C.Koy wrote:
>
> I've been experimenting with bare-bones PHP I've built from pristine
> sources so far. Don't you think you should do the same, in dealing with
> such a bug?
>
My personal system is a BSD derivative; the Turkish locales on these use
latin rather t
> Moreover, that still doesn't protect you, as it would be possible to
> make a valid image where the payload happened in the image data...
Agreed. But sanitizing input by silently removing blocks of data your
users rightfully expect to be preserved? That's egregious, even if it
"worked."
(Like m
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
>> Then one can strip off the exif info with the comments, I believe.
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 reaso
This whole business of bending over backwards to prevent injection of php when
apache is misconfigured just encourages apache misconfiguration IMHO. Smart
people are protecting you, you don't have to do these things right, don't worry
about it!
Sent from my iPhone
On May 5, 2012, at 1:50 PM, "
On Sat, May 5, 2012 at 7:50 PM, Richard Lynch wrote:
> On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote:
> > On Sat, May 5, 2012 at 6:32 PM, Richard Lynch wrote:
> >
> >> On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote:
> >> >In
> >> > most systems you can upload *anything* with a .jpg exte
On 5/5/2012 7:01 PM, Wim Wisselink wrote:
Try to var_dump the setLocale and see if it return the specified locale
or just 'false'.
I thought he was way past that control. Anyway, a simple test should
suffice:
setlocale(LC_CTYPE, 'tr_TR') or exit('setlocale failed\n');
--
PHP Internals
On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote:
> On Sat, May 5, 2012 at 6:32 PM, Richard Lynch wrote:
>
>> On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote:
>> >In
>> > most systems you can upload *anything* with a .jpg extension and
>> the
>> > app will take it, so you can still include th
On Tue, April 17, 2012 3:34 am, Martin Jansen wrote:
> On 17.04.12 10:24, Bas van Beek wrote:
>> Sounds like facilitating wrong security protocols to me. In this
>> 365/24/7 environment, sysadmins should be willing and able to patch,
>> fix
>> and secure systems at any time. Weekend should be no ex
On Sat, May 5, 2012 at 6:32 PM, Richard Lynch wrote:
> On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote:
> >In
> > most systems you can upload *anything* with a .jpg extension and the
> > app will take it, so you can still include the file
>
> People don't use imagecreatefromjpeg() to be sure
[soapbox]
Several people in at least one thread (I can't remember) have stated:
Education won't work.
I must take objection to that.
Not too long ago, a large number of people on this very list agreed
that SQL Injection was a Big Problem, and if they all blogged about
it, awareness would help.
On Wed, April 11, 2012 12:25 am, Stas Malyshev wrote:
> Hi!
>
>> I'm sure you have seen the same code in JSON hijack countermeasure.
>>
>> while(1){}
>
> I think you misunderstood what I means. What I meant is you can inject
> code without the
> improvement?
> kill() function would be just an exam
On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote:
>In
> most systems you can upload *anything* with a .jpg extension and the
> app will take it, so you can still include the file
People don't use imagecreatefromjpeg() to be sure it isn't some ware
or executable or PHP script disguised as a JPEG
On Tue, April 10, 2012 1:27 pm, Stas Malyshev wrote:
> Hi!
>
>> Scroll down a bit; he gets into valid points about the == operator,
>> for instance. It's not a useless post. He does cite too many things
>> that he has to follow up himself by saying "this was fixed in PHP
>> 5.x.y." If it was fixed,
On 05/04/2012 11:22 PM, Galen Wright-Watson wrote:
On Fri, May 4, 2012 at 7:01 AM, C.Koy wrote:
On 5/2/2012 10:03 PM, Galen Wright-Watson wrote:
On Wed, May 2, 2012 at 5:23 AM, C.Koy wrote:
On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
On Thu, Apr 26, 2012 at 3:45 AM, C.Koywrot
On Wed, April 11, 2012 5:14 pm, Yasuo Ohgaki wrote:
> I think my RFC confused people on this list due to improper
> descriptions
> and too much information. Sorry for the confusion. I revised the RFC
> so
> that most important points can be understood at a glance.
>
> https://wiki.php.net/rfc/nophp
On Tue, April 10, 2012 5:53 pm, Nikita Popov wrote:
> Another reason is that currently you get a very obscure error message
> if you try to use empty() on a function return value: "Can't use
> function return value in write context". Aha. Where did I try to write
> to the return value?!
On the lin
On Thu, April 12, 2012 6:05 pm, Johannes Schlüter wrote:
> On Wed, 2012-04-11 at 00:53 +0200, Nikita Popov wrote:
>>
>> Currently the empty() language construct only works on variables.
>> You
>> can write if (empty($array)) but not empty if
>> (empty(getSomeArray()).
>
> I've mentioned this though
Hi,
2012/4/26 Clint Priest :
> I'm having some trouble setting up the re2c to allow the isset/unset. Here
> are the definitions, I've added the two T_ISSET statements:
>
>
> accessors:
> accessor_function
Hi Clint,
On Wed, May 2, 2012 at 3:23 PM, Clint Priest wrote:
> Anyone have any help with this?
hard to say like this with this partial patch, do you have some git
branch I can pull from to reproduce and analyze this?
Alternatively, the complete an up-to-date patch?
Best Regards,
--
PHP Inter
Hi Dmitry:
On Sat, May 5, 2012 at 6:38 PM, Laruence wrote:
> On Sat, May 5, 2012 at 2:36 PM, Dmitry Stogov wrote:
>> Hi Laruence,
>>
>> Thank you for sending this.
>>
>> I'm not sure if the patch is completely correct.
>> With the patch all the threads share the single copy of script_encoding_li
On Wed, April 18, 2012 9:42 pm, Rasmus Schultz wrote:
>> On 04/10/2012 06:20 PM, Adir Kuhn wrote:
>>
>> "PHP Gotchas, how they came to be, and why we can't simply fix
>> them"
>>
>
> can't or won't?
>
> It seems that the requirement for backward compatibility, as with most
> software, stands in th
I'm terribly sorry, but I managed to delete the original while running
through the thread to be sure I didn't duplicate comments, and my
mailer won't let me respond to a deleted message.
So this will appear as a new thread.
#1
A standard for non-core extension version fields is a great idea.
But
On 5/5/2012 12:22 AM, Galen Wright-Watson wrote:
That also ran without error for me. I'm not sure how to account for the
different behavior. Here are the details of the system that I'm using:
$ uname -a
Linux n10 3.2.6mtv10 #1 SMP Wed Mar 14 06:22:06 PDT 2012 x86_64 GNU/Linux
$ php -v
PHP 5.2
On Fri, May 4, 2012 2:10 pm, Kris Craig wrote:
> On Fri, May 4, 2012 at 11:48 AM, Richard Lynch wrote:
>
>> On Wed, May 2, 2012 4:43 am, Pierre Joye wrote:
>> >>> empty() on the other hand, tests if something is empty, and only
>> if
>> >>> it
>> >>> is empty. The result of an expression can be e
On Sat, May 5, 2012 at 2:36 PM, Dmitry Stogov wrote:
> Hi Laruence,
>
> Thank you for sending this.
>
> I'm not sure if the patch is completely correct.
> With the patch all the threads share the single copy of script_encoding_list
> and when one thread terminates it calls compiler_globals_dtor()
On Sat, May 5, 2012 at 1:38 AM, Stefan Marr wrote:
>
> On 04 May 2012, at 21:46, Hannes Magnusson wrote:
>
>> On Fri, May 4, 2012 at 8:30 PM, Scott MacVicar wrote:
>>> This caused a few bugs for us / confusion. The final keyword is accepted
>>> inside a trait but it the class also defines a meth
33 matches
Mail list logo
