Repositories, bad style: unmasking their own content

[Massimo B.]

In the past we have seen repositories with a very treacherous and hardly visible style, they unmask their own content. And even worse, they unmask all content also from other repositories.

https://bugs.gentoo.org/624864
https://bugs.gentoo.org/624936
https://github.com/gentoo-mirror/stefantalpalaru/blob/master/profiles/package.unmask

By default I add a */* mask for each repo I add in order to only explicitly unmask single parts of a repo, which in my opinion should be the default when adding repos:

[Ralphred]

[Massimo B.]

My package.mask does exactly that: If an ebuild needs something else from the repo then I get informed and need to unmask that too.
Think about the other situation, you only want a package foobar, but the repo also includes some unstable very new version of a system package, then it would just replace it just by having the repo enabled. That's the reason I started masking all from every repo eventhough it requires some more work to unmask the parts I want to have from the repo.

For the main issue of this thread, that some repo's unmask overrules my own mask, I need to add that this makes it quite easy to infiltrate and hijack a Gentoo installation just by adding a bad repo. Sure, adding repos is on my own responsibility, but repos especially when listed in the eselect repository list should aim for a minimal quality, which made some repos being blocked from the list in the past.

This thread should not be about which repos to be blocked and why. I wonder if Portage should allow overlays applying such a style and if the order of priority of portage configurations is right here (repository overruling /etc/portage/package.mask).
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770

[szatox]

I'd say a repository should only be able to mask its own ebuilds and not able to unmask anything at all.
There are already other mechanisms in place that apply soft masks (keywords, licenses, etc). If a sysadmin puts a hard mask in place, it should be treated like he means it.
That's the technical part.

However... Using a provided repository implies you trust whomever provided it. If you think there is something shady going on, perhaps you should drop it and purge any remnants from your system.
This is the social part of the problem
_________________
Make Computing Fun Again

[logrusx]

[Hu]

I would like a more intricate mechanism, which is not directly represented in the poll options. I propose that a repository's package.unmask can override entries in that repository's package.mask, but that the repository's package.unmask cannot override entries in the administrator's package.mask. Thus, the decision tree would be:

• Is it unmasked in /etc/portage/package.unmask? If yes, stop. The package is not masked. This makes the local administrator the ultimate authority on unmasking.
  
• Is the package masked in /etc/portage/package.mask? If yes, stop. The package is masked. This makes the local administrator the ultimate authority on masking, because only a local unmask can supersede the administrator's local mask. If the administrator wants something masked, he is obliged not to turn around and locally unmask it.
  
• Is it unmasked in any of the applicable package.unmask files from the repository? If yes, stop. The package is unmasked.
  
• Is it masked in any of the repository's package.mask files? If yes, stop. The package is masked.
  
• Finally, having found no mask or unmask entries, stop. The package is implicitly not masked.

[Massimo B.]

Please add youself on Cc for https://bugs.gentoo.org/624936 to show your interest. Voting isn't enabled on bgo?
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770