Feature Request: Remember keyring per mirror

[Zocker1999NET]

While currently you can use -keyring to enforce using given keyring, if I want to use a different keyring per mirror, I am required to always remember (or lookup) the correct keyring for the correct mirror. So I propose to add support for storing & using the keyring value beside other values for each mirror if given while creating the mirror. This would easily allow one to mirror multiple repositories signed with different keys without allowing all keys in a global keyring to sign all repositories accessed.

Context

I would use this to merge multiple public repositories of proprietary software (e.g. VS Code, Slack, …) into a single one for my devices. With using -filter and -keyring, I want to ensure that e.g. Microsoft can only "publish" VS Code while Slack can only "publish" Slack into my repository. While -filter is remembered in the database, -keyring is not and so I need to always pass the path to the correct keyring for the mirror.

Enforcing different keyrings on different remote repositories increases security as:

• if any key used by any repository gets hacked, you could only "attack aptly users" by also uploading the files to the same web server and not to any remote repository used. If an aptly installation would be used for multiple purposes, this will lower the impact of such attack.
• if a key gets hacked and users get notified, they might remove the mirror but not remove the key from the keyring. Then they would still be vulnerable to attacks using the hacked private key.
• if used together with -filter, it is ensured that after merging packages from multiple mirrors that afterwards package A was released by key owner A and package B by key owner B. If a common key ring is used, key owner A would be able to upload a modified package B to repo B signed by his key.

Even if some attack scenarios might be unrealistic, implementing a better support for one keyring per mirror should be quite easy if possible like I propose below. So allowing such attack vectors seems unnecessary to me.

Possible Implementation

If -keyring option (or a new option) was given during mirror create, store the path to the keyring beside the archive URL and always enforce using this keyring while updating the mirror.