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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
