What is this fork for? #1109
|
As Watchtower upstream is now archived, what is this downstream repo? Is it a continuation? Changes? What are the differences? Can and how do we trust you? |
Replies: 2 comments 7 replies
What is this downstream repo?It's my personal fork that I make freely available for anyone to use. I use it personally in my own production environment, so continued maintenance and improvements are for my own benefit as much as for everyone else who uses and contributes to it. Is it a continuation?Yes, in that the current semantic versioning of v1.x.x should indicate that there are no major breaking changes that would generally prevent someone from migrating their configuration to this fork. That said, there is a long-term expectation of a new, major release (i.e. version 2); however, that's not to be expected for likely until another year. Changes?You can view the differences here: containrrr/watchtower@main...nicholas-fedor:watchtower:main What are the differences?This branch has been constantly evolving as I continue to work through issues and adding features.
There's definitely more that I'm missing, but hopefully this just highlights that this is now an active project. I also maintain a fork of the notification library, Shoutrrr, which has allowed me to implement fixes, add features, etc there as well that benefits Watchtower. Can and how do we trust you?For all intensive purposes, I'm just another random person on the Internet. Given the functionality of this software (i.e. handling containers in an automated fashion), there's an inherit level of trust required before using it. The code is fully open-sourced, GitHub Actions are used to perform automated testing and basic security scanning, and the builds are performed via GitHub Actions. In effect, everything is in the open for anyone to audit and/or build themselves. ContributionsI will just add that if anyone wishes to contribute to this repo, then they are free to submit a PR. There's no shortage of bugs, features, or just even cosmetic improvements that can be addressed. If there's a unique or major feature that someone wants to collaborate on, then there's no reason that a branch cannot be started and developed. If you have any further questions, then feel free to let me know! |
Can you vouch for a little guarantees? E.g. not dropping it randomly or infecting it?
This is not practically possible as there are many spammy commits like dependency updates. What are the key highlight differences? (You should periodically merge dependency updates as a squashed commits to prevent spammy commits)
That answers the key highlights. thanks
I think you should, simply because it gives a lot of confidence, security benefits but is not a lot of work. Some keywords I can quickly suggest you are: github artifact attestation (github proves that certain assets are generated by a workflow and thus linked to source code, which prevents you from maliciously swapping release assets), immutable releases (a github feature that prevents you to swap release assets once its created), gpg signing artifacts (mitigates supply chain attack by signature). As you can, you basically protect everyone from "yourself" as well as protect yourself from everyone else (e.g. supply chain attacks). Its not very difficult to setup, and its definitly worth it, if you believe your project can be something many people and even organizations depend on. Thanks! |
|
All of your answers are both in my earlier response and via a review of the repo. |
|
Most peoples workflow is this:
If you intend to serve less than what the user expects in this workflow please add a disclaimer that you may drop the project at your convenience, there's no warranties or guarantees for anything, and that you have no plan in offering basic securities such as supply chain or gpg. This will help users in this common workflow identify quickly and painlessly if they want to commerce into the project or if their risk model or profile doesn't allow it. Of course this is just based on my understanding of what you said so far and what I read between the lines. |
|
You are welcome to review the repository and validate it for your own edification. |
|
And so is everyone else, but nobody does it and you also can't implicitly expect everyone to do that. If you truly want to contribute as a volunteer, disclaim how you want to do it. Otherwise you're just misleading, intentional or unintentionally |
|
As previously mentioned, all of your concerns are alleviated by reviewing the project. It's difficult to be misleading when everything is available for anyone to audit. There is nothing further to discuss. |
What is this downstream repo?
It's my personal fork that I make freely available for anyone to use. I use it personally in my own production environment, so continued maintenance and improvements are for my own benefit as much as for everyone else who uses and contributes to it.
Is it a continuation?
Yes, in that the current semantic versioning of v1.x.x should indicate that there are no major breaking changes that would generally prevent someone from migrating their configuration to this fork. That said, there is a long-term expectation of a new, major release (i.e. version 2); however, that's not to be expected for likely until another year.
Changes?
You can view the differences here: c…