foster/forgejo-docs
0
0
Fork 0
mirror of https://codeberg.org/forgejo/docs.git synced 2025-01-21 02:12:15 -05:00
Code Issues Activity

tree-wide: fix typos

Browse source 
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
This commit is contained in:
Christoph Heiss 2025-01-04 12:41:17 +01:00 • committed by Earl Warren
parent 2bb951215c
commit 46420f31e0
11 changed files with 21 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/admin/actions.md
View file

@ -98,7 +98,7 @@ A label has the following structure:
<label-name>:<label-type>://<default-image>
```
The `label name` is a unique string that identifies the label. It is the part that is specified in the `runs-on` field of workflows to choose which runners the workflow can be excecuted on.
The `label name` is a unique string that identifies the label. It is the part that is specified in the `runs-on` field of workflows to choose which runners the workflow can be executed on.
The `label type` determines what containerization system will be used to run the workflow. There are three options:
@ -153,7 +153,7 @@ Label example:
### Special labels
Runner labels can also be used to define other special features a runner has. For example, you could use `gpu:docker://node:20-bullseye` to define a runner that has a GPU installed. Workflows which need a GPU could then specify `runs-on: gpu` to be excecuted on this runner.
Runner labels can also be used to define other special features a runner has. For example, you could use `gpu:docker://node:20-bullseye` to define a runner that has a GPU installed. Workflows which need a GPU could then specify `runs-on: gpu` to be executed on this runner.
### Mimicking GitHub runners

4
docs/admin/config-cheat-sheet.md
View file

@ -588,7 +588,7 @@ And the following unique queues:
- `ENABLED`: **false**: Enable media proxy, we support images only at the moment.
- `SERVER_URL`: **\<empty\>**: URL of camo server, it **is required** if camo is enabled.
- `HMAC_KEY`: **\<empty\>**: Provide the HMAC key for encoding URLs, it **is required** if camo is enabled.
- `ALLWAYS`: **false**: Set to true to use camo for both HTTP and HTTPS content, otherwise only non-HTTPS URLs are proxied
- `ALWAYS`: **false**: Set to true to use camo for both HTTP and HTTPS content, otherwise only non-HTTPS URLs are proxied
## OpenID (`openid`)
@ -887,7 +887,7 @@ The defaults of the console change if Forgejo detects that stdout and/or stderr
- For the console logger `COLORIZE` will default to `true` if not on windows or the terminal is determined to be able to color.
- `STDERR`: **false** (journald: **true**): Use Stderr instead of Stdout.
- `FLAGS`: **stdflags** (journald: **journaldflags**): Instead of colour or text annotations, machine-readable prefixes are used that can be parsed by sytemd-journald.
- `FLAGS`: **stdflags** (journald: **journaldflags**): Instead of colour or text annotations, machine-readable prefixes are used that can be parsed by systemd-journald.
### File log mode (`log.file`, or `MODE=file`)

2
docs/admin/database-preparation.md
View file

@ -4,7 +4,7 @@ license: 'Apache-2.0'
origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8e705d2a86030/docs/content/installation/database-preparation.en-us.md'
---
You need a database to use Forgejo. The easiest option is SQLite which managed files next to Forgejo and does not require setting up a database server. However, if you plan to use Forgejo with several hundreds of users, or if you already run a databse server, you might want to choose another option.
You need a database to use Forgejo. The easiest option is SQLite which managed files next to Forgejo and does not require setting up a database server. However, if you plan to use Forgejo with several hundreds of users, or if you already run a database server, you might want to choose another option.
Forgejo supports:

2
docs/admin/runner-installation.md
View file

@ -369,7 +369,7 @@ A special kind of token is needed and can be obtained from the `Create new runne
![Screenshot showing runner registration popup](../_images/user/actions/runners-add.png)
To register the runner, excecute `forgejo-runner register` and fill in the prompts. For example:
To register the runner, execute `forgejo-runner register` and fill in the prompts. For example:
```shell
$ forgejo-runner register

2
docs/contributor/adr/adr-activity-for-like.md
View file

@ -86,7 +86,7 @@ This way of expressing stars will have the following features:
3. With NodeInfo given it would be more easy to distinguish the uri layout for object and actor id's and make implementation more straight forward
1. The NodeInfo field reflects the software & version sending an activity. Values of may be gitea, forgejo, gitlab, ...
2. Knowing the sending system will it make easier to interact with:
1. We know exactly how the actor can be derefernced - names maybe filled & used different (see: https://codeberg.org/meissa/forgejo/src/commit/7cac9806f8247963b1cdce3f2c5f5d1bc3763fbe/routers/api/v1/activitypub/repository.go#L180)
1. We know exactly how the actor can be dereferenced - names maybe filled & used different (see: https://codeberg.org/meissa/forgejo/src/commit/7cac9806f8247963b1cdce3f2c5f5d1bc3763fbe/routers/api/v1/activitypub/repository.go#L180)
2. We know how we can validate the given references - valid uris will be different in details (see: https://codeberg.org/meissa/forgejo/src/commit/7cac9806f8247963b1cdce3f2c5f5d1bc3763fbe/models/forgefed/actor.go#L121)
4. startTime protects against The Reply Attack discussed in [threat-analysis][threat-analysis]

4
docs/contributor/development-environment.md
View file

@ -89,7 +89,7 @@ Or for eglot:
(add-hook 'go-mode-hook #'eglot-format-buffer-before-save)
```
As additional quality of life inprovements, you might consider installing [company](https://company-mode.github.io/), [flycheck](https://www.flycheck.org/en/latest/) and/or [magit](https://magit.vc/). Consider the package website for a complete explanation and installation instructions.
As additional quality of life improvements, you might consider installing [company](https://company-mode.github.io/), [flycheck](https://www.flycheck.org/en/latest/) and/or [magit](https://magit.vc/). Consider the package website for a complete explanation and installation instructions.
<details>
<summary> Here is an init example if you just want to use all three packages </summary>
@ -176,7 +176,7 @@ vim.g.mapleader = " "
vim.g.maplocalleader = " "
local on_attach = function(client, bufno)
-- depricated since neovim 0.10
-- deprecated since neovim 0.10
-- vim.api.nvim_buf_set_option(bufno, "omnifunc", "v:lua.vim.lsp.omnifunc")
vim.api.nvim_set_option_value("omnifunc", "v:lua.vim.lsp.omnifunc", { buf = bufno })

2
docs/contributor/federation-architecture.md
View file

@ -29,6 +29,6 @@ In order to normalize URIs we care:
3. No parameters: `https://federated-repo.prod.meissa.de/api/v1/activitypub/user-id/1?some-parameters=1`
4. No Webfinger: `https://user1@federated-repo.prod.meissa.de` (with following redirects)
5. No default api: `https://federated-repo.prod.meissa.de/api/activitypub/user-id/1`
6. No autorization: `https://user:password@federated-repo.prod.meissa.de/api/v1/activitypub/user-id/1`
6. No authorization: `https://user:password@federated-repo.prod.meissa.de/api/v1/activitypub/user-id/1`
7. No default ports: `https://federated-repo.prod.meissa.de:443/api/v1/activitypub/user-id/1`
8. Accept non default ports: `http://localhost:3000/api/v1/activitypub/user-id/1`

5
docs/contributor/testing.md
View file

@ -185,7 +185,8 @@ using `USE_GOTESTSUM=yes` while running tests, for example:
USE_GOTESTSUM=yes make test
```
`gotestsum` behaves like the default `go test` except it reformats the test results
so that they are clearer for human interpreation and include a helpful summary.
`gotestsum` behaves like the default `go test` except it reformats the test
results so that they are clearer for human interpretation and include a helpful
summary.
You need to have `gotestsum` installed (see the link above) to use it as it does not come built-in unlike `go test`.

6
docs/contributor/threat-analysis/threat-analysis-like-activity.md
View file

@ -66,14 +66,14 @@ license: 'CC-BY-SA-4.0'
1. **Knock foreign http server**: Script Kiddi sends a Like Activity containing an attack actor url `http://attacked.target/very/special/path` in place of actor. Our repository server sends a `get Person Actor` request to this url. The target receives a DenialdOfService attack. We loose CPU & instance reputation.
2. **Sql injection**: Experienced hacker sends a Like Activity containing an actor url pointing to an evil forgejo instance. Our repository server sends an `get Person Actor` request to this instance and gets a person having sth. like `; drop database;` in its name. If our server tries to create a new user out of this person, the db might be dropped.
3. **Malicious Activities**: Malicious Fediverse Member sends Star Activities containing non authorized Person Actors. The Actors listed as stargazer might get angry about this. The project may loose project reputation.
4. **DOS by Rate**: Experienced Hacker records activities sent and replays some of them. Without order of activities (i.e. timestamp) we can not decide wether we should execute the activity again. If the replayed activities are UnLike Activity we might loose stars.
4. **DOS by Rate**: Experienced Hacker records activities sent and replays some of them. Without order of activities (i.e. timestamp) we can not decide whether we should execute the activity again. If the replayed activities are UnLike Activity we might loose stars.
5. **Replay**: Experienced Hacker records activities sends a massive amount of activities which leads to new user creation & storage loss. Our instance might fall out of service. See also [replay attack@wikipedia][2].
6. **Replay out of Order**: Experienced Hacker records activities sends again Unlike Activities happened but was succeeded by an Like. Our instance accept the Unlike and removes a star. Our repository gets rated unintended bad.
7. **DOS by Slowlories**: Experienced Hacker may craft their malicious server to keep connections open. Then they send a Like Activity with the actor URL pointing to that malicious server, and your background job keeps waiting for data. Then they send more such requests, until you exhaust your limit of file descriptors openable for your system and cause a DoS (by causing cascading failures all over the system, given file descriptors are used for about everything, from files, to sockets, to pipes). See also [Slowloris@wikipedia][1].
8. **Saturate by future StartTime**: Hacker sends an Activity having `startTime` in far future. Our Instance does no longer accept Activities till they have far far future `startTime` from the actors instance.
9. **Malicious Forge**: If a "Malicious Fediverse Member" deploys an 'federated' forge that sends the right amount of Like activities to not hit the rate limiter, an malicious user can modify the code of any 'federated' forge to ensure that if an foreign server tries to verify and activity, it will always succeed (such as creating users on demand, or simply mocking the data).
10. **Malicious Controlled Forge**: A "Malicious Forge Admin" of a good reputation instance may impersonate users on his instance and trigger federated activities.
11. **Side Chanel Malicious Activities**: A Owner of a good reputation instance may craft malicious activities with the hope not to get moderated.
11. **Side Channel Malicious Activities**: A Owner of a good reputation instance may craft malicious activities with the hope not to get moderated.
### Mitigations
@ -84,7 +84,7 @@ license: 'CC-BY-SA-4.0'
5. We introduce (or have) rate limiting per IP.
6. We ensure, that outgoing HTTP requests have a reasonable timeout (if you didn't get that 500b JSON response after 10 seconds, you probably won't get it).
7. **Instance Level Moderation** (such as blocking other federated forges) can mitigate "Malicious Forge"
8. **User Level Moderation** (such as blocking other federated users) can mitigate "Side Chanel Malicious Activities"
8. **User Level Moderation** (such as blocking other federated users) can mitigate "Side Channel Malicious Activities"
### DREAD-Score

8
docs/user/oauth2-provider.md
View file

@ -87,7 +87,7 @@ In this example https://v7.next.forgejo.org will be configured to add the option
- Choose an arbitrary but distinctive name for the OAuth2 provider: (e.g. **Codeberg**).
- Choose an existing Codeberg user to create the OAuth2 application. It does not need to be a user with elevated privileges. (e.g. **user-for-oauth-application**)
- On https://codeberg.org, login as **user-for-oauth-application**
- Visit https://codeberg.org/user/settings/applications and create a new OAuth2 application. There needs to be only one redirect URI, composed with the abitrary name that was chosen above: https://v7.next.forgejo.org/user/oauth2/Codeberg/callback.
- Visit https://codeberg.org/user/settings/applications and create a new OAuth2 application. There needs to be only one redirect URI, composed with the arbitrary name that was chosen above: https://v7.next.forgejo.org/user/oauth2/Codeberg/callback.
![Create a new OAuth2 application](../_images/user/oauth2-provider/authsource-provider-create.png)
- When created, the OAuth2 application is given a **Client ID** and a **Client secret** that https://v7.next.forgejo.org will need to let https://codeberg.org know it is an authorized OAuth2 client.
![Client ID and secret of a new OAuth2 application](../_images/user/oauth2-provider/authsource-provider-show.png)
@ -95,16 +95,16 @@ In this example https://v7.next.forgejo.org will be configured to add the option
- Create a new authentication source on https://v7.next.forgejo.org, the Forgejo instance that is going to act as the OAuth2 client, allowing its users to register using the account they have on https://codeberg.org.
- Visit https://v7.next.forgejo.org/admin/auths/new to create the authentication source with:
- **Authentication type:** OAuth2
- **Authentication name:** the abitrary name that was chosen above (e.g. **Codeberg**)
- **Authentication name:** the arbitrary name that was chosen above (e.g. **Codeberg**)
- **OAuth2 provider:** OpenID Connect
- **Client ID:** copy/pasted from the OAuth2 application created on Codebeg
- **Client Secret:** copy/pasted from the OAuth2 application created on Codebeg
- **Icon URL:** https://design.codeberg.org/logo-kit/icon.svg
- **OpenID Connect Auto Discovery URL:** https://codeberg.org/.well-known/openid-configuration
- Leave all other fields to their default values
![Create a new OAuth2 authentication soure](../_images/user/oauth2-provider/authsource-client-create.png)
![Create a new OAuth2 authentication source](../_images/user/oauth2-provider/authsource-client-create.png)
- It will show in the list of authentication sources at https://v7.next.forgejo.org/admin/auths.
![List of OAuth2 authentication soure](../_images/user/oauth2-provider/authsource-client-list.png)
![List of OAuth2 authentication source](../_images/user/oauth2-provider/authsource-client-list.png)
- On https://v7.next.forgejo.org, not logged in
- Visit https://v7.next.forgejo.org/user/login
![Login page with Codeberg authentication source](../_images/user/oauth2-provider/authsource-intro-login-page.png)

2
docs/user/repo-mirror.md
View file

@ -94,4 +94,4 @@ After adding the push mirror, you can click the **Copy public key** link to copy
![The push mirror entry is shown](../_images/user/repo-mirror/push_mirror_with_ssh.png)
This public key can then be added as a deploy key on the target repository, how to add one varies by platform but generally it should be an option in the repository's settings.
After adding the public key as the deploy key, you can go back to Forgejo and click the **Syncronize now** button and see that it works.
After adding the public key as the deploy key, you can go back to Forgejo and click the **Synchronize now** button and see that it works.