👍

Thank you @nicolas-grekas.

Very very bad decision to put a BC Break and not respecting semver.

You made a BC Break, so you made a major version right ? According to the semver standard ?

http://semver.org/

MAJOR version when you make incompatible API changes,

and of course not a minor version because minor is for backwards-compatible bug fixes. According to the semver standard.

Please consider http://symfony.com/blog/fixing-the-trusted-proxies-configuration-for-symfony-3-3

You have many solution to avoid BC Break.
You can add an alert about that in https://github.com/sensiolabs/security-checker
You can add a message displayed when you use php app/console to warn you about that.
Etc, etc.

Not respecting semver is a bad thing.

@syrm the security-checker warns about using an insecure version of a library. But it won't help about building a secure version of the API

It can evolve.

Thank you for breaking my production, I think such I huge framework as Symfony should stick to the semver rules.

But the worst thing is I get an official answer about that they gonna do that again in futur.

The rules have always been very clear and have always been part of the documentation. For security issues, we can break backward compatibility.

As for breaking BC in general, I like to think that we are doing a great job. Of course, from time to time, we might break BC by error. When it happens and when it's reported before the stable release, we fix it. Then, there are also cases where the difference between breaking BC and fixing a bug is not that clear.

It's not black and white. It's difficult. The core team spends most of its time on this topic. Happy if you can help.

As I said, even for security reason you should NEVER do a BC break. For example this security problem is only on AWS. And you break the code for everyone one using proxy. You should have put a warning on dev bar about this security problem and let each one should do what they want.

I think you misunderstood the security issue, it's not AWS specific at all but can affect anyone using trusted proxies really.

Only if you have bad server config

Sorry for joining the party a bit late. I understand Symfony policy about security issues and I second them. However when you have:

framework:
    trusted_proxies: ~

Which is the default in a fair number of applications, you get a hard BC break still even though there is no security threats. IMO this is being downright annoying for absolutely no reason.

@theofidry I a gree, when default (null) is set it should be simple ignored. Otherwise you can throw an exception as then it shouldn't go left unnoticed.

Anyone who would like to give Theo's idea a try? (The config option should then be deprecated)

I just tried quickly with something like:

->arrayNode('trusted_proxies') // @deprecated in version 3.3, to be removed in 4.0
                    ->beforeNormalization()
                        ->always(function ($values) {
                            if (null === $values || array() == $values) {
                                return $this;
                            }

                            return $this->thenInvalid('The "framework.trusted_proxies" configuration key has been removed in Symfony 3.3. Use the Request::setTrustedProxies() method in your front controller instead.')
                        })
                    ->end()
                ->end()

But it didn't seem to work very well. I'm not very familiar with the config and I didn't see anything on how to create a custom validation rule here.

Unfortunately I cannot continue on this right now, might give it another try later during the week if I find some time.

Can you give #23049 a try?

return $this; ? 😄 you can simple return $values; 😛

My main complain is because the issue simply broke with a recommended solution that could have come as a default argument.

It took me a couple of hours to first identify that the issue wasn't on my side and that after chain of dependencies it was SF's update that did it.

I wonder if there is a proper way to warn people of an incoming BC, as @syrm recommended.
It doesn't look like this security issue was so urgent as it took eight months from the report to the update.

For the record, this has been reverted (at least the BC break) in #23067 and will be part of the upcoming 3.3.1 release.

Hello!

i have a same error on a web server to install shopware.de

error:
Fatal error: Uncaught Symfony\Component\HttpFoundation\Exception\ConflictingHeadersException: The request has both a trusted Forwarded header and a trusted Client IP header, conflicting with each other with regards to the originating IP addresses of the request. This is the result of a misconfiguration. You should either configure your proxy only to send one of these headers, or configure Symfony to distrust one of them. in /home/frischebry/www/vendor/symfony/http-foundation/Request.php:822 Stack trace: #0 /home/frischebry/www/vendor/symfony/http-foundation/Request.php(852): Symfony\Component\HttpFoundation\Request->getClientIps() #1 /home/frischebry/www/engine/Shopware/Kernel.php(215): Symfony\Component\HttpFoundation\Request->getClientIp() #2 /home/frischebry/www/engine/Shopware/Kernel.php(178): Shopware\Kernel->transformSymfonyRequestToEnlightRequest(Object(Symfony\Component\HttpFoundation\Request)) #3 /home/frischebry/www/vendor/symfony/http-kernel/HttpCache/HttpCache.php(491): Shopware\Kernel->handle(Object(Symfony\C in /home/frischebry/www/vendor/symfony/http-foundation/Request.php on line 822

it was the same error as this I think
https://symfony.com/doc/current/request/load_balancer_reverse_proxy.html#my-reverse-proxy-sends-x-forwarded-for-but-does-not-filter-the-forwarded-header

or how could I to an work around?
how could I fix that?

thx
Peter

@petereth it's in the issue description: https://symfony.com/blog/fixing-the-trusted-proxies-configuration-for-symfony-3-3, or alternatively you can just update (Sf 3.1.1 and 3.1.2 have already been released)

Hi @theofidry thank you really for that help, is it possible for you that you could please help for that case to fix that I do not know where to find this on https://github.com/shopware/shopware/tree/5.2/vendor - there is a symphony tree !

thank you
Regards
Peter