Add well-known security.txt #9890

New Issue

GiteaMirror · 2025-11-02T08:52:23-06:00

GiteaMirror commented

2025-11-02 08:52:23 -06:00

Originally created by @6543 on GitHub (Nov 25, 2022).

Originally assigned to: @6543 on GitHub.

the security.txt described in RFC 9116 should be signed by giteas bot key and should be able to be overwritten ... like other custom templates.

Originally created by @6543 on GitHub (Nov 25, 2022). Originally assigned to: @6543 on GitHub. the [security.txt](https://securitytxt.org/) described in [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116) should be signed by giteas bot key and should be able to be overwritten ... like other custom templates.

GiteaMirror added the type/feature label 2025-11-02 08:52:23 -06:00

GiteaMirror closed this issue

2025-11-02 08:52:23 -06:00

GiteaMirror commented

2025-11-02 08:52:24 -06:00

@6543 commented on GitHub (Nov 25, 2022):

easyest way would be to just write a template and add this route ...
... more advanced way would be to write a lib that can generate, parse and validate according, and use the instance gpg key for signing if changes where made ... else use the gpg key of gitea-bot to sign

example:

@6543 commented on GitHub (Nov 25, 2022): easyest way would be to just write a template and add this route ... ... more advanced way would be to write a lib that can generate, parse and validate according, and use the instance gpg key for signing if changes where made ... else use the gpg key of gitea-bot to sign example: - https://github.com/.well-known/security.txt - https://www.google.com/.well-known/security.txt - https://www.dropbox.com/.well-known/security.txt

GiteaMirror commented

2025-11-02 08:52:24 -06:00

@caesar commented on GitHub (Nov 25, 2022):

Will it be possible for the insurance admin to opt into also receiving reports, or only by replacing the whole file via the templates mechanism?

@caesar commented on GitHub (Nov 25, 2022): Will it be possible for the insurance admin to opt into also receiving reports, or only by replacing the whole file via the templates mechanism?

GiteaMirror commented

2025-11-02 08:52:24 -06:00

@silverwind commented on GitHub (Nov 25, 2022):

easyest way would be to just write a template

I'd just expose the individual values as config options. Easier to use than custom templates.

@silverwind commented on GitHub (Nov 25, 2022): > easyest way would be to just write a template I'd just expose the individual values as config options. Easier to use than custom templates.

GiteaMirror commented

2025-11-02 08:52:24 -06:00

@alex19srv commented on GitHub (Jul 7, 2023):

Hello.
I want to implement this feature. My vision: add app.ini-> security section SECURITY_TXT_FILE optional key with path to security.txt file. If key defined and file does not exist - report failure. If not defined/empty - use hardcoded security.txt value.

The reason for such architecture - .ini files do not support multiline values (and if do support security.txt content need to be written in single line - this is inconvenient). Also separate file allow easy support for signed security.txt file content. In such situation I do not see how "individual values as config options" will work better then bulk hardcoded security.txt + custom file (suggestions are welcome if I missed some usecase).

In My version custom security.txt easily supported also as signed version. Fallback for default value will work in 99% cases.

Excuse my english if something not clear.

@alex19srv commented on GitHub (Jul 7, 2023): Hello. I want to implement this feature. My vision: add `app.ini`-> `security` section `SECURITY_TXT_FILE` optional key with path to `security.txt` file. If key defined and file does not exist - report failure. If not defined/empty - use hardcoded `security.txt` value. The reason for such architecture - `.ini` files do not support multiline values (and if do support security.txt content need to be written in single line - this is inconvenient). Also separate file allow easy support for signed `security.txt` file content. In such situation I do not see how "individual values as config options" will work better then bulk hardcoded `security.txt` + custom file (suggestions are welcome if I missed some usecase). In My version custom `security.txt` easily supported also as signed version. Fallback for default value will work in 99% cases. Excuse my english if something not clear.

GiteaMirror commented

2025-11-02 08:52:24 -06:00

@wxiaoguang commented on GitHub (Jul 8, 2023):

My suggestion is not adding a new config key.

But make Gitea can read serve files in "CustomPath/web-well-known" as its "http://gitea/.well-known" directory. Then users could add anything they like, not only the "security.txt"

@wxiaoguang commented on GitHub (Jul 8, 2023): My suggestion is not adding a new config key. But make Gitea can read serve files in "CustomPath/web-well-known" as its "http://gitea/.well-known" directory. Then users could add anything they like, not only the "security.txt"

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9890