PPA doesn't allow signed contributed builds

[Richard Wilbur]

Only standard architectures are currently supported in the PPA.
Case 1: A package maintainer may point users to the project's PPA for apt access to the latest builds only on standard architectures (currently i386, amd64, and lpia). It would simplify the user interaction for those with other architectures (powerpc, sparc, etc.) if they could use the same sources.list line and possibly a different key to access the latest builds for their architectures.

If members of the project's team, which have upload rights for signed binary packages in the project's download area, could put those same signed binary packages in the PPA and have the uploader's identity and key-link associated, this would seem to simplify supporting other architectures while preserving some security and traceability.

Example: bazaar project download area for release 1.15.1 - powerpc build I contributed (just as version 1.15.1 was superseded by 1.16)
https://launchpad.net/bzr/1.15/1.15.1
PPA for the bazaar project lives at https://launchpad.net/~bzr/+archive/ppa

Discussion thread on bazaar development mailing list:
https://lists.ubuntu.com/archives/bazaar/2009q2/059604.html
Discussion thread on launchpad-users mailing list:
https://lists.launchpad.net/launchpad-users/msg05065.html

Case 2: Programmer fixes a bug in a package that is only demonstrated on a community-supported (port) architecture and wants to distribute the result to interested parties for testing with the minimal amount of pain to the tester. He creates a new signed source package and uploads it to his PPA. How can he provide the binary package to testers on the affected community-supported architecture? As an individual he doesn't have a download area. There is no way to request that his PPA build for a community-supported architecture. He could also benefit from the ability to upload a signed binary package to his PPA.

Example: f-spot - bug in v0.4.3.1 shipped in Hardy LTS crashes the program on powerpc architecture when a digital camera import starts
Launchpad bug report to which I attached the fixed powerpc binary package:
https://bugs.launchpad.net/debian/+source/f-spot/+bug/176707
My PPA containing patched source:
https://launchpad.net/~richard-wilbur/+archive/ppa

[Karl Fogel (kfogel)]

Further discussion thread on launchpad-users@ starts here:

https://lists.launchpad.net/launchpad-users/msg05207.html

[Christian Reis (kiko)]

I had a conversation with James T. about this and we came up with some suggestions on how to move forward on this. Here are some thoughts:

  - The special thing about a PPA that allows you to download binaries that weren't compiled by us is that there is no guarantee of the link between binary package and source package. This is somewhat subtle a difference (and probably not really a risk in the sense that a malignant PPA owner could always upload binary blobs as part of his source package).
  - If we were to do this, we would only allow binary uploads for architectures where we do not actually support PPA building; for instance, binary uploads for i386, etc, would be rejected, but uploads of debs for, say, PPC would be file.
  - The easiest way to model this would be a flag on the PPA, settable by a Launchpad admin, which indicated that the PPA would accept binary uploads.
  - The key for this PPA could be generated with text to indicate clearly that this PPA accepts binary uploads.
  - The PPA's Release file should also contain a header that would indicate the same; this allows agents downloading from this PPA to present it in a special manner to the end-user.

This doesn't look like a massive amount of work if someone in the community is interested in helping out with the patch and QA for it.

[Julian Edwards (julian-edwards)]

I would be happy to mentor and sponsor anyone in the community who takes this on. We can break the work down into several pieces:
 * UI changes - the PPA page would need to clearly delineate contributed binaries, and the admin form needs to include the new flag
 * Upload policy changes - the "insecure" upload policy would need to take into account this new binary flag
 * Publisher changes - To add data to the Release file
 * Database changes - add the new flag to the schema

One problem is that it's hard to amend the key after it's already been generated. We need to think about that.

If anyone does take this on, please talk to someone in the Soyuz team first.