gitlab-skill

This skill appears to do what it claims, but review these risks before installing or running it with real tokens: - Token leakage risk: clone_repo inserts the access token into HTTPS clone URLs (https://oauth2:TOKEN@...), which can expose your token in process listings and may end up stored in .git/config for the cloned repo. Avoid using this behavior or remove tokens from git remotes after cloning; prefer SSH keys or credential helpers. - TLS bypass: several code paths create an unverified SSL context (ssl._create_unverified_context()) or use curl -k when insecure is requested. Confirm when/why TLS verification is disabled; do not use these options in production or against public GitLab instances. - Process & logging exposure: the scripts call subprocesses (curl, git) and build command-line headers that may expose tokens to other local users via process arguments. Run in a trusted environment and avoid shared/multi-user hosts if using real tokens. - Metadata mismatch: the registry metadata lists no required env vars but the skill expects GITLAB_HOST and GITLAB_TOKEN at runtime — ensure your deployment environment supplies these securely. - Saving credentials: the credential loader can save tokens to ~/.claude/gitlab_config.json (it sets 600 permissions). Only allow saving on machines you control, and rotate tokens if exposed. Recommendations: inspect/modify the clone behavior to avoid embedding tokens, ensure TLS verification is enabled by default, run the scripts in an isolated environment for initial testing, give tokens minimal scopes, and rotate tokens after first use. If you need further assurance, request a full audit of the specific functions that disable TLS and modify clone URL handling.