symfony 1.2.8 - rolling back our security fix

Reverting the security fix from 1.2.7

Fabien did revert the fix for the non-visible form fields in Changeset 19819. Here the reasoning from the commit comment:

These changes have been done to plug a security hole in the symfony
admin generator (more information on the [symfony blog](
http://www.symfony-project.org/blog/2009/04/27/symfony-1-2-6-security-fix)).
But a lot of people complained because it causes more harm than
good. The fix disables for instance the possibility to have custom
partials. Moreover, the problem also exists in a normal form if you
don't use the "echo $form" construct and if you forget to display
some non-required fields in the template.

After some discussion with the core team members, it appears that
there is no way to "fix" the problem for the developer. We thought
that we would be able to provide something, but the reality is that
we cannot.

Is it a problem? We think it is not a big problem as the
circumstances under which there can be an exploit are extremely rare
or even inexistent as if you are vulnerable, it also means that your
database data will be corrupted in some way (read the next section
for more information). As a matter of fact, all frameworks around
are vulnerable and have the exact same problem. We already provide
more advanced security features for the form framework than any
other framework around, but we cannot go any further. Security is
also a developer matter, and too much magic is sometimes a bad
thing.

Here is the exact circumstances under which you might be vulnerable:
A field is vulnerable only if you forget to display its widget in
the template and only if it has a non-required validator. Then, an
attacker could potentially inject a valid value for this field, and
it will be saved with the rest of the object. But two things greatly
mitigate the issue: first, if you forget to display a field, each
time you save the form, its value will be lost. So, most of the
time, you will be aware of the problem because the data in the
database will be corrupted. Second, the attacker need to know the
exact field name, which is not easy as no information is contained
in the HTML.

I am sorry for any inconvenience this caused, but we felt it was right to revert something which is a wrong solution, even (or especially) when it was a security fix.

Whats else in 1.2.8

We bumped Doctrine to 1.0.10 and fixed some issues with it alongside. We also put some efforts in to ensure PHP 5.3 compatibility and improved some PHPdoc, which were mainly contributions from 1day1ticket. Besides that a lot smaller issues got resolved, so I heavily recommend checking out the changelog.

How to install

Please upgrade your existing projects by updating the reference to the 1.2.8 subversion tag or by running the PEAR upgrade command:

$ pear upgrade symfony/symfony-1.2.8

If you use the 1.2 branch from our SVN repository, just run the svn update command to upgrade your project.

Last but not least, don't forget to clear your cache by running for doctrine:

$ php symfony doctrine:build-model
$ php symfony doctrine:build-forms
$ php symfony doctrine:build-filters
$ php symfony cache:clear

or when using propel:

$ php symfony propel:build-model
$ php symfony propel:build-forms
$ php symfony propel:build-filters
$ php symfony cache:clear