Hi all,
I currently have a MR open against archlinux-keyring [1], that adds a
systemd service and timer, which would automatically refresh valid and
existing keys on user systems. For people without access to the
repository's ticket and merge request features, it is possible to browse
the commits
On 23.07.2022 18.38, David Runge wrote:
Hi all,
I currently have a MR open against archlinux-keyring [1], that adds a
systemd service and timer, which would automatically refresh valid and
existing keys on user systems. For people without access to the
repository's ticket and merge request fea
On Sat, 23 Jul 2022 at 19:39, David Runge wrote:
> Packages that are signed with a key that still had marginal trust in
> release A (and therefore already existed on the user system since
> release A) and gained full trust in release B will not be updated before
> the user does a system upgrade. T
On 2022-07-23 21:24:38 (+0200), Kristian Klausen wrote:
> The load aspect should be solvable, worst-case DevOps gets annoyed ;)
>
> My main concern is putting ourselves in a position, where we know
> every arch installation, yes it is just the IP addresses, but still.
> At the same time it becomes
On 2022-07-23 23:49:09 (+0300), Evangelos Foutras wrote:
> This is solvable by not cutting a release with marginally trusted
> keys. Having all Arch Linux installations make 100-ish requests daily
> to cover such an edge case is a misutilization of resources (on both
> sides).
Refreshing existing
On 24/7/22 06:49, Evangelos Foutras wrote:
On Sat, 23 Jul 2022 at 19:39, David Runge wrote:
Packages that are signed with a key that still had marginal trust in
release A (and therefore already existed on the user system since
release A) and gained full trust in release B will not be updated be
