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

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

The issue mentions package.json, requirements.txt, pyproject.toml, .npmrc, pip.conf, and .pypirc, but names no repository files, tests, or entry points. Start by locating the existing scan and fix authentication flows across supported ecosystems; done means mixed public and private registries work securely, credentials are masked and temporary, and cleanup occurs on failure as well as success.