Some Friendica instances tripped a bug in our auth module, visible in our test ONI instance, where when receiving a signed request, we try to fetch the Actor which the signing key belongs to.
We do this with a signed request, and Friendica wants to load our signing Actor and does so with a signed request, and then...
Well, this becomes an infinite loop of requesting each-other's public keys, and it generates a lot of traffic on ONI's side and sluggish responses on Friendica's side.
A bug has been filled for them here.
hey, is there anyone working on this? i'd like to try and investigate this one, i'm not really experienced with this repo tho, but i'll do my best to come up with the patches.
Hi ~vhespanha, I don't have yet a good idea about how to fix this, so I haven't started working on it. I wouldn't really be able to give you a lot of information about how a solution would look like.
May I ask why you have your mind set on this task specifically?
nothing in particular really, just seems like a good opportunity to practice debugging as opposed to just coding; i'd at least like to try and reproduce it so someone more familiar with the project can submit a fix.
The problem with reproducing this, is that it requires two federated services working in the same network.
I won't argue against you trying, but in order to be able to debug you'll need two separate instances that will trigger (and I am not yet sure that this is the full feedback loop that occurs). I'm listing here what I think happens:
Start condition: Instance A: wants to load
Actor BB(or its Public Key) on Instance B:
- Instance A does a GET request for
Actor BBthat contains a HTTP signature forActor AA(belonging to Instance A)- Instance B receives the request and tries to validate the HTTP Signature of
Actor AA, to do that it needs to loadActor AAfrom Instance A- Instance B does a GET request for
Actor AAand uses a HTTP Signature (either fromActor BB[1])- Instance A receives the request and tries to validate the HTTP Signature of
Actor BB, to do that it needs to loadActor BBfrom Instance B- Instance A
GOTO 2(this is where the loop gets restarted)I hope this information can help. I think the elements that can be mocked are the HTTP servers returning the two actors with public key and the client from Instance B.
If you want to get some experience with the library, you can start with some of the other modules, the ActivityPub vocabulary module has a lot of tests that are marked as Skipped, and you can maybe add some code there
[1] In the case of the bug I reported to Friendica the request form instance B is done using an instance level actor, which probably was different than the initial
Actor BB
I have implemented a potential fix in commit 26e3111da3d7.
I'm not entirely satisfied, but hopefully this handles the context deadline errors and requests the remote actor without a signature that would trigger the feedback loop.
I won't close this now, as I'm not 100% sure this will work as I intend it.