Make Debian repository signing key generation use explicit stronger defaults
and embed the creation time in the OpenPGP comment for newly created keys.
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
- Use `gitrepo.IsRepositoryExist` instead of `util.IsExit` or
`util.IsDir`
- Use `gitrepo.OpenRepository` instead of `git.OpenRepository`
- Use `gitrepo.DeleteRepository` instead of `util.RemoveAll`
- Use `gitrepo.RenameRepository` instead of `util.Rename`
## Summary
This PR adds support for closing keywords (`closes`, `fixes`, `reopens`,
etc.) with full URL references in markdown links.
**Before:**
- `closes #123` ✅ works
- `closes org/repo#123` ✅ works
- `Closes [this issue](https://gitea.io/user/repo/issues/123)` ❌ didn't
work
- `Fixes [#456](https://gitea.io/org/project/issues/456)` ❌ didn't work
**After:**
All of the above now work correctly.
## Problem
When users reference issues using full URLs in markdown links (e.g.,
`Closes [this issue](https://gitea.io/user/repo/issues/123)`), the
closing keywords were not detected. This was because the URL processing
code explicitly stated:
```go
// Note: closing/reopening keywords not supported with URLs
```
Both methods of writing the reference render the same in the UI, so
users expected the closing keywords to behave the same.
## Solution
The fix works by:
1. Passing the original (unstripped) content to
`findAllIssueReferencesBytes`
2. When processing URL links from markdown, finding the URL position in
the original content
3. For markdown links `[text](url)`, finding the opening bracket `[`
position
4. Using that position to detect closing keywords before the link
## Testing
Added test cases for:
- `Closes [this issue](url)` - single URL with closing keyword
- `This fixes [#456](url)` - keyword in middle of text
- `Reopens [PR](url)` - reopen keyword with pull request URL
- Multiple URLs where only one has a closing keyword
All existing tests continue to pass.
Fixes#27549
This pull request adds an option to automatically verify SSH keys from
LDAP authentication sources.
This allows a correct authentication and verification workflow for
LDAP-enabled organizations; under normal circumstances SSH keys in LDAP
are not managed by users manually.
Use the dynamically parsed host in the request for LFS links, but not
use the hard-coded AppURL.
Make LFS server support multi-domain or run Gitea behind a reverse-proxy
with different ROOT_URL.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Crowdin does not remove empty lines in nested JSON translation files.
Therefore, we use flattened translation keys instead. We have also
updated the key-loading logic to ensure that empty values are not
applied during translation.
---------
Signed-off-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: TheFox0x7 <thefox0x7@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
- Replace fomantic form CSS with custom module
- Moved code in `form.css` to `modules/form.css`, removed around 70% of
the previous module.
- Moved captcha styles previously in `form.css` to its own file.
There is probably more unused CSS, like form error state colors which to
my knowledge is not used anywhere, but I'm not sure about that one so I
kept it.
One notable change is the removal of `type` combinator here, which
lowers the selector specificity and I noticed one issue where selector
`.ui.search > .prompt` was winning, so I added a workaround for that
until the `search` module can be removed as well.
```css
.ui.form .fields.error .field input:not([type])
.ui.form .fields.error .field input[type="date"]
```
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
Fixes: https://github.com/go-gitea/gitea/issues/36216
Now `detectWebAuthnSupport` returns the error type and lets the caller
decide whether they call `webAuthnError` and show the error. It no
longer shows the error during page load when the user has not even
interacted with the feature.
The bug affects all users on HTTP, so I think a quick fix release for
this might be good.
ExcellencedevandGitHub
luo jiyinandGitHub
Lunny XiaoandGitHub
alphazebaandGitHub
GiteaBot
Gregorius Bima Kharisma WicaksanaandGitHub
Ivan TkatchevandGitHub
DaanSelenandGitHub