[arch-dev-public] [aur-general] AUR migration

[Filipe Laíns]

On Mon, 2020-07-27 at 14:43 -1000, Gaetan Bisson via arch-dev-public wrote:
> [2020-07-27 21:10:23 -0300] Giancarlo Razzolini:
> > Em julho 27, 2020 21:03 Gaetan Bisson escreveu:
> > > It's quite unsettling that we seem to be rushing to write a news post
> > > while this very reasonable suggestion remains completely ignored.
> > > 
> > 
> > It wasn't ignored. They keys were deliberately changed in the process.
> 
> Why? Baptiste rightly points out "it's the same service as before and
> (presumably) the host private keys were not compromised, so there is no
> reason to change keys." Yet his message remains unanswered...

If one machine gets compromised the keys are also compromised. If we
can just use different keys on each machine to mitigate this, why
wouldn't we? I think the short term bothers of changing the key do not
warrant at all compromising security like this.
But your experience might be different, is there anything in specific
you are worried about or find annoying? I have been trying to figure
what would possibly justify this but I can't, please let me know.

Baptiste's answer was presumably under the assumption that the full
machine would be migrated, but he would have to confirm. On which case,
his request would be perfectly reasonable IMO.

> > I think the issue you refer to happened on the orion -> gemini migration and
> 
> You are correct.
> 
> > I personally think that everything that runs as a service on Arch servers should
> > be properly tracked on ansible, even if it's a user service.
> 
> That is certainly a worthy goal but it does not imply that we must kill
> everything that is not tracked by ansible at every migration. Copying
> home directories over to the new host used to be standard practice for
> any administrator of a system which serves multiple users...

None of this happened, when it did hapen in soyuz everyone got properly
notified and had plenty time to get their stuff out, on top of that,
the system was backed up in case someone forgot. I don't understand
what issue you are trying to get on here, Grazzolini already explained
this did not happen. I agree with what you said, no machine should be
killed without a proper handling of the user data, but what is the
issue right now?

Cheers,
Filipe Laíns
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20200728/94d7cd32/attachment.sig>