- The RSS and atom feed for branches exposes details about the code, it
therefore should be guarded by the requirement that the doer has access
to the code of that repository.
- Added integration testing.
- _Simply_ add `^$` to regexp that didn't had it yet, this avoids any
content being allowed that simply had the allowed content as a
substring.
- Fix file-preview regex to have `$` instead of `*`.
- This unifies the security behavior of enrolling security keys with
enrolling TOTP as a 2FA method. When TOTP is enrolled, you cannot use
basic authorization (user:password) to make API request on behalf of the
user, this is now also the case when you enroll security keys.
- The usage of access tokens are the only method to make API requests on
behalf of the user when a 2FA method is enrolled for the user.
- Integration test added.
- Consider private/limited users in the `AccessibleRepositoryCondition`
query, previously this only considered private/limited organization.
This limits the ability for anomynous users to do code search on
private/limited user's repository
- Unit test added.
- If the incoming mail feature is enabled, tokens are being sent with
outgoing mails. These tokens contains information about what type of
action is allow with such token (such as replying to a certain issue
ID), to verify these tokens the code uses the HMAC-SHA256 construction.
- The output of the HMAC is truncated to 80 bits, because this is
recommended by RFC2104, but RFC2104 actually doesn't recommend this. It
recommends, if truncation should need to take place, it should use
max(80, hash_len/2) of the leftmost bits. For HMAC-SHA256 this works out
to 128 bits instead of the currently used 80 bits.
- Update to token version 2 and disallow any usage of token version 1,
token version 2 are generated with 128 bits of HMAC output.
- Add test to verify the deprecation of token version 1 and a general
MAC check test.
- Add a `purpose` column, this allows the `forgejo_auth_token` table to
be used by other parts of Forgejo, while still enjoying the
no-compromise architecture.
- Remove the 'roll your own crypto' time limited code functions and
migrate them to the `forgejo_auth_token` table. This migration ensures
generated codes can only be used for their purpose and ensure they are
invalidated after their usage by deleting it from the database, this
also should help making auditing of the security code easier, as we're
no longer trying to stuff a lot of data into a HMAC construction.
-Helper functions are rewritten to ensure a safe-by-design approach to
these tokens.
- Add the `forgejo_auth_token` to dbconsistency doctor and add it to the
`deleteUser` function.
- TODO: Add cron job to delete expired authorization tokens.
- Unit and integration tests added.
- Optimize generting random files.
- Reduce big file of 128MiB to 32MiB (git was never made for large files
anyways, but simply tests that it works).
- Reduce looped git operations from 100 iterations to 10.
- Add extra print statements to know what a slow test is doing, this
also helps to see if a particular piece of code in a slow test is the
culprit or if the test is just very extensive.
- Set `[ui.notification].EVENT_SOURCE_UPDATE_TIME` to 1s to speed up
`TestEventSourceManagerRun`.
- Sneaked in some general test improvements.
- Only prepare repositories once.
- Move the repositories to temporary directories (these should usually be stored in
memory) which are recreated for each test to avoid persistentance
between tests. Doing some dirty profiling suggests that the preparing
test functions from 140-100ms to 70-40ms
When the CI vars.ROLE is forgejo-coding, it is assumed to be the
repository where collaborative coding happens,
i.e. https://codeberg.org/forgejo/forgejo
When the CI vars.ROLE is forgejo-testing, it is assumed that only codebase
testing is to be run and no other tests such as release build
integration, label constraints, backporting etc.
When the CI vars.ROLE is forgejo-coding, it is assumed to be the
repository where collaborative coding happens,
i.e. https://codeberg.org/forgejo/forgejo
When the CI vars.ROLE is forgejo-testing, it is assumed that only codebase
testing is to be run and no other tests such as release build
integration, label constraints, backporting etc.
- When a dependency is renamed, specified via `package="actual-name"` in
Cargo.toml, this should become the name of the depedency when the
package is retrieved from the registery by cargo and the old name should
be available in the `package` field.
- The reference implementation also does this: 490e66a9d6/src/controllers/krate/publish.rs (L702-L705)
- Resolves#5936
- Unit test added.
Notify https://code.forgejo.org/forgejo/forgejo that a new release was
published by setting the trigger label to
https://code.forgejo.org/forgejo/forgejo/issues/5.
It is only ever useful when a stable release is published, the
experimental releases are not mirrored. But it is triggered in all
cases. This will waste a few mirror check daily, when experimental
releases are built. This is an improvement compared to the current
situation where mirrors are checked hourly:
* Instead of being checked 24 times per day it will be down to less
than 5
* The mirror happens immediately after the release is published
instead of waiting for the next run of the cron job.
If a mirror operation is in progress, as evidenced by the presence of
the trigger label on the issure, it means two releases are being
published. Wait up to 1h for the mirror to complete and remove the
trigger label.
Goals:
- speedup
- less flakiness
- best practices and more use
- documentation
config:
- sync ports in Makefile and playwright config
(otherwise, some tests fail locally because they assert the full URL including the (wrong) port)
- even more generous timeouts
- limit workers to one again (because I finally understand how
Playwright works)
- allow nested functions to group them together with the related test
all:
- deprecate waitForLoadState('networkidle')
- it is discouraged as per https://playwright.dev/docs/api/class-page#page-wait-for-load-state
- I could not find a usage that seems to require it actually (see
added documentation in README)
- adding an exception should be made explicitly
- it does not do what you might expect anyway in most cases
- only log in when necessary
webauthn:
- verify that login is possible after disabling key
- otherwise, the cleanup was not necessary after the previous refactor to create a fresh user each
issue-sidebar / WIP toggle:
- split into smaller chunks
- restore original state first
- add missed assertion to fix race condition (not waiting
before state was reached)
- explicitly toggle the state to detect mismatch earlier
issue-sidebar / labels:
- restore original state first
- better waiting for background request
