Search

It just occurred to me…

What if someone created an amazing extension but secretly pasted a tiny bit evil code in it that would e-mail your username and password to some weird server in North-Korea?

I for one don’t check each line of PHP-code of each extension I use, I just assume that it works and does the thing it says it does, without executing some evil code.

Now I’m not saying this is a serious threat, but I think it should be something to think about while the Symphony userbase is growing.

Perhaps an extension could be labeled as safe when it’s tested and looked at by a various number of Symphony users just to ensure it’s safe? I’m not sure who has this time on it’s hand but it’s just a thought…

On the other hand: it could also be a good USP! And although it’s not a serious threat at the moment, if it would happen some day that some evil hacker is trying to submit a ‘trojan horse extension’, it would mean very bad publicity for Symphony… It’s better to prevent than to cure…

How could an extension ever be safe without being “frozen” after the examination? Every single update would need to undergo the same testing procedure. Hard to imagine how this could be done.

In a world of open source, I think there has to be a level of trust.

The extensions which I use are all well “Dunn”.

:-)

The extensions which I use are all well “Dunn”.

+1 :-)

Third. I think the trick with any open source community is knowing who some of the key developers are. Almost all the extensions I use are from Nick and Nils and for good reason. They both make high-quality, safe extensions.

That being said, before I push any extension into a production environment I test it and then make backups before pushing it live.

What if someone created an amazing extension but secretly pasted a tiny bit evil code in it that would e-mail your username and password to some weird server in North-Korea?

Isn’t the password hashed?

Generally, I think extension security & trust is analogous to Wordpress. Not saying that’s the best, but it’s a common expectation.

Isn’t the password hashed?

It is, but you could write an extension that reset the password to something else and emailed it to you. Not that anyone would. Well they might. But we’d spot it.

I think a bigger risk is a security flaw that can be introduced by extensions. Not really sure how to prevent that though.. Maybe good extension developer docs with best practices will help.,

I think it is hard to completely prevent security flaws in our open source extension. But I think there could be nicer ways (actually there is nothing like this right now) to show that extensions are not up to date in the symphony settings. This could help to get people to update their unsafe extensions more quickly.

This could help to get people to update their unsafe extensions more quickly.

Or maybe an updater to update extensions from the backend, without the need to ftp or git into the host. That would be pretty awesome.

Or maybe an updater to update extensions from the backend, without the need to ftp or git into the host.

I wouldn’t like that. You’d only run into even worse access problems (PHP-user writing rights), security problems (PHP being able to edit the code it’s running), stability problems (updates don’t always run that smoothly). No, I’m fine with the status quo. :-)

Or maybe an updater to update extensions from the backend, without the need to ftp or git into the host.

This remembers me of Symphony 1.5 awesomeness :)

I wouldn’t like that. You’d only run into even worse access problems (PHP-user writing rights), security problems (PHP being able to edit the code it’s running), stability problems (updates don’t always run that smoothly).

That’s why it was removed in Symphony 1.6 or 1.7 :(

But I guess an (optional) update notifier would be great and easy to implement.

I wouldn’t like that. You’d only run into even worse access problems (PHP-user writing rights), security problems (PHP being able to edit the code it’s running), stability problems (updates don’t always run that smoothly). No, I’m fine with the status quo. :-)

Except for the php user rights I think you are beeing pessimistic;)

If the updater is seperated from the code it updates, nothing really scary should happen. The only remaining question, of course, is how to update the updater, lol.

Either way, I completely understand why this has been removed. Maybe if a stable solution comes up it might be worth remembering though.

I’m not sure about the updater either. Though the extensions page could and should be way more useful than it is now.

Right now it ‘just’ shows which extensions are installed, in which state they are, the version number and the author.

But actually the extensions page could also show which version is installed and if a new version is available. Also it could show the current compatibility status and it should point to one of these pages: Related discussion thread, issue page, extension info page or the github page.

On the other hand I know that one of the most stressed principles behind Symphony is simplicity. Also I’m not sure what is already planned for Symphony 3.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details