Attach attachments of issues/comments in notification emails #7042

New Issue

GiteaMirror · 2025-11-02T07:14:15-06:00

GiteaMirror commented

2025-11-02 07:14:15 -06:00

Originally created by @lunny on GitHub (Mar 21, 2021).

When post issues or comments with attachments, some notification emails will be sent to related users. But the attachments is absent.

Originally created by @lunny on GitHub (Mar 21, 2021). When post issues or comments with attachments, some notification emails will be sent to related users. But the attachments is absent.

GiteaMirror added the type/enhancement label 2025-11-02 07:14:15 -06:00

GiteaMirror commented

2025-11-02 07:14:15 -06:00

@craig-tx commented on GitHub (Sep 3, 2021):

When you say 'absent' do you mean that the attachment link is there but not accessible? From what I observe the linked attachment requires authentication to view it - and of course the email client is not authenticated to Gitea (see screenshot).

What could be the workaround? Modify the configuration somehow so that attachments do not require authentication? Of course you would need to accept the security risk of making attachments publicly available.

@craig-tx commented on GitHub (Sep 3, 2021): When you say 'absent' do you mean that the attachment link is there but not accessible? From what I observe the linked attachment requires authentication to view it - and of course the email client is not authenticated to Gitea (see screenshot). What could be the workaround? Modify the configuration somehow so that attachments do not require authentication? Of course you would need to accept the security risk of making attachments publicly available. ![image](https://user-images.githubusercontent.com/16706018/131951276-eca7d404-a046-48f4-9602-c3be3541706c.png)

GiteaMirror commented

2025-11-02 07:14:16 -06:00

@wxiaoguang commented on GitHub (Sep 3, 2021):

The attachment URL is "https://xxxx/team/repo/attachments/222a65d6-b297-4477-bb9b-1c55e46dd4e9", so it won't be displayed unless the repository has public access.

The fix can be "Allow anonymous to access attachments in non-public repositories", but I do not know whether this change affects security concerns. From my side, I think it's OK.

@wxiaoguang commented on GitHub (Sep 3, 2021): The attachment URL is "https://xxxx/team/repo/attachments/222a65d6-b297-4477-bb9b-1c55e46dd4e9", so it won't be displayed unless the repository has public access. The fix can be "Allow anonymous to access attachments in non-public repositories", but I do not know whether this change affects security concerns. From my side, I think it's OK.

GiteaMirror commented

2025-11-02 07:14:16 -06:00

@wxiaoguang commented on GitHub (Sep 3, 2021):

Another more secure design can be:

Add a secret_seed column to attachments table, and generate a random secret for every attachment.

When a attachment should be accessed without authentication, use a URL like "http://.../attachments/xxxxx?timestamp=yyyyyy&sign=zzzzzzzz", the sign is calculated by secret_seed and timestamp.

But this mechanism is too complex. "Allow anonymous to access attachments in non-public repositories" seems enough.

@wxiaoguang commented on GitHub (Sep 3, 2021): Another more secure design can be: Add a `secret_seed` column to `attachments` table, and generate a random secret for every attachment. When a attachment should be accessed without authentication, use a URL like "http://.../attachments/xxxxx?timestamp=yyyyyy&sign=zzzzzzzz", the sign is calculated by secret_seed and timestamp. But this mechanism is too complex. "Allow anonymous to access attachments in non-public repositories" seems enough.

GiteaMirror commented

2025-11-02 07:14:16 -06:00

@craig-tx commented on GitHub (Sep 6, 2021):

secret_seed and timestamp.

Is the idea with this option that the link has a brief lifetime of when it will work? Similar to an Amazon S3 presigned URL that expires after 7 days? I can see how that could help with reducing exposure to possible URL guessing attacks (although attachments being GUIDs already makes that type of attack difficult)

But this mechanism is too complex. "Allow anonymous to access attachments in non-public repositories" seems enough.

I would agree. Allow the admin to decide whether the convenience of rendering attachments unauthenticated is worth the security tradeoff.

@craig-tx commented on GitHub (Sep 6, 2021): > secret_seed and timestamp. Is the idea with this option that the link has a brief lifetime of when it will work? Similar to an Amazon S3 presigned URL that expires after 7 days? I can see how that could help with reducing exposure to possible URL guessing attacks (although attachments being GUIDs already makes that type of attack difficult) > But this mechanism is too complex. "Allow anonymous to access attachments in non-public repositories" seems enough. I would agree. Allow the admin to decide whether the convenience of rendering attachments unauthenticated is worth the security tradeoff.

GiteaMirror commented

2025-11-02 07:14:16 -06:00

@lunny commented on GitHub (Sep 7, 2021):

Another more secure design can be:

Add a secret_seed column to attachments table, and generate a random secret for every attachment.

When a attachment should be accessed without authentication, use a URL like "http://.../attachments/xxxxx?timestamp=yyyyyy&sign=zzzzzzzz", the sign is calculated by secret_seed and timestamp.

But this mechanism is too complex. "Allow anonymous to access attachments in non-public repositories" seems enough.

I don't think this is the best resolution. The link maybe not visited from users' computer directly. And the gitea service maybe stopped because of maintain. I would like embed files in email if it's an image or attachment files in email.

@lunny commented on GitHub (Sep 7, 2021): > Another more secure design can be: > > Add a `secret_seed` column to `attachments` table, and generate a random secret for every attachment. > > When a attachment should be accessed without authentication, use a URL like "http://.../attachments/xxxxx?timestamp=yyyyyy&sign=zzzzzzzz", the sign is calculated by secret_seed and timestamp. > > But this mechanism is too complex. "Allow anonymous to access attachments in non-public repositories" seems enough. I don't think this is the best resolution. The link maybe not visited from users' computer directly. And the gitea service maybe stopped because of maintain. I would like embed files in email if it's an image or attachment files in email.

GiteaMirror commented

2025-11-02 07:14:17 -06:00

@wxiaoguang commented on GitHub (Sep 7, 2021):

@lunny I just tried on GitHub.

What GitHub does is the simple solution: do not limit attachment access.

For example, I uploaded an attachment into my private repository on GitHub, the attachment can be accessed anonymously:

https://user-images.githubusercontent.com/2114189/132302915-624237f7-54f9-42c4-8d19-ba9034bf433d.png

So I think it's still reasonable to use the simple mechanism.

@wxiaoguang commented on GitHub (Sep 7, 2021): @lunny I just tried on GitHub. What GitHub does is the simple solution: do not limit attachment access. For example, I uploaded an attachment into my private repository on GitHub, the attachment can be accessed anonymously: https://user-images.githubusercontent.com/2114189/132302915-624237f7-54f9-42c4-8d19-ba9034bf433d.png So I think it's still reasonable to use the simple mechanism.

GiteaMirror commented

2025-11-02 07:14:17 -06:00

@lunny commented on GitHub (Sep 7, 2021):

Yes, the uuid is generated randomly. It should not be guessed or iterated by others if we don't leak it. So a permission check is not necessary.

@lunny commented on GitHub (Sep 7, 2021): Yes, the `uuid` is generated randomly. It should not be guessed or iterated by others if we don't leak it. So a permission check is not necessary.

GiteaMirror commented

2025-11-02 07:14:17 -06:00

@renothing commented on GitHub (Nov 17, 2021):

the best simple way maybe image embed in content by base64 data directly.
for exmaple:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4
  //8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

https://www.w3docs.com/snippets/html/how-to-display-base64-images-in-html.html

@renothing commented on GitHub (Nov 17, 2021): the best simple way maybe image embed in content by base64 data directly. for exmaple: ``` <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4 //8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" /> ``` [https://www.w3docs.com/snippets/html/how-to-display-base64-images-in-html.html](https://www.w3docs.com/snippets/html/how-to-display-base64-images-in-html.html)

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