feat: add a parameter `fetch_options`

[suzuki-shunsuke]

issue: https://github.com/guitarrapc/git-shallow-clone-orb/issues/12

[suzuki-shunsuke]

Oh, sorry. clone_options and fetch_options don't work as expected.

https://circleci.com/gh/suzuki-shunsuke/test-circleci/69

      - git-shallow-clone/checkout_shallow:
          clone_options: "--shallow-since '1 years ago'"

+ git clone --shallow-since ''"'"'1' years 'ago'"'" git@github.com:suzuki-shunsuke/test-circleci.git .
fatal: Too many arguments.

I'm investigating now.

[suzuki-shunsuke]

eval seems to be required.

$ docker run --rm -ti alpine:3.11.3 sh
/ # apk add git
/ # clone_opts="--shallow-since '60 days ago'"
/ # git clone $clone_opts https://github.com/guitarrapc/git-shallow-clone-orb
fatal: Too many arguments.

usage: git clone [<options>] [--] <repo> [<dir>]

    -v, --verbose         be more verbose
    -q, --quiet           be more quiet
    --progress            force progress reporting
    -n, --no-checkout     don't create a checkout
    --bare                create a bare repository
    --mirror              create a mirror repository (implies bare)
    -l, --local           to clone from a local repository
    --no-hardlinks        don't use local hardlinks, always copy
    -s, --shared          setup as shared repository
    --recursive ...       alias of --recurse-submodules
    --recurse-submodules[=<pathspec>]
                          initialize submodules in the clone
    -j, --jobs <n>        number of submodules cloned in parallel
    --template <template-directory>
                          directory from which templates will be used
    --reference <repo>    reference repository
    --reference-if-able <repo>
                          reference repository
    --dissociate          use --reference only while cloning
    -o, --origin <name>   use <name> instead of 'origin' to track upstream
    -b, --branch <branch>
                          checkout <branch> instead of the remote's HEAD
    -u, --upload-pack <path>
                          path to git-upload-pack on the remote
    --depth <depth>       create a shallow clone of that depth
    --shallow-since <time>
                          create a shallow clone since a specific time
    --shallow-exclude <revision>
                          deepen history of shallow clone, excluding rev
    --single-branch       clone only one branch, HEAD or --branch
    --no-tags             don't clone any tags, and make later fetches not to follow them
    --shallow-submodules  any cloned submodules will be shallow
    --separate-git-dir <gitdir>
                          separate git dir from working tree
    -c, --config <key=value>
                          set config inside the new repository
    --server-option <server-specific>
                          option to transmit
    -4, --ipv4            use IPv4 addresses only
    -6, --ipv6            use IPv6 addresses only
    --filter <args>       object filtering
    --remote-submodules   any cloned submodules will use their remote-tracking branch

/ # eval git clone $clone_opts https://github.com/guitarrapc/git-shallow-clone-orb
Cloning into 'git-shallow-clone-orb'...
remote: Enumerating objects: 96, done.
remote: Counting objects: 100% (96/96), done.
remote: Compressing objects: 100% (45/45), done.
remote: Total 96 (delta 41), reused 84 (delta 34), pack-reused 0
Unpacking objects: 100% (96/96), done.

[suzuki-shunsuke]

Hmm. But eval is danger in terms of security. For example, at the CI of pull request malicious command may be executed.

[guitarrapc]

yes, I always avoid eval as possible as I can.

[suzuki-shunsuke]

Sorry. I reconsider.

On CircleCI, malicious users can update source code and run any command in the CI of pull request even if we don't use eval.

So maybe there is no problem to use eval.

[guitarrapc]

let's split discussion

1. is malicious user can invoke CI?
2. is malicious user can invoke there user code?
3. is eval is the only thing security vulnerable?
4. can we ignore eval's potential risk?

---

is malicious user can invoke CI?

No, for default. fork PR is not permitted to run build on CircleCI by default. Yes when owner enable it, and circleci explain it is dangerous.

is malicious user can invoke there user code on ci?

no, for default. fork PR is not permitted to run build on CircleCI by default. Yes when owner enable it, and circleci explain it is dangerous.

is eval is the only thing security vulnerable?

no, if owner permit fork PR build on CI. malicious user can execute their own code without any permission. user can try to peek secret and post it to external.

can we ignore eval's potential risk?

if possible I must avoid it. I have responsibility to keep user safe as possible. however if user understand risk and accept it, tha't user's matter.

[guitarrapc]

I believe "99% of cases user accpect eval" is private repo and all commiter is safe. but orb can not restrict this usage and it's up to user.

this is quite risk to depend on user judgement.

[guitarrapc]

I've include this PR change to https://github.com/guitarrapc/git-shallow-clone-orb/pull/14 now command checkout_advanced can specify fetch_options too.

thank you for your contribution and let me close this PR.