[repoman] transport mechanism

[Jason Chu]

On Tue, Jul 10, 2007 at 08:12:49AM -0400, Paul Mattal wrote:
> Jason Chu wrote:
> > On Mon, Jul 09, 2007 at 12:20:58PM -0400, Paul Mattal wrote:
> >> Jason Chu wrote:
> >>> 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.
> >> Yes, but then do you set up a separate user system? I don't want 
> >> everyone authenticating off one password file.
> > 
> > I was thinking it'd be different chroots per instance.  That way it is
> > different password files (repo.or.cz uses just ssh-keys, which I think
> > works pretty well).
> 
> I'm slowly coming around. Given the signature method of validating
> packages, I actually don't care who uploads them, as long as it's
> someone we basically trust (who won't DoS us). In that case, we can have
> one chroot jailed SSH and one set of accounts (and/or keys) for
> uploaders. The db would be responsible for having the signature for each
> package in advance and so could guarantee they're authentic.

Then the only thing you have to worry about is how users get the signature
into the db.  If they use the same method (let's say ssh into a chroot and
execute a command), you might be in trouble.

Remember how I said there are two parts, sending packages and sending
commands?

For sending commands, I thought just a couple of python scripts would do,
permissions detected off the username, but you'd have to have a way to
refer to multiple instances of repoman using only one command.

Commands would be things like this: repoman-addpkg, repoman-updatesig,
repoman-movepkg, repoman-deletepkg, repoman-mkrepo, etc.  Maybe if the
first argument was the instance name...

I don't know what your expectations are for two instances running at once.
Are they to be totally and absolutely separate or separate for the sake of
permissions but still share the same ways of accessing them?  If it were
one program with one data file, I wouldn't be asking this, but there are a
lot of pieces to the whole thing...

> The remaining piece is that an upload needs also to trigger an action. I
> suppose this could be done by an "upload monitor" watching a directory
> and handling files as they appear there. This is probably safest because
> the monitor can live outside the chroot jail, guaranteeing the uploaders
> cannot manipulate or examine any aspect of the monitor.

That part is actually pretty easy.  Judd made something like that for the
arch64 guys before they got full access.

> Yes, I think I'm sold. Additional advantage is that if you're running a
> local system, you just point your monitor at some directory and it's up
> to users to just move their packages in there. So it works for people
> with a lightweight setup and those who need the transport layer.

Yup, the chroot is pretty much optional.  I like that.

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/20070710/831d9f36/attachment.bin