Re: [PHP] No MIME-Type in "imap_fetch_overview()"

[Domain nikha . org]

Aziz Saleh am Montag, 23. September 2013 - 22:06:
> What Niklaus wishes for is a way to detect if an email message
contains an
> attachment by just reading the headers (correct me if I am wrong).
> 
Yes, that's what I'm seeking :-)

> This isn't really a PHP issue. In any language you can't really figure
out
> if an email has an attachment by just looking at the headers, you need
to
> check the body. You can try to infer by using the content-type or the
size,
> but that isn't 100% valid.
> 

That's like radio Eriwan: In principle you are right!

BUT: I want not show the whole MIME-structure in the mailbox overview!
That whould be absurd, and indeed could only be done by reading the
body.

Nevertheless we have in the primary header of any MIME compliant message
the line "Content-Type". (We have it also in the headers of the attached
parts, but that is not intresting now)

In this primary header (fetched by "imap_fetchbody($mailbox, $msg_no,
0)) the leading part of the MIME-type description can have only two
values: "text" or "multipart". Right? I'm sure you will never find other
values in the _primary_ header.

That's the first decision for your script. "text: no attachment",
"multipart: attachment". No matter the subtype-value after the slash,
you have what I want! And ONLY by looking on the header. And this ist
100% valid, because it follows logically from the imap- and MIME-rfc's.

About malformed messages violating the protocols we discuss next year,
you agree? :-)

You may evaluate the subtype after the slash. If the type is multipart,
you will find "mixed", "alternative", "related" or "digest", if the type
is "text", you will have "plain" or "html" as subtype.

May be there are more subtypes on the way, but all these are optional
for the primary job, a decent mailbox overview must do: tell the user,
whether there are attachments or not.

My own webmail client does this job pretty good, but it violates my own
standard of good practice. Whether "imap_fetch-overview()" nor
"imap_headerinfo" are reading the "Content-Type"-line while parsing much
other header lines of minor importance. My script must refetch the
mailheaders to do that! This is an ugly overhead I wish to avoid.

BTW: the "squirrelmail"-staff, leading in the PHP-webmail-world, just
ignores the whole imap-extension of PHP. Instead, they talk low level
with the server. But this way is a little bit too hard for me...

Therefore my pledge to all involved into the development of the fabulous
PHP framework, section imap:
Please ad the primary MIME-type to the objects returned by
fetch_overview and headerinfo! It's so ridiculous simple: read the
"Content-Type"-line in the primary mailheader as I must do afterwards,
only because you do not!

Niklaus


  
 

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] No MIME-Type in "imap_fetch_overview()"

[Domain nikha . org]

Negin Nickparsa am Montag, 23. September 2013 - 20:59:
> I have read your mail twice and still I could not get what you want
> exactly.  

Sorry for my bad english! 
What I want is, that the users of my webmail client can see at a glance,
if mails in their mailboxes have attachments or not. (Thats a human
right! But of course I was joking... It's simply nice to provide this
information and should be done)

> but if you want to get the type of files fetch the structure and then
you
> can use disposition string, find the "attachment" and then return the
> array.

Yes, I could do even that! But this is worse! Imagine, you do this in
the overview of the mailbox content! This can be hunderds of mails! My
script paginates this stuff in blocks of 16 (or something) mail headers,
but even then you have an huge overhead.

Why? 
Because, first you must collect the sender and subject information. This
is done by "imap_fetch_overview()", parsing the mailheaders and grabing
some server data, like arrival date, size and flags.

Fine, but you still know nothing about attachments! You must do
something more. OK?

You whould run "imap_fetchstructure()", but sorry, that's the wrong time
and place. You will need this monster object only when the user _reads_
some specific mail. At the moment, we are not reading, but collecting
mails to present them in the mailbox overview.

My script modestly fetches the mailheaders again to read the
"Content-Type"-line. That's quite fast, works fine, but is stupid,
because this headers were fetched and parsed just before! 

I ask you, and all PHP developpers: Why the hell this function does not
parse this line too? (a part of so much others of less importance) The
same is true for "imap_headerinfo()". And: of course this
"Content-Type"-line provides by far not the complete MIME-structure as
"imap_fetchstructure()" does, but, as said, we don't need this at the
moment.

The result is a script, that I self whould not describe as "good
practice" because of it's duplicated parsing of the same string, but I
found no other way yet.

That's my problem, you see?

Sincerely
Niklaus

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Apache

[Tamara Temple]

On Sep 23, 2013, at 1:36 PM, Domain nikha.org  wrote:

> Better solutions?

One I have used, and continue to use in Apache environments, is place uploads 
only in a place where they cannot be executed by turning off such options and 
handlers in that directory. This is *in addition* to untainting files and names 
of uploaded files.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] No MIME-Type in "imap_fetch_overview()"

[Aziz Saleh]

What Niklaus wishes for is a way to detect if an email message contains an
attachment by just reading the headers (correct me if I am wrong).

This isn't really a PHP issue. In any language you can't really figure out
if an email has an attachment by just looking at the headers, you need to
check the body. You can try to infer by using the content-type or the size,
but that isn't 100% valid.

Aziz


On Mon, Sep 23, 2013 at 2:59 PM, Negin Nickparsa wrote:

> I have read your mail twice and still I could not get what you want
> exactly.  can't get the structure of the email either although you
> elaborate it in details.
>
> you have said something about human rights that I couldn't understand why?
> but if you want to get the type of files fetch the structure and then you
> can use disposition string, find the "attachment" and then return the
> array.
>
>
>
>
> Sincerely
> Negin Nickparsa
>
>
> On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org  wrote:
>
> > Hello all,
> >
> > im posting this here, because the bug report system of "php.net" is not
> > right
> > place for my problem. It's not a bug, but a wish - an I found there no
> > "wishlist" option at all.
> >
> > I'm running my own webmail-client, written in PHP. It is stable, fast and
> > pretty, showing the full power of the PHP imap section.
> >
> > Of course it presents paginated content lists for every mailbox the user
> > may
> > open. These lists tell him some usefull things about every mail actually
> > listed:
> > Sender, date, subject, size and (eventually) flags.
> >
> > All these things are nicely delivered by the function
> > "imap_fetch_overview()"
> > The same could be done by calling "imap_headerinfo()" for every single
> > mail, but
> > "fetch_overview" seems to be faster, because it does it at once for the
> > whole
> > batch.
> >
> > BUT NONE OF THEM returns any information about the MIME-Type of the mail!
> >
> > Since the user of my webmail client has the intrinsic, natural born an
> > general
> > human right to KNOW whether some mail in his mailbox has attachments or
> > not, I'm
> > forced to do very ugly things. My script calls additionally for every (!)
> > actually listed mail  "imap_fetchbody($connect, $msg_no, 0)" - where
> > "$connect"
> > holds the result of "imap_open()".
> >
> > That gives me the mail header, the script reads the line starting with
> > "Content-Type:" and returns its content. Evaluating this against "mixed"
> or
> > "alternative" we have finaly what we want: This mail has attachments! Or
> is
> > written in HTML, what is even more we wanted!
> >
> > Works fine, but is ugly. First "fetch_overview" parses all mail headers,
> > then
> > they are fetched again to be parsed for the MIME-Type. I could just omit
> > "fetch_overview" and read the headers by my own means, that whould be
> > faster,
> > but then I loose the size information, that is NOT (and cannot) be part
> of
> > the
> > mail header!
> >
> > If I want to have both, size and MIME-Type, and I WANT to have both,
> > respecting
> > the intrinsic, natural born and general human rights of my user, im must
> > call
> > both, "overview" and "fetchbody".
> >
> > My question is this: Is there a better solution? Or is there someone that
> > knows
> > someone among the PHP-Developpers to suggest them an improvement of the
> > functions "imap_fetch_overivew()" and "imap_headerinfo()". Please,
> Please,
> > add
> > the MIME-Type to your fantastic object collections! BTW: It's really
> easy.
> > Read
> > the "Content-Type"-Line! Sorry...
> >
> > Hope, somebody has an idea,
> > my regards,
> >
> > Niklaus
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP] Apache

[Ashley Sheridan]

On Mon, 2013-09-23 at 20:36 +0200, Domain nikha.org wrote:

> Stuart Dallas am Montag, 23. September 2013 - 12:58:
> 
> > And, honestly, who would have a PHP file per language? I think it's
> perfectly reasonable to not allow that, because duplicating PHP code
> across many files is an incredible stupid way to support multiple
> languages.
> > 
> I agree!! Didn't even know, that this kind of faked language support
> exists...
> 
> > "Some people run all their files through PHP" - true, but that doesn't
> mean they should, or that you, as a responsible web host, should be
> endorsing it.
> > 
> > PHP developers should absolutely validate all content coming in from
> users in every possible way, but I would be highly dubious about
> trusting a host who gives the reason above for what I consider a lax and
> insecure Apache configuration. It's like saying they sliced your arm off
> with their chainsaw because it's made for cutting things, attempting to
> dodge all responsibility for having swung it in your direction!
> > 
> OK, in principle, I also agree. But this case is very easy to handle.
> I'm simply running "str_replace()" against dangerous parts of uploaded
> filenames, ".php" for instance. After that, Apache in every
> configuration will just serve, and never execute user uploaded files.
> Remains the risk on the clients side, I must concede. Better solutions?
> 
> Nice days,
> Niklaus   
> 


No, no, no! That is not a good stand-in for fundamental security
principles!

This is a better method for ensuring an image is really an image:







Obviously it's only rough, and checks only for jpeg images, but that's
easy to alter. I've just tested this with a regular jpeg, the same jpeg
with PHP code concatenated onto the end (which still appears to be a
valid image to viewing/editing software) and a pure PHP file with a .jpg
extension. In the case of the first 2, a new jpeg is generated with the
same image and without the code. The third example just echoes out an
error.


Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)

[Michał Kochanowicz]

W dniu 2013-09-23 17:24, Tamara Temple pisze:

That is one whopping-big inode number — I am really out on a limb here, but is 
this a 32-bit vs 64-bit issue?



You're right - 64-bit inode number was a cause. I had to add "inode32" mount 
option (XFS).


Regards
Michał


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)

[Michał Kochanowicz]

W dniu 2013-09-23 10:06, Negin Nickparsa pisze:

regardless of you, saying they have same permissions I think they do not have
the same permission


The reason was 64-bit inode number. PHP can't stat() files with 64-bit nodes, 
at lease on 32-bit system.


Regards
Michał


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] No MIME-Type in "imap_fetch_overview()"

[Negin Nickparsa]

I have read your mail twice and still I could not get what you want
exactly.  can't get the structure of the email either although you
elaborate it in details.

you have said something about human rights that I couldn't understand why?
but if you want to get the type of files fetch the structure and then you
can use disposition string, find the "attachment" and then return the
array.




Sincerely
Negin Nickparsa


On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org  wrote:

> Hello all,
>
> im posting this here, because the bug report system of "php.net" is not
> right
> place for my problem. It's not a bug, but a wish - an I found there no
> "wishlist" option at all.
>
> I'm running my own webmail-client, written in PHP. It is stable, fast and
> pretty, showing the full power of the PHP imap section.
>
> Of course it presents paginated content lists for every mailbox the user
> may
> open. These lists tell him some usefull things about every mail actually
> listed:
> Sender, date, subject, size and (eventually) flags.
>
> All these things are nicely delivered by the function
> "imap_fetch_overview()"
> The same could be done by calling "imap_headerinfo()" for every single
> mail, but
> "fetch_overview" seems to be faster, because it does it at once for the
> whole
> batch.
>
> BUT NONE OF THEM returns any information about the MIME-Type of the mail!
>
> Since the user of my webmail client has the intrinsic, natural born an
> general
> human right to KNOW whether some mail in his mailbox has attachments or
> not, I'm
> forced to do very ugly things. My script calls additionally for every (!)
> actually listed mail  "imap_fetchbody($connect, $msg_no, 0)" - where
> "$connect"
> holds the result of "imap_open()".
>
> That gives me the mail header, the script reads the line starting with
> "Content-Type:" and returns its content. Evaluating this against "mixed" or
> "alternative" we have finaly what we want: This mail has attachments! Or is
> written in HTML, what is even more we wanted!
>
> Works fine, but is ugly. First "fetch_overview" parses all mail headers,
> then
> they are fetched again to be parsed for the MIME-Type. I could just omit
> "fetch_overview" and read the headers by my own means, that whould be
> faster,
> but then I loose the size information, that is NOT (and cannot) be part of
> the
> mail header!
>
> If I want to have both, size and MIME-Type, and I WANT to have both,
> respecting
> the intrinsic, natural born and general human rights of my user, im must
> call
> both, "overview" and "fetchbody".
>
> My question is this: Is there a better solution? Or is there someone that
> knows
> someone among the PHP-Developpers to suggest them an improvement of the
> functions "imap_fetch_overivew()" and "imap_headerinfo()". Please, Please,
> add
> the MIME-Type to your fantastic object collections! BTW: It's really easy.
> Read
> the "Content-Type"-Line! Sorry...
>
> Hope, somebody has an idea,
> my regards,
>
> Niklaus
>
>
>
>
>
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP] Re: Apache

[Domain nikha . org]

Tim Streater am Montag, 23. September 2013 - 12:56:
> On 23 Sep 2013 at 11:37, Domain nikha.org  wrote: 
> 
> > The problem is the weak PHP upload mechanism! 
> 
> I'd have said the problem is weak metadata provision - overloading the
filename for other purposes.
> 
> --
> Cheers  --  Tim
> 

You are right, but unfortunately filenames ARE metadata for Apache. 
Would be better, if they were not, and just identifiers...

Niklaus

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Apache

[Domain nikha . org]

Stuart Dallas am Montag, 23. September 2013 - 12:58:

> And, honestly, who would have a PHP file per language? I think it's
perfectly reasonable to not allow that, because duplicating PHP code
across many files is an incredible stupid way to support multiple
languages.
> 
I agree!! Didn't even know, that this kind of faked language support
exists...

> "Some people run all their files through PHP" - true, but that doesn't
mean they should, or that you, as a responsible web host, should be
endorsing it.
> 
> PHP developers should absolutely validate all content coming in from
users in every possible way, but I would be highly dubious about
trusting a host who gives the reason above for what I consider a lax and
insecure Apache configuration. It's like saying they sliced your arm off
with their chainsaw because it's made for cutting things, attempting to
dodge all responsibility for having swung it in your direction!
> 
OK, in principle, I also agree. But this case is very easy to handle.
I'm simply running "str_replace()" against dangerous parts of uploaded
filenames, ".php" for instance. After that, Apache in every
configuration will just serve, and never execute user uploaded files.
Remains the risk on the clients side, I must concede. Better solutions?

Nice days,
Niklaus   

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] No MIME-Type in "imap_fetch_overview()"

[Negin Nickparsa]

I have read your mail twice and still I could not get what you want
exactly.  can't get the structure of the email either although you
elaborate it in details.

you have said something about human rights that I couldn't understand why?
but if you want to get the type of files fetch the structure and then you
can use disposition string, find the "attachment" and then return the
array.




Sincerely
Negin Nickparsa


On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org  wrote:

> Hello all,
>
> im posting this here, because the bug report system of "php.net" is not
> right
> place for my problem. It's not a bug, but a wish - an I found there no
> "wishlist" option at all.
>
> I'm running my own webmail-client, written in PHP. It is stable, fast and
> pretty, showing the full power of the PHP imap section.
>
> Of course it presents paginated content lists for every mailbox the user
> may
> open. These lists tell him some usefull things about every mail actually
> listed:
> Sender, date, subject, size and (eventually) flags.
>
> All these things are nicely delivered by the function
> "imap_fetch_overview()"
> The same could be done by calling "imap_headerinfo()" for every single
> mail, but
> "fetch_overview" seems to be faster, because it does it at once for the
> whole
> batch.
>
> BUT NONE OF THEM returns any information about the MIME-Type of the mail!
>
> Since the user of my webmail client has the intrinsic, natural born an
> general
> human right to KNOW whether some mail in his mailbox has attachments or
> not, I'm
> forced to do very ugly things. My script calls additionally for every (!)
> actually listed mail  "imap_fetchbody($connect, $msg_no, 0)" - where
> "$connect"
> holds the result of "imap_open()".
>
> That gives me the mail header, the script reads the line starting with
> "Content-Type:" and returns its content. Evaluating this against "mixed" or
> "alternative" we have finaly what we want: This mail has attachments! Or is
> written in HTML, what is even more we wanted!
>
> Works fine, but is ugly. First "fetch_overview" parses all mail headers,
> then
> they are fetched again to be parsed for the MIME-Type. I could just omit
> "fetch_overview" and read the headers by my own means, that whould be
> faster,
> but then I loose the size information, that is NOT (and cannot) be part of
> the
> mail header!
>
> If I want to have both, size and MIME-Type, and I WANT to have both,
> respecting
> the intrinsic, natural born and general human rights of my user, im must
> call
> both, "overview" and "fetchbody".
>
> My question is this: Is there a better solution? Or is there someone that
> knows
> someone among the PHP-Developpers to suggest them an improvement of the
> functions "imap_fetch_overivew()" and "imap_headerinfo()". Please, Please,
> add
> the MIME-Type to your fantastic object collections! BTW: It's really easy.
> Read
> the "Content-Type"-Line! Sorry...
>
> Hope, somebody has an idea,
> my regards,
>
> Niklaus
>
>
>
>
>
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)

[Tamara Temple]

On Aug 13, 2013, at 3:00 AM, Michał Kochanowicz  wrote:

> Hello
> 
> I've got a file, which can't be checked with filesize(). I copy it (with 
> permissions) and then I can filesize() the copy. This is same directory, 
> permissions are same. I don't understand what's the difference. Can you help 
> me?
> 
> Original file:
>  File: 'DSC_5196_fx-1553725666.JPG'
>  Size: 1907383 Blocks: 3728   IO Block: 4096   regular file
> Device: 803h/2051d  Inode: 5905591363  Links: 1
> Access: (0644/-rw-r--r--)  Uid: (   51/http)   Gid: (   51/http)
> Access: 2013-08-13 00:47:28.107477918 +0200
> Modify: 2013-08-12 21:38:27.219913208 +0200
> Change: 2013-08-13 00:47:08.931478654 +0200
> Birth: -
> 
> Copy:
>  File: 'DSC_5196_fx-1553725666_X.JPG'
>  Size: 1907383 Blocks: 3728   IO Block: 4096   regular file
> Device: 803h/2051d  Inode: 144 Links: 1
> Access: (0644/-rw-r--r--)  Uid: (   51/http)   Gid: (   51/http)
> Access: 2013-08-13 00:45:48.0 +0200
> Modify: 2013-08-12 21:38:27.0 +0200
> Change: 2013-08-13 00:47:28.199477914 +0200
> Birth: -
> 
> The only difference is inode: (5905591363 - doesn't work vs 144 - does work).
> 
> Test script:
> 
> 
> 
> 
>  $f3 = 
> '/home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666.JPG';
> $f4 = 
> '/home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666_X.JPG';
> 
> print $f3.": ".filesize($f3)."\n";
> print $f4.": ".filesize($f4)."\n";
> 
> ?>
> 
> 
> 
> 
> Result:
> 
> Warning: filesize(): stat failed for 
> /home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666.JPG
>  in /home/services/httpd/html.galeria.michal.waw.pl/gallery3-3.0.x/test.php 
> on line 13
> /home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666.JPG:
>  
> /home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666_X.JPG:
>  1907383
> 
> Regards
> Michał
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


That is one whopping-big inode number — I am really out on a limb here, but is 
this a 32-bit vs 64-bit issue?


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Problem with mbstring.internal_encoding, mcrypt and php-fpm

[Condor]

On 2013-09-23 15:42, Aziz Saleh wrote:

Hristo,

Try changing the php.ini config:

mbstring.func_overload 0

See if that helps your issue, more on what it does:
http://php.net/manual/en/mbstring.overload.php [3]

Aziz

On Mon, Sep 23, 2013 at 8:23 AM, Condor  wrote:


Hello,

from two days I have strange problem with this param
mbstring.internal_encoding on nginx and php-fpm.
I use php version 5.4.20 and when I setting
mbstring.internal_encoding I have a problem with mcrypt.

NOTICE: PHP message: PHP Warning:  mcrypt_generic_init(): Iv size
incorrect; supplied length: 12, needed: 8 in file.php

I setup php.ini file:

zend.multibyte = On
default_mimetype = "text/html"
default_charset = "UTF-8"
mbstring.internal_encoding = UTF-8

and here is function:

 85         private function decrypt($blob)
 86         {
 87                 $deckey = $_SESSION['key'];
 88                 $realkey = sha1($deckey, true);
 89                 $rawblob = hex2bin($blob); /* binary
blob */
 90                 $td =
mcrypt_module_open($this->CIPHER, "", MCRYPT_MODE_CFB, "");
 91                 $iv = mb_substr($rawblob, 0,
mcrypt_enc_get_iv_size($td)); /* IV */
 92                 if (mb_strlen($iv) <
mcrypt_enc_get_iv_size($td)) return FALSE;
 93                 $ct = mb_substr($rawblob,
mcrypt_enc_get_iv_size($td)); /* CipherText */
 94    --->         mcrypt_generic_init($td, $realkey, $iv);
 95                 $unblob = mdecrypt_generic($td, $ct);
 96                 mcrypt_generic_deinit($td);
 97                 $pt = mb_substr($unblob, 20);
 98                 $check = mb_substr($unblob, 0, 20);
 99                 if ($check != sha1($pt, true))
100                 {
101                         return FALSE;
102                 } else {
103                         return $pt;
104                 }
105         }

The same code with the same config options is worked fine with
apache httpd.

Any one can give me a little help ?
Thanks

Regards,
Hristo S.




Hello,

I just try and no effect after reload the php-fpm.

Regards,
Hristo S.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Problem with mbstring.internal_encoding, mcrypt and php-fpm

[Aziz Saleh]

Hristo,

Try changing the php.ini config:

mbstring.func_overload 0

See if that helps your issue, more on what it does:
http://php.net/manual/en/mbstring.overload.php

Aziz


On Mon, Sep 23, 2013 at 8:23 AM, Condor  wrote:

>
> Hello,
>
> from two days I have strange problem with this param
> mbstring.internal_encoding on nginx and php-fpm.
> I use php version 5.4.20 and when I setting mbstring.internal_encoding I
> have a problem with mcrypt.
>
> NOTICE: PHP message: PHP Warning:  mcrypt_generic_init(): Iv size
> incorrect; supplied length: 12, needed: 8 in file.php
>
> I setup php.ini file:
>
> zend.multibyte = On
> default_mimetype = "text/html"
> default_charset = "UTF-8"
> mbstring.internal_encoding = UTF-8
>
>
>
> and here is function:
>
>  85 private function decrypt($blob)
>  86 {
>  87 $deckey = $_SESSION['key'];
>  88 $realkey = sha1($deckey, true);
>  89 $rawblob = hex2bin($blob); /* binary blob */
>  90 $td = mcrypt_module_open($this->**CIPHER, "",
> MCRYPT_MODE_CFB, "");
>  91 $iv = mb_substr($rawblob, 0,
> mcrypt_enc_get_iv_size($td)); /* IV */
>  92 if (mb_strlen($iv) < mcrypt_enc_get_iv_size($td))
> return FALSE;
>  93 $ct = mb_substr($rawblob,
> mcrypt_enc_get_iv_size($td)); /* CipherText */
>  94---> mcrypt_generic_init($td, $realkey, $iv);
>  95 $unblob = mdecrypt_generic($td, $ct);
>  96 mcrypt_generic_deinit($td);
>  97 $pt = mb_substr($unblob, 20);
>  98 $check = mb_substr($unblob, 0, 20);
>  99 if ($check != sha1($pt, true))
> 100 {
> 101 return FALSE;
> 102 } else {
> 103 return $pt;
> 104 }
> 105 }
>
>
> The same code with the same config options is worked fine with apache
> httpd.
>
> Any one can give me a little help ?
> Thanks
>
> Regards,
> Hristo S.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP] Problem with mbstring.internal_encoding, mcrypt and php-fpm

[Condor]

Hello,

from two days I have strange problem with this param 
mbstring.internal_encoding on nginx and php-fpm.
I use php version 5.4.20 and when I setting mbstring.internal_encoding I 
have a problem with mcrypt.


NOTICE: PHP message: PHP Warning:  mcrypt_generic_init(): Iv size 
incorrect; supplied length: 12, needed: 8 in file.php


I setup php.ini file:

zend.multibyte = On
default_mimetype = "text/html"
default_charset = "UTF-8"
mbstring.internal_encoding = UTF-8



and here is function:

 85 private function decrypt($blob)
 86 {
 87 $deckey = $_SESSION['key'];
 88 $realkey = sha1($deckey, true);
 89 $rawblob = hex2bin($blob); /* binary blob */
 90 $td = mcrypt_module_open($this->CIPHER, "", 
MCRYPT_MODE_CFB, "");
 91 $iv = mb_substr($rawblob, 0, 
mcrypt_enc_get_iv_size($td)); /* IV */
 92 if (mb_strlen($iv) < mcrypt_enc_get_iv_size($td)) 
return FALSE;
 93 $ct = mb_substr($rawblob, 
mcrypt_enc_get_iv_size($td)); /* CipherText */

 94---> mcrypt_generic_init($td, $realkey, $iv);
 95 $unblob = mdecrypt_generic($td, $ct);
 96 mcrypt_generic_deinit($td);
 97 $pt = mb_substr($unblob, 20);
 98 $check = mb_substr($unblob, 0, 20);
 99 if ($check != sha1($pt, true))
100 {
101 return FALSE;
102 } else {
103 return $pt;
104 }
105 }


The same code with the same config options is worked fine with apache 
httpd.


Any one can give me a little help ?
Thanks

Regards,
Hristo S.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Friday's Question

[Eric K. Dickinson]

54, Only when the surface of the desk is problematic.

On 09/20/2013 12:58 PM, Larry Martell wrote:

On Fri, Sep 20, 2013 at 10:51 AM, Tedd Sperling  wrote:

Hi gang:

Do you use a Mousepad?

My reason for asking is that I've used a Mousepad ever since mice first came 
out (back when they had one ball).

Now that mice are optical (no balls), Mousepads are not really needed -- or so 
I'll told by the college -- you see, they don't provide Mousepads for their 
student's computers.

As such, I wondered what's the percentage of programmers still using a Mousepad?

Secondly, are Mousepads used primarily by older programmers (like me) while 
younger programmers don't use Mousepads, or what?

So -- please respond with:

Age: *
Mousepad: Yes/No


54 Yes



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Apache

[Stuart Dallas]

On 23 Sep 2013, at 11:37, Domain nikha.org  wrote:

> Tamara Temple am Montag, 23. September 2013 - 06:49:
>> 
>> GoDaddy's default plesk-generated configuration for FastCGI-served PHP
> files only looked to see if the file contained ".php" somewhere on it's
> path - i.e. it would happily execute 'malicilous.php.txt' as php code,
> even something ridiculous like 'malware.phpnoreallyiwantthistorun'.
>> 
> 
> Yes, looks stupid.  
> But my service prodider wrote me this, I quote:
> ---QUOTE---
> This is because Apache offers features like language negotiation based
> on extensions, too -- the final extension doesn't always just specify
> the handler; it can specify other things. Apache can automatically pick
> a German-language script from these, for example:
> 
> file.php.de
> file.php.en
> 
> Whether this is a good idea or not is debatable. It's possible to set
> things up in a different way (using FilesMatch instead of AddHandler)
> to
> avoid this particular problem, but that breaks other things, so there's
> no perfect solution.
> 
> More generally, the real problem is that scripts are looking at the
> final extension of uploaded files to decide whether they're safe or
> not,
> which is dangerous. They're simply assuming that a ".gif" file can't
> run
> a PHP interpreter, for example... which is usually true, but certainly
> not always: some people run all their files through PHP.
> ---END QUOTE---

This is somewhat daft. Yes, Apache offers this feature, but you don't need to 
configure it to work will all extensions. I'd be curious to know what their 
issue is with using FilesMatch, since that provides a way to disable this 
behaviour. And, honestly, who would have a PHP file per language? I think it's 
perfectly reasonable to not allow that, because duplicating PHP code across 
many files is an incredible stupid way to support multiple languages.

"Some people run all their files through PHP" - true, but that doesn't mean 
they should, or that you, as a responsible web host, should be endorsing it.

> The problem is the weak PHP upload mechanism! 
> As workaround my service provider tries to block suspicious filenames,
> but the PHP developpers themself should work on this severe security
> problem.

PHP developers should absolutely validate all content coming in from users in 
every possible way, but I would be highly dubious about trusting a host who 
gives the reason above for what I consider a lax and insecure Apache 
configuration. It's like saying they sliced your arm off with their chainsaw 
because it's made for cutting things, attempting to dodge all responsibility 
for having swung it in your direction!

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Apache

[Tim Streater]

On 23 Sep 2013 at 11:37, Domain nikha.org  wrote: 

> The problem is the weak PHP upload mechanism! 

I'd have said the problem is weak metadata provision - overloading the filename 
for other purposes.

--
Cheers  --  Tim

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Apache

[Domain nikha . org]

Tamara Temple am Montag, 23. September 2013 - 06:49:
> 
> GoDaddy's default plesk-generated configuration for FastCGI-served PHP
files only looked to see if the file contained ".php" somewhere on it's
path - i.e. it would happily execute 'malicilous.php.txt' as php code,
even something ridiculous like 'malware.phpnoreallyiwantthistorun'.
> 

Yes, looks stupid.  
But my service prodider wrote me this, I quote:
---QUOTE---
This is because Apache offers features like language negotiation based
on extensions, too -- the final extension doesn't always just specify
the handler; it can specify other things. Apache can automatically pick
a German-language script from these, for example:

 file.php.de
 file.php.en

Whether this is a good idea or not is debatable. It's possible to set
things up in a different way (using FilesMatch instead of AddHandler)
to
avoid this particular problem, but that breaks other things, so there's
no perfect solution.

More generally, the real problem is that scripts are looking at the
final extension of uploaded files to decide whether they're safe or
not,
which is dangerous. They're simply assuming that a ".gif" file can't
run
a PHP interpreter, for example... which is usually true, but certainly
not always: some people run all their files through PHP.
---END QUOTE---

The problem is the weak PHP upload mechanism! 
As workaround my service provider tries to block suspicious filenames,
but the PHP developpers themself should work on this severe security
problem.

Niklaus
 

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)

[Carsten Jensen]

if you have console access and the cli version of php works,
what does

echo filesize('/path/to/file');

tell (try running as root, then later as uid 51/webuser)
this will eliminate permission doubts

also you should use 
regardless of you, saying they have same permissions I think they do not
have the same permission

try to use --reference for chmod to see if there is any differences

try to copy the file keeping the whole permissions from original using sudo
cp -rp and check.
if this copy has the warning then your problem is from the permissions.


Sincerely
Negin Nickparsa


On Tue, Aug 13, 2013 at 11:30 AM, Michał Kochanowicz
wrote:


Hello

I've got a file, which can't be checked with filesize(). I copy it (with
permissions) and then I can filesize() the copy. This is same directory,
permissions are same. I don't understand what's the difference. Can you
help me?

Original file:
   File: 'DSC_5196_fx-1553725666.JPG'
   Size: 1907383 Blocks: 3728   IO Block: 4096   regular file
Device: 803h/2051d  Inode: 5905591363  Links: 1
Access: (0644/-rw-r--r--)  Uid: (   51/http)   Gid: (   51/http)
Access: 2013-08-13 00:47:28.107477918 +0200
Modify: 2013-08-12 21:38:27.219913208 +0200
Change: 2013-08-13 00:47:08.931478654 +0200
  Birth: -

Copy:
   File: 'DSC_5196_fx-1553725666_X.JPG'
   Size: 1907383 Blocks: 3728   IO Block: 4096   regular file
Device: 803h/2051d  Inode: 144 Links: 1
Access: (0644/-rw-r--r--)  Uid: (   51/http)   Gid: (   51/http)
Access: 2013-08-13 00:45:48.0 +0200
Modify: 2013-08-12 21:38:27.0 +0200
Change: 2013-08-13 00:47:28.199477914 +0200
  Birth: -

The only difference is inode: (5905591363 - doesn't work vs 144 - does
work).

Test script:









Result:

Warning: filesize(): stat failed for /home/services/httpd/html.**
galeria.XXX/gallery/var/**albums/988_Rok-2013/333_**
Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666.JPG in
/home/services/httpd/html.**galeria.michal.waw.pl/**
gallery3-3.0.x/test.phpon
 line 13
/home/services/httpd/html.**galeria.XXX/gallery/var/**
albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666.JPG:

/home/services/httpd/html.**galeria.XXX/gallery/var/**
albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666_X.JPG:
1907383

Regards
Michał

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php







--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)

[Negin Nickparsa]

regardless of you, saying they have same permissions I think they do not
have the same permission

try to use --reference for chmod to see if there is any differences

try to copy the file keeping the whole permissions from original using sudo
cp -rp and check.
if this copy has the warning then your problem is from the permissions.


Sincerely
Negin Nickparsa


On Tue, Aug 13, 2013 at 11:30 AM, Michał Kochanowicz
wrote:

> Hello
>
> I've got a file, which can't be checked with filesize(). I copy it (with
> permissions) and then I can filesize() the copy. This is same directory,
> permissions are same. I don't understand what's the difference. Can you
> help me?
>
> Original file:
>   File: 'DSC_5196_fx-1553725666.JPG'
>   Size: 1907383 Blocks: 3728   IO Block: 4096   regular file
> Device: 803h/2051d  Inode: 5905591363  Links: 1
> Access: (0644/-rw-r--r--)  Uid: (   51/http)   Gid: (   51/http)
> Access: 2013-08-13 00:47:28.107477918 +0200
> Modify: 2013-08-12 21:38:27.219913208 +0200
> Change: 2013-08-13 00:47:08.931478654 +0200
>  Birth: -
>
> Copy:
>   File: 'DSC_5196_fx-1553725666_X.JPG'
>   Size: 1907383 Blocks: 3728   IO Block: 4096   regular file
> Device: 803h/2051d  Inode: 144 Links: 1
> Access: (0644/-rw-r--r--)  Uid: (   51/http)   Gid: (   51/http)
> Access: 2013-08-13 00:45:48.0 +0200
> Modify: 2013-08-12 21:38:27.0 +0200
> Change: 2013-08-13 00:47:28.199477914 +0200
>  Birth: -
>
> The only difference is inode: (5905591363 - doesn't work vs 144 - does
> work).
>
> Test script:
>
> 
> 
> 
>  $f3 = '/home/services/httpd/html.**galeria.XXX/gallery/var/**
> albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**
> DSC_5196_fx-1553725666.JPG';
> $f4 = '/home/services/httpd/html.**galeria.XXX/gallery/var/**
> albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**
> DSC_5196_fx-1553725666_X.JPG';
>
> print $f3.": ".filesize($f3)."\n";
> print $f4.": ".filesize($f4)."\n";
>
> ?>
> 
> 
> 
>
> Result:
>
> Warning: filesize(): stat failed for /home/services/httpd/html.**
> galeria.XXX/gallery/var/**albums/988_Rok-2013/333_**
> Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666.JPG in
> /home/services/httpd/html.**galeria.michal.waw.pl/**
> gallery3-3.0.x/test.phpon
>  line 13
> /home/services/httpd/html.**galeria.XXX/gallery/var/**
> albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666.JPG:
>
> /home/services/httpd/html.**galeria.XXX/gallery/var/**
> albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666_X.JPG:
> 1907383
>
> Regards
> Michał
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>