Wordpress Themes - WP Forum at BFA
Click here to register or to donate.
Auto self-registration is not available here - far too many spammers. This forum has many, many backlinks and because of that there is an intense desire among spammers to drop their links here.

Wordpress Themes - WP Forum at BFA » WordPress Themes » Atahualpa 3 Wordpress theme » New Versions, & Updating »

Discussion about the use of Stream Wrappers vrs eval() (Suhosin issue)


  #1  
Old Apr 19, 2011, 06:42 AM
juggledad's Avatar
juggledad
 
23,597 posts · Mar 2009
OSX 10.11.5 WP 4.x Atahualpa(all) Safari, Firefox, Chrome
[moderater note: the following posts were removed from 'if you are getting blank page with Atahualpa 3.6.x (Suhosin issue)' since they are a discussion about the merits of the way the theme is written, and have no bearing on solving the Suhson issue for the existing version - ie it's all off topic]

When I refer to the 'server' I mean all the software: the server itself (Apache, Windoes etc), PHP, MySql. Just those three, with all there options, gives an unimaginable number of permutations that are not under any theme's control...
__________________
"Tell me and I forget, teach me and I may remember, involve me and I learn." - Benjamin Franklin
Juggledad | Forum Moderator/Support

Last edited by juggledad; May 11, 2011 at 05:47 AM.
  #2  
Old Apr 20, 2011, 09:11 AM
metapete
 
7 posts · Feb 2011
Gosport Hampshire UK
Sorry but I have to raise a slight issue with the following reasoning:

The problem is not with the Atahaulpa theme.
The problem is with the server variables.

Yes there are many 'server variables not under any theme's control' but generally (and in most cases) they are compatible which each other and the stuff that relies on them such as a theme.

If this wasn't the case the web would come to a grinding halt.

If a theme is so dependant on the server environment, then this must raise serious questions on the stability of any Wordpress based site.

I think the problem is with Atahaulpa, which is a shame.
  #3  
Old Apr 20, 2011, 10:53 AM
Flynn's Avatar
Flynn
 
3,768 posts · Oct 2008
Munich, Germany
Other themes don't allow you to include custom PHP code through the theme options. They don't have the issues because they don't have the feature.

Custom PHP code worked fine in Atahualpa as long as "Eval" was allowed in themes, which it isn't anymore.

I had to look for a replacement for Eval to keep the feature and found it in stream wrappers. Admittedly I didn't know that Suhosin would pretty much make it impossible to use stream wrappers if the user doesn't have access to the PHP config. After all, stream wrappers are a core PHP feature, Suhosin is not.

That being said, this will be fixed, by removing this feature (to add executable PHP code through the theme options) altogether.
  #4  
Old Apr 21, 2011, 03:21 AM
metapete
 
7 posts · Feb 2011
Gosport Hampshire UK
Thanks for this explanation - it is now much clearer to me.
Atahaulpa is a great theme - long may it continue.
  #5  
Old Apr 26, 2011, 05:21 PM
SharonJ's Avatar
SharonJ
 
637 posts · Sep 2010
Duncan BC Canada
...and finally, I am dying of curiosity...who ever came up with the idiotic name of Suhosin?
Sounds like an Asian sauce you would put on prawns or something.

And if I have insulted anyone, I am very sorry!
  #6  
Old Apr 26, 2011, 05:49 PM
SharonJ's Avatar
SharonJ
 
637 posts · Sep 2010
Duncan BC Canada
Oh God. Me and my big mouth. Sorry if I offended you. Who knew that a blank page would be called after a guardian angel? I stand corrected.
  #7  
Old Apr 26, 2011, 05:52 PM
lmilesw's Avatar
lmilesw
 
10,174 posts · Jul 2009
Central New York State USA
The blank page is a result of the Suhosin patch being installed on SOME hosts and in SOME environments.

You DID NOT offend anyone. We are just having fun.
__________________
~Larry (CNY Web Designs)
This site should be a membership site since it so full of good stuff.
Please consider donating which gives you access to even more good stuff.

Last edited by lmilesw; Apr 26, 2011 at 07:19 PM.
  #8  
Old May 10, 2011, 09:31 AM
PowerKiKi
 
6 posts · May 2011
Quote:
Originally Posted by metapete
I think the problem is with Atahaulpa, which is a shame.
I agree with metapete on this one. Obviously Wordpress chose to ban eval() because of security issues. Then Atahualpa did not comply and instead looked for a workaround. Hence still compromising security and still going against Wordpress' will to harden the whole system.

The workaround, using stream wrapper, raises new issues when used in "high level of security" environment. That shouldn't surprise anyone as basically nothing changed, the theme still does potentially dangerous actions (but a slightly different way).

The only proper solution to this is to fully accept Wordpress' will and remove the feature as we know it. (or just go against their will to please users and to not change something which was not broken in the first place)

Btw, I would be interested to read where Wordpress explained their choice to remove support of eval() and technical solution to do this. Anyone got a link ?
  #9  
Old May 10, 2011, 09:57 AM
juggledad's Avatar
juggledad
 
23,597 posts · Mar 2009
OSX 10.11.5 WP 4.x Atahualpa(all) Safari, Firefox, Chrome
PowerKiKi - see post #96

you have to ask yourself, why don't they ban plugins that use eval()?? (widget logic, exec-php...)
__________________
"Tell me and I forget, teach me and I may remember, involve me and I learn." - Benjamin Franklin
Juggledad | Forum Moderator/Support
  #10  
Old May 10, 2011, 10:00 AM
Harald
 
72 posts · Mar 2010
I don't think it is a Atahualpa problem. When I run my site on my own server (Vertrigo) everything works fine. When I move the same site to my host provider, I got a blank page. Did the fix regarding Suhosin mentioned earlier in this thread and the problem went away.
  #11  
Old May 10, 2011, 10:44 AM
Flynn's Avatar
Flynn
 
3,768 posts · Oct 2008
Munich, Germany
Quote:
Originally Posted by PowerKiKi
I agree with metapete on this one. Obviously Wordpress chose to ban eval() because of security issues. Then Atahualpa did not comply and instead looked for a workaround. Hence still compromising security and still going against Wordpress' will to harden the whole system.

The workaround, using stream wrapper, raises new issues when used in "high level of security" environment. That shouldn't surprise anyone as basically nothing changed, the theme still does potentially dangerous actions (but a slightly different way).

The only proper solution to this is to fully accept Wordpress' will and remove the feature as we know it. (or just go against their will to please users and to not change something which was not broken in the first place)

Btw, I would be interested to read where Wordpress explained their choice to remove support of eval() and technical solution to do this. Anyone got a link ?

Not sure where you got the idea from that Atahualpa would "not comply" or do "potentially dangerous actions".

Atahualpa is the most downloaded theme on wordpress.org, and most likely the one with the most active installations right now. The code was looked through by numerous persons in the past years, from automattic, from wordpress.org. It went through dozens of reviews including some very in-depth ones.

If all this doesn't ring a bell, don't you think that Wordpress would take Atahualpa off the list on wordpress.org if it was doing "potential dangerous actions"?

This eval/stream wrapper issue has nothing to do with Atahualpa specifically, these formerly permitted (standard) PHP features were now globally removed by Wordpress, for all themes, along with other PHP functions, leading to a situation where themes are more limited in what they can do inside WordPress.

The WordPress team did probably not discover these PHP functions just now, it's that they made the decision that from now on themes can live with a more restricted feature set and be forced to align more closely to a particular philosophy how a theme must be structured, what features it can have, etc...

Theoretically this should result in better overall compatibility between WP/Themes/Plugins, and in better upgrade compatibility. It should also make it easier for the new voluntary review team to check themes.

Disallowing eval is easier than looking through all themes whether eval is used in a malicious way or not. However all this does of course put a burden on more advanced themes like Atahualpa to either find new ways to implement their features or to drop the feature altogether.
  #12  
Old May 10, 2011, 10:55 AM
PowerKiKi
 
6 posts · May 2011
I agree there is a debate on "should we ban dangerous function ? why and how ?". But this is not the point. According to Flynn, that discussion already happened within Wordpress's team and they decided for us.

The issue is that Atahualpa pretend to agree with them, yet it doesn't. The whole operation is about hardened security. If BytesForAll agree with Wordpress' point of view, Atahualpa should drop the feature. Otherwise just don't do anything. But trying to "hide" security issues under several layers of code and "complex" mechanics is not a wise thing to do IMHO. It's digging a hole to fill another one.

But again, I would really like to read what Wordpress said about that. Do you, or anyone else, have a link to a reference ? googling this didn't get me anything...
  #13  
Old May 10, 2011, 11:08 AM
PowerKiKi
 
6 posts · May 2011
Flynn,

by "potentially dangerous actions", I meant eval() code which was not written by theme's authors.

Why Wordpress decided to ban eval() ?
I bet it is because eval() can be used to execute arbitrary code, which was not written by theme's authors (or crypted code via base64_decode()).

Am I wrong ? Is there another thing I am not aware of about eval() usage ?

One of Atahualpa strength is specifically to execute code written by the end-user. By definition it's going against new Wordpress rules (as long as I am not mistaken on the reason of this ban).

Btw, how do Wordpress ban this function ? Do they review the code and ban themes which include "eval" ?
  #14  
Old May 10, 2011, 11:52 AM
juggledad's Avatar
juggledad
 
23,597 posts · Mar 2009
OSX 10.11.5 WP 4.x Atahualpa(all) Safari, Firefox, Chrome
Quote:
Btw, how do Wordpress ban this function ? Do they review the code and ban themes which include "eval" ?
Yes that is exactly what they do, if a theme uses eval() it is automatically rejected.
__________________
"Tell me and I forget, teach me and I may remember, involve me and I learn." - Benjamin Franklin
Juggledad | Forum Moderator/Support
  #15  
Old May 10, 2011, 10:19 PM
Knut Sparhell
 
34 posts · Jun 2010
Fredrikstad, Norway
Quote:
Originally Posted by PowerKiKi
Btw, how do Wordpress ban this function ? Do they review the code and ban themes which include "eval" ?
Yes, exactly. Theme Guidelines. There is a Theme Check Plugin that incorporates most of the automated checks.

See also Theme Reviewers Mailing List in the thread "Alternatives to eval()".

Even a version of the P2 theme from Automattic, used for internal blogs on wordpress.org, got rejected because of an eval.

The Atahualpa developers then found a way to circumvent this restriction. This was clever, but then the Suhosin issue arrived. Looks like a nightmare to me.

Point is: It's not considered safe to allow input from theme option fields to be executed as raw PHP code.

My advice would be to extend the Atahualpa substitution variables with new ones for the name of the blog, the different URL paths on so on, until most needs are satisfied.

The next version, if released without the ability to enter PHP code in options, could detect all PHP code and nag the user to remove this, while suggesting some substitution variables.
  #16  
Old May 11, 2011, 04:12 AM
PowerKiKi
 
6 posts · May 2011
Thanks for your input Knut Sparhell, it was an interesting read !

At first I thought "let's not listen to Wordpress guidelines and keep the eval()", but then I realized I really don't want Wordpress to end up like Typo3. Splitting code between file and database is a nightmare for maintenance. I much prefer use child-themes or plugins, as suggested in the thread mentioned. At least you know where to look for bug: one single location, the files, which can be versioned.

Again, I firmly believe Wordpress didn't say "don't use this specific eval() function", but rather "don't let arbitrary code be executed". And the links provided by Knut seems to confirm that opinion.

I agree with Knut's advice about adding new Atahualpa substitution variables to "replace" PHP execution feature.
  #17  
Old May 13, 2011, 08:58 PM
Flynn's Avatar
Flynn
 
3,768 posts · Oct 2008
Munich, Germany
Substitution with variables will be the way to keep the dynamic nature of Atahualpa

Not as dynamic (any PHP code, no limits) as it used to be but not that bad either.

Instead of being able to use all existing PHP functions plus any IF/ELSE logic etc., only a much, much smaller set of predefined, known PHP functions, without loops or other logic, can be used in the future, and Atahualpa's predefined variables

The still usable PHP would be parsed as text and translated into executing PHP
A working parser is already in 3.6.7, to make custom widget areas work. It works with code of the type:

<?php function_name('parameter1=Parameter 1&parameter2=Parameter 2'); ?>

I will implement something along these lines for other functions to bring back some of the custom PHP code functionality.

One possibility to still have full PHP access would be to create custom widget areas in Atahualpa (bfa_widget_areas(...) works) and then put the PHP code widget into those areas. The PHP code widget like all plugins apparently is still allowed to use "Eval". The question is whether WP will keep allowing Eval in plugins. A fresh copy of the PHP code widget should work for a long time, though. It is a small plugin.
  #18  
Old May 13, 2011, 10:13 PM
BradBrown's Avatar
BradBrown
 
54 posts · Mar 2009
Have you considered building hooks into the theme? That would allow users who need PHP execution to enable it either through a plug-in or by adding a function to functions.php.

Just a thought.

-Brad
  #19  
Old May 16, 2011, 04:20 AM
PowerKiKi
 
6 posts · May 2011
I would strongly advise against implementing a parser in a theme. Parser are not small tasks and I really don't see the point to re-invent something which already exists and which will be much more limited (by design).

BradBrown's suggestion is really the way I would go. Let the coders code in files, not in forms.
  #20  
Old May 16, 2011, 05:07 AM
juggledad's Avatar
juggledad
 
23,597 posts · Mar 2009
OSX 10.11.5 WP 4.x Atahualpa(all) Safari, Firefox, Chrome
The beauty of allowing php in the theme options is that the user doesn't have to recoded changes to any theme files each time there is an upgrade.

The argument that users should might make an error in a theme option so they should only make the change in a php file is, in my humble opinion, ridiculous. More support issues will occur if they change the theme files and six months later do an automatic upgrade which wipes out the existing code, and suddenly their changes are gone. And you know they won't have made a backup or written down what they did, human nature being what it is.

Besides, that method will also cost them time/money having to redo the work again and again.

I agree that eval(), with encrypted arguments, should not be allowed. However, I think using eval() to parse a theme option THAT THE USER codes, should be allowed and WordPress has done a disservice to the community.
__________________
"Tell me and I forget, teach me and I may remember, involve me and I learn." - Benjamin Franklin
Juggledad | Forum Moderator/Support
  #21  
Old May 27, 2011, 04:11 AM
PowerKiKi
 
6 posts · May 2011
The problem of upgrading themes you describe is exactly what child themes are for. A clean (and easy) way to modify themes while still allowing easy upgrade.

http://codex.wordpress.org/Child_Themes
  #22  
Old May 27, 2011, 04:27 AM
juggledad's Avatar
juggledad
 
23,597 posts · Mar 2009
OSX 10.11.5 WP 4.x Atahualpa(all) Safari, Firefox, Chrome
If you make a child theme and change function.php or any of the other files and the next upgrade of the theme upgradesthe module you changed, you still have to go back and make a new copy and add your changes back in. I really wouldn't call this a 'clean' process.

plus, the power of Atahualpa is that you have so many theme options to change the CSS. If it was all hardcoded in style.css you couldn't do this.

So in a typical theme, yes child themes are the way to go, because it's the only way to keep things across upgrades (unless sthe module you changed changes) but with Atahualpa, you don't need to change the theme code to create a new look and feel and the changes you make are in the database so you don't have to worry about upgrade issues.

While both methods work, I think Atahualpa is much easier.
__________________
"Tell me and I forget, teach me and I may remember, involve me and I learn." - Benjamin Franklin
Juggledad | Forum Moderator/Support

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
if you are getting blank page with Atahualpa 3.6.x (Suhosin issue) lmilesw Old Version fixes and change logs 102 Sep 29, 2011 05:59 PM
Is ThemeFrame using Stream wrappers? interfasys ThemeFrame Presales 2 Mar 24, 2011 05:41 PM
ata doesen't work width php 5.3.5/Suhosin agesci New Versions, & Updating 6 Mar 16, 2011 04:26 AM
[SOLVED] Blank Page (not Suhosin!) Clippership New Versions, & Updating 4 Mar 14, 2011 06:56 AM


All times are GMT -6. The time now is 10:38 AM.


Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.