search

mvo5 / unattended-upgrades

Automatic installation of security upgrades on apt based systems
GNU General Public License v2.0
278 stars 78 forks source link

WIP: Introduce new config options for blacklisting by Origin #334

Open markkrj opened 2 years ago

markkrj commented 2 years ago

Fix #319

This allows users to blacklist origins (by pattern) instead of individual packages. This way, we would not need to change configurations for every package installed from a third party repo, and instead blacklist an entire repo.

I renamed and refactored some functions to better reflect what they do and avoid duplicating code and also because some functions had somewhat misleading/confusing names (as is_in_allowed_origin, which checked if a version is in allowed origins and ver_in_allowed_origin, which returns a version from a specified set of origin patterns). If renaming those are not acceptable, or might be breaking, I can revert the naming changes, as it might be merely cosmetic.

I did not added tests and docs yet, as I don't know if this approach would be acceptable.

rbalint commented 2 years ago

IMO this should be done by pinning instead and pinning already works reliably.

markkrj commented 2 years ago

Imagine we have a third party repo which we use for installing some (not just one) package, and manage updates from it manually. Currently, we would need to:

  1. Pin up every package coming from 3rd party repo and add the repository to allowed origins
    • This would cause u-u to update packages from 3rd party, which might not be desirable
  2. Pin down every package coming from 3rd party repo to <100 in official repos
    • This require extra work for every package we which to install from 3rd party.

From those options, only 2 would be acceptable, but then we would need to pin every package we install from 3rd parties, and hope to not forget anyone. With the option introduced by this PR, we could pin down an entire repo, from which we intend to manage updates manually.

rbalint commented 2 years ago

287 has a more generic proposed solution for this problem

markkrj commented 2 years ago

287 has a more generic proposed solution for this problem

How would we solve this problem with APT config?

rbalint commented 2 years ago

287 has a more generic proposed solution for this problem

How would we solve this problem with APT config?

Unattended-upgrades could use additional APT preferences, too, where users could set u-u-specific pinning.

markkrj commented 2 years ago

287 has a more generic proposed solution for this problem

How would we solve this problem with APT config?

Unattended-upgrades could use additional APT preferences, too, where users could set u-u-specific pinning.

If the implementation of that proposal respects pinning for disallowed repositories, then yes...