Private attachments #10321

New Issue

GiteaMirror · 2025-11-02T09:04:14-06:00

GiteaMirror commented

2025-11-02 09:04:14 -06:00

Originally created by @delvh on GitHub (Feb 22, 2023).

Feature Description

At the moment, any attachment you upload on a gitea instance will be publicly available,
i.e. https://try.gitea.io/attachments/a35cb41a-1afe-4415-bb8c-6058e29e9e21.

This is not always a good idea, as sometimes attachments are files that should be hidden from the public, i.e. personal information or security concerns.
This is especially a requirement for private issues, as otherwise no attachments can be safely shared.

Proposal

In addition to the existing upload mechanism that uploads to /attachments/<UUID>, we should add a second mechanism that returns 404 if the user is not allowed to read this attachment.
I can think of two possible implementations for the backend:

Add a separate path structure /attachments/private/<context>/UUID to store private attachments, where <context> can be for example <user>/<repo>/<comment-id>
Add a proxy before returning the attachment that stores in the db the necessary information for private attachments, i.e.

type AttachmentInfo struct {
  ID int64
  AttachmentID string `xorm:"UNIQUE"`
  RepoID int64
  PosterID int64

Then, if no attachment info exists, the attachment is public, and otherwise the user must be the poster of this attachment, or have (at least) read access to issues (and PRs) on this repo.
The edge case attachmentInfo exists (=> attachment is private) && user is not logged in should probably still result in not showing the attachment, as a private attachment should always mean "only logged in users can see it", otherwise it could also be public.
The problem with this feature are especially two points:

What UI would result in a good user experience for this?
How to avoid performance problems? Every query for an attachment now needs a database query…

Originally created by @delvh on GitHub (Feb 22, 2023). ### Feature Description At the moment, any attachment you upload on a gitea instance will be publicly available, i.e. https://try.gitea.io/attachments/a35cb41a-1afe-4415-bb8c-6058e29e9e21. This is not always a good idea, as sometimes attachments are files that should be hidden from the public, i.e. personal information or security concerns. This is especially a requirement for private issues, as otherwise no attachments can be safely shared. ## Proposal In addition to the existing upload mechanism that uploads to `/attachments/<UUID>`, we should add a second mechanism that returns `404` if the user is not allowed to read this attachment. I can think of two possible implementations for the backend: 1. Add a separate path structure `/attachments/private/<context>/UUID` to store private attachments, where `<context>` can be for example `<user>/<repo>/<comment-id>` 2. Add a proxy before returning the attachment that stores in the db the necessary information for private attachments, i.e. ```go type AttachmentInfo struct { ID int64 AttachmentID string `xorm:"UNIQUE"` RepoID int64 PosterID int64 ``` Then, if no attachment info exists, the attachment is public, and otherwise the user must be the poster of this attachment, or have (at least) read access to issues (and PRs) on this repo. The edge case `attachmentInfo exists (=> attachment is private) && user is not logged in` should probably still result in not showing the attachment, as a private attachment should always mean "only logged in users can see it", otherwise it could also be public. The problem with this feature are especially two points: 1. What UI would result in a good user experience for this? 2. How to avoid performance problems? Every query for an attachment now needs a database query…

GiteaMirror added the type/enhancement type/proposal labels 2025-11-02 09:04:14 -06:00

GiteaMirror commented

2025-11-02 09:04:14 -06:00

@KN4CK3R commented on GitHub (Feb 23, 2023):

Why not use the existing attachment model? Could simply add one more check in repo.GetAttachment then.

@KN4CK3R commented on GitHub (Feb 23, 2023): Why not use the existing attachment model? Could simply add one more check in `repo.GetAttachment` then.

GiteaMirror commented

2025-11-02 09:04:14 -06:00

@wxiaoguang commented on GitHub (Feb 23, 2023):

Just FYI, according to my test, GitHub's issue attachments are also open to public, even in a private repo. I just pasted an image into a private issue: https://user-images.githubusercontent.com/2114189/220891059-1d6e99c6-f906-4e21-9365-0e548ca67a18.png

@wxiaoguang commented on GitHub (Feb 23, 2023): Just FYI, according to my test, GitHub's issue attachments are also open to public, even in a private repo. I just pasted an image into a private issue: https://user-images.githubusercontent.com/2114189/220891059-1d6e99c6-f906-4e21-9365-0e548ca67a18.png

GiteaMirror commented

2025-11-02 09:04:15 -06:00

@lunny commented on GitHub (May 31, 2023):

I think this has already been implemented by #9340 ?

@lunny commented on GitHub (May 31, 2023): I think this has already been implemented by #9340 ?

GiteaMirror commented

2025-11-02 09:04:15 -06:00

@delvh commented on GitHub (Jun 2, 2023):

Partly.
As I've been able to confirm now for completely private repos, attachments won't be shown if the user has no access to them.
However, this issue talks about private issues in a public repo in particular.
You cannot simulate private issues with a private repo as then only people you've granted access can report something that should be kept private.
That's typically not how security sensitive issues work.

@delvh commented on GitHub (Jun 2, 2023): Partly. As I've been able to confirm now for completely private repos, attachments won't be shown if the user has no access to them. However, this issue talks about private issues in a public repo in particular. You cannot simulate private issues with a private repo as then only people you've granted access can report something that should be kept private. That's typically not how security sensitive issues work.

GiteaMirror commented

2025-11-02 09:04:15 -06:00

@lunny commented on GitHub (Jun 2, 2023):

Then this should be a part of #3217 ?

@lunny commented on GitHub (Jun 2, 2023): Then this should be a part of #3217 ?

GiteaMirror commented

2025-11-02 09:04:15 -06:00

@delvh commented on GitHub (Jun 2, 2023):

Well… Yesn't.

This is especially a requirement for private issues, as otherwise no attachments can be safely shared.

I see it as a requirement for implementing private issues.
While it could be implemented in the same PR, I recommend a separate PR to keep the diffs manageable.
That's the whole point why I opened this issue, so that this one gets implemented first.

@delvh commented on GitHub (Jun 2, 2023): Well… Yesn't. > This is especially a requirement for private issues, as otherwise no attachments can be safely shared. I see it as a requirement for implementing private issues. While it could be implemented in the same PR, I recommend a separate PR to keep the diffs manageable. That's the whole point why I opened this issue, so that this one gets implemented first.

GiteaMirror commented

2025-11-02 09:04:16 -06:00

@GiteaBot commented on GitHub (Sep 8, 2023):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Sep 8, 2023): We close issues that need feedback from the author if there were no new comments for a month. :tea:

GiteaMirror commented

2025-11-02 09:04:16 -06:00

@KN4CK3R commented on GitHub (Sep 8, 2023):

I think this should remain open.

@KN4CK3R commented on GitHub (Sep 8, 2023): I think this should remain open.

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#10321