mattmc3
Pin a specific commit of a plugin
Per https://github.com/getantibody/antibody/issues/386:
Is it possible to pin a specific commit of a plugin in case of breaking changes?
Are there any blockers to this feature being implemented? I'd like to help, if possible
No blockers - I've always thought of it as a pretty easy feature. I haven't done it yet because there hasn't been a lot of interest in it before now, and I just need some volunteers to test it.
My take on implementing the feature is this:
- Add a
pin:SHAannotation that tells antidote which commit SHA you want for your plugins. - Add a
pinsubcommand like:antidote pin [-r|--remove] [<PLUGIN>] [<SHA>]. This lets you pin (or unpin) a plugin (or all plugins) to either a specified SHA or whatever is current - Ensure
antidote updaterespects pinning and is a no-op for pinned repos - Perhaps allow
antidote updateto unpin and then re-pin for a updates (a --force flag??) - Figure out error handling of invalid SHAs
- Update all the docs
Any other relevant features you'd like me to consider as part of this feature?
Adding a layer that could convert tags to commit SHAs, as I have a few plugins that I version using tags. I'd make it so that the pin annotation would support pin:SHA|TAG
@obvionaoe It's not pretty but for tags you can already do this:
antidote install -b v5.8.3 olets/zsh-abbr.- or
olets/zsh-abbr branch:v5.8.3inzsh_plugins.txt.
Doesn't give you the guarantees that pinning a SHA-256 commit ref would give you of course.
It's on my short list to address this feature in the next release. No ETA, but planning for a release fairly soon. In the mean time, there's a pretty simple workaround if you want to revert to a plugin to an older SHA:
# make sure antidote is loaded, and then set these vars to whatever you need
source /path/to/antidote.zsh
GIT_WORKING_SHA=cfc3fd9a75d0577aa9d65e35849f2d8c2719b873
GIT_DIR=$(antidote path marlonrichert/zsh-autocomplete)
# revert Zsh plugin managed by antidote to a prior SHA
git -C "$GIT_DIR" fetch --unshallow
git -C "$GIT_DIR" checkout $GIT_WORKING_SHA
It will be great if pinning can be supported in the static plugin file, and it supports pinning by git commit or git branch. Maybe reusing the existing query string used by git, like ?rev=<commit-sha>
This is also an important security feature against supply chain attack.
Imagine if a plugin maintainer's account is hacked and the hacker injects malicious code into the latest commit. Since the plugin is open source, hopefully within a few days people will find out. (unless it is too unpopular or extremely covert.) Hence, there's a common software engineering practice that delays dependency update for a few days if the dependency comes straight from the upstream developer.
However, there's no defense line for antidote users. antidote update just installs the latest commit right away and the user becomes a victim of this attack.
IMHO, zsh plugins are a sweet spot to attack: There are a lot of people using them, but not too many so that security measurements (such as in antidote) aren't quite geared up.
There is an interesting example of an overt supply chain attack, leading to https://github.com/vuejs/vue-cli/issues/7054 , which is totally avoidable by the wisdom of delaying updates for a few days.
@mattmc3 By extension, should pinning tags be considered part of this issue, or should I make a new one?
Edit: Perhaps @devnoname120 mentions tags https://github.com/mattmc3/antidote/issues/1#issuecomment-2483475129 work. But it hasn't dug me out of the plugin issue.
Brief scenario, in favor of pinning tags
https://github.com/junegunn/fzf/issues/4211 - tracking the trunk caused this breakage.
https://github.com/junegunn/fzf doesn't have a branch to use, but has a tag that's unreachable https://github.com/junegunn/fzf/tree/v0.58.0.
