Modularize trust system

[rossmeier]

Hi,

I would like to be able to manually review changes to packages, using a (Telegram/Slack/Whatever)Bot or a Webinterface with E-Mail notifications. To be able to do this: I propose the following trust system:
To determine if an update is trusted, a list of modules will be provided in the config. Then when an update is available, every trust module is executed with some metadata and the repo diff as arguments. Every module can return three values: "Trust", "Don't Trust", "Can't decide" and "WaitOnCallback". "Can't decide" will cause the next module in the list to be called. User prompts should be allowed to modules when a special argument is given. "WaitOnCallback" means that the module can't currently decide and will present it's decision in the future.

Example list of modules:

• Trivialdiff: Accept any diff where only the package version and the hashes change
• Maintainer: Accept any package by a trusted maintainer. This would be the only configured module by default, since it reflects the current behaviour. With the interactive flag set, this module can ask the user whether the maintainer should be trusted
• Ask user: Ask the user via some kind of Notification system.

[alexheretic]

Interesting idea, thanks for raising this.

One general issue is that aurto is designed for unattended/automatic building. In use you don't directly interact with it, so when trust fails currently the packages are simply evicted from the aurto repo and you can see them with pacman -Qm and maybe re-add them etc.

Just thinking about that it would be cool to have more clarity/notifications when that happens. But user prompts are not really something aurto is equipped to do.

[rossmeier]

If trust fails, of course there needs to be a notification. But for both trust failure and temporary failure, I would not remove the current package from the repo, but just not build the update. Adding a new package should almost always be done with user supervision anyway.

[alexheretic]

If trust fails, of course there needs to be a notification. But for both trust failure and temporary failure, I would not remove the current package from the repo, but just not build the update.

aurto removes them from the repo sort of as the way of notifying (you can run pacman -Qm / look at logs). But I think better & configurable notifications would be great to have.

Removing works fairly well as otherwise it would be more difficult to get aurutils to avoid rebuilding them & of course the packages do stay installed on actual systems they just need maintenance before becoming automatically updated in the aurto repo again.

Adding a new package should almost always be done with user supervision anyway.

Yep when you add packages is when you currently interact with the trust system, ie add trusted maintainers.

So I see some separate items from this:

• Add new configurable trust mechanisms (currently we can do maintainer-trust or trust-everyone).

• Add new ways for the aurto jobs to notify (particularly for when packages are evicted due to trust failure).

  I'm not sure the best way to do this avoiding specific integration with email/im services etc. Maybe there's a nice abstraction we can use that already exists, or we could just write notification to a file and end-users can sort out the pipe into their notification sink of choice?