[repoman] transport mechanism

[Jason Chu]

On Mon, Jul 09, 2007 at 10:13:15AM -0400, Paul Mattal wrote:
> 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.

But ssh can be run on multiple ports... even with a custom client/server
you'd probably still run it on multiple ports for multiple instances.

Another common option is gpg signed emails.  To upload a package, just
attach it, to execute a command (move package, delete package, create repo,
etc) it's just a text command.  This solution also doesn't require a custom
client/server, only custom scripts.

I still prefer the multiple ssh servers solution though.

> [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.

Ok, just as long as the hash isn't required at checkin time or can be
changed any number of times before the package reaches the repos.

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://archlinux.org/pipermail/repoman/attachments/20070709/1d6cd0e4/attachment-0001.bin