lockfile-lint: How to add exception to allow e.g. `git+ssh://git@gitlab.foo.bar`

Addressed in https://github.com/lirantal/lockfile-lint/pull/52

I would like to see --alowed-uri-prefix or --allowed-uri-pattern option, as it would allow to for example whitelist packages hosted in private repos, e.g.:

--allowed-uri-prefix git+ssh://github.com/ixti/*.git
--allowed-uri-prefix git+ssh://github.com/ixti/{foo,bar,baz}.git

@lirantal Sure. Added my 2 cents to #39.

@ixti can you jmp over to https://github.com/lirantal/lockfile-lint/issues/39 to discuss? I’m wondering if just changing the current behavior of --allowed-hosts will be enough to cover this.

Alrighty, let’s leave out allowed-uri for now as I think we have a plan around allowed schemes and allowed hosts updates and that should work well for now. We can work out allowed uri in future PR.

Regarding your question about a practical example, here are a couple:

npm’s package-lock.json:

    "foo-bar-project": {
      "version": "git+ssh://git@bat.baz:some-git-repo-user-group/foo-bar-project.git#6910d82b0ba139fc4d9a9c92306a21abdc0e508c",
      "from": "git+ssh://git@bat.baz:some-git-repo-user-group/foo-bar-project.git",
      "requires": {
        "@babel/runtime": "^7.5.5",
        "source-map-support": "^0.5.13",
        "ts-log-debug": "^5.1.0"
      }
    },

yarn’s yarn.lock:

"foo-bar@git+ssh://git@bat.baz:some-git-repo-user-group/foo-bar.git":
  version "0.1.0"
  resolved "git+ssh://git@bat.baz:some-git-repo-user-group/foo-bar.git#48e839c2fd5fad2b08dc2c0c64671aea5533ad4f"
  dependencies:
    "@babel/runtime" "^7.5.5"
    source-map-support "^0.5.13"
    ts-log-debug "^5.1.0"

On the scheme/protocol - I think either would be fine; perhaps per https://tools.ietf.org/html/rfc7320 , scheme is more precise. Very minor topic though.

I agree on authority and fragment perhaps only being useful for git+ssh, but thought to suggest that since, in the future, other schemes might arise, so this would be flexible to adapt. Just a suggestion; this can be made to work many different ways.

As a really simple way to offer the flexibility we’re looking for here in terms of letting developers use this tool even on projects that have, for example, dep’s on github.com projects, perhaps the commandline option could support something like, --allowed-uri and then the user just supplies the complete uri (inclusive of course to any url). So that way, only one single, dead-simple parameter would need to be added to lockfile-lint.

I have actually aligned with the syntax used by Node.js’s URL API: https://nodejs.org/api/url.html#url_url_protocol - though perhaps worth to use the universal language for it instead of the object keys.

Indeed not sure how authority and fragment will only be relevant for specific schemes so I’m not 100% on those. Agree with --validate-https staying as-is.

I actually had to make a change though, since right now we’re validating the --allowed-hosts as complete origins, meaning npm validates https://registry.npmjs.org - so the scheme is derived from it however I’m going to change that so that it matches the host only.

so I’m thinking you could whitelist such URLs in this way:

If you only want to lint based on the hostname:

lockfile-lint --type yarn --path yarn.lock --allowed-hosts yarn github.com

notice that with the change I’m thinking about, --allowed-hosts yarn github.com will only match the actual hosts such as: registry.npmjs.org and github.com. To also enforce HTTPS now you’ll need to explicitly opt-in to it

If you want to lint based on the hostname and enable https

lockfile-lint --type yarn --path yarn.lock --allowed-protocols "https:" "git+ssh" --allowed-hosts yarn github.com

WDYT?

That’s a good point. What would be the use-case we’d want to support? a specific one-off complete URL as a source? such as something like git+ssh://lirantal@github.com/lirantal/lockfile-lint.git#1234567890 or would you want to only match the protocol git+ssh?