dachary
August 5, 2021, 2:01pm
22
3 posts were merged into an existing topic: Grant application for federation in Gitea
@pilou would you be so kind as to post the following reply to this message ?
dachary:
It is also a matter of defining the first baby steps that would lead Gitea in the direction of federation. At the moment there only is a very high level discussion that can hardly be translated into actionable items. In your expert opinion, what would be the first minimal tasks that would make most sense?
@zeripath @cjslep here is an idea for the first baby step: creating a keypair for every user that will be used to sign http requests (see also the IETF draft ). Although signing http requests is not required by ActivityPub or ActivityStreams , it is mentioned in the ActivityPub wikii . Since mastodon, bookwyrm and other ActivityPub implementations verify and expect a signature, it is de facto required.
If it sounds sensible to you, I think the creation of the corresponding issue as well as its implementation is eligible to be funded by the 5,000€ grant made available by the fedeproxy project a month ago :
Write a detailed issue to create a keypair for every user , with technical details that would allow a skilled Go developer with no prior knowledge of the codebase to work on it
Propose a pull request to implement the issue, add it to the 1.16 roadmap and get it merged
2 Likes
For the record @techknowlogick created an issue at:
opened 07:38AM - 18 Aug 21 UTC
closed 07:19PM - 28 Sep 21 UTC
type/proposal
topic/federation
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: https://github.com/go-gitea/gitea/issues/14186#issuecomment-899455331
cc: @pilou- (as agent of Loic)
1 Like
I created a second issue for another “baby step” issue towards federation:
opened 10:36PM - 20 Aug 21 UTC
closed 11:38PM - 27 Sep 21 UTC
type/proposal
topic/federation
Nodeinfo is a way to expose certain metadata about a server for use of discovery… regarding functionality of its federation capabilities.
Two endpoints are required:
1. `/.well-known/nodeinfo` which informs client where it can find the location of the location of its metadata (including which version of the schema is used)
2. the endpoint which exposes the metadata in json format according to schema.
Notes:
* `openRegistrations` is a required field, but I propose to set to false as default in case someone writes a crawler to discover "open" gitea instances
* to limit data leakage I also propose to not include the `usage` field (note it is required so it should be included, but left as empty).
More info:
https://github.com/jhass/nodeinfo
https://github.com/jhass/nodeinfo/tree/main/schemas/2.1
http://nodeinfo.diaspora.software/protocol.html
cc: @pilou-
2 Likes
Excellent idea, that’s actually the first endpoint that was implemented in fedeproxy.
I have what may be a naive question regarding the private keypair issue . It is in the 1.16 milestone but not in the Plan of Gitea v1.16 . What is the difference?
2 Likes
The “plan of gitea v1.16” issue is a place for maintainers to state what they intend to work on for a specific version, but I have been lazy and just put things into the milestone. I will make a comment about that now in the thread.
2 Likes
Am I right to assume the storage secret PR mentionned here
opened 07:38AM - 18 Aug 21 UTC
closed 07:19PM - 28 Sep 21 UTC
type/proposal
topic/federation
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: https://github.com/go-gitea/gitea/issues/14186#issuecomment-899455331
cc: @pilou- (as agent of Loic)
is this one
go-gitea:main ← lafriks-fork:feat/secrets
opened 11:35AM - 27 Jan 21 UTC
Also needed for #13539
some screenshots:
repository level secrets
<img widt… h="1177" alt="image" src="https://user-images.githubusercontent.com/81045/195858378-850cad84-a2ea-4f3e-8a67-8e8406f70f0c.png">
org level secrets
<img width="1193" alt="image" src="https://user-images.githubusercontent.com/81045/195858455-1c28f91f-3727-422d-b364-24eee6ca1a58.png">
?
That is indeed correct, my initial implementation won’t include it (as to not be blocked by the other PR), however it will be fairly easy to update the implementation as needed once the secrets PR is merged. As a related note, when checking how other federated software (mastodon, peertube, pixelfed, etc…) implemented this they all have it stored as plain text but perhaps they should also change that in the future as well (but this is up to each of those maintainers to decide to do that if they so chose).
3 Likes
