Trytond 6.0 and Werkzeug 2.x

Tryton6 - the current and LTS release - limits the build environment to a Werkzeug version < 2, a version that is outdated and will probably not receive any updates.
(First release candidate of Werkzeug 2 is from Feb 2021, release was in May 2021)

IMO it makes sense to update Tryton6 to a recent Werkzeug-version - what do you think?

Werkzeug 2.0 was released after Tryton 6.0 so it could not depend on it. And we do not update dependencies in bugfix releases (otherwise it will not be a bugfix release).

The development version already supports werkzeug 2.x and this will be the case also for the upcoming 6.2 release.

If you need some features available on werkzeug 2.x you should consider updating to it. Remeber that upgradig to newer series is always supported.

I dont need the features (for the moment), I just prefer up-to-date software.
I have patched my build and could not see a negative impact so far.
Except that it makes the LTS more future proof.

we do not update dependencies in bugfix releases

This makes sense for standard Tryton releases but not for the LTS. I hope this policy can be discused and amended. Plus, updating transitive dependencies in your minor versions is totally accepted in semver.

If a vulnerability was found in trytond-6.0.X, it would be fixed, wouldn’t it? Well, Werkzeug v1 is the vulnerability since Werkzeug<2.0.2 has been flagged as insecure Werkzeug Changelog -

Obviously I am upgrading to Tryton 6.2 ASAP, but I feel sad for the wasted collective effort of maintaining a LTS this way.

This is not possible. We can not upgrade to a new major release of such core dependency.
As the maintainer I know the burden it will cost and I’m not giving it for free (as in free beer). So as long as nobody step up with a plan that is secured in resources for 5 years. This is not going to happen.

I can not find to which security issue you are talking. And neither if Tryton would be affected.
But anyway, we are not responsible of the maintenance of werkzeug 1. It is bad if the upstream project is not providing security maintenance for series it published 1.5 years ago. But you should complain to them.

I mean, if Tryton’s release process was somewhat semver friendly this would not even be a discussion.

Lets say Tryton published

* 10.0 10/2018 --> 10/2023    |---.---.---.---.---|
* 12.0  5/2019 -->  5/2020      |---|
* 14.0 10/2019 --> 10/2020        |---|
* 16.0  5/2020 -->  5/2021          |---|
* 18.0 10/2020 --> 10/2021            |---|
* 20.0  5/2021 -->  5/2026              |---.---.---.---.---|
* 22.0 10/2021 --> 10/2022                |---|

so you could keep odd versions for development releases and use 10, 20, 30, etc for LTS. Despite the commitment to not shipping new features in the LTS, It would be totally legitimate to release a 20.1 version upgrading aging dependencies at any point of the long LTS lifespan.

Now, wasting the major fragment in the Tryton version schema is your choice. But if you are already not abiding by semver, then why holding a LTS down to insecure dependencies at all?

I don’t want to turn this discussion into a total amendment of Tryon’s release process, but I honestly think Tryton v6.0 should at least support both Werkzeug v1 and v2.

And what is your plan to support such maintenance burden? It is easy to say to others what they should do.

Also I’m still missing information about your statement that there is a security issue.
FYI the project has not reported any security release since version 0.15.5: Security | The Pallets Projects

Feel free to pick the required patches from Show Application:ERP:Tryton:6.0 - openSUSE Build Service

And what is your plan to support such maintenance burden? It is easy to say to others what they should do.

Just backporting Issue 337571002: tryton-env: Add support for werkzeug 2.0 - Code Review . It should be tested but it looks rather Werkzeug-v1-compatible.

As for the burden: once the project commits to maintaining a LTS you can be sure the burden will be a real thing. Again, this is a choice that was made, which brings me to your next point: who should do it.

Well, I just wish we can agree on WHAT should be done first. You sure understand nobody is making the slightest work until this debate ends with certain garuantees that developments for upgrading transitive dependencies in a LTS would be accepted.

After that, anyone can do it. Potentially me or @coogor or anyone who feels the urge to upgrade whatever is aging badly. I just hope you don’t hold back to this idea because it is a burden for you.

Also I’m still missing information about your statement that there is a security issue.

Any famework

  1. Is responsible for the dependencies it chooses.
  2. Should not make nor force assumptions on how it will be deployed.

Even if Werkzeug<2.0.1 vulnerability didn’t affect the Tryton application, you can’t know if someone is deploying a vulnerable Flask site or custom API besides Tryton because of your constraint on Werkzeug-v1.

The present Werkzeug vulnerability impacts authentication TLS guarantees on the debugging site, so exploitability will depend on a somewhat reckless, but still legit, deployment. Let’s just say I make an exception for this particular vulnerability because after some analysis I trust it doesn’t impact me and I whitelist it. Later in time someone else (or even me) could inadvertently unleash the exploit in our deployment. That’s why you don’t make security exceptions: optional security is insecure.

I just search an agreement on not actively holding down Tryton LTS dependencies by policy. I can totally agree about not upgrading transitive dependencies in standard releases, but not for LTS!

So still not proper link.
I’m boring of people telling us what to do without doing their own homework. I’m just muting this thread for me.

Theese are the 2 related issues

I am sorry you mistook a discussion with me telling you what to do. I’d gladly do it myself but contributors really need to feel the project is open for debates before being involved.

It is compatible with werkezeug v1. When I did the patch I tested with both series.
Indeed you can use 6.2 (which already contains the patch) with v1 without any issues.
Upgrade to newer versions is fully supported.

I just want to really understand the problem, but I have some doubts about it:

  • If it’s related to a development server, it should not affect any production site (you should be running a real web server on production).
  • If this is a security issue, while is not werkzeug backporting it to 1.x series? Are they no longer supported? I was unable to find any maintenance version of werkzeug.
  • If this is really a security issue and it will be never backported to 1.x series, how are linux distributions (i.e: ubuntu lts, debian stable) facing this problem?

I see that debian ships werkzeug 1.0 on its stable version and its including the v2 series only on the testing version.

Note that I mentioned debian because we are using it as source of our docker image, so we should at least care about the behaviour (i.e: If they backport the patch we will not need to update our image).


  • This is related to the debugging middleware provided by Werkzeug. Using the following Tryton configuration
TRYTOND_WSGI MIDDLEWARE__CONSOLE=werkzeug.debug.DebuggedApplication

will setup a site in the /console path yielding an interactive terminal featuring RCE secured only by the cookie in question, regardless of your favorite production wsgi server. The werkzeug.serving module would only setup this if requested with the --debug flag. Still, this is a legit configuration for a staging deployment and even for production if the insecure cookie couldn’t be abused to fool outdated browsers (and wasn’t to be rejected by modern ones).

  • Judging by recent Werkzeug releases, this project did never commit to backport security fixes, probably due to the ease to simply upgrade to version 2.
  • I understand this is a concern for the Tryton releases shipped from linux distributions. Please also understand many people do not deploy the Tryton server that way. I’m not deep into it but telling from Trytond 6.0 and Werkzeug 2.x - #9 by coogor I understand openSUSE already upgraded Werkzeug and is now patching the very Tryton LTS because of this issue? Maybe @coogor can share better insights.

Same can be done for Tryton, upgrading to newer series is easy and fully supported. So if you want to use middleware provided by newer versions just upgrade to newer series. I do not see a big issue on that.

But if the problem is really that a fix is not backported you should complain to werkzeug so others using werkzeug will benefit also for the fix.

As I stated, I am not staying in old versions nor any LTS. I just don’t see the point to maintain a LTS this way and feel sorry for the wasted community efforts. So I wanted to vouch for Tryton LTS keeping its compatibility with transient dependencies up to date, regardless of this particular Werkzeug issue nor any other. Rephrased:

Tryton is also responsible for the dependencies it chooses and for their versions it constraints. Specially after User Guide - pip documentation v22.0.dev0 . Werkzeug v1 is not an alive LTS release, but Tryton 6.0 is. Arguing to request a backport to Werkzeug v1 is as valid as arguing to backport it to v0.11 or anything older, just as I could not argue to backport anything to Tryton 4.0: it reached its EOL. I am afraid I’ll stop pursuing this idea if we can’t agree in this point. The ball is on Tryton’s roof, not Werkzeug’s.

…except that you dont want to do that on a production system ever half year.

@Dan we are turning in circles. A LTS is always a balance between required upgrades and ‘stability’ …
[Edit: Ah, just saw your comment. Agree]

1 Like

For me the issue is that you are requesting to backport something that is not a securtiy fix.
This is the same as implementing a new feature on tryton and requesting backporting to released series. We do not backport, we just encourage users to upgrade to newer series.

If you have any security concern related to tryton 6.0 using werkzeug 1.0 please fill a security issue on our bug tracker and we will discuss it there. If there is no security issue nor any bug on 6.0 series, there is nothing to discuss.

We declare that 6.0 series require Werkzeug 2.0 and the pip installer takes care about that. If you have a look at the CI build logs for 6.0 series you will see that werkzeug 1.0.1 is correctly installed. So there is no issue here.

Nobody prevents you to backport something your Tryton4.0 server :man_shrugging:

Then just keep the 6.0 (or the want you prefer) series with the supported Werkzeug version.

Where do you see that?

Not really. There is no branch 0.11.x of werkzeug but there is one 1.0.x.

As long as we do not have a clear statement from pallets project about there major release management. We could only expect they follow semver and keep supporting for security the series 1.0.

1 Like

I only assumed it, given those patches were never backported upfront, so: my bad. But here’s a rather clear statement about that assumption: Werkzeug v1 EOL and security backports policy? · Issue #2316 · pallets/werkzeug · GitHub