EarTrumpet manifest incorrectly modified without our knowledge

[riverar]

While preparing for an update to our EarTrumpet manifest, I discovered our manifest had been incorrectly altered (#5759) and signed off by @KevinLaMS without any involvement on our part. This resulted in the distribution of ⚠ development binaries to all our winget users between December 29, 2020 and February 17, 2021.

Some questions:

• How do we identify affected users?
• How many times was EarTrumpet downloaded in this period?
• Can you clarify policy regarding manifest ownership, manifest updates, and describe how external contributions are vetted/approved?

cc: @aclinick

New PR: #7533

[jedieaston]

I don't know if this helps, but as far as I can tell, winget doesn't record analytics about what packages were installed or when (or if it does, it doesn't send them back to the mothership). The only way to know how many users were affected is to look and see how many times the file was requested on your server.

Manifests are owned by the community, and updated by whoever wants to do it, much like Wikipedia or something. There isn't a way (yet, see #5833 ) for a vendor to automatically provide manifests outside of opening their own PRs (which some groups, like the VSCode team, have elected to do). Manifests aren't locked either, so if a community member updates it before the vendor, it'll be merged.

When a PR is opened, the manifest is validated (things like formatting, SHA256 hash, etc.) and the linked installer runs through static analysis. Then someone with rights (in this case @KevinLaMS) runs the manifest in a virtual machine to ensure it installs and isn't a virus. Then it is merged into master.

The best way to get around this problem for the time being would probably be to block access to your dev installer server from everyone on the web, if you don't want them using the installers. Otherwise, once the channel support for winget comes out (#147), a dev channel and a release/stable channel can exist in the manifests to allow you to have the users select which build they want. (I concur that there needs to be a process for blacklisting certain domains/url paths from providing applications in the community repo, maybe via the bot, but this doesn't exist yet unfortunately).

[riverar]

Manifests are owned by the community, and updated by whoever wants to do it, much like Wikipedia or something. There isn't a way (yet, see microsoft/winget-pkgs#5833 ) for a vendor to automatically provide manifests outside of opening their own PRs (which some groups, like the VSCode team, have elected to do). Manifests aren't locked either, so if a community member updates it before the vendor, it'll be merged.

I don't quite agree. I crafted the manifest and submitted it to the repository. I legally own the manifest and retain its copyright. Microsoft has licensed this file from me by way of the CLA to distribute it, edit it, etc. But that's just the small stuff.

By submitting a manifest to the repository, it was my understanding that I—not others—would be the immediate maintainer [1][2] of the package described, similar to how other package repositories function (e.g. Fedora, Nuget, Chocolatey, etc.). (Of course, repository maintainers exist higher in the hierarchy, should a package maintainer not be available or emergency action is needed.)

[1] https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages?rd=Extras/Policy/WhoIsAllowedToModifyWhichPackages
[2] https://en.opensuse.org/openSUSE:Package_maintainership_guide#Package_maintainer

I recognize this may not be how the winget community repository is managed, hence the need for additional policy and guidance documentation.

The best way to get around this problem for the time being would probably be to block access to your dev installer server from everyone on the web, if you don't want them using the installers. [...]

We expose dev builds to users to support a number of activities, such as debugging. Blocking access to those resources doesn't solve any problems as the installation URL could have easily pointed to a resource elsewhere.

[denelon]

We are designing a feature to allow entities to "own" a manifest. #100

[denelon]

@riverar does it look like #100 would address your concern here?

[riverar]

@denelon Yep, looks like it'll work for our needs. Are there any updates to the proposal? It's pretty old.

[denelon]

@riverar We're going to take a deeper dive over the next few weeks. I'll share progress/changes when we're about to start working on it. I'm sure there will be some questions, and we're happy to hear any feedback. I'll ping back here so we can get EarTrumpet locked down.

[pbrandstetter]

@riverar I am sorry for the troubles you have now.
It was/is currently not clear who "owns" a manifest and since this is opensource ppl contribute and try to keep the system up to date.
I created #5759 because the manifest you provided did not work anymore. #5757 requested the problem and I tried to solve it (since nobody else did). In my opinion, if an "owner" of a manifest changes the update url she also has to change the manifests with the old urls.
Sorry again, hopefully we can do better next time.

[Samuel12321]

@pbrandstetter @denelon
Hi, I'm one of the developers for ModernFlyouts, while preparing to release an updated manifest for 0.9.1, happened to notice commit c0a5274 and discovered that someone altered the link to the home page to a website that is not ours. (Redirecting users to a 3rd part site not affiliated to ModernFlyouts)
I hope this issue is taken seriously and some solution can be found to prevent this.

@riverar sorry for hijacking this this issue but i thought they both stemmed from the same issue.

[riverar]

@Samuel12321 How dare you! Kidding. Microsoft's proposal is promising, do check that out.

@pbrandstetter Appreciate you reaching out, sounds like we're on the right path now.

[pbrandstetter]

@riverar Thank you for your answer. I will be more carefully next time. Hope msft will find a solution for manifests with owners so such problems won't occur again.

[denelon]

@pbrandstetter have you already updated the manifest to point to the proper site? The feature to specify owners for packages should help prevent others from making changes to manifests in the future.

[pbrandstetter]

@denelon riverar already submitted #7533 with the most current version. This pr also points to the correct address.

[riverar]

The proposal is almost a year old now, are there any updates? Is it going to be executed on? Timeline?

[denelon]

It's next up for one of our engineers. After we review the plan and adjust, they will get assigned and we'll update the specification. It's going to be the first of several features that we would like to link to publicly visible meta-data. Part of the solution will involve how we can properly identify package owners. I'd like to get the initial implementation done this month if possible.

[denelon]

@riverar is your GitHub alias the only one you want approved to submit PRs for https://github.com/microsoft/winget-pkgs/tree/master/manifests/f/File-New-Project/EarTrumpet/2.1.8.0?

Would you like this restricted to the package manifests/f/File-New-Project/EarTrumpet/*

-or-

Would you like this to apply for any package published by manifests/f/File-New-Project/*

[denelon]

We still have the "business process" work to build out for identifying the proper owners for a package, and therefore the manifests. As that work completes, we will share the results with the community.

[riverar]

@denelon Would prefer to take over the whole org (option 2) but both options look good.

[denelon]

@riverar we've completed the technical implementation. We're working on the business process portion of the verified developer feature. Can you send me an e-mail so I can get permission to use EarTrumpet as a first implementation?

[riverar]

@denelon Will do.

[vedantmgoyal9]

Any updates on this?

[o-l-a-v]

Any updates on this?

#100

[denelon]

We're still working through the appropriate business process for validating ownership of packages. It involves several different teams and there are several open concerns regarding ownership disputes and correlating packages with owners and their GitHub aliases. We're very close to testing this with some Microsoft packages. Initially, I'm expecting the .NET team to take ownership of their packages. I hope this will pave the way forward quickly.

[riverar]

Any movement on this?