Comments (12)
@armab No, we don't have a mechanism in place right now for tracking security vulnerabilities. We can revisit this if and when this becomes an issue. In the meantime, there's nothing stopping users from building their own image as frequently as desired, and based on a specific version of st2.
@shusugmt Yes, that's my understanding.
So then, summarizing the above discussion:
Image:Tag | StackStorm Version | Description |
---|---|---|
stackstorm:dev |
2.6dev |
Latest 2.6dev, and most recent changes to st2-docker:master . |
stackstorm:latest |
2.5.0 |
Changes merged to st2-docker:master branch will result in a new image being deployed. |
stackstorm:2.5 |
2.5.0 |
Latest 2.5.x release |
stackstorm:2.5.0 |
2.5.0 |
Immutable, even if changes merged to st2-docker:master |
stackstorm:2.4.1 |
2.4.1 |
Immutable, even if changes merged to st2-docker:master |
stackstorm:2.4.0 |
2.4.0 |
Immutable, even if changes merged to st2-docker:master |
stackstorm:2.3.2 |
2.3.2 |
Immutable, even if changes merged to st2-docker:master |
stackstorm:2.3.1 |
2.3.1 |
Immutable, even if changes merged to st2-docker:master |
stackstorm:2.3.0 |
2.3.0 |
Immutable, even if changes merged to st2-docker:master |
from st2-docker.
- For the development version, I think just
stackstorm:dev
would be enough as it was before and avoid overcomplication. There are usually very few reasons someone will need previous development version of stackstorm. Let's focus on most used & popular cases. - Same for
stackstorm:2.4.1.001
, - looks very confusing, - I'd suggest to avoid this too and keep it simple as possible. Your approach withlatest
tag already solves the security/patching issue. - I definitely like the way with major.minor version like
stackstorm:2.4
pointing to2.4.1
or2.4.2
, depending on current released StackStorm patch version 👍
from st2-docker.
Same for stackstorm:2.4.1.001, - looks very confusing, - I'd suggest to avoid this too and keep it simple as possible. Your approach with latest tag already solves the security/patching issue.
:2.5.0
and :latest
(actually it is st2 2.5.0, assuming that it is the latest st2 release version at this point) will be different if there's any breaking change merged into st2-docker
after the upstream release of 2.5.0 and first :2.5.0
image is out. Of course same applies to the case with security patch. Is that really
"solves the security/patching issue"
?
I 1000% agree with not having so many tags here, but :2.5.0-nnn
is still needed if we apply the policy of making :2.5.0
image immutable.
from st2-docker.
Let's clarify what means "security patch" and plans about the case.
Every software becomes unsync/outdated quickly. When there is a vulnerability found in any other software (say base image which is ubuntu:trusty
for stackstorm), does it mean you're going to release a patch to all possible "old" and affected versions of StackStorm docker images?
Another question: do we have any real mechanism in place of tracking the security-affected software in StackStorm images and plan to go this path consistently to track/re-release new Docker image? Is it really a problem we're trying to solve?
At StackStorm/st2 we're not doing any back-porting, but instead release a new version and ask users to update. Giving that you have latest
tag in place, - that'll give you a solution and additionally encourage users to update.
Pragmatically speaking, it's good to think about it early, but I'd suggest to wait and time shows if you'll really need someday that additional tag suffix.
from st2-docker.
I get your point. Dealing with all security issues is impossible.
At StackStorm/st2 we're not doing any back-porting, but instead release a new version and ask users to update. Giving that you have latest tag in place, - that'll give you a solution and additionally encourage users to update.
So, let me clarify this part. After we fix the tagging policy, all enhancements and fixes made against st2-docker
will not available to current latest release image (:2.5.0
for example) because it's immutable after the upstream release. Those are treated as 2.6dev like other core components, and once upstream releases 2.5.1 (or 2.6.0) then all those will be included in :2.5.1
. This way we can keep track of the changes in st2-docker
with upstream release, and make it easier for both users and maintainers/developers to know what change was made to docker image between the st2 releases.
Am I right?
from st2-docker.
Looks good to me 👍
Let's also update the table in the first message and leave it here for a while so other users will have a chance to comment on the approach before actual implementation and VERSIONING.md
documentation.
from st2-docker.
I've updated the first message...
from st2-docker.
missing stackstorm:2.4
(and stackstorm:2.3
too) in table? Do we explicitly delete those tags after the release of stackstorm:2.5.0
?
from st2-docker.
They're not in the table because I'd planned to enable two digit tags beginning with stackstorm:2.5
. It's very unlikely we'll ever release a new release < 2.5
from st2-docker.
Ah, you are right.
We should add to description of :2.5
like something below:
Latest 2.5 release. Will not be updated (or become immutable?) after the release of new minor version (2.6.0 in this case)
from st2-docker.
My view is that it should not become immutable. After 2.6.0 is released, it is technically possible there could be another 2.5 release... although extremely unlikely.
from st2-docker.
I see. Certainly it is possible that upstream will release 2.5.3 after 2.6.0 release.
from st2-docker.
Related Issues (20)
- Simplify or document network configuration of docker-compose HOT 4
- ST2_API_KEY HOT 6
- bash: st2: command not found HOT 1
- Please support monitoring when using https HOT 1
- After Docker daemon restart, containers do not gracefully recover HOT 1
- st2ctl status returns no st2 component running HOT 1
- ServerSelectionTimeoutError when services connect to mongo. HOT 10
- ReplicaSet on docker-compose
- Providing core.remote stanley ssh keys HOT 2
- st2-rule-tester doesn't work in docker HOT 1
- Bad docker-compose.yml HOT 5
- CI build reports success on failed tests HOT 8
- Can document be updated on how to enable HTTPS support ?
- How to install it to mac m1 system. HOT 1
- Unnamed Docker volumes for stclient
- webhook The resource could not be found HOT 1
- `st2-docker-st2makesecrets-1` fails to start HOT 1
- Upgrading to Python version 3.10 or 3.9 in Stackstorm st2 v3.8.1 HOT 3
- Inconsistent Ansible version used by Docker and the one used by Stackstorm HOT 1
- st2makesecrets, st2client, and st2chatops containers fail to start successfully HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from st2-docker.