Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add dependency-confusion protection: scope internal package names and pin the registry

Open
  • Is something wrong?
#282 1 comment 0 reactions 0 assignees View on GitHub

@rupesh-kumar-sah is already working on this.

Since Oct 9, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
32/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, nodejs, python, typescript
Domain
build-system, release, security

Research direction

Start with the package names in .github/workflows/build-check.yml, the name and url in the Python setup.py, and the name and private fields in package.json. Before changing anything, confirm with maintainers whether the unscoped PyPI name has ever been published, since renaming a published package is breaking. Done means a CI step fails when the generated name drifts, the setup.py URL points at the real repository, and "private": true is still set.

Written by the indexing model from the issue text.

Description

advanced security tooling

Problem

package.json is marked "private": true and "name": "alian-structure-api", but CI generates and publishes SDK artifacts under unscoped package names:

# .github/workflows/build-check.yml
name: "@alian-structure/api-client"     # TypeScript SDK (scoped)
name: "alian-structure-api"              # Python SDK setup.py (unscoped)

The Python SDK's setup.py publishes to PyPI as the unscoped alian-structure-api, with url="https://github.com/alian-structure/structure-api" — a URL that does not match the actual repository location.

The TypeScript SDK is correctly scoped, but nothing in the repository prevents an unscoped name from being introduced later, and nothing verifies that published package names match what is registered.

Why it matters

Unscoped public package names are a dependency-confusion risk. If an attacker (or an employee who loses access) publishes alian-structure-api to PyPI, installs that resolve by name will silently get the attacker's code — which for an SDK means it runs inside every consumer's application with access to their environment and credentials.

The URL mismatch compounds it: nobody can tell which repository the package legitimately originates from.

Suggested Direction

  1. Scope every publishable name. Prefer alian-structure-* or an org scope for both ecosystems. For Python, a package name and an import name can differ, so the import path can stay readable while the distribution is scoped.
  2. Reserve and verify the names. Document that the maintainers control both PyPI and npm names, and record where they are registered.
  3. Fix the repository URL in setup.py to the real location so consumers can verify provenance.
  4. Pin the source of truth in CI. Add a check that the generated package.json/setup.py name matches an expected value, failing the build on drift.
  5. Consider provenance attestation — npm and PyPI both support it, and it gives consumers a cryptographic statement about where the artefact came from.
  6. Add integrity pinning for install sources: .npmrc with a registry URL and, where practical, lockfile integrity verification (already in place via npm ci).

Constraints

  • Renaming a published package is breaking for existing consumers. Coordinate with maintainers and check whether the current names have been published at all — if they are new and unused, renaming now is cheap.
  • package.json has "private": true, so the root package cannot be published accidentally — that protection must be preserved.
  • Do not add publishing credentials to the repository; use CI secrets or npm provenance.
  • The Python SDK version is passed as ${{ github.ref_name }} in CI, which produces invalid PEP 440 versions for branch names like feature/x. That is a separate publishing bug worth flagging.

Acceptance Criteria

  • Every publishable artifact name is scoped and documented.
  • The Python SDK setup.py URL points at the real repository.
  • CI verifies the generated package name matches an expected value and fails on drift.
  • The root package.json retains "private": true.
  • Publishing credentials are not present in the repository.
  • Provenance/attestation is enabled or explicitly deferred with a reason.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.