Re: Progeny apt enhancements: SSL, redirect, cookies, auth

[Jeff Licquia <jlicquia@progeny.com>]

On Mon, 2002-07-29 at 17:56, Jason Gunthorpe wrote:
> 
> On 29 Jul 2002, Jeff Licquia wrote:
> 
> > [Please CC; lists.debian.org appears to be slow in processing my
> > subscription request.]
> 
> Deity is a non-supscription list..

That would explain what's taking so long. :-)  Ah, well, I don't mind
being CCed.

> > We've looked at the apt-https work, and it looks to be mostly right up
> > our alley.  However, we're only interested in encrypting the
> 
> Are you using Tomas Pospisek's latest https work? It is quite good and
> already does authentication/etc.

Yes, that's what we started from.  And our delta is very minor; we
folded ServerStateSSL's functionality into ServerState proper, and had
ServerState decide whether to create a Connection or ConnectionSSL based
on the URI.  It should be 100% compatible with Tomas's work, even to the
configuration parameters.

As I understand it, apt-https does auth based on certs.  This is
interesting long-term to us, but short-term we need something a little
simpler.

> > The other three extensions we're planning to write.  Cookie and redirect
> > support don't seem terribly difficult.  Authentication, I understand, is
> > already supported by embedding the username and password into the
> 
> Cookies, I don't know about that, people have alot of strong feelings on
> that subject. There really isn't much need for it outside whatever it is
> you are trying to do (is the cookie to pass the auth info from the SSL to
> non-SSL side?)

Yes, that's the idea.

I had planned to allow cookie support to be disabled or to make cookies
transient (the easiest way: point your cookie file at /dev/null).  But
if there's no demand for it outside of what we're doing, we don't mind a
mild fork.  If the impact can be localized to the http method, we could
possibly just package it as a diversion.

> Have you considered using ftp instead? It is a lot more suited to this
> sort of stuff, you don't need to use the redirect hack, you probably don't
> need cookies and it's dead easy to make the control connection encrypted
> and the data one not. HTTP will be fugly and complicated to wed something
> like this too.

I'll send this suggestion along, but I'm not sure it will work for what
we're doing.

Does the ftp (rsh/ssh) method support interactive auth?  I didn't think
it did, but I'd love to be wrong.

> > sources.list URL; we think, however, that there will be a need for
> > interactive authentication.  Our current thinking on implementing this
> > involves using optional callbacks for registering interactive auth
> > support, making the apt frontend responsible for supporting and
> > implementing the callbacks.  This way, current clients would still work
> 
> Yes, that's probably sensible. I wouldn't use anything like debconf, that
> will badly interfere with the front ends.. The library already has
> sufficient bi-directional communication with the methods that there should
> be no problem with a passwd protocol. Look at how the CDROM swapping stuff
> was implemented.

OK.  Is this something you would be interested in for mainline apt?


-- 
To UNSUBSCRIBE, email to deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org