microsoft / microsoft/winget-pkgs

Using the original publisher's name in the identifier for a custom build shoud be forbidden unless it is admitted

Open
#180,229 2 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Area-Validation-Pipeline Issue-Feature
Dominant language
No language data
Stars
11.1k
Forks
9.7k
Avg merge
1h 32m
Merged PRs (30d)
376

Description

It's normal for people to make and release custom builds for the projects that didn't provide any pre-built binary or pre-built Windows binary (i.e., only the source code or ELF binaries are provided, which is common in Linux-based projects). However, these customs builds should not use the original author's name in the package identifiers if they haven't been admitted by the author like being listed in the project website or README. Otherwise there might be some security concerns.

This came into my attention when I was handling the package AdrianThurston.Ragel (added in #153218), which is actually the PolarGoose's custom build of Adrian's Ragel, while I couldn't find any places where the author mentioned this build. I'm not suspecting PolarGoose, but moderates should pay attention to such issues.

Contributor guide

Open the contributing guide

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.

Research direction

Review the AdrianThurston.Ragel package mentioned in the issue and compare it with the context from issue #153218. Determine where package identifiers and publisher admission are governed, then define the policy or workflow change needed to prevent unadmitted custom builds from using an original author's name. Done means the rule and its enforcement path are explicitly specified.

Written by the indexing model from the issue text.

Assessment

Domain
cli, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.