Please show an example on https://try.gitea.io.

Docs recommend a global var ctx = context.TODO(), maybe it would be more performant to do that instead of recreating that context every time?

:rocket:

And https://github.com/go-gitea/gitea/pull/13649 makes avatars actually cachable by removing the redirects. This should pretty much solve this performance issue in most cases, but actual image resizing would still be nice to have.

This is ready for review now. Turns out org avatars were already working and caching, I was just confused by their different URL scheme (they use /avatars/num instead of storage paths).

I don't think there is anything left to clean up from the old avatar code, bits and pieces are still in use in some places.

make fmt missing?

Measured the perf, and formatIntl doesn't really add much overhead. Even on 4x slowdown, just a few milliseconds here and there. It seems trivial.

5kB added to the base bundle size, not bad.

I also added some (fairly bad) French translations, but I'm just trying to get one other language supported so I can start testing.

This will undoubtedly not be the final design, but right now this is pretty good for testing and to at least unblock people who want to add translations.

LOCALE=fr yarn build will build a French version.

as title

<!-- 1. Please speak English, this is the language all of us can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/NsatcWJ) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. -->

Hi :wave:

• Gitea version (or commit ref): v1.7.0
• Git version: v2.11.0
• Operating system: Debian 9
• Database (use [x]):
  • [X] PostgreSQL
  • [ ] MySQL
  • [ ] MSSQL
  • [ ] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • [ ] Yes (provide example URL)
  • [ ] No
  • [X] Not relevant
• Log gist:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x872bbc]
goroutine 853 [running]:
code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh.newPacketCipher(0x2808d77, 0x1, 0x1, 0x2808d78, 0x1, 0x1, 0x2808d79, 0x1, 0x1, 0xc0026c6040, ...)
        /go/src/code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh/transport.go:245 +0x15c
code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh.(*transport).prepareKeyChange(0xc0000b87e0, 0xc001285500, 0xc000908200, 0xc001285500, 0xc00258ac00)
        /go/src/code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh/transport.go:80 +0xeb
code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh.(*handshakeTransport).enterKeyExchange(0xc0000f62c0, 0xc00233b800, 0x588, 0x588, 0x1, 0x1)
        /go/src/code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh/handshake.go:598 +0x3d0
code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh.(*handshakeTransport).kexLoop(0xc0000f62c0)
        /go/src/code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh/handshake.go:301 +0x1d6
created by code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh.newServerTransport
        /go/src/code.gitea.io/gitea/vendor/golang.org/x/crypto/ssh/handshake.go:143 +0x105

Description

When using the built-in SSH server, the application is crashing when SSH connections occurred.

It was already the case on the v1.6.X branch. If needed, I can run further tests on my own.

Thanks, bye :bow:

EDIT : Maybe related to #5460 (?). The OP didn't precise whether its instance crashed or not though.

It looks like I can't reproduce as of 1.12.6. Although, I haven't tried it in a long time so it might have been fixed before.

Bye, closing here :wave:

<!-- NOTE: If your issue is a security concern, please send an email to [email protected] instead of opening a public issue -->

<!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. -->

• Gitea version (or commit ref): 1.12.3 (Codeberg)

Description

When using anchors within the same Markdown doc, then upon save everything works fine. The anchors are processed and the prefix user-content- is added.

But when referencing an anchor in another Markdown document in the same repo, then this doesn't work, and the prefix must be manually added to the anchor text. E.g.

- [Header 1 works](#header-1-works)
- [Subpage Header 1 does not](subfolder/subpage.md#subpage-header-1-does-not)
- [Subpage Header 1 prefixed does](subfolder/subpage.md#user-content-subpage-header-1-prefixed-does)

And <a href="subfolder/subpage.md#subpage-header-1">does not work either.</a>

# Header 1 works

Maybe it is hard to change this behavior, as it would require more parsing and checks of the referenced page, probably. But for working in a documentation repository with potentially many pages and cross-references (I intend to follow readme-driven development) this will be very confusing for all the people involved in refining said docs.

Update discord domain in webhook repository settings.

Reference Article

Update discord domain in webhook repository settings.

Reference Article

• Use CSS vars for all markdown colors
• Tweak repo header, removing double borders and adjust sizes
• Use menu instead of buttons for issue open/close switcher
• Add emoji inversion for select emoji glyphs in arc-green
• Use border over box-shadow for all buttons
• Add spacing element to login form without openid

I only suggested autodetection for the tests, to implement the suggestion on https://github.com/go-gitea/gitea/pull/13462#issuecomment-723537202

E.g., we can detect what is supported on the platform with a ssh connection, and test only those type of keys. If we can't connect by ssh during the tests, they would fail anyway no matter what keys we try.

Codecov Report

Merging #13746 (e173df2) into master (e00a355) will decrease coverage by 0.00%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #13746      +/-   ##
==========================================
- Coverage   42.22%   42.22%   -0.01%     
==========================================
  Files         699      699              
  Lines       76957    76957              
==========================================
- Hits        32498    32494       -4     
- Misses      39098    39099       +1     
- Partials     5361     5364       +3     

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update e00a355...e173df2. Read the comment docs.

• github.com/alecthomas/chroma v0.8.1 -> v0.8.2
• github.com/blevesearch/bleve v1.0.12 -> v1.0.13
• github.com/editorconfig/editorconfig-core-go v2.3.8 -> v2.3.9
• github.com/klauspost/compress v1.11.2 -> v1.11.3
• github.com/minio/minio-go v7.0.5 -> v7.0.6

I've been thinking about how to write about running gitea in the security context of a dedicated user (see 1. above) for a bit - because it contradicts parts of the existing setup guide for Windows. I wonder how to best frame it. As an alternative approach? As an FAQ? Replacing the contradicting parts for consistency?

Setting the Windows service up to log on as a dedicated user account seems to work just fine. That raised the following question that I wanted to throw into the ring:

Why does the existing documentation recommend running gitea as the LocalSystem account on Windows?

Especially because there are major security implications associated with doing so?

I found this being either explicitly or implicitly recommended in the following docs:

1. https://docs.gitea.io/en-us/windows-service/#prerequisites

RUN_USER = COMPUTERNAME$

Sets Gitea to run as the local system user.

authored by @ve3

2. https://docs.gitea.io/en-us/#system-requirements

Gitea should be run with a dedicated non-root system account on UNIX-type systems.

changed by @MTecknology and @bkcsoft from the original:

Gitea is supposed to be run with a dedicated non-root user account on UNIX systems, no other mode of operation is supported. (NOTE: in case you run it with your own user account and the built-in SSH server disabled, Gitea modifies the ~/.ssh/authorized_keys file so you will not be able to interactively log in.)

3. https://docs.gitea.io/en-us/faq/#ssh-common-errors (not specific to Windows)

Check the permissions of the .ssh directory in the system user’s home directory.

Make sure that the git system user has a usable shell set

authored by @techknowlogick @jolheiser

Does anyone remember the reason why this was the recommended Windows setup? I can't seem to find any documented reason for this recommendation. Cheers!

Codecov Report

Merging #13695 (2cf8c45) into master (e00a355) will increase coverage by 0.03%. The diff coverage is 82.35%.

@@            Coverage Diff             @@
##           master   #13695      +/-   ##
==========================================
+ Coverage   42.22%   42.26%   +0.03%     
==========================================
  Files         699      699              
  Lines       76957    76974      +17     
==========================================
+ Hits        32498    32530      +32     
+ Misses      39098    39083      -15     
  Partials     5361     5361              

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update e00a355...2cf8c45. Read the comment docs.

Addressed in https://github.com/go-gitea/gitea/pull/13744.

Adjusted the remaining instances of open/close button combos as well. Their template can not easily be shared because the use different hrefs.

Codecov Report

Merging #13630 (d8cd33e) into master (e00a355) will decrease coverage by 0.02%. The diff coverage is 8.45%.

@@            Coverage Diff             @@
##           master   #13630      +/-   ##
==========================================
- Coverage   42.22%   42.20%   -0.03%     
==========================================
  Files         699      700       +1     
  Lines       76957    77028      +71     
==========================================
+ Hits        32498    32512      +14     
- Misses      39098    39152      +54     
- Partials     5361     5364       +3     

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update e00a355...d8cd33e. Read the comment docs.