aboutsummaryrefslogtreecommitdiff
path: root/lib/pleroma/signature.ex
AgeCommit message (Collapse)Author
2022-09-05Merge branch 'fix/user-private-key-generation' into 'develop'Haelwenn
User: generate private keys on user creation See merge request pleroma/pleroma!3737
2022-09-05User: generate private keys on user creationHélène
This fixes a race condition bug where keys could be regenerated post-federation, causing activities and HTTP signatures from an user to be dropped due to key differences.
2022-08-16fix resolution of GTS user keysFloatingGhost
2022-02-25Copyright bump for 2022Sean King
2021-01-13Bump Copyright to 2021Haelwenn (lanodan) Monnier
grep -rl '# Copyright © .* Pleroma' * | xargs sed -i 's;Copyright © .* Pleroma .*;Copyright © 2017-2021 Pleroma Authors <https://pleroma.social/>;'
2020-11-17Remove FedSocketsrinpatch
Current FedSocket implementation has a bunch of problems. It doesn't have proper error handling (in case of an error the server just doesn't respond until the connection is closed, while the client doesn't match any error messages and just assumes there has been an error after 15s) and the code is full of bad descisions (see: fetch registry which uses uuids for no reason and waits for a response by recursively querying a ets table until the value changes, or double JSON encoding). Sometime ago I almost completed rewriting fedsockets from scrach to adress these issues. However, while doing so, I realized that fedsockets are just too overkill for what they were trying to accomplish, which is reduce the overhead of federation by not signing every message. This could be done without reimplementing failure states and endpoint logic we already have with HTTP by, for example, using TLS cert auth, or switching to a more performant signature algorithm. I opened https://git.pleroma.social/pleroma/pleroma/-/issues/2262 for further discussion on alternatives to fedsockets. From discussions I had with other Pleroma developers it seems like they would approve the descision to remove them as well, therefore I am submitting this patch.
2020-09-18Federate data through persistent websocket connectionsSteven Fuchs
2020-06-16moving custom ecto types in context foldersAlexander Strizhakov
2020-05-01Signature: Handle non-ap ids in key ids.lain
Mastodon and Gab sometimes send the format `acct:name@server`.
2020-03-03Update CopyrightsMark Felder
2019-10-06Move local keys out of `user.info`rinpatch
2019-08-22fix /inbox for RelayMaksim Pechnikov
2019-07-28Fix HTTP sig tweak on KeyIdThomas Sileo
2019-07-23signature: properly deduce the actor from misskey key IDsAriadne Conill
2019-07-18signature: make key_id_to_actor_id() publicAriadne Conill
2019-07-17http signatures: derive actor ID from key ID.Ariadne Conill
Almost all AP servers return their key ID as the actor URI with #main-key added. Hubzilla, which doesn't, uses a URL which refers to the actor anyway, so worst case, Hubzilla users get refetched.
2019-05-22move key generation functions into Pleroma.Keys moduleWilliam Pitcock
2019-05-14switch to pleroma/http_signatures libraryWilliam Pitcock