Fix npmnpmrcproject fixture: scope legacy auth keys to the registry

[agrasth]

Summary

• npm 12 hard-rejects the bare email and _auth npmrc auth config keys with ERR_INVALID_AUTH, which was failing TestNpmNativeSyntax/npm_i_with_npmrc_project (and the equivalent legacy-syntax test) for every npm 12.x version in our pm-version-monitor compatibility tracking — the very first npm install call in the test errored out before jfrog-cli's own npm command logic ever ran.
• This is a test-fixture staleness issue, not a jfrog-cli npm command bug: testdata/npm/npmnpmrcproject/.npmrc still used the pre-npm-12 unscoped auth key format.
• Scope both keys to the registry host, matching the format the fixture's existing _authToken line already uses (and exactly what npm's own error message names as the fix).

Test plan

• Verified locally: npm install --dry-run against the original fixture with npm 12.0.0 reproduces ERR_INVALID_AUTH: Invalid auth configuration found: 'email' must be renamed to '//<registry>/:email' in project config
• Verified the fixed fixture passes config validation with npm 12.0.0 (fails only on ENOTFOUND for the fixture's placeholder NO-NO-REPO host, which is expected — the real test redirects to a live Artifactory instance)
• go vet ./... and gofmt — no changes needed, fixture-only diff

[github-actions]

View full scan results in JFrog Platform

📗 Scan Summary

• Frogbot scanned for vulnerabilities and found 1 issues

Scan Category	Status	Security Issues
Software Composition Analysis	✅ Done	Not Found
Contextual Analysis	✅ Done	-
Static Application Security Testing (SAST)	✅ Done	1 Issues Found 1 High
Secrets	✅ Done	Not Found
Infrastructure as Code (IaC)	✅ Done	Not Found

---

🐸 JFrog Frogbot

[github-actions]

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
High	TLS settings are configured insecurely, exposing communications to risks

Full description

Vulnerability Details

Rule ID:	go-insecure-tls

Overview

Insecure TLS Configuration is a type of vulnerability that occurs when an
application uses weak or outdated cryptographic protocols, ciphers, or
configurations for secure communication over the network.

Vulnerable example

package main

import (
    "crypto/tls"
)

func main() {}

func insecureMinMaxTlsVersion() {
    {
        config := &tls.Config{}
        config.MinVersion = 0
    }
    {
        config := &tls.Config{}
        config.MinVersion = tls.VersionSSL30
    }
    {
        config := &tls.Config{}
        config.MaxVersion = tls.VersionSSL30
    }
    {
        config := &tls.Config{}
    }
}

func insecureCipherSuites() {
    config := &tls.Config{
        CipherSuites: []uint16{
            tls.TLS_RSA_WITH_RC4_128_SHA,
        },
    }
    _ = config
}

In this example, the MinVersion field is set to tls.VersionSSL30, which
uses the outdated SSL 3.0 protocol, making the application vulnerable to
attacks such as POODLE.

Remediation

package main

import (
    "crypto/tls"
)

func main() {}

func insecureMinMaxTlsVersion() {
    {
        config := &tls.Config{}
-       config.MinVersion = 0
+       config.MinVersion = tls.VersionTLS12
    }
    {
        config := &tls.Config{}
-       config.MinVersion = tls.VersionSSL30
+       config.MinVersion = tls.VersionTLS12
    }
    {
        config := &tls.Config{}
-       config.MaxVersion = tls.VersionSSL30
    }
    {
-       config := &tls.Config{}
+       config := &tls.Config{MinVersion: tls.VersionTLS12}
    }
}

func insecureCipherSuites() {
    config := &tls.Config{
        CipherSuites: []uint16{
-           tls.TLS_RSA_WITH_RC4_128_SHA,
+           tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
        },
+       MinVersion: tls.VersionTLS12,
    }
    _ = config
}

By using safe TLS versions (e.g., tls.VersionTLS12) and secure cipher suites we can
mitigate the risk of insecure TLS configurations and improve the security of the
application.

---

🐸 JFrog Frogbot