Pkg.jl: `]add $PACKAGE_NAME#remotes/cache/pull/$NUM/head` works; a feature or a security hole?

[tkf]

I noticed that ]add $PACKAGE_NAME#remotes/cache/pull/$NUM/head installs a not-yet-merged PR from GitHub where $PACKAGE_NAME is a name of a registered package and $NUM is the PR ID. I used it sometimes when recommending people to use a PR. Although it's handy for letting users try things out in the PR, it gives a wrong impression that this installs code from the official repository $PACKAGE_NAME. But the truth is that it can be any code since anyone can send a PR. I think in the end users have to know what the command they use does, but I wonder if Pkg.jl wants to avoid random git ref to be specified.

[staticfloat]

I think it's in general impossible to know what a git ref "means". The fact that a branch named remotes/cache/pull/<num>/head exists within the remote repository is just an implementation detail of GitHub; on GitLab this may not work or it may be available as pull_requests/by_issue_num/<num>, etc... I don't think Pkg can really do anything about this, because it is also completely valid for you as a user to have a git repository with a branch name that actually is remotes/cache/pull/99999/head. As an example, I just did that right here.

So it's impossible to know if this is "unsafe" code or an actually desirable branch name from Pkg's perspective, and even if we did try to "block" things matching this pattern, GitHub may change their internal representation eventually.

[tkf]

I was thinking to prepend refs/remotes/origin/ to the branch supplied by the user. Assuming that libgit2 has git-rev-parse-like behavior, wouldn't this (more or less) ensure that it is the branch name of the origin? But I just noticed that ]add claims to support specifying the commit hash. So Pkg would have to fallback to treat the given #name as the commit hash to support it.

[staticfloat]

I just tried to reproduce this and I couldn't. How are you seeing this behavior?

[tkf]

Here is a quick oneliner to see it:

HOME="$(mktemp -d --suffix "-julia")" julia -i --color=yes --startup-file=no -e 'using Pkg; pkg"add PyCall#remotes/cache/pull/556/head"'

It seems that it works outside my laptop: https://github.com/JuliaPy/PyCall.jl/issues/565#issuecomment-422320792

[KristofferC]

I would say this is a feature.

[StefanKarpinski]

There's no such thing as client-side security.