Merge lp:~cjwatson/launchpad/snap-build-record-code into lp:launchpad
Status: | Rejected | ||||
---|---|---|---|---|---|
Rejected by: | Colin Watson | ||||
Proposed branch: | lp:~cjwatson/launchpad/snap-build-record-code | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
524 lines (+244/-23) 11 files modified
lib/lp/code/model/branch.py (+17/-4) lib/lp/code/model/gitrepository.py (+15/-3) lib/lp/code/model/tests/test_branch.py (+3/-1) lib/lp/code/model/tests/test_gitrepository.py (+3/-1) lib/lp/security.py (+25/-4) lib/lp/snappy/interfaces/snapbuild.py (+36/-0) lib/lp/snappy/model/snap.py (+2/-1) lib/lp/snappy/model/snapbuild.py (+49/-5) lib/lp/snappy/model/snapbuildbehaviour.py (+2/-0) lib/lp/snappy/tests/test_snapbuild.py (+91/-3) lib/lp/testing/factory.py (+1/-1) |
||||
To merge this branch: | bzr merge lp:~cjwatson/launchpad/snap-build-record-code | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Launchpad code reviewers | Pending | ||
Review via email: mp+365356@code.launchpad.net |
Commit message
Record the code object from which a SnapBuild was created, for use by security adapters.
Description of the change
This is annoying, but I don't see any other way to cope with privacy changes of code objects that have snaps attached to them without leaking information about old builds.
We shouldn't land this until https:/
https:/
Unmerged revisions
- 18923. By Colin Watson
-
Add warning for future developers.
- 18922. By Colin Watson
-
Merge devel.
- 18921. By Colin Watson
-
Check privacy of code objects associated with snap builds.
- 18920. By Colin Watson
-
Add an explicitly_private flag to SnapBuild.
This lets us avoid accidental information leaks.
- 18919. By Colin Watson
-
Record the code object from which a SnapBuild was created, for later use by security adapters.
There are a couple of known problems with this, discussed on today's LP team call:
(1) When the snap build is detached, it will no longer have a private code artifact attached to it and thus may become public. Oops.
(2) It's not obvious that these are quite the semantics we want. Unlike source packages, Git repositories include history, but the history can be mutated (e.g. via git filter-branch), and the process of making a private repository public might well include redacting its history. If old snap builds automatically become public then that could be a problem.
We may need a private flag on the build, but it probably can't just be that because we need some way of knowing who can see it. Perhaps we could detach from public builds (thus keeping logs for old builds that are on public Ubuntu images, etc.) but delete private builds. Perhaps only the snap owner could see old detached private builds, or maybe even only admins. Or something else ...