Hi, this is a new bug related to the exciting work going on to make private bug attachments well, private.
Sadly, that work is building on an incomplete foundation - the restricted librarian has only been used for system controlled content so far - that is, content where we are (reasonably) sure that it is harmless. The StreamOrRedirect view doesn't set content-disposition, and uses content sniffing to determine the content. As such, once db-devel deploys to staging today, a private bug attachment which is hostile javascript, will have full access to the viewing users launchpad account on staging; if we deploy that facility to production we'll be open to the same attack on production.
This is a critical issue to fix before our upcoming release, so I'm marking it as critical.
As far as fixing it goes, the simplest way would be to set cd:attachment on all StreamOrRedirect responses, but that will cause things like build logs which are system controlled and extremely hard to attack, to be downloaded rather than viewed in the browser.
A better approach might be to have two StreamOrRedirect views, and choose the right one based on the type of file - whether its a bug attachment (unsafe), a merge proposal diff(safe), log file from our buildds (safe) etc etc.