[bug] Custom emoji IDs are on the wrong origin #694

New issue

Closed

opened 2024-02-17 19:13:25 +00:00 by puckipedia · 4 comments

puckipedia commented

2024-02-17 19:13:25 +00:00

Your setup

OTP

Extra details

No response

Version

(this is an issue at least on the last commit)

PostgreSQL version

No response

What were you trying to do?

Render a custom emoji received from an Akkoma instance

What did you expect to happen?

It renders.

What actually happened?

It doesn't render, because the ID of the Emoji tag is equivalent to the url, which may not be on the same origin as the object.

For security reasons, Kroeg, a piece of ActivityPub software, rejects any object that has an ID from a different origin, instead opting to fetch it afresh from that instance. Custom Emoji that are hotlinked from another origin, thus, fall under this category, and are discarded.

See transmogrifier.ex's build_emoji_tag.

Logs

No response

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup OTP ### Extra details _No response_ ### Version (this is an issue at least on the last commit) ### PostgreSQL version _No response_ ### What were you trying to do? Render a custom emoji received from an Akkoma instance ### What did you expect to happen? It renders. ### What actually happened? It doesn't render, because the ID of the `Emoji` tag is equivalent to the `url`, which may not be on the same origin as the object. For security reasons, Kroeg, a piece of ActivityPub software, rejects any object that has an ID from a different origin, instead opting to fetch it afresh from that instance. Custom Emoji that are hotlinked from another origin, thus, fall under this category, and are discarded. See `transmogrifier.ex`'s `build_emoji_tag`. ### Logs _No response_ ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

puckipedia added the

bug

label 2024-02-17 19:13:25 +00:00

floatingghost commented

2024-02-17 19:29:54 +00:00

Owner

this behaviour is correct and not a bug

the only concievable way to react with remote emoji, as we allow, is to rely on the ID of the emoji object

to "correct" that would be to remove the functionality, or would amount to proxying images through the instance

this behaviour is correct and not a bug the only concievable way to react with remote emoji, as we allow, is to rely on the ID of the emoji object to "correct" that would be to remove the functionality, or would amount to proxying images through the instance

floatingghost commented

2024-02-17 19:33:49 +00:00

Owner

additionally please ensure you set the correct severity when you raise an issue - it helps us prioritise

this is not a cannot-use-the-software level issue

additionally please ensure you set the correct severity when you raise an issue - it helps us prioritise this is not a cannot-use-the-software level issue

puckipedia commented

2024-02-17 19:39:02 +00:00

Author

additionally please ensure you set the correct severity when you raise an issue - it helps us prioritise

oh, i did not actually enter anything into that field (i overlooked it), it might not be the best to default that to the highest priority?

the only concievable way to react with remote emoji, as we allow, is to rely on the ID of the emoji object

The issue is that the ID used is that of the image of the emoji, even if it were on a remote server, rather than the ID of the Emoji JSON-LD object.

As an example. Mastodon renders the id of the emoji to be "https://<domain>/emojis/<emoji id>", rather than https://<cdn path>/custom_emojis/images/<numbers>.png; I'd be okay if you used the remote server's Emoji object ID, rather than its image URL, as the ID for the Emoji object, as that can (in many cases) be resolved.

> additionally please ensure you set the correct severity when you raise an issue - it helps us prioritise oh, i did not actually enter anything into that field (i overlooked it), it might not be the best to default that to the highest priority? > the only concievable way to react with remote emoji, as we allow, is to rely on the ID of the emoji object The issue is that the ID used is that of the image of the emoji, even if it were on a remote server, rather than the ID of the Emoji JSON-LD object. As an example. Mastodon renders the `id` of the emoji to be `"https://<domain>/emojis/<emoji id>"`, rather than `https://<cdn path>/custom_emojis/images/<numbers>.png`; I'd be okay if you used the remote server's `Emoji` object ID, rather than its image URL, as the ID for the Emoji object, as that can (in many cases) be resolved.