Commit 360b3fd17c (Include username in email headers (#28981),
2024-02-03) adds usernames to the From field of notification emails in
the form of `Display Name (@username)`, to prevent spoofing. However,
some email filtering software flags "@" in the display name part of the
From field as potential spoofing, as you could set the display name part
to another email address than the one you are sending from (e.g.
`From: "apparent@email-address" <actual@email-address>`). To avoid
being flagged, instead send emails from `Display Name (username)`.
Closes: #29107
---------
Co-authored-by: Giteabot <teabot@gitea.io>
- Use maintained fork https://github.com/golangci/misspell
- Rename `mispell-check` to `lint-spell`, add `lint-spell-fix`
- Run `lint-spell` in separate actions step
- Lint more files, fix discovered issues
- Remove inaccurate and outdated info in docs (we do not need GOPATH for
tools anymore)
Maybe later we can add more spellchecking tools, but I have not found
any good ones yet.
Replace #28849. Thanks to @yp05327 for the looking into the problem.
Fix#28840
The old behavior of newSignatureFromCommitline is not right. The new
parseSignatureFromCommitLine:
1. never fails
2. only accept one format (if there is any other, it could be easily added)
And add some tests.
IE usage has dropped enough to not be included in the defaults
browserslist anymore as per https://browsersl.ist/#q=defaults, so we can
use the defaults now.
I'm using this convention in other projects and I think it makes sense
for gitea too because the vitest setup file is loaded globally for all
tests, not just ones in web_src, so it makes sense to be in the root.
Outgoing new release e-mail notifications were missing links to the
actual release. An example from Codeberg.org e-mail:
<a href=3D"">View it on Codeberg.org</a>.<br/>
This PR adds `"Link"` context property pointing to the release on the
web interface.
The change was tested using `[mailer] PROTOCOL=dummy`.
Signed-off-by: Wiktor Kwapisiewicz <wiktor@metacode.biz>
When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.
Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.
Fixes: https://github.com/go-gitea/gitea/issues/29084
Try to improve #28949
1. Make `ctx.Data["ShowOutdatedComments"] = true` by default: it brings
consistent user experience, and sometimes the "outdated (source
changed)" comments are still valuable.
2. Show a friendly message if the comment won't show, then the end users
won't fell that "the comment disappears" (it is the special case when
`ShowOutdatedComments = false`)
Fix for gitea putting everything into one request without batching and
sending it to Elasticsearch for indexing as issued in #28117
This issue occured in large repositories while Gitea tries to
index the code using ElasticSearch.
I've applied necessary changes that takes batch length from below config
(app.ini)
```
[queue.code_indexer]
BATCH_LENGTH=<length_int>
```
and batches all requests to Elasticsearch in chunks as configured in the
above config
Remove lightningcss and minify with esbuild again. The size of output
CSS will increase by around 1.4%, but I think it's worth it to allow
building gitea in more cases like the one in the linked issue. We can
reconsider once lightningcss becomes more stable.
Fixes: https://github.com/go-gitea/gitea/issues/29058
- The watch/unwatch button and star/unstar get their own template
- The backend returns HTML instead of redirect
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Resolves https://github.com/go-gitea/gitea/issues/28704
Example of an entry in the generated `APKINDEX` file:
```
C:Q1xCO3H9LTTEbhKt9G1alSC87I56c=
P:hello
V:2.12-r1
A:x86_64
T:The GNU Hello program produces a familiar, friendly greeting
U:https://www.gnu.org/software/hello/
L:GPL-3.0-or-later
S:15403
I:36864
o:hello
m:
t:1705934118
D:so:libc.musl-x86_64.so.1
p:cmd:hello=2.12-r1
i:foobar=1.0 !baz
k:42
```
the `i:` and `k:` entries are new.
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
Fixes#28660
Fixes an admin api bug related to `user.LoginSource`
Fixed `/user/emails` response not identical to GitHub api
This PR unifies the user update methods. The goal is to keep the logic
only at one place (having audit logs in mind). For example, do the
password checks only in one method not everywhere a password is updated.
After that PR is merged, the user creation should be next.
Follow #28654
The `comments` might be empty, so the templates shouldn't (and couldn't)
use it to render. When there is no comment, the UI should also be
updated to empty, so returning an empty body is good enough.
This PR adds a new `must-change-password` parameter to the
`change-password` cli command.
We already have the `must-change-password` command but it feels natural
to have this integrated into the `change-password` cli command.
---------
Co-authored-by: 6543 <6543@obermui.de>
Emails from Gitea comments do not contain the username of the commenter
anywhere, only their display name, so it is not possible to verify who
made a comment from the email itself:
From: "Alice" <email@gitea>
X-Gitea-Sender: Alice
X-Gitea-Recipient: Bob
X-GitHub-Sender: Alice
X-GitHub-Recipient: Bob
This comment looks like it's from @alice.
The X-Gitea/X-GitHub headers also use display names, which is not very
reliable for filtering, and inconsistent with GitHub's behavior:
X-GitHub-Sender: lunny
X-GitHub-Recipient: gwymor
This change includes both the display name and username in the From
header, and switches the other headers from display name to username:
From: "Alice (@fakealice)" <email@gitea>
X-Gitea-Sender: fakealice
X-Gitea-Recipient: bob
X-GitHub-Sender: fakealice
X-GitHub-Recipient: bob
This comment looks like it's from @alice.
This change allows act_runner / actions_runner to use jwt tokens for
`ACTIONS_RUNTIME_TOKEN` that are compatible with
actions/upload-artifact@v4.
The official Artifact actions are now validating and extracting the jwt
claim scp to get the runid and jobid, the old artifact backend also
needs to accept the same token jwt.
---
Related to #28853
I'm not familar with the auth system, maybe you know how to improve this
I have tested
- the jwt token is a valid token for artifact uploading
- the jwt token can be parsed by actions/upload-artifact@v4 and passes
their scp claim validation
Next steps would be a new artifacts@v4 backend.
~~I'm linking the act_runner change soonish.~~
act_runner change to make the change effective and use jwt tokens
<https://gitea.com/gitea/act_runner/pulls/471>
Behaviour now matches GH. Safeguard added in the for loop because
`textContent` may be null in which case it does not make sense to render
the copy button.
