search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.09k stars 5.49k forks source link

Private attachments #23071

Open delvh opened 1 year ago

delvh commented 1 year ago

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. 
    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:

  3. What UI would result in a good user experience for this?
  4. How to avoid performance problems? Every query for an attachment now needs a database query…
KN4CK3R commented 1 year ago

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

wxiaoguang commented 1 year ago

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

lunny commented 1 year ago

I think this has already been implemented by #9340 ?

delvh commented 1 year ago

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.

lunny commented 1 year ago

Then this should be a part of #3217 ?

delvh commented 1 year ago

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.

GiteaBot commented 1 year ago

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

KN4CK3R commented 1 year ago

I think this should remain open.