Hello geeks,
Why does PHP 5.5 remove the logo functions? Is this a security
related move? Shouldn't these emit E_DEPRECATED errors in 5.5?
Regards,
Philip
Hello geeks,
Why does PHP 5.5 remove the logo functions? Is this a security
related move? Shouldn't these emitE_DEPRECATEDerrors in 5.5?Regards,
Philip--
Because the guids were removed. They were replaced with data URIs. It
would make sense if there was some function to expose those data URIs
to user-land, in the same way that the *_guid functions did, but I
guess there isn't.
On Fri, Nov 16, 2012 at 3:31 AM, Sherif Ramadan theanomaly.is@gmail.comwrote:
Hello geeks,
Why does PHP 5.5 remove the logo functions? Is this a security
related move? Shouldn't these emitE_DEPRECATEDerrors in 5.5?Regards,
Philip--
Because the guids were removed. They were replaced with data URIs. It
would make sense if there was some function to expose those data URIs
to user-land, in the same way that the *_guid functions did, but I
guess there isn't.--
it was removed when https://github.com/php/php-src/pull/132 got merged
after a brief vote on the internals mailing list.
see Stas concerns about reusing the same function names for getting the
data urls: internals@lists.php.net/msg59293.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg59293.html
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Fri, Nov 16, 2012 at 3:31 AM, Sherif Ramadan theanomaly.is@gmail.com
wrote:Hello geeks,
Why does PHP 5.5 remove the logo functions? Is this a security
related move? Shouldn't these emitE_DEPRECATEDerrors in 5.5?Regards,
Philip--
Because the guids were removed. They were replaced with data URIs. It
would make sense if there was some function to expose those data URIs
to user-land, in the same way that the *_guid functions did, but I
guess there isn't.--
it was removed when https://github.com/php/php-src/pull/132 got merged after
a brief vote on the internals mailing list.
see Stas concerns about reusing the same function names for getting the data
urls: internals@lists.php.net/msg59293.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg59293.html--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Obviously it doesn't make sense to use the same function names for the
data uris, but why weren't new functions added to expose the data uris
to userspace in the same way we used to expose the guids to userspace?
It only seems to make sense that we'd continue to do that and it's
such a simple fix to replace the functions with new ones. I honestly
don't care too much about this particular feature myself, but it
sounds pretty silly that this PR did not include the new functions for
exposing the uris.
My 0.00002 cents...
On Fri, Nov 16, 2012 at 10:38 PM, Sherif Ramadan theanomaly.is@gmail.comwrote:
Obviously it doesn't make sense to use the same function names for the
data uris, but why weren't new functions added to expose the data uris
to userspace in the same way we used to expose the guids to userspace?It only seems to make sense that we'd continue to do that and it's
such a simple fix to replace the functions with new ones. I honestly
don't care too much about this particular feature myself, but it
sounds pretty silly that this PR did not include the new functions for
exposing the uris.My 0.00002 cents...
Why would you need those data uris? I mean, if you want to embed a PHP
logo, then just embed that logo. If you want to put an image on a website,
you would usually also just include that .png, rather than creating a data
URI from it and embedding that.
I don't see a reason to expose those uris.
Nikita
Hi Nikita
2012/11/16 Nikita Popov nikita.ppv@gmail.com:
I don't see a reason to expose those uris.
We all seem in the PHP project to talk about the inconsistency of the
language, and the like, re-implementing a "feature", or well an
ability, what I proposed and I even think I committed a change until
it was shut down was to convert the *_logo_guid() functions into
constants, since it returns a constant/static value, I don't think it
would hurt to do the same here for the data:uri's.
But I honestly don't think it makes much sense to re-add them as
functions, while I do think it makes sense to expose the data, because
why not if its useful to some users like the *_logo_guid() functions
did/does.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Why would you need those data uris?
For what reason would anyone need the GUIDs? To get the logo maybe? I
don't know.
I mean, if you want to embed a PHP logo,
then just embed that logo. If you want to put an image on a website, you
would usually also just include that .png, rather than creating a data URI
from it and embedding that.I don't see a reason to expose those uris.
I didn't see a reason to expose the GUIDs either, but hey I'm just
stating the obvious here.
PHP had a way to get the logo exposed to userspace. It seems like we
just make up these reasons as we go along. When they were GUIDs they
were OK when they became data URIs, obviously (and for reasons that
appear to be obvious only to those who make these decisions) they
weren't.
I guess I need to get in on this foresight I'm not in possession of.
On Sat, Nov 17, 2012 at 6:09 PM, Sherif Ramadan theanomaly.is@gmail.comwrote:
On Fri, Nov 16, 2012 at 5:07 PM, Nikita Popov nikita.ppv@gmail.com
wrote:Why would you need those data uris?
For what reason would anyone need the GUIDs? To get the logo maybe? I
don't know.I mean, if you want to embed a PHP logo,
then just embed that logo. If you want to put an image on a website, you
would usually also just include that .png, rather than creating a data
URI
from it and embedding that.I don't see a reason to expose those uris.
I didn't see a reason to expose the GUIDs either, but hey I'm just
stating the obvious here.PHP had a way to get the logo exposed to userspace. It seems like we
just make up these reasons as we go along. When they were GUIDs they
were OK when they became data URIs, obviously (and for reasons that
appear to be obvious only to those who make these decisions) they
weren't.
The GUID functions were added decades ago, but now we're talking about ...
now. Things changed. PHP isn't in the just-add-a-function-for-everything
mode anymore. Unless displaying a PHP logo is a common thing to do there is
no reason to add a function for it.
Thanks everyone, I didn't remember thinking about this so was
impulsively curious. Dug a little now, so here's what happened:
Proposal to internals (July 14, 2012) with discussion July 14-18:
Thread: http://markmail.org/thread/kewdoz3dowrr7rfv
Summary: Seemed okay, discussed more "how" than "why", and
more "yes" than "maybe" approved.
Conclusion: No clear decision was reached.
The patch:
Patch: https://github.com/php/php-src/pull/132
Pull: http://git.php.net/?p=php-src.git;a=commitdiff;h=c9eb641
Summary: Mostly a technical/patch related discussion there,
several tweaks, then pulled.
Conclusion: Merged/pulled into master on August 4, 2012.
What happened:
- The PHP logo GUIDs were removed, and replaced with data URIs
in `phpinfo()` and friends.
- BC: Removed four *_logo_* functions, and GUID usage.
- `E_DEPRECATED` was not used beforehand, nor doc updates, they
were simply removed. FWIW, also no RFC.
It's understandable how a minimally used feature can be changed and
removed without much worry/thought. But, they appear to be the only
functions removed in 5.5, and this helps it feel even easier to not
break BC for this not-so-important change.
Proposal: I propose we revert this change. Future consideration might
include E_DEPRECATED for these functions in 5.5, although I am not
proposing that part. Seems sensible, though.
Regards,
Philip
Hi!
Proposal: I propose we revert this change. Future consideration might
I see no reason to revert the change and keep dragging around the GUIDs.
Data URLs are much better and cleaner solution, and only reasons not to
do it are purely bureaucratic, for which I don't care much. We could
keep the functions, but what these functions would do?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Proposal: I propose we revert this change. Future consideration might
I see no reason to revert the change and keep dragging around the GUIDs.
Data URLs are much better and cleaner solution, and only reasons not to
do it are purely bureaucratic, for which I don't care much. We could
keep the functions, but what these functions would do?
The issue I have with this is just that we don't seem to be making
much of an effort to stick to the promises we've made around BC when
it doesn't suit us to. I agree: in practice, I can't imagine anyone
caring a jot about these functions being removed, but we've said that
when we're going to remove something, we'll deprecate for a minor
release, then remove. Why don't we live up to it?
Adam
Proposal: I propose we revert this change. Future consideration might
I see no reason to revert the change and keep dragging around the GUIDs.
Data URLs are much better and cleaner solution, and only reasons not to
do it are purely bureaucratic, for which I don't care much. We could
keep the functions, but what these functions would do?The issue I have with this is just that we don't seem to be making
much of an effort to stick to the promises we've made around BC when
it doesn't suit us to. I agree: in practice, I can't imagine anyone
caring a jot about these functions being removed, but we've said that
when we're going to remove something, we'll deprecate for a minor
release, then remove. Why don't we live up to it?
We also have to apply common sense here. You are implicitly comparing
ext/mysql which millions of sites use to these logo functions which 0
sites use. The one and only reason we had to add them over simply doing
an <img src> tag was because people complained that we were tracking
them. It is obviously way better to just stick an img src tag in your
page if you want to put a php logo on there so there is no reason for
people to use these functions and people don't. We weren't even going to
document them actually, but someone did for completeness sake, I guess.
-Rasmus
Hi!
The issue I have with this is just that we don't seem to be making
much of an effort to stick to the promises we've made around BC when
We make a lot of effort to do this. But it does not mean we should be
blindly and stupidly following the rigid rules even when it makes zero
sense in practice.
it doesn't suit us to. I agree: in practice, I can't imagine anyone
caring a jot about these functions being removed, but we've said that
when we're going to remove something, we'll deprecate for a minor
release, then remove. Why don't we live up to it?
Exactly because in practice it is not important. So on one side, you
have making PHP better without any practical downside. On the other
side, you have delaying making PHP better, but feeling good about
strictly following bureaucratic rules. I prefer the former.
Rules are important, but it is also important to not lose the sight of
the goal - why these rules exist and when they make sense. And when they
don't.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
The issue I have with this is just that we don't seem to be making
much of an effort to stick to the promises we've made around BC whenWe make a lot of effort to do this. But it does not mean we should be
blindly and stupidly following the rigid rules even when it makes zero
sense in practice.
We made sense, and are not being blind and stupid. You may disagree but
I don't understand why this discussion has to become so harsh.
it doesn't suit us to. I agree: in practice, I can't imagine anyone
caring a jot about these functions being removed, but we've said that
when we're going to remove something, we'll deprecate for a minor
release, then remove. Why don't we live up to it?Exactly because in practice it is not important. So on one side, you
have making PHP better without any practical downside. On the other
side, you have delaying making PHP better, but feeling good about
strictly following bureaucratic rules. I prefer the former.Rules are important, but it is also important to not lose the sight of
the goal - why these rules exist and when they make sense. And when they
don't.
It's the inconsistency that bothers me. I think a rule like "Never remove
a ~function without it first emitting E_DEPRECATED" can be followed 100%
of the time, and don't see this as a bureaucratic rule but instead think
this consistency would make PHP better.
Regards,
Philip
Hi!
It's the inconsistency that bothers me. I think a rule like "Never remove
a ~function without it first emitting E_DEPRECATED" can be followed 100%
of the time, and don't see this as a bureaucratic rule but instead think
this consistency would make PHP better.
I guess that's where we disagree. I think in this particular case the
change does make PHP better, and I do not value consistency for its sake
and having 100% for its sake. If there were any practical reason why the
change is wrong, that'd be different matter of course.
P.S. I of course did not mean you or anybody else when talking about
stupidly following rules, I just described a situation we want to avoid.
Sorry if I sounded offensive, it was not my intent.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
it doesn't suit us to. I agree: in practice, I can't imagine anyone
caring a jot about these functions being removed, but we've said that
when we're going to remove something, we'll deprecate for a minor
release, then remove. Why don't we live up to it?Exactly because in practice it is not important.
Actually, I'm going to retract my statement, and here's why:
http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.php
Let's set aside that this is terribly misguided code[0]. If that was a
good enough reason to remove functionality willy-nilly, I could have
saved myself a lot of e-mails on the ext/mysql front. But (to my
horror) users are actually using php_logo_guid() in the wild. I
haven't searched for the other functions, but I assume there are cases
where they're used too.
And it's not just one WordPress plugin. Nanoweb[1] calls
php_logo_guid() on its demo page[2]. ErfurtWiki[3] has a similar demo
page[4]. There are other projects of dubious provenance on Ohloh that
call it too.
It may only be a handful of projects, none of which any of us have
probably ever heard of, or will ever hear a complaint from, but I bet
those projects are important to their creators.
Rules are important, but it is also important to not lose the sight of
the goal - why these rules exist and when they make sense.
The rules are there to protect developers from having functions
dropped out from under them without warning.
I don't see the problem with reverting this on the 5.5 branch only,
adding E_DEPRECATED warnings to the appropriate places, and making the
first item in the master UPGRADING guide for 5.6 be that these
functions were removed.
Adam
[0] Hell, it won't even "decrypt" or "encrypt" properly on April 1,
which is entertaining.
[1] "The PHP Web Server": http://nanoweb.si.kz/
[2] http://nanoweb-instant.googlecode.com/svn/trunk/www/vhosts/www.cgidemo.com/index.php
[3] http://sourceforge.net/projects/erfurtwiki/
[4] https://erfurtwiki.svn.sourceforge.net/svnroot/erfurtwiki/trunk/ewiki/examples/zendwiki.php
Hi!
Actually, I'm going to retract my statement, and here's why:
http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.php
I think breaking this code is an advantage :) That's definitely not how
php_logo_guid should be used and using it as a secure salt makes no
sense at all. To add insult to injury, it's wrapped in an if()! Please
make me unsee it.
The rules are there to protect developers from having functions
dropped out from under them without warning.
I know why the rules are. I just think in this case the function is
clearly abused and delaying this improvement for at least a year because
of somebody using logo guids as encryption salts makes no sense to me.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Actually, I'm going to retract my statement, and here's why:
http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.phpI think breaking this code is an advantage :) That's definitely not how
php_logo_guid should be used and using it as a secure salt makes no
sense at all. To add insult to injury, it's wrapped in an if()! Please
make me unsee it.
Agree. We never guaranteed this to be any stable value.
And even using it to display the logo is error-prone: Whether the logo
can be shown depends on expose_php in php.ini.
johannes