Hi there,
I am a bit confused, I’d like to evaluate the point releases of comunda 7.x.y that contain the Spring4Shell Security-Fixes, but I seem to be unable to locate the source code for them? The Repository only seems to contain the ‘major’ versions, i.e. 7.x.0 and alpha / beta versions leading up to them?
Where is the development that goes into those point releases? Where are the Tags / Branches for them?
Thanks in advance!
Ohh yeah, would be good to know! 
Hi,
I guess with “point release” you mean patches, like 7.14.20, 7.15.14, 7.16.8, 7.17.1 that introduce the Spring4Shell fix? For Camunda 7, these are only available for enterprise customers via the Camunda artifactory. That’s also where customers can access the source code of these artifacts in the form of source jars. The code repositories are private to Camunda.
On the master branch in the community edition, the fix was made via chore(parent): bump Spring versions by tmetzke · Pull Request #1869 · camunda/camunda-bpm-platform · GitHub if that helps.
Cheers,
Thorben
@thorben Do I get this right? This seems to mean that open source users have to basically track the master branch to use camunda in production?
In this case, you can decide to use alpha releases, update Spring yourself (e.g. in case of Spring Boot, override dependencies) or wait for the next minor release.
@thorben Does that mean Master is unstable and should not be used? Sorry if this is common knowledge, but I haven’t really found documentation about this.
I don’t think there is a direct yes/no answer to this question. In terms of quality assurance, you can generally say that master (aka snapshot releases) are less tested than alpha releases are less tested than minor releases/patch releases.
From practice I can say that master/snapshots sometimes have work-in-progress features or regressions that we detect only after merge. Alpha releases may have work-in-progress features and non-critical bugs. Minor and patch release have no work-in-progress features and we strive to deliver them without known regressions (but you know how it is in software development :)).
That seems to imply that there is no way to get any security fixes for camunda without accepting all the regressions that will happen on master.
I mean, is there a way to run a camunda instance responsibly (i.e. fix time from known defect to deployment < 24 hours) without tracking master?
I think in this case you could inquire about our enterprise offering. Sorry that I cannot offer you a community-only answer.
