Pin a specific commit of a plugin

[mattmc3]

Per getantibody/antibody#386:

Is it possible to pin a specific commit of a plugin in case of breaking changes?

[obvionaoe]

Are there any blockers to this feature being implemented? I'd like to help, if possible

[mattmc3]

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:SHA annotation that tells antidote which commit SHA you want for your plugins.
• Add a pin subcommand 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 update respects pinning and is a no-op for pinned repos
• Perhaps allow antidote update to 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?

[obvionaoe]

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

[devnoname120]

@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.3 in zsh_plugins.txt.

Doesn't give you the guarantees that pinning a SHA-256 commit ref would give you of course.

[devnoname120]

Related: #171

[josevelaz]

@mattmc3 Does there happen to an update to this issue?

[mattmc3]

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

[winston0410]

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>

[xuhdev]

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 vuejs/vue-cli#7054 , which is totally avoidable by the wisdom of delaying updates for a few days.