- Deleting attachments are also seen as updating attachments due to the frontend always sending a field to edit the name even if the name didn't change. This was not reflected in the unit tests.
- Refactor the updating attachment logic to be more flexible if a attachment does not exist, because it was just deleted or because someone is being malicious.
- Resolvesforgejo/forgejo#11636
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11642
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- For small modals fomantic tried to add a `scrolling` class using a function that was not implemented, this function is now stubbed.
- There's not really a need to conditionally change the behavior of scrolling or not, we can specify `overflow-y: auto` which is more than enough to take care of this. We do add some layout changes to ensure the modal is fully scrollable.
- Refactor to nested CSS.
- Resolvesforgejo/forgejo#10991
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11547
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Remove recipients that are not active (e.g. done by moderation or
organizational reasons) and those that have the permi ssion to read
releases on that repository.
It was sufficiently checked for the repostiory case, but for user/org
project it was not checked and you could change the state of any
project by there mere knowledge of a ID.
The API already checked the permission sufficiently if auto merge could
be cancelled by the doer. The web route did not. Consolidate this check
in the function that lives in the services directory.
It was possible to hijack attachments during update and create functions
to another owner as permissions to check they weren't already attached
to another resource and wasn't checked if it belonged to the repository
that was being operated on.
There are two ways to use a OAuth2 token:
Via the Authorization header as a Bearer token.
Via the Authorization header as a Basic login.
For the former the scope was correctly passed through, for the latter it
was not and would mean no scope was checked if you used the token via
this way.
We do not know for sure, but it is quite likely someone assumed implicit
fallthrough. This meant that if someone used S256 for PKCE, it simply
did not verify the code challenge and always accepted it.
PKCE only started working recently as it was broken for a long time
already, forgejo/forgejo!8678
- When working forgejo/forgejo!8714 I did not touch the UI to remove the
note and `disabled` attribute. This was not intentional, and was likely
caused by me straight going for testing (as the backend code would allow
the username change).
- Slightly refactor the context to a common function, don't hard error
if `CanUserRename` fails but does default to that you cannot rename in
that case (which is the standard behavior of OAuth2 users anyway).
I already was aware that it seems !8714 wasn't working on Codeberg but someone at FOSDEM pointed it out again, thus the reason for this bug fix.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11171
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- Resolvesforgejo/forgejo#10849
- Yes, the referrer policy is causing cross-origin protection to fail.
Why? Because someone really cared about privacy, the referrer policy was
set to no-referrer. So no `Referrer` HTTP header and `Origin` is either
omited or set to `null`, because hey the browser isn't allowed to leak
it via that header either. The new cross-origin protection relies on
Sec-Fetch metadata to determine if the request is same-origin or not.
This metadata is only sent to trustworthy origins, and thus not when
you visit Forgejo on your intranet. But the new protection has a
fallback to compare the Origin to the Host header... but the Origin
header was conviently set to `null` to protect the user's privacy.
- We now set the referrer policy to strict-origin, which means only for
same-origin requests a Origin header is set. For cross-origin the
behavior is unchanged and the user's privacy is preserved.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10851
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
This was implicitly loaded during the mail notifications notifier. If
you disable mail notifications on Forgejo then this will result in the
reviewer not being loaded and NPE.
`GPGKeyToEntity` incorrectly assumed that within a keyring with multiple
keys that the first key is verified and should be exported. Look at all
keys and find the one that matches the verified key ID.
Within Codeberg we are looking into distributing the database queries, we tried forgejo/forgejo!7212 on several occasions but never got it to work.
After a long debugging session in a staging environment I was able to find two bugs that made it impossible for this feature to work: forgejo/docs!1587 which resulted in replica engines never being configured and used if you followed the documentation. The other bug is what this patch intends to fix. In order to do some database operation, you need the database engine - it will first look if one is set for the context (only useful for transactions) and otherwise create a new session of the engine from the master engine `x`. The problem is that `x` is explicitly set to be the master engine and not the engine group (that includes the replica engines) - Unless the code uses `DefaultContext`, which is almost nowhere used after some great refactoring in Gitea to use the passed context, it did not use the replica engines.
Get engine from the `DefaultContext` (which is set to the enginegroup) and create a new session from that.
https://codeberg.org/forgejo/forgejo/src/commit/20f8572b923c83258a53f1629782953000dd0e75/models/db/engine.go#L220-L231
And `SetDefaultEngine` is called from https://codeberg.org/forgejo/forgejo/src/commit/20f8572b923c83258a53f1629782953000dd0e75/models/db/engine.go#L212
Where `eng` is the engine group.
## Test
1. Configure database replicas.
2. Start Forgejo.
3. Verify Forgejo loads.
4. Stop the database replicas.
5. Verify Forgejo shows 500 errors.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10140
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Move the function to the repository struct. There is no need to have it as a separate function, move it to the Repository struct. Add extra unit tests.
---
Remove a field from a struct. It has nothing to do with git, it is not the right place to have that field in the git `Tag` struct. Get this value when it's converted to the API struct.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10109
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Webkit and Mobile safari are comically unreliable, will fail for unexplainable reasons and are very hard to run locally in comparison with the other supported platforms. I do not remember the last time where these two platforms were able to catch a regression where the other platforms did not.
I would like to stress, for the historical record, that many hours has been devoted into adjusting the tests and following best practices to make these two platforms more stable but despite those, IMO wasted, efforts these two platforms are causing many hours of wasted CPU time simply because they are flaky and make (new) contributors nervous if their change contains a regression or not.
To my knowledge, the tests are not broken for these two platforms. If you go to the issue tracker you will not find issues by users that use these two platforms and report that Forgejo is broken. It does not reflect reality.
This is the sunk cost fallacy, bite the bullet and agree that these platforms will not contribute positively to Forgejo's excellent test suite.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10103
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
In forgejo/forgejo!2834 and forgejo/forgejo!5307 it was made so it's no longer possible to modify and delete internal reference, not having this restriction lead to broken pull requests when people used something like `git push --mirror`. However it now still leads to problem with that command as the git client tries to delete such references. We can solve this by using git's `receive.hideRefs` to make this ref read-only and avoid advertising it when someone does `git push --mirror`.
Resolvesforgejo/forgejo#9942
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10015
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Return the Note object (avoid C-style functions).
Motivation to refactor this function is to avoid the function that uses last commit cache for git-notes, because it is not needed at the scale of git-notes. In the worst case it can be considered to make a patch to git to get the message and commitID, because git seems to have efficient code to do this (for getting messages, but does not expose the commit id).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9985
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- Follow up of forgejo/forgejo!5041, forgejo/forgejo!6074, forgejo/forgejo!8692
- The `task` table contains three secrets: clone address (with credentials), auth password and auth token. These secrets are stored for migrating repositories (also the only usage of this table, although it allows for more usages).
- Use `keying` to safely store these secrets and bound them to the table, column, row id and JSON field name.
- The migration isn't spectacular but does closely follow what we learned in the previous two migrations: use a transaction and delete records when you can't decrypt them. We also learned about `db.Iterate` not being happy when updating records but it has since been fixed.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9923
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Replace the anti-CSRF token with a [cross origin protection by Go](https://go.dev/doc/go1.25#nethttppkgnethttp) that uses a stateless way of verifying if a request was cross origin or not. This allows is to remove al lot of code and replace it with a few lines of code and we no longer have to hand roll this protection. The new protection uses indicators by the browser itself that indicate if the request is cross-origin, thus we no longer have to take care of ensuring the generated CSRF token is passed back to the server any request by the the browser will have send this indicator.
Resolvesforgejo/forgejo#3538
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9830
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- When a issue sees a modification regarding to which project they are assigned, then a timeline event is created for this. The link to the project that is constructed for this timeline event incorrectly assumes the project is a repository project.
- Use the `Link` function to construct the link to the project, this will correctly take into account if the project is a org, user or repo project.
- Resolvesforgejo/forgejo#9817
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9872
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- When clicking on the content history menu "edited" item, show a spinner animation as before the dropdown is show can take a measurable amount of time.
- We cannot rely on fomantic adding the loading indicator (although it does have this capability), it only adds this indicator when waiting for the network request. For a fast Forgejo instance waiting for the network response is faster than what fomantic is doing to prepare the dropdown.
- Resolvesforgejo/forgejo#9841
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9874
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
`GetPullRequestFiles` is the API route handler to get the files that are changed in a pull request, it has to know the start commit and end commit to diff for (so it can gather the changed file and other information). The end commit is clear, the pr ref (`ref/pull/xxx/head`). However the start commit has to be computed, it is the merge base commit between the base branch and pr ref. However if the pr was merged, then we should use the `pr.MergeBase` as it's possible the `pr.BaseBranch` no longer exists.
Instead of doing this computation via `GetCompareInfo` that also does some other computations, compute the merge base directly ourselves in this function, if no merge base exists then fallback to the base reference (this is the same behavior as in `GetCompareInfo`). The only difference is that in the case of the fallback we don't convert the base ref to a commit ID, this is not necessary as the call to `git-diff` will accept any valid reference. So technically we could drop the call to `baseGitRepo.GetRefCommitID()` as well, but that's left for another time to keep the change minimal.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9740
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
When you edit a comment and the comment already has a markdown editor,
then the code will click on the 'Write' tab, in case you canceled
editting the comment when you were at the 'Preview' tab. In
forgejo/forgejo#2681 I added `href="#"` to the tab items, this causes
that when the 'Write' tab is being clicked by the code the page is
jumped the beginning of the page.
Instead of being clever and trying to make this item interactive via
another way or via javascript avoid this jumping, we do better and make
this element a button. This item is not a link, it's a button that will
perform a action. This entirely avoids the issue of jumping and it's
still interactive.
Resolvesforgejo/forgejo#9542
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9645
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
The codeowner features computes the mergebase (I'm not exactly sure why, because this should be stored in the database in `merge_base` column, but if there's no harm to compute it again as that will always be the correct answer) in order to get the changed files between the merge base and the head commit. To do this a function was used that adds a remote... my best reasoning is that this was done because the only function that that was exported on the repository struct had this requirement. Add a new function that *simply* computes the merge base without requiring a remote.
The main benefit of not using a remote is that within Codeberg we are frequently seeing `config.lock` being lingered around (see forgejo/forgejo#1946) so its best to avoid modifying the config when possible - in this case it was completely unnecessary.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9610
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
This patch contains two fixes/enhancements to two functions that were updating all columns of the `access_token` and `repository` table when they were only updating a select few columns. Within Codeberg we saw these two queries quite often when something problematic with the database was going on, likely because of this all columns update pattern. `UpdateAccessToken` is removed and a new function `UpdateLastUsed` was added, for `updateRepoRunsNumbers` we can simply add which columns we want to have updated in that query.
It's likely there are more of such queries, but these were the ones being executed often.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9572
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
With forgejo/forgejo#9075 the `GetUserByEmail` now actually only used activated emails. This however broke sending recovery mails to unactivated users, as their email are not yet activated.
Use the newly introduced function `GetUserByEmailSimple` to not care about this activated email requirement and also avoid the no-reply address being a valid email address for this functionality.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9504
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Renovate uses the latest npm version, however this is now causing a
issue where the latest npm version is diverging from the npm version
packaged with node v22 (version the CI uses) in terms of what the
`package-lock.json` should contain (!9477) (some `"peer": true` lines).
Constrain renovate to use npm v10 to avoid this mismatch issue.
Thank you @viceice for helping with this patch.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9496
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Some Vue components were already lazy-loaded, but not all.
There are three main changes:
1. Move init scripts outside Vue code.
2. Make the init scripts lazy-load the Vue components.
3. Deal with vue linters, because apparently if you do `export default` then some Vue linters will notice that's vue sfc.
The rationale for this pull requests is that this reduces the size of the `index.js` file.
- Uncompressed: 1.24 MB -> 954.40 kB
- Compressed (gzip, via `reverse_proxy` of Caddy): 400.45 kB -> 298.95 kB
- Compressed (zstd, via `bindata` tag): 363.75 kB -> 274.22 kB
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9444
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- The current implementation for modals is provided by fomantic UI.
- This patch introduces a new implementation that relies on the `<dialog>` element to provide modal, whereby the heavy lifting is done by the browser.
- This implementation is considerably simpler, accessible (although untested) and lightweight. It is capable of replacing fomantic UI's modal implementation + our dimmer implementation (~2k lines of code and CSS).[^1] As a first step the empty content modal is migrated.
- This brings in the CSS needed to display `<dialog>` and a helper function that hides some boilerplate code that's needed to show `<dialog>` as a modal.
- Add a E2E test that shows the modal's cancel and approve button works.
[^1]: The heavy work has already been done by me in a local branch, but reviewing that gigantic patch in one PR is not doable.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8859
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
TL;DR we can test if transactions are actually working.
Forgejo has many helper functions to test various aspects of the database state, however one aspect it is not able to test is transactions. As this would require that some random SQL query fails to indeed observe that the whole transaction is being rollbacked.
So how do we make a random SQL query fail? Via a fault injector hook, which is always added to xorm (during unittest) and can be enabled on demand to say after how many SQL queries it should start returning a error (fault injecting).
This allows a test to do the following: after two SQL queries lets call it a day and then execute the function that starts a transaction and does a few SQL query. It can then observe that indeed the function was fault injected (`ErrFaultInjected` is returned) and after querying the database it can observe that nothing was changed and thus can conclude the transaction was rollbacked.
---
To demonstrate how the fault injector test helper can be used, lets add a test to a function I really wanted to test but couldn't because the fault injector didn't exist. `NewTwoFactor` was recently made into a transaction (a8c61532d2) and although it would not be catastrophic it would be really bad if records were being inserted if for some reason setting the secret failed.
The test that's added demonstrates that the function uses a transaction and rollbacks correctly.
Weirdly enough the fault injector can be viewed as testing a specification, because it assumes nothing about how the function does it (and you could even design a function that purposely doesn't work but succeeds this test), it merely assumes there's a transaction and within that transaction some SQL queries will be done. However it also needs a certain amount of knowledge about how the function is implemented because the developer needs to tell after how many SQL queries you want to inject a fault and you want to do at a point where there's already a observable change happening in the transaction and not fault inject if the transaction only contains `SELECT` queries.
I'm sure you could design a smart fault injector that can do such guess work (although it sounds like a topic for a PhD thesis) and you could design a helper function that can then guide the fault injector to find every interesting place to do a fault injection and ensure the transaction always falls back; as a first prototype having the programmer tell after how many SQL queries a fault should be injected is sufficient for a lot of the transaction we are going to test in Forgejo.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9314
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
This change comes from Codeberg's Forgejo fork and has been in deployed in production for a month now. (https://codeberg.org/Codeberg-Infrastructure/forgejo/commit/de372975c703b1368ce6d538de1b21f20c6f3a84)
What we noticed on Codeberg is that navigating to the organisation's home was quite slow, for example https://codeberg.org/forgejo, this was caused by searching for the repositories that is owned by the organisation. The expensive part of this SQL was that it tried to show repositories where the organisation is a collaborator of... which is none as you cannot add organisations as a collaborator. Not doing this made the SQL query very fast again.
There's no test associated with this, as it's essentially a no-op before and after. So no testing would fail without this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9309
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Adds new a function, `AcceptsGithubResponse`, to the API router context struct to check if the requests accepts a Github response. Although Forgejo API will never be compatible with the Github API, historically Forgejo's API has been designed to follow that of Github closely and we know that a lot of tooling that uses the Github API can be used against the Forgejo API with little to no problem.
As a meet in the middle solution, this function can be used to respond with a more appropriate response that follows the Github API. This allows Forgejo to avoid breaking compatibility with existing users of the API and allows the API to be oh so slightly more compatible with that of Github for API clients that expect a Github response.
Because the `upload_url` field was added purely to match the Github API (forgejo/forgejo#580), it is fair to actually make it compatible with how the Github API intended it to be and that is by adding `{?name,label}` which is used by Github's Oktokit.
Only add `{?name,label}` when Forgejo knows the request accepts a Github response. This avoids breaking the API compatibility with non-Github API clients.
ResolvesCodeberg/Community#2132
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9285
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
- CSRF has to be validated for any request that can change the state, in
practice this means any HTTP request where the method isn't
GET/HEAD/OPTIONS.
- The code only considered POST to be a state-changing request.
- Forgejo has several PUT/DELETE (that changes state) routes for which
no CSRF was being validated.
- Change the code to validate CSRF for all non-"safe" methods.
- The creation of new API tokens for users via the API is guarded behind
a extra check. This extra makes sure the user is authorized via the
reverse proxy method (if enabled) or via basic authorization.
- For, what seems to me, historical reasons the basic authorization also
handles logging in via the API token.
- This results in a API token (with `write:user` scope) or OAuth2 token
being able to create a new API token with escalated privileges.
- Add a new condition to this check to ensure the user logged in via
password.
- Change error to better indicate what went wrong.
- When cloning with credentials is used, don't set the credentials in
the URL and pass that to Git, instead use Git credential helper to pass
the credential. This avoids the credentials to be leaked through the
process list.
Do not allow credentials to be present in the URLs that are provided for
migrations and push mirrors. They have to be given via the dedicated
input fields. Give a error when this happens.
There's nothing wrong with trying have the backend "correct" this, but
would be a larger patch than necessary in the context of a security fix.
This can be done in public.
