Merge lp:~adeuring/launchpad/bug-39674-update-retricted-flag-of-private-bugattachments into lp:launchpad/db-devel

[Abel Deuring]

This branch adds a schema patch to update the "restricted" flag of LibraryFileAlias records belonging to bug attachments of private bugs.

A related branch, lp:~adeuring/launchpad/bug-39674-flip-lfa-restricted-flag , will land soon which will set LFA.restricted when a bug attachment is added to a private bug or when Bug.setPrivate() is called. We should also set LFA.restricted for existing data once this branch is merged.

[Robert Collins (lifeless)]

So, we have a problem here - making user content visible in the launchpad.net domain is a huge security hole - we can't do it at all safely - we need to either:
 - set content-disposition: attachment
 - serve the content from a different domain (I have a proof of concept branch working on this).

So, while this is slightly the wrong venue, we need to ensure that one of the two above things happens *before* any private bug attachments are served.

review: Needs Fixing

[Abel Deuring (adeuring)]

On 03.08.2010 00:36, Robert Collins wrote:
> Review: Needs Fixing
> So, we have a problem here - making user content visible in the launchpad.net domain is a huge security hole - we can't do it at all safely - we need to either:
> - set content-disposition: attachment
> - serve the content from a different domain (I have a proof of concept branch working on this).

Could you elaborate a bit what the security hole is?

(and, BTW, I'm using the standard pattern for proxied LFAs, so, if they
have a security problem, this problem exists too in other places where
restricted LFAs are used. And while these other uses cases may not be as
problematic as a core dump file visible to the wrong person, the current
situation is worse for bug attachments: All of them are public.)

>
> So, while this is slightly the wrong venue, we need to ensure that one of the two above things happens *before* any private bug attachments are served.

As I wrote above -- we serve them since years completely unrestricted...

[Robert Collins (lifeless)]

I've filed a separate bug about this this morning, and chatted with
Abel on IRC, I think we're all on the same page now.

[Abel Deuring (adeuring)]

> So, we have a problem here - making user content visible in the launchpad.net
> domain is a huge security hole - we can't do it at all safely - we need to
> either:
> - set content-disposition: attachment
> - serve the content from a different domain (I have a proof of concept branch
> working on this).
>
> So, while this is slightly the wrong venue, we need to ensure that one of the
> two above things happens *before* any private bug attachments are served.

This is fixed in a different branch: lp:~adeuring/launchpad/bug-612779

[Stuart Bishop (stub)]

This is fine and should be fairly quick and doable as a database patch.

patch-2207-79-0.sql

review: Approve (db)

=== added file 'database/schema/patch-2207-79-0.sql'
--- database/schema/patch-2207-79-0.sql	1970-01-01 00:00:00 +0000
+++ database/schema/patch-2207-79-0.sql	2010-08-04 09:15:56 +0000
@@ -0,0 +1,14 @@
+-- Copyright 2010 Canonical Ltd. This software is licensed under the
+-- GNU Affero General Public License version 3 (see the file LICENSE).
+
+-- Update the flag restricted of LibraryFileAlias records which belong
+-- to bug attachments of private bugs.
+
+SET client_min_messages=ERROR;
+
+UPDATE LibraryFileAlias SET restricted=true
+    WHERE id IN (
+        SELECT libraryfile from BugAttachment, Bug
+            WHERE BugAttachment.bug = Bug.id AND Bug.private);
+
+INSERT INTO LaunchpadDatabaseRevision VALUES (2207, 79, 0);