Closed luigimannoni closed 4 months ago
it might be safer to run a specific and community battle-tested version.
This project has a very quick release cycle, so there's isn't a "battle-tested version" (would you consider battle-tested a version published 2 days ago whereas a newer one has been published yesterday?).
Anyway, back to the actual question: using the very latest version or a fixed version? I think there is no one-size-fits-all answer: anyone can adopt the approach they want.
In any case, this is more a question/comment than a bug, so it'd be better to use discussions for it.
Sure, thanks for the feedback - I'll move the ticket on a discussions thread.
Yes, that's probably overthinking and slightly paranoid - I know it's up for the devs to make necessary adjustments but in the era of AI pulling down information from readmes and copy and pastes probably it's worth thinking about it.
I never felt a particular sympathy on pulling down the latest version of any package. Main reason being that images on local and on remote may differ: I'd be developing on an old image of 3/4 months while on deploy it might download a new version of the package with its new deprecations/incongruences.
Secondly, after the xz backdoor drama, it might be safer to run a specific and community battle-tested version.
So, on the readme we have these examples:
Can they follow the same way other oss binaries provide examples, eg for the composer dockerfile they use version pinning as such:
Funnily enough, on their same dockerfile they also install this binary with signature checking:
So can we suggest people on the readme to run the following, and potentially also provide signatures to check against:
Thoughts?