Re: [arch-dev-public] [aur-general] AUR migration
On 27-07-20, Giancarlo Razzolini via aur-general wrote: > 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. Ok, thanks, now I know it was intended and not just an oversight. The root issue is of course the host / service confusion, but there's not much that can be done about it if everything runs on port 22. From a user perspective, it's the same service running under the same name (aur.archlinux.org), so it should keep using the same key after the migration. From an sysadmin perspective, these are two different hosts, so they should use different keys. When thinking service first, it's not a problem to have the same key on multiple machines. Think about github.com or gitlab.com: they must have tens of machines with the same host key. If a single one is compromised, they lose the key, but all machines likely have the same attack surface anyway. Anyway, in the end, it's not surprising you chose the sysadmin perspective, and the old/new servers don't seem to have the same attack surface. Baptiste PS: I didn't know about UpdateHostKeys and it looks really useful, thanks for pointing it out! signature.asc Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
On 7/28/20 4:13 PM, Gaetan Bisson via arch-dev-public wrote: > [2020-07-28 13:46:23 +0100] Filipe Laíns: >> If one machine gets compromised the keys are also compromised. > > I never suggested to use the same keys for multiple servers. > > Only that if luna's main purpose is to provide a service and this > service is moved to a different host, it makes sense to move the SSH > host keys too, and to generate new keys for luna. Again, those keys are still used for ssh://git.archlinux.org -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [aur-general] AUR migration
[2020-07-28 13:46:23 +0100] Filipe Laíns: > If one machine gets compromised the keys are also compromised. I never suggested to use the same keys for multiple servers. Only that if luna's main purpose is to provide a service and this service is moved to a different host, it makes sense to move the SSH host keys too, and to generate new keys for luna. > 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 wanted to point out that I consider copying user home directories over to a new host an important part of any migration. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Use detached package signatures by default
Em julho 28, 2020 16:26 Anatol Pomozov via arch-dev-public escreveu: It sounds great. If we go this route for pacman 6.0 then it will take about 1 year to switch to the detached signatures. As it is quite an important change I would love to see its codepath tested as much as possible before we remove the embedded signatures from pacman database files. It will help to catch issues like https://bugs.archlinux.org/task/67232. What do you think about starting to use detached signatures by default *and* having embedded signatures as a backup option for time being? i.e. pacman database will have the signatures (the same as now) but it will be ignored. Instead pacman will use the detached *.sig files. And in case if there is a major issue with this implementation then a user would be able to switch back to embedded signatures using a pacman.conf option (e.g. "UseEmbeddedSignatures"). If folks are fine with it I can implement a patch for it. Hi Anatol, Can't we go with a different option here? Instead of an option the user sets on their end, we make pacman fallback to embedded db sigs, if there are no detached *or* if the signature check fails for some reason. This could be maintained as a patch on the package, it doesn't necessarily have to be on pacman's code itself. Just so we make this transition as painless as possible to users. Regards, Giancarlo Razzolini pgpraXRYuv3EK.pgp Description: PGP signature
Re: [arch-dev-public] Use detached package signatures by default
Hi On Wed, Jul 8, 2020 at 8:22 PM Allan McRae via arch-dev-public wrote: > > On 9/7/20 1:05 pm, Anatol Pomozov wrote: > > Given this information I would like to propose to stop using embedded > > signatures and move to detached signatures by default. This will > > require pacman 6.x or as alternative backport the fix(es) to 5.x > > branch. It will help to make system updates even faster, something > > that me and many other Arch users really love. > > There are several steps we need to complete: > > 1) backport the patch (or wait for pacman-6.0, which may be a while > yet). I'll leave that to the distro packagers to decide! > > 2) adjust repo-add to optionally add signatures. > > 3) make a time line that all users need to have the patched/released > pacman installed - we usually require at least 6 months. > > 4) turn off signature inclusion in repo dbs. It sounds great. If we go this route for pacman 6.0 then it will take about 1 year to switch to the detached signatures. As it is quite an important change I would love to see its codepath tested as much as possible before we remove the embedded signatures from pacman database files. It will help to catch issues like https://bugs.archlinux.org/task/67232. What do you think about starting to use detached signatures by default *and* having embedded signatures as a backup option for time being? i.e. pacman database will have the signatures (the same as now) but it will be ignored. Instead pacman will use the detached *.sig files. And in case if there is a major issue with this implementation then a user would be able to switch back to embedded signatures using a pacman.conf option (e.g. "UseEmbeddedSignatures"). If folks are fine with it I can implement a patch for it.
Re: [arch-dev-public] [aur-general] AUR migration
Em julho 28, 2020 9:46 Filipe Laíns escreveu: 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 Guys, the news is out, the keys are changed. I've taken a look at the remaining migrations and I don't think ssh keys are going to be an issue, because all the services that depend on ssh keys are migrated already. The orion mail migration will hopefully use keycloak for authentication, so no need for users to login to the machine for setting up/changing passwords. Most things are separated and isolated now to their own VPS, so, if in the future we need to do these migrations, it's easier to use the same keys, or rely on the UpdateHostKeys functionality to be able to gracefully change host keys. Thank you all for the help. Regards, Giancarlo Razzolini pgpXT2TUQKjak.pgp Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
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 signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] [aur-general] AUR migration
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. For future migrations I would greatly appreciate if not all on-disk data were thrown away. On top of SSH keys, there are home directories which contain not only user data but also in some cases things useful for the distro as a whole (such as the service I use to version iana-etc files). The AUR was running on luna, which still hosts git.archlinux.org (where a few projects still are) and lists.archlinux.org. No data was deleted from it, only the AUR database and uploads were copied to the new machine. I think the issue you refer to happened on the orion -> gemini migration and 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. Regards, Giancarlo Razzolini pgpjbq_c6akLb.pgp Description: PGP signature
