On 2022-07-24 12:23:29 (+1000), Allan McRae wrote:
> Not shipping keys that are marginally trusted is ideal in principle...
> However we have seen it many times recently as main/master keys were
> cycled. Hopefully this is less of an issue moving forward. This is
> why the keyring was set up to ha
On Sat, 2022-07-23 at 18:38 +0200, 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
On 2022-07-25 09:23:53 (+0100), Leonidas Spyropoulos wrote:
> I'm aligning probably against such systemd unit. Mainly because or
> privacy issues and given the options users will probably set something
> like refresh every 1 hour and then we need to go into rate-limiting
> just to keep our gitlab u
On 2022-07-24 21:56:28 (+0200), Johannes Löthberg wrote:
> I'm fine with it existing, and I would be fine with it being enabled
> in a vendor preset, but I'm against it being statically enabled in
> /usr. This is not something that's critical for the regular
> functioning of the system, and so is
On 2022-07-24 10:53:24 (-0700), Brett Cornwall wrote:
> Just wanna point out that just because we already do something it
> doesn't validate doing a similar thing. :)
No. That was not the point I was trying to make. :)
It serves as a good example as to why such a thing does not have to be a
privac
On 24/07/2022 20:56, Johannes Löthberg wrote:
Excerpts from David Runge's message of July 23, 2022 18:38:
Currently the timer which triggers this service is supposed to be vendor
enabled (i.e. symlink in /usr/lib/systemd/system/timers.target.wants/)
and run daily with a deviation of up to 12h.
M
Excerpts from David Runge's message of July 23, 2022 18:38:
Currently the timer which triggers this service is supposed to be vendor
enabled (i.e. symlink in /usr/lib/systemd/system/timers.target.wants/)
and run daily with a deviation of up to 12h.
Members of the DevOps team have raised concerns
On 2022-07-23 23:30, David Runge wrote:
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 s
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
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 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 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 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
13 matches
Mail list logo
