Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add well-known security.txt #21942

Closed
6543 opened this issue Nov 25, 2022 · 5 comments · Fixed by #25974
Closed

Add well-known security.txt #21942

6543 opened this issue Nov 25, 2022 · 5 comments · Fixed by #25974
Assignees
@6543
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active.

Comments

@6543
Copy link
Member

6543 commented Nov 25, 2022

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.
@6543 6543 added the type/feature Completely new functionality. Can only be merged if feature freeze is not active. label Nov 25, 2022
@6543 6543 self-assigned this Nov 25, 2022
@6543
Copy link
Member Author

6543 commented Nov 25, 2022 •
edited

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:

@caesar
Copy link
Contributor

caesar commented 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?

@silverwind
Copy link
Member

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.

@alex19srv
Copy link

alex19srv commented Jul 7, 2023 •
edited

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.

@wxiaoguang
Copy link
Contributor

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"

@alex19srv alex19srv mentioned this issue Jul 14, 2023
Closed
@wxiaoguang wxiaoguang mentioned this issue Jul 16, 2023
Merged
silverwind pushed a commit that referenced this issue Jul 18, 2023
@wxiaoguang @6543 @GiteaBot
Move public asset files to the proper directory (#25907)
faa28b5 
Move `public/*` to `public/assets/*`

Some old PRs (like #15219) introduced inconsistent directory system.

For example: why the local directory "public" is accessed by
`http://site/assets`? How to serve the ".well-known" files properly in
the public directory?

For convention rules, the "public" directory is widely used for the
website's root directory. It shouldn't be an exception for Gitea.

So, this PR makes the things consistent:

* `http://site/assets/foo` means `{CustomPath}/public/assets/foo`.
* `{CustomPath}/public/.well-known` and `{CustomPath}/public/robots.txt`
can be used in the future.

This PR is also a prerequisite for a clear solution for:
* #21942
* #25892 
* discourse.gitea.io: [.well-known path serving custom files behind
proxy?](https://discourse.gitea.io/t/well-known-path-serving-custom-files-behind-proxy/5445/1)

This PR is breaking for users who have custom "public" files (CSS/JS).
After getting approvals, I will update the documents.

----

## ⚠️ BREAKING ⚠️

If you have files in your "custom/public/" folder, please move them to
"custom/public/assets/".

---------

Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Giteabot <teabot@gitea.io>
@wxiaoguang wxiaoguang mentioned this issue Jul 19, 2023
Merged
silverwind added a commit that referenced this issue Jul 21, 2023
@wxiaoguang @silverwind @GiteaBot
Serve pre-defined files in "public", add "security.txt", add CORS hea…
52fb936 
…der for ".well-known" (#25974)

Replace #25892

Close  #21942
Close  #25464

Major changes:

1. Serve "robots.txt" and ".well-known/security.txt" in the "public"
custom path
* All files in "public/.well-known" can be served, just like
"public/assets"
3. Add a test for ".well-known/security.txt"
4. Simplify the "FileHandlerFunc" logic, now the paths are consistent so
the code can be simpler
5. Add CORS header for ".well-known" endpoints
6. Add logs to tell users they should move some of their legacy custom
public files

```
2023/07/19 13:00:37 cmd/web.go:178:serveInstalled() [E] Found legacy public asset "img" in CustomPath. Please move it to /work/gitea/custom/public/assets/img
2023/07/19 13:00:37 cmd/web.go:182:serveInstalled() [E] Found legacy public asset "robots.txt" in CustomPath. Please move it to /work/gitea/custom/public/robots.txt
```
This PR is not breaking.

---------

Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Giteabot <teabot@gitea.io>
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@6543 6543

Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Projects
None yet
Milestone
No milestone
5 participants
@silverwind @caesar @wxiaoguang @6543 @alex19srv