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.. > 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. > 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?) 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. > 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. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
