[repoman] transport mechanism

[Paul Mattal]

Jason Chu wrote:
>>> On the whole, I think the custom client/server is still winning for me, 
>>> at the moment, though I wish support for SSL servers in Python was 
>>> better. But I really feel like there should be something standard we 
>>> could use for this authentication and transport.
>>>
>>> Any ideas?
> 
> The new one I learned was using ssh from a chroot.  That's how repo.or.cz
> works and that's how phrakture planned on doing projects.archlinux.org.
> That way "developers" can have accounts but they don't need shells on the
> hosting system.  You can even limit the commands they can execute using
> something like rsh.

This violates one of the goals of repoman, though: be able to deploy 
more than once on a single server. This is critical, because there 
will not be (at least at first) granular permissions within an 
install. If you're a trusted party, you get to work on all the repos.

Otherwise, this is a very good solution that phrakture mentioned and 
I considered.

[stuff snipped]

>>> One thought that just occurred to me.. we could take a page out of the 
>>> monotone trick book and separate trust from transport. We could add a 
>>> file to the PKGBUILD directory which gets stored in the SCM and contains 
>>> the sha1sum of the BINARY package that corresponds to this PKGBUILD 
>>> built for a particular architecture. Then we don't need to care where or 
>>> who a binary package comes from.. anyone can upload the binary package 
>>> to the server (without authentication) as long as the package has the 
>>> proper sha1sum. This also has the benefit of keeping developers from 
>>> accidentally uploading the wrong binary package.
> 
> As we talked about in the dev meeting, the problem with this is that
> two compiles of the same package will have different sha1sums.  This is
> because of timestamps within the tar, the order of files within the tar,
> the contents of the binaries (I'm pretty sure linked libraries aren't
> ordered, for example.
> 
> Saying that one PKGBUILD creates a package with a sha1sum of X means we
> can't autobuild at all.

I think we can still autobuild if we trust the autobuilder. My point 
is that a single package foo-2.1-7-i686 should correspond to EXACTLY 
one binary package that ever gets distributed to the world, and it 
should have been produced by running makepkg (in some environment) 
on the contents of the PKGBUILD directory and SCM version pointed to.

So if the autobuilder builds, calculates the signature, and puts it 
in the db, I'm fine with that-- we can create some hooks so that an 
autobuilder can do that easily.

The point is that at *some point*, someone or something should 
decide that package pkgver-pkgrel-arch corresponds to ONE binary 
thing that will be distributed (and that meets whatever level of 
quality checking and testing is appropriate), and the signature will 
always allow us to check that. Once it's been put in a repo, we will 
never change the signature again. Of course, you can always do a 
pkgrel bump and upload a new version; this just enforces that a 
particular pkgrel really is exactly one release of a binary package.

Then when someone sends in a bug report against a 
pkgver-pkgrel-arch, you can be sure (and ask him to verify) that his 
package is the same as yours. It lets you make draw strong 
conclusions about what's going on that you can rely upon when 
debugging. Although I believe that pacbuild will get us much closer 
to packages being uniformly built, I still prefer to trust the bits 
themselves to guarantee we're both running the same software when 
we're chasing bugs.

- P