Mainly for MySQL/MSSQL.
It is important for Gitea to use case-sensitive database charset
collation. If the database is using a case-insensitive collation, Gitea
will show startup error/warning messages, and show the errors/warnings
on the admin panel's Self-Check page.
Make `gitea doctor convert` work for MySQL to convert the collations of
database & tables & columns.
* Fix#28131
## ⚠️ BREAKING ⚠️
It is not quite breaking, but it's highly recommended to convert the
database&table&column to a consistent and case-sensitive collation.
- Resolves https://github.com/go-gitea/gitea/issues/22493
- Related to https://github.com/go-gitea/gitea/issues/4520
Some admins prefer all timestamps to display the full date instead of
relative time. They can do that now by setting
```ini
[ui]
PREFERRED_TIMESTAMP_TENSE = absolute
```
This setting is set to `mixed` by default, allowing dates to render as
"5 hours ago". Here are some screenshots of the UI with this setting set
to `absolute`:
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: delvh <dev.lh@web.de>
According to [Debian
docs](https://wiki.debian.org/DebianRepository/UseThirdParty):
> The certificate MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded
by apt-key add.
> ...
> If future updates to the certificate will be managed by an apt/dpkg
package as recommended below, then it SHOULD be downloaded into
/usr/share/keyrings using the same filename that will be provided by the
package. If it will be managed locally , it SHOULD be downloaded into
/etc/apt/keyrings instead.
> ...
> A sources.list entry SHOULD have the signed-by option set.
The CORS code has been unmaintained for long time, and the behavior is
not correct.
This PR tries to improve it. The key point is written as comment in
code. And add more tests.
Fix#28515Fix#27642Fix#17098
Update more actions to use nodejs20 runtime and also update the docs for
checkout action usage.
similar to:
- #27836
- #27096
---------
Signed-off-by: Rui Chen <rui@chenrui.dev>
Nowadays, cache will be used on almost everywhere of Gitea and it cannot
be disabled, otherwise some features will become unaviable.
Then I think we can just remove the option for cache enable. That means
cache cannot be disabled.
But of course, we can still use cache configuration to set how should
Gitea use the cache.
* Close#28444
* Actually, it doesn't need to use that trick because it looks like it
is not necessary, no user really needs it
* Remove the hidden (legacy) "doctor" subcommand and update documents
* Fix "actions" usage
Several fields in the "Verify group membership in LDAP" docs were
confusingly titled when compared to the actual fields in the
application, this change rectifies that by matching the docs to the
fields already present in gitea.
Signed-off-by: David Hulick <dave.hulick@gmail.com>
Close#28287
## How to test it in local
convert Makefile L34 into:
```
cd .tmp/upstream-docs && git clean -f && git reset --hard && git fetch origin pull/28302/head:pr28302 && git switch pr28302
```
https://gitea.com/gitea/gitea-docusaurus/actions/runs/661/jobs/0#jobstep-9-39
I noticed that there are many warning logs in building docs.
It is causing 404 in docs.gitea.com now, so we need to fix it.
And there are also some other problems in v1.19 which can not be done in
this PR.
ps: Are there any good methods to test this in local?
https://blog.gitea.com/release-of-1.20.0/#-user-profile-readme-23260
(#23260) did introduce Profile Readme for Users.
This makes it usable for Organisations:
---
*Sponsored by Kithara Software GmbH*
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
The bug has been fixed for several months in the
`docker/build-push-action`
The fix commit is
[d8823bfaed](d8823bfaed)
as the Gitea Actions Doc mentioned too.
This patchset changes the connection string builder to use net.URL and
the host/port parser to use the stdlib function for splitting host from
port. It also adds a footnote about a potentially required portnumber
for postgres UNIX sockets.
Fixes: #24552
See [issue on
gitea.com](https://gitea.com/gitea/gitea-docusaurus/issues/38), copied
below for convenience:
> Hello, may I first confirm that the app.ini PROTOCOL config is case
sensitive (must be lowercase)?
>
> If so, I'd like to suggest for it to be highlighted in the [HTTPS
Setup](https://docs.gitea.com/administration/https-setup#using-the-built-in-server)
page.
> Perhaps something like:
> For the PROTOCOL=https field, make sure https is lowercase. Writing
PROTOCOL=HTTPS may result in a SSL_ERROR_RX_RECORD_TOO_LONG error on
Firefox or ERR_SSL_PROTOCOL_ERROR on Chrome and Edge.
>
> Background
> At first I carelessly wrote PROTOCOL=HTTPS in my app.ini, and Firefox
didn't allow me to connect because:
> Secure Connection Failed
> An error occurred during a connection to gitea.local.lan. SSL received
a record that exceeded the maximum permissible length.
> Error code: SSL_ERROR_RX_RECORD_TOO_LONG
> I spent maybe half an hour troubleshooting my certs, ports, and other
configs before backtracking to the start and realizing the
capitalization difference there 😅. When I changed that config to
lowercase, it worked.
For this PR I added the note in the Config Cheat Sheet page and fixed
the links to it from the HTTPS Setup page.
Was originally thinking to put the note in the HTTPS Setup page itself,
but since there are 2 sections referencing the PROTOCOL config, I was
thinking it'd be neater and more concise to put it in the Config Cheat
Sheet page instead. Especially since both sections already link to it,
and I actually tried to check that link quite early on in my
troubleshooting (but didn't pay much attention to it since the link was
broken).
## Before/After screenshots as per [this repo's
docs](https://github.com/go-gitea/gitea/tree/main/docs)
Before - links
Note: For this the links weren't broken, the links fix is because they
were broken on gitea.com's docs (see below).
After - links
Before - config cheat sheet
After - config cheat sheet
## Before/After screenshots as per [gitea.com's
docs](https://gitea.com/gitea/gitea-docusaurus)
Before - links
After - links
Before - config cheat sheet
After - config cheat sheet
Closes#27455
> The mechanism responsible for long-term authentication (the 'remember
me' cookie) uses a weak construction technique. It will hash the user's
hashed password and the rands value; it will then call the secure cookie
code, which will encrypt the user's name with the computed hash. If one
were able to dump the database, they could extract those two values to
rebuild that cookie and impersonate a user. That vulnerability exists
from the date the dump was obtained until a user changed their password.
>
> To fix this security issue, the cookie could be created and verified
using a different technique such as the one explained at
https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#secure-remember-me-cookies.
The PR removes the now obsolete setting `COOKIE_USERNAME`.
