Feature Request: Support Mixed Public and Private Registries with Secure Authentication

[Richard-Barrett]

Feature Request: Support Mixed Public and Private Registries with Secure Authentication

Problem

Frogbot currently does not support projects that consume dependencies from multiple package registries (for example, a private Artifactory registry alongside public open-source registries).

In real-world projects, it is common to:

• Pull internal packages from a private Artifactory registry
• Pull open-source packages from public registries (npmjs, PyPI, etc.)
• Reference both within the same dependency manifest (package.json, requirements.txt, pyproject.toml, etc.)

Today, there is no supported way to provide Frogbot with multiple registry authentication contexts for a single scan or fix run.

---

Impact / User Pain

• Frogbot fails to resolve or update dependencies when private packages require authentication.
• Users must create custom CI workflows per package manager (npm, pip, poetry, etc.) to manually inject credentials.
• This undermines Frogbot’s goal of being a reusable, language-agnostic fix bot.
• Manual credential handling increases the risk of:
  • secret leakage
  • credentials being left behind on disk
  • inconsistent security practices across repositories

---

Expected Behavior

Frogbot should support mixed registry authentication in a single scan or fix run, such that:

• Public dependencies can be resolved from public registries
• Private dependencies can be resolved from private Artifactory registries
• Authentication is provided securely and temporarily, without requiring custom workflows per ecosystem

---

Proposed Capabilities (Non-Prescriptive)

Frogbot should provide a mechanism to:

• Accept registry authentication inputs for supported ecosystems (e.g. npm, Python, Maven, etc.)
• Materialize temporary authentication or configuration files during execution, such as:
  • .npmrc
  • pip.conf / .pypirc
  • other tool-specific authentication files
• Scope credentials strictly to the Frogbot execution lifecycle
• Ensure all generated authentication artifacts are:
  • removed after execution, or
  • isolated in ephemeral execution environments

---

Security Requirements

• Secrets must never be committed to the repository
• Secrets must not persist beyond the Frogbot execution lifecycle
• Credentials must be masked in logs
• Cleanup must occur even if the scan or fix process fails

---

Why This Matters

Without first-class support for mixed registry authentication:

• Frogbot cannot be reliably adopted in enterprise environments
• Users must maintain fragile, duplicated CI logic
• The value of Frogbot as a “drop-in” fix automation tool is significantly reduced

Supporting this capability would:

• Align Frogbot with real-world dependency management practices
• Reduce operational complexity for users
• Improve security posture by centralizing and standardizing credential handling

---

Example Scenario

A repository uses:

• Private packages hosted in Artifactory
• Public open-source packages from npmjs.org or PyPI

Frogbot should be able to:

• Authenticate to Artifactory for private packages
• Fall back to public registries for open-source packages
• Update dependencies without requiring a committed .npmrc, .pypirc, or equivalent file