Problems of {plugin}[{snr}] naming scheme

[ZyX_I]

I just realized that this scheme contains at least three problems:

1. Addition of new plugin (renaming some of old plugins) with name matching old one will leave old plugin without updates.
2. Renaming of some plugin will leave existing installations being not updated automatically anymore.
3. You can make user update plugin with name={plugin1}{snr1} with plugin with name={plugin2}={plugin1}{snr1} if {snr2}<{snr1} (opposite leads to garbage names ({plugin}{snr}{snr})).

Do you have some statistics about how often does this happen and whether it is worth working on (first two, third is vulnerability and must be fixed)? I suggest

1. Duplicating of just {plugin} entries with {plugin}%{snr} (easy), so one can always use persistent name.
2. Having a renames file which will create warnings if you try to update renamed plugin.
3. Replacing {plugin}{snr} scheme with {plugin}%{snr} as percent sign is not allowed to be in plugin names, but allowed in file names on windows (easy, but breaks compatibility). Another solution is to make script check whether newly created names is already taken, but this leads to garbage names (names with duplicate {snr} parts) as well.

[ZyX_I]

Fix that addresses 3. problem of issue #18, current solution: `leave garbage names'

→ 4574af758790

[marco-oweber]

Excerpts from ZyX-I's message of Tue Nov 15 18:08:36 +0100 2011:

1. Addition of new plugin (renaming some of old plugins) with name matching old one will leave old plugin without updates.

Well - old plugins usually still work. Currently we have to deprecate old names manually - you know the feature with the strange messages :)

2. Renaming of some plugin will leave existing installations being not updated automatically anymore.

You should not rename plugins. See 1. VAM does not exactly define what a name (which is used as plugin identifier) is or should be. Everything is in a flux. If it gets the job done - then its fine - and it does.

3. You can make user update plugin with `name={plugin1}{snr1}` with plugin with `name={plugin2}={plugin1}{snr1}` if `{snr2}<{snr1}` (opposite leads to garbage names (`{plugin}{snr}{snr}`)).

I'm not sure I know what you're talking about. If change the path names eg "VAM-kr" being installed to vim-addons/VAM-kr/github_marc_weber/ then you'll get a new checkout if the default source changes eg because upstream changed from github.com/MarcWeber to github.com/ZyX leaving the old repo outdated in place.

VAM was never meant to be the perfect solution - sorry. It works for me and I'd like to spend my time on more important things such as rewriting and updating the web site.

Do you have some statistics about how often does this happen and whether it is worth working on (first two, third is vulnerability and must be fixed)? I suggest

Every update is a vulnerability. Who can guarantee that you don't pull a "rm -fr " ? Then you're out of luck anyway. Repo location does not have to change .. - Seriously: Have I ever asked how secure you store your SSH keys (because I granted you access to my github VAM repos?) .. I never had reason regretting having done so :)

VAM is only as secure as the sources are. Luckily not much bad happened in the past.

2. Having a renames file which will create warnings if you try to update renamed plugin.

When should those warnings happen? I'd suggest when loading VAM-kr. It should not take place always. Vim should shut up and get its job done on average case.

3. Replacing `{plugin}{snr}` scheme with `{plugin}%{snr}` as percent sign is not allowed to be in plugin names, but allowed in file names on windows (easy, but breaks compatibility). Another solution is to make script check whether newly created names is already taken, but this leads to garbage names (names with duplicate `{snr}` parts) as well.

Still not sure what you mean. Yeah - currently VAM odes not care about name collisions. Things may go silently wrong in those cases. However it is easy to fix manually then. We don't have man power to support all plugins and check names and ... This manual part ensures that we spend time on plugins causing trouble - thus on plugins which are actually used by people. Again: There is not much support I have to give - so its working well IMHO.

Oh - now I got you SNR is the number which is assigned if the same name occurs twice. So what's the solution? Generate UIDS for each plugin? Horrible.

Find real use cases - and we can introduce manual patching of those special cases such as

'foobar_script_id_10' => 'name-x' 'foobar_script_id_1000' => 'name-y'

That's easy, understandable and will scale good enough?

[ZyX_I]

> 3. You can make user update plugin with `name={plugin1}{snr1}` with plugin with `name={plugin2}={plugin1}{snr1}` if `{snr2}<{snr1}` (opposite leads to garbage names (`{plugin}{snr}{snr}`)).

I'm not sure I know what you're talking about. If change the path names

eg "VAM-kr" being installed to vim-addons/VAM-kr/github_marc_weber/ then you'll get a new checkout if the default source changes eg because upstream changed from github.com/MarcWeber to github.com/ZyX leaving the old repo outdated in place.

No, it is different. Pretend that there are two plugins `abc`: one with script number 123 and second with script number 42. Some bad guy gained access to plugin with script number 100. He can now rename this plugin to `abc123` and then own anybody who will update plugin `abc123`.

It was fixed in last commit, but at a cost of someone being able to spoil plugin names. My solution (use `{sname}%{snr}` scheme instead of current `{sname}{snr}` takes care of this).

Every update is a vulnerability. Who can guarantee that you don't pull a

"rm -fr " ? Then you're out of luck anyway. Repo location does not have to change .. - Seriously: Have I ever asked how secure you store your SSH keys (because I granted you access to my github VAM repos?) .. I never had reason regretting having done so :)

No, that was different. You can pull from @MarcWeber which is not likely to put `rm -rf` or from John Smith. This is vulnerability because VAM will silently change the source of the pull. Do not forget *I am not talking about SCM sources here at all*.

[ZyX_I]

Well - old plugins usually still work. Currently we have to deprecate

old names manually - you know the feature with the strange messages :)

No. Pretend that you are the first who created plugin named `aligner`. As it is very trivial name, Bob also created script named `aligner` after you. Now users of your plugin are left without updates until they manually rename the directory and put appropriate changes into the vimrc.

In addition, www.vim.org, allows you to rename `aligner` with `c-aligner`. Users are now also left without updates. I do not think both situations must be somehow *fixed*, but it is worth generating note for a user.

[ZyX_I]

When should those warnings happen? I'd suggest when loading VAM-kr. It

should not take place always. Vim should shut up and get its job done on average case.

I totally agree here: I thought it warning on update, on loading of VAM-kr is also fine. In addition that VAM should shut up, it does not have enough information to generate such warning.

[ZyX_I]

Still not sure what you mean. Yeah - currently VAM odes not care about

name collisions. Things may go silently wrong in those cases. However it is easy to fix manually then. We don't have man power to support all plugins and check names and ... This manual part ensures that we spend time on plugins causing trouble - thus on plugins which are actually used by people. Again: There is not much support I have to give - so its working well IMHO.

I never said they must be checked *manually*. My commit (the only one mentioned here) implements this recheck, but it looks much better if you'd allowed usage of `{name}%{snr}` scheme.

[ZyX_I]

Oh - now I got you SNR is the number which is assigned if the same name

occurs twice.

So what's the solution? Generate UIDS for each plugin? Horrible.

What UID's? I never talked about them. Just a small change to a naming scheme: where it had `$_.=$snr;` (previously `k . v2['vim_script_nr']`) there will be `$_.="%$snr";`.

Find real use cases - and we can introduce manual patching of those

special cases such as

'foobar_script_id_10' => 'name-x' 'foobar_script_id_1000' => 'name-y'

That's easy, understandable and will scale good enough?

No need in doing this: current scheme would be good enough with a small fix.

[marco-oweber]

...

I got it now. Yes - it was a wise / good choice to fix. It makes a difference which plugin owner you trust.

Now what happens in this case: - scm['foo'] = {'type':git',...} but no vim_org['foo']

then org['foo'] is added to vim.org and you install on a system not having 'git' in PATH?

So we should even avoid the executable('git') bit in .vimrc ? Sorry for that. Sorry for that :)

[ZyX_I]

It may be better if users would be able to pass names `{name}%{snr}` or `%{snr}`: first to force check on matching script number and second to select plugin by its script number as it is the only persistent property of the plugin. Per cent sign will thus be reserved and forbidden in plugin names, but it is not a loss as it is not currently used. For plugins not posted on vim.org this is `{name}%{URL}`/`%{URL}`. It will prevent downloading plugins from untrusted source in cases like “author renamed plugin and then bad guy created malware plugin named identical to old normal plugin name”.

By the way, what should be used instead of “bad guy” here? In Russian it is “злоумышленник” which is translated as “malefactor, deliberate criminal; culprit”, but I like neither of these translations.

[ZyX_I]

My suggestion can be implemented (by user) using name rewriting, but it requires additional steps (one condition added to `vam#install#Install` + additions to documentation) to reserve per cent sign and forbid it to appear in normal names. And I would like to see this in upstream.

[ZyX_I]

One addition: it may make sense to load script with number `{snr}` even if `{name}` does not match, but generate a warning.

[ZyX_I]

And another one: as we will be able to use `{name}%{snr}` scheme then when two plugins have identical names both can be kept in known repositories dictionary only by their `{snr}` thus forcing user to use `{name}%{snr}` scheme: in this case there will be no need in keeping code that renames both plugins to `{name}{snr}`.