#2201 Releases page is on a different domain
Closed: Invalid 7 years ago Opened 7 years ago by rharwood.

The directory for releases is on a separate domain - .org instead of .io - from the rest of pagure. For instance: https://releases.pagure.org/gssproxy/


Metadata Update from @lslebodn:
- Issue tagged with: IDM

7 years ago

It used to be on pagure.io and we moved it to pagure.org, this is very much in purpose. Since we do not control what is uploaded there, having this in the same domain as the main application could lead to security issue.

Metadata Update from @pingou:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

7 years ago

I don't see how tarballs are an issue but the main repository - which can also be arbitrary uploaded content - is not. Surely placing them on their own subdomain already - releases - is sufficient to prevent any security issues (not that I can think of any, because I can't).

As a point of comparison, GitHub hosts their release tarballs, including all custom-uploaded files, on the same domain (not even a subdomain), just in a subdirectory. See, for instance, python-gssapi's releases.

Metadata Update from @rharwood:
- Issue status updated to: Open (was: Closed)

7 years ago

Uploads done to the releases folder can be anything, including html containing malicious JS to do cross-site scripting.

Using sub-domain is not enough for this, we need an entirely different domain.

Content uploaded in the git repo is loaded by the app, if binary it is not rendered in the browser but offered for download and if text we clean its content to prevent executing malicious code.

These are the exact same reasons as the docs are hosted under pagure.org and not pagure.io.

Also, could you provide some rational on how this is problematic for you? Because I am not sure to see why it is.

@rharwood GitHub does not actually host tarballs on the same domain:
Things you upload yourself get served from https://github-cloud.s3.amazonaws.com/, the auto-generated tarballs from https://codeload.github.com/.

As @pingou said, user-uploaded content could be html with javascript, and we want to prevent XSS attacks.

Another advantage of a separate domain is that it's easier to see that the content is not provided by Pagure itself: this is what Github does better than Pagure even, with its githubusercontent.com.

If Pagure would autogenerate tarballs, I'd be okay with a subdomain, since we know for sure it's a tarball.

If it is a user-uploaded thing, we would need to detect the file type, and then filter based on that what we are going to send as headers, which brings all kinds of difficult problems with it.

For reference: https://developer.github.com/changes/2014-04-25-user-content-security/

If anything, I'd say we need to move more from Pagure to a separate domain.

They're redirects from the github.com domain; regardless of where they can be served from.

It's confusing to have the releases and main repository on different sites. If this is intentional then so be it I guess.

Metadata Update from @rharwood:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

7 years ago

Login to comment on this ticket.

Metadata