Bug 190505
| Summary: | Default action for clicking on attachment should be to view in browser instead of downloading | ||
|---|---|---|---|
| Product: | Services | Reporter: | mp39590 |
| Component: | Bug Tracker | Assignee: | Eitan Adler <eadler> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | bdrewery, eadler, kwm, mat, shurd |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190699 | ||
|
Description
mp39590
2014-06-02 12:42:27 UTC
this depends on having a second domain used for showing untrusted content. We are working on enabling this. (In reply to Eitan Adler from comment #1) > this depends on having a second domain used for showing untrusted content. > We are working on enabling this. Why is this requirement different than how gnats has always worked? You could view raw PR on freebsd.org. Even this shows it in browser on freebsd.org: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports%2F188457&getpatch=1 Primary concern is security. Bugzilla reports attachments with their 'correct' mime type. This means it may be possible to force HTML to be shown in the context of whatever domain is used for attachments. Needless to say, this is dangerous. (In reply to Eitan Adler from comment #3) > Primary concern is security. Bugzilla reports attachments with their > 'correct' mime type. This means it may be possible to force HTML to be > shown in the context of whatever domain is used for attachments. Needless > to say, this is dangerous. Showing it on randomdomain.com does not increase security. Yes it does. See https://en.wikipedia.org/wiki/Same-origin_policy and https://en.wikipedia.org/wiki/Cross-site_scripting (In reply to Eitan Adler from comment #5) > Yes it does. See https://en.wikipedia.org/wiki/Same-origin_policy and > https://en.wikipedia.org/wiki/Cross-site_scripting If you're worried that someone can serve HTML and have it RENDER in the browser, showing from a different domain is irrelevant. It's not enough to protect freebsd.org from CSRF, we don't want users uploading malicious pages to serve out from freebsd.org regardless. The only safe thing IMHO is to serve everything as text/plain. *** Bug 190599 has been marked as a duplicate of this bug. *** so. I'm looking into this a bit more. It may depend on 'custom templates' (i.e., custom patches to our source code). Give me a bit to discuss with the relevant folk. It annoys me too. The current situation is very difficult to work with. https://bugs.freebsd.org/bugzilla/attachment.cgi?id=139347&action=edit This is text/plain. Why can this not be displayed as is right now? Gnats showed patches and we never considered it a problem. This makes it worse for actually getting PR handled. Many people tend to look at a PR to see how much effort is involved. Now there is several extra steps to even determine if the patch is proper (if subsequent patches are as well) or how much work is involved to test it. I sat down to commit some PR and have to jump through hoops to see which I can fit into my current time slot. There is a feature, which may be considered, if attached file is marked as 'patch' (e. g. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190618 ), you will get few extra options, like viewing colored diff and raw file (click diff then "Raw Unified"). If it's possible to make bugzilla convert currently attached files based on, let say, file mask *.{patch,diff} to 'patches', maybe it will lower down the tensions. we are *not* customizing bugzilla until bug 190518 is fixed. This will happen, but the solution isn't as obvious as it looks like. I'm just as annoyed at the inability to view a patch inline as you are. Give us a little bit of time please. (In reply to mp39590 from comment #10) > There is a feature, which may be considered, if attached file is marked as > 'patch' (e. g. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190618 ), > you will get few extra options, like viewing colored diff and raw file > (click diff then "Raw Unified"). > > If it's possible to make bugzilla convert currently attached files based on, > let say, file mask *.{patch,diff} to 'patches', maybe it will lower down the > tensions. This ^ You can currently go into an attachment, edit details, and then check patch box and save. Then you can view the diff inline! This is a decent workaround for now. (In reply to Eitan Adler from comment #11) > we are *not* customizing bugzilla until bug 190518 is fixed. This will > happen, but the solution isn't as obvious as it looks like. > > I'm just as annoyed at the inability to view a patch inline as you are. Give > us a little bit of time please. I think you misunderstood. I'm not asking for inline viewing. I'm asking for attachments of text/plain to be allowed to be viewed when clicked on. It says it's disabled for security reasons. Having inline patches would be nice too but is at least a separate issue for me. comment #0 is also discussing clicking of the actual attachment and not inline. For me, files which are marked as "patches" (and therefor having this "Diff" button) are perfectly acceptable - I can view them as html or raw with couple clicks. What I proposed in comment #10 (and probably was misunderstood) - create a script which will mark all *currently* attached *.{patch,diff} files as "patches". I /hope/ that it's about changing one field in DB. At the end it will: 1) Affect all bugs with an attachment in the system; 2) Lower down the tensions, because as Bryan said - it's really nice workaround; 3) If people will stop complain (essentially meaning, that this functionality is OKAY for them) - our bugzilla won't need another custom patch to support any weird "inline viewing". What I propose is about files which are currently in the system, for new bugs people will need to check this patch box manually upon submit, I hope they will do it, it's not that hard. Can you open a separate bug "mark all existing attachments as diffs" ? I thought this would help quite a bit. Going forward we *do* need a solution. I'm working with clusteradm on this. (In reply to Eitan Adler from comment #15) > Can you open a separate bug "mark all existing attachments as diffs" bug 190699 Apparently text/plain is allowed now without checking 'Patch'. Yay. I think this can be closed, can't it ? The issue is fixed. |
