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 https://codereview.tryton.org/337571002 . 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
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:
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).
AFAIU
TRYTOND_WSGI MIDDLEWARE__CONSOLE=werkzeug.debug.DebuggedApplication
TRYTOND_WSGI CONSOLE__KWARGS={'evalex': True}
WERKZEUG_DEBUG_PIN=123-456
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).
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 v24.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]
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 
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.
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