Feature request: Create keypair per user for signing federated requests

[techknowlogick]

As a first step towards federation this issue, a small part of federation to be implemented would be to create an RSA keypair per user. Although signing http requests is not required by ActivityPub or ActivityStreams, many implementations verify/expect one.

What a PR would include:

1. Code to generate RSA key pair
2. add key pair fields to user struct (allow nullable, as in future we may store remote/federated users in same table, and we of course wouldn't have access to the private part of their keypair)
3. On user create, add code for generation of keypair so that it is created/saved to DB when a user is created.
4. migration to add key pair to each user (think about more this due to rand pool exhaustion possibility, perhaps on demand generation is better)
5. While the user key pair would be stored in the DB, an "instance actor" key could also be generated and stored on disk (similarly to how the jwt key pair is stored).

I have most of a PR ready, and will have it done by the next videoconference, but the first step is creating an issue for the PR to link to.

Related: #14186 (comment)
cc: @pilou- (as agent of Loic)

[lunny]

I think this depends on secret store PR.

[techknowlogick]

I've created #16834 as a dependency for this issue, as I intend to store the pub/priv key pair in this new table. The benefits include that when loading users objects we don't need to store the keypair in memory for unrelated tasks (an alternative would be to modify each query to only include what you need, but this is allows for more options in the future, and less DB migrations).

[techknowlogick]

I claim 2,500€ from the fedeproxy Gitea federation grant for the work I did to create this issue and implement the associated pull requests, where 25% will be split among the reviewers, and 25% will go to the project (via opencollective).

@lunny / @lafriks do you approve this? (more info linked here: https://forum.fedeproxy.eu/t/howto-5-000-grant-earmarked-for-gitea-federation/330/17)

[prologic]

Just noticed this issue and the associated PR and upcoming 1.16 release.

Is there or will there be an option to turn off Federation? I don't really want this and don't see the point at all.

Thanks 🙇‍♂️

[lunny]

Just noticed this issue and the associated PR and upcoming 1.16 release.

Is there or will there be an option to turn off Federation? I don't really want this and don't see the point at all.

Thanks 🙇‍♂️

Yes, it could be turn off via app.ini.

[federation]
ENABLED = false

[prologic]

@lunny Thank you! 🙇‍♂️ And finally could you explain to me why Gitea is integrating ActivityPub like I'm 5? Thanks! 😅 -- What "problem" are we setting out to solve here? 🤔

[lunny]

The feature is aimed to let users could keep their privacy data in they trusted Gitea instances but also could interactive with other Gitea instances from this Gitea instance. i.e.

User A has an account at Gitea instance B, and he could fork repository C from another Gitea instance D. The forked repository E is only in B. Even if D is down. User A could still use the forked repository E.

[prologic]

User A has an account at Gitea instance B, and he could fork repository C from another Gitea instance D. The forked repository E is only in B. Even if D is down. User A could still use the forked repository E.

Please rest assured I'm not trying to argue against this feature -- I actually truly don't understand this whole ActivityPub / "Federation" idea, often the way I see it is it's a "solution" "looking for a problem". But that's my opinion.

But... What you describe above... I have to wonder. Isn't this already possible even without ActivityPub? I can already go clone any Git repo I want from anywhere, no matter what platform, and "fork it". I mean this is basically how Git works.

What am I missing here?

[RoiArthurB]

The goal (as far as I understand it) is to be able to have communication between instances without having to really import the project in your Gitea.

I'm not sure the @lunny's fork example is the best to illustrate that idea I would prefer this examples to show the interest of federation :

1. To be able to switch all your account from one instance to another smoothly
2. To be able to comment issues of a repo on instance A from your account on instance B (which doesn't have it forked)

• More generally, we can extend it to all the project management package

3. To be able to make PR between instances
4. To be able to stargaze/follow (i.e. notifications) one repo from other instances

In a more global example, the point of it is to be able to do every possible action on your instance, but from another one (and so, no need to create new accounts, follow several websites, etc.) (it has better than mirroring all the issue/actions/etc. already scrapped from the other instance and not only git's commits)