From 7583eceb38c3bcfa8a10d31c12963667178fd2ec Mon Sep 17 00:00:00 2001 From: Oneric Date: Sun, 1 Dec 2024 01:40:52 +0100 Subject: [PATCH] Make SigningKey data migration future-proof Bug originally discovered by tudbut --- .../migrations/20240625220752_move_signing_keys.exs | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/priv/repo/migrations/20240625220752_move_signing_keys.exs b/priv/repo/migrations/20240625220752_move_signing_keys.exs index 9104b7c29..f5569ce09 100644 --- a/priv/repo/migrations/20240625220752_move_signing_keys.exs +++ b/priv/repo/migrations/20240625220752_move_signing_keys.exs @@ -8,13 +8,14 @@ def up do # we do not handle remote users here! # because we want to store a key id -> user id mapping, and we don't # currently store key ids for remote users... - query = - from(u in User) - |> where(local: true) - - Repo.stream(query, timeout: :infinity) + # Also this MUST use select, else the migration will fail in future installs with new user fields! + from(u in Pleroma.User, + where: u.local == true, + select: {u.id, u.keys, u.ap_id} + ) + |> Repo.stream(timeout: :infinity) |> Enum.each(fn - %User{id: user_id, keys: private_key, local: true, ap_id: ap_id} -> + {user_id, private_key, ap_id} -> IO.puts("Migrating user #{user_id}") # we can precompute the public key here... # we do use it on every user view which makes it a bit of a dos attack vector