Commit graph

17 commits

Author SHA1 Message Date
07a48b9293 giant massive dep upgrade and dialyxir-found error emporium (#371)
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Reviewed-on: AkkomaGang/akkoma#371
2022-12-14 12:38:48 +00:00
0b14f02ed2 User: generate private keys on user creation
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-09-11 19:54:37 +01:00
85e2e64c82 fix resolution of GTS user keys 2022-07-18 15:21:27 +01:00
Haelwenn (lanodan) Monnier
c4439c630f
Bump Copyright to 2021
grep -rl '# Copyright © .* Pleroma' * | xargs sed -i 's;Copyright © .* Pleroma .*;Copyright © 2017-2021 Pleroma Authors <https://pleroma.social/>;'
2021-01-13 07:49:50 +01:00
rinpatch
2c55f7d7cb Remove FedSockets
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-11-17 17:28:30 +03:00
Steven Fuchs
f2ef9735c5 Federate data through persistent websocket connections 2020-09-18 11:58:22 +00:00
Alexander Strizhakov
3c2cee33ad
moving custom ecto types in context folders 2020-06-16 17:50:33 +03:00
lain
a912f72a36 Signature: Handle non-ap ids in key ids.
Mastodon and Gab sometimes send the format `acct:name@server`.
2020-05-01 15:54:38 +02:00
Mark Felder
05da5f5cca Update Copyrights 2020-03-03 16:44:49 -06:00
rinpatch
fefbd31c6e Move local keys out of user.info 2019-10-06 16:56:36 +03:00
Maksim Pechnikov
8dc6a6b210 fix /inbox for Relay 2019-08-22 22:48:07 +03:00
Thomas Sileo
961e778531 Fix HTTP sig tweak on KeyId 2019-07-28 14:17:56 +02:00
Ariadne Conill
e7c64f106e signature: properly deduce the actor from misskey key IDs 2019-07-23 16:47:22 +00:00
Ariadne Conill
18d8d12d53 signature: make key_id_to_actor_id() public 2019-07-18 15:35:42 +00:00
Ariadne Conill
f84fb340b7 http signatures: derive actor ID from key ID.
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-07-17 19:18:19 +00:00
William Pitcock
045803346d move key generation functions into Pleroma.Keys module 2019-05-22 03:58:15 +00:00
William Pitcock
071f78733a switch to pleroma/http_signatures library 2019-05-14 20:03:13 +00:00