mikaelbr / mversion Goto Github PK

It has a Denial of Service risk.

Are you open to that ?
Having tagged versions without "v" as a prefix.

Hi,

I'm trying to execute a gulp task that will compile some CSS files for me. One thing it does is insert a banner into the built file with a reference to the current version in the package.json. I'd like to run this task just after mversion has updated package.json but before it creates the tag and commits it.

It seems wherever I put the gulp task in the hooks it always creates the tag and commits it before the gulp task runs.

Updated to new version: v0.7.0
Updated package.json
Updated bower.json
<-- I want to run my task here
Commited to git and created tag 0.7.0

I've installed latest master because I thought #26 might solve it for me, but no joy. Any suggestions?

Thanks!

Updating bower.json's version is deprecated as per https://github.com/bower/spec/blob/master/json.md#user-content-version . Can you add an option (or default) to avoiding adding it to bower.json?

Hi there, thanks for creating mversion. :-)

The parameter -m does create a commit but it doesn't "release" a tag.

Not sure if I'm missing something or maybe I misunderstood what you meant by "tag".

Some files aren't needed when using the package as a dependency. It'd be great if you specify what are those files (.npmignore) or what are the files that are needed ("files" property in package.json). See https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-package

If the git repo isn't clean, mversion will edit the json files and then fail to tag. This is bad because if you tidy the git repo and call mversion again it isn't obvious that your project will be bumped up two versions.

I think it should check first and only edit the json files if the git repo is ready to be tagged. Otherwise, print an error and exit.

Here is my preupdate script scripts/foo.sh :

#!/usr/bin/env bash
echo "Hello from foo"
touch foo
exit 1

Here is my .mversionrc :

{
    "scripts": {
        "preupdate": "./scripts/foo.sh",
    }
}

Then mversion patch :

Error running preupdate: Command failed: ./scripts/foo.sh
Stopping execution

No output from my script (echo "Hello from foo"). However, the foo file got created, meaning my script did execute.

Shouldn't I see my script output ? Or what am I doing wrong ?

Hello,

I am a member of the GitHub Security Lab (https://securitylab.github.com).

I've attempted to reach a maintainer for this project to report a potential security issue but have been unable to verify the report was received. Please could a project maintainer could contact us at [email protected], using reference GHSL-2020-110?

Thank you,
Kevin Backhouse
GitHub Security Lab

Using mversion minor -n -m ignore the -m.
Maybe you should use something like minimist to easily parse cli arguments.

I've been using mversion with great pleasure. Unfortunately mversion does not work for projects which are registered as jquery plugins.

For a jquery plugin named X, the plugin file is X.jquery.json.

To support this, mversion should search for all files matching *.jquery.json in the current directory, and update their version numbers too (together with package.json, bower.json, etc)

Adding wildcard support to mversion should be relatively straightforward by using the node_module glob. I could submit a pull-request implementing this feature if necessary/preferred.

I ran an npm audit on selenium-standalone which is a tool that uses mversion in dev environment only.
Please consider updating the dependencies:

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=3.0.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ mversion [dev]                                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ mversion > minimatch                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/118                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=3.0.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ mversion [dev]                                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ mversion > vinyl-fs > glob-stream > glob > minimatch         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/118                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=3.0.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ mversion [dev]                                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ mversion > vinyl-fs > glob-stream > minimatch                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/118                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=3.0.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ mversion [dev]                                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ mversion > vinyl-fs > glob-watcher > gaze > globule > glob > │
│               │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/118                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=3.0.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ mversion [dev]                                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ mversion > vinyl-fs > glob-watcher > gaze > globule >        │
│               │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/118                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

npm bump not only creates a tag, but also pushes the repo to it's origin. Is that something you would want to add?

I'm using mversion in my projects and I like it! My website projects I want to have the version in the index.html file as a meta-tag. Using precommit and postcommit scripts I thought I could use sed to search and replace a special string.

{
    "scripts": {
        "precommit": "sed -e s/\{mversion\}/%s/g app/index.html",
        "postcommit": "git push --tags && sed -e s/%s/\{mversion\}/g app/index.html"
    }
}

<meta name="version" content="{mversion}" />

The problem I have is that %s is not available in the scripts, or I don't know how to use it. Could you implement this or update the documentation?
If I move the commands to its own file, maybe you can append the %s as an argument of the shell script.

We use sonarqube to monitor our code quality, which means that each project has a sonar-project.properties file with the version specified in it. It would be great to be able to use mversion to bump this as well. If this is desirable I am happy to work on it and submit a PR, let me know.

Just an idea, but I started using pre-commit and now when it fails when running mversion -m I'd expect it the changes to rollback. In fact, if anything in the process fails I feel like it should undo the changes.

I just wanted to try out annotated tags so I can start taking advantage of GitHub releases, but having a single line message is a bit difficult to write. Any chance of adding a -a flag that'll set it to annotate and then prompt for the tag message?

Edit: Decided to try it out, but it doesn't seem to tie in with GitHub releases which is a bummer since I kind of like it. I might continue using GitHub releases, but have you found whether it can integrate with tags? It's definitely cleaner and simpler than using a change log.

Hello! mversion throw next error when I'm using -m on Windows 7.

mversion patch -m
Failed updating:
Command failed: C:\Windows\system32\cmd.exe /s /c "git tag -a v0.0.2 -m "v0.0.2""
fatal: tag 'v0.0.2' already exists

For some reasons command C:\Windows\system32\cmd.exe /s /c "git tag -a v0.0.2 -m "v0.0.2" aren't working for me.
I'm using bash-enabled terminal so if I switch from C:\Windows\system32\cmd.exe /s /c "git tag -a v0.0.2 -m "v0.0.2" to git tag -a v0.0.2 -m "v0.0.2" then it will fix this issue. Is there an ability to do it? Maybe with help of .mversionrc file ?

Sometimes it's nice just to specify which file you want change, rather than changing them all. Or at least instructions on the README on how to do this.

Feature request!

I think it would be great if mversion looked at it's current directory and up for any .mversionrc files and allowed you to put settings there.

After running mversion patch -m, mversion removes new lines from package.json and bower.json :(

Example:

mozilla/webmaker-kits@1664df0

You would only want to run git push or git push --tags if you have the -m or -message flag. So we need scripts that are exclusively for this.

Should post- and pre-update also be for commit? I feel this makes most sense.

I think a good feature would be to add the possibility to update a version in a module, may be with a regular expression. An example :

In Backbone, https://github.com/documentcloud/backbone/blob/master/backbone.js :

mversion --file backbone.js --var Backbone.version

If the argument contains a -h anywhere in it, the mversion help text will display instead of the command running as expected

Example: We have a convention of using our feature branch names as part of our package versions for testing. So today, I tried to run

mversion 1.20.1-common-request-host.1 -m

This gets interpreted as mversion -h and prints the help text.

Seems to be this package only creates a lightweight tag, but no annotated one. Is there a way to get annotated tags, i. e with an option of -a?

Explicitly setting the new version doesn't help.

$ mversion -m 0.0.6
Updated to new version: v0.1.0
Updated package.json
Updated bower.json
Commited to git and created tag v0.1.0

$ mversion patch --tag -m '%s' gives me this:

Failed updating:
Command failed: fatal: /Users/mohsen/Google: '/Users/mohsen/Google' is outside repository

Hi!
It would be nice if you could only get the next version number, without updating package files.
Maybe something like:

mversion [ <newversion> | major | minor | patch | prerelease ] [--show -s]

Thanks for your work. Excellent project :)

Hi there,
I need a tool to bump a few packages in bulk so I figured I'd give mversion a try.
My command line script uses this module

var exec = require('child_process').exec;

module.exports = function (filePath, options) {
  var script = [
    process.cwd() + '/node_modules/.bin/mversion',
    options.version,
    '-n' // no prefix (omit the v from vNUMBER)
  ];

  options.commitMessage && script.push('-m "' + options.commitMessage + '"');
  options.overrideTag && script.push('-t');

  exec(script.join(' '), { cwd: filePath });
};

But it feels very wrong to me.
Ideally I would like to use the mversion module but I don't know how to set the cwd (if that's even possible). Any suggestion?

If precommit scripts were executed right before the commit (inside the update method, after the clean repo check) we could add files to the commit being created to do things like:

• Generate an automatic changelog file
• Generate API docs
• Add distributable scripts only in release commits (like jQuery does)

When I start a new project I often set the version to 0.1.0 (which you could argue is stupid, and probably comes from my Java background starting projects at 0.1.0-SNAPSHOT. Fair 'nuff). I expected to be able to run mversion 0.1.0 and just have the tool go through the normal tagging steps even though the version wasn't changing. Instead I got:

Failed updating:
Command failed:

which was puzzling. It took diving through the code to find that the invocation of git add was returning 1 since there were no modifications.

The simplest way to overcome this would be to stick a --allow-empty in there...but upon reflection, I think a better option would be

A) Enhance logging in such a way that I can tell I'm being stupid or...
B) Detect this condition and skip the commit step or...
C) ?

In the meantime I think I'll survive.

Here is my .mversionrc :

{
    "scripts": {
        "preupdate": "echo preupdate",
        "precommit": "echo precommit",
        "postcommit": "echo postcommit",
        "postupdate": "echo postupdate"
    }
}

Then mversion patch :

Output running preupdate: preupdate

Updated to new version: v0.0.6
Updated package.json
Updated bower.json
Output running postupdate: postupdate

no trace of commit hooks execution... (mversion v1.10.1)

This could potentially be caused by a third party API, or perhaps an incorrect use of a third party API.

$ node -v
v0.12.2

$ mversion -h
node_modules/mversion/node_modules/cli-usage/node_modules/marked/lib/marked.js:1226
    throw e;
          ^
TypeError: undefined is not a function
Please report this to https://github.com/chjj/marked.
    at InlineLexer.output (node_modules/mversion/node_modules/cli-usage/node_modules/marked/lib/marked.js:685:28)
    at Parser.tok (node_modules/mversion/node_modules/cli-usage/node_modules/marked/lib/marked.js:985:21)
    at Parser.parse (node_modules/mversion/node_modules/cli-usage/node_modules/marked/lib/marked.js:935:17)
    at Function.Parser.parse (/node_modules/mversion/node_modules/cli-usage/node_modules/marked/lib/marked.js:922:17)
    at marked (node_modules/mversion/node_modules/cli-usage/node_modules/marked/lib/marked.js:1218:19)
    at fromFile (node_modules/mversion/node_modules/cli-usage/index.js:45:10)
    at get (node_modules/mversion/node_modules/cli-usage/index.js:30:12)
    at module.exports (node_modules/mversion/node_modules/cli-usage/index.js:22:15)
    at Object.<anonymous> (node_modules/mversion/bin/cli.js:9:1)
    at Module._compile (module.js:460:26)

✍️ Description

Affected versions allow an attacker to execute remote commands. The issue occurs because tagName user input is formatted inside the exec function in #L64 is executed without any checks.

🕵️‍♂️ Proof of Concept

// poc.js
// node poc.js

var mversion = require('mversion');

mversion.update({
       version: "major",
       commitMessage: "testing",
       tagName: "; touch hbkhan",
 })

💥 Impact

This issue may lead to remote code execution if a client of the library calls the vulnerable method with untrusted input.

ex. use agvtool and Apple Version System for ios project