Skip to content

bc: source_provenance mislabeled GnuProject — it's gavinhoward/bc (v7.x), not GNU bc #237

@bryan-minimal

Description

@bryan-minimal

Found during a fleet-wide source_provenance audit (spun out of the license enrichment in #236).

packages/bc/build.ncl declares:

source_provenance = { category = 'GnuProject, gnu_name = "bc" }

…but the pinned version is 7.0.3, and GNU bc tops out at 1.07.1. Version 7.x is Gavin Howard's bc (the 7.0.3 tag exists there). It's a different upstream that just shares the name bc.

Why it matters

source_provenance drives both vuln-advisory matching and the upstream version-check:

  • Vuln scanning matches against GNU bc's namespace → it would miss any gavinhoward/bc advisory and could false-match GNU bc ones. (False-negatives are the dangerous direction.)
  • Version-check queries GNU FTP → sees 1.07 → the check is meaningless for this package.

Suggested fix

source_provenance = {
  category = 'GithubRepo,
  owner = "gavinhoward",
  repo = "bc",
}

Strictly better on both axes. (The license_spdx was already corrected to BSD-2-Clause in #236 for the same root cause — it's Gavin Howard's BSD-2 bc, not GNU's GPL bc.)

For review

Package created by @twitchyliquid64; the GnuProject provenance came from @jakeyrg's bulk source_provenance pass (859ee45). Flagging for a sanity-check before changing — the name-based guess (bc → GNU) is completely understandable, and y'all know the intent. Filing as an issue rather than a direct PR per that request.

Audit covered all 339 packages; only bc and chromium-bin/-headless came up. gettext@1.0, mpc@1.4.0, openssh, tcl were false alarms (verified correct — GNU gettext really did jump to 1.0, etc.).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions