Make SigningKey data migration future-proof

Bug originally discovered by tudbut
This commit is contained in:
Oneric 2024-12-01 01:40:52 +01:00 committed by Floatingghost
parent 834edfcf96
commit 7583eceb38

View file

@ -8,13 +8,14 @@ def up do
# we do not handle remote users here! # we do not handle remote users here!
# because we want to store a key id -> user id mapping, and we don't # because we want to store a key id -> user id mapping, and we don't
# currently store key ids for remote users... # currently store key ids for remote users...
query = # Also this MUST use select, else the migration will fail in future installs with new user fields!
from(u in User) from(u in Pleroma.User,
|> where(local: true) where: u.local == true,
select: {u.id, u.keys, u.ap_id}
Repo.stream(query, timeout: :infinity) )
|> Repo.stream(timeout: :infinity)
|> Enum.each(fn |> 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}") IO.puts("Migrating user #{user_id}")
# we can precompute the public key here... # 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 # we do use it on every user view which makes it a bit of a dos attack vector