Re: sslio as a STARTTLS wrapper

On Fri, 7 Jan 2005, Scott Gifford wrote:

> Charlie Brady <[email protected]> writes:
> 
> > On Fri, 7 Jan 2005, Scott Gifford wrote:
> >
> >> Charlie Brady <[email protected]> writes:
> >> 
> >> [...]
> >> 
> >> > It's my impression that SIGCONT is the only signal we can send
> >> > across uid boundaries (presuming that both smtpd and sslio have
> >> > changed uid), and then only if the processes are in the same session
> >> > (as I think they would be here). I can't think of how we'd send two
> >> > different messages ("take over", "die") with that one signal.
> >> 
> >> Ah, you're right, a quick test confirms that.  Using SIGCONT seems
> >> quite kludgey, though I can't think of any other reason than
> >> aesthetics not to use it.  Well, maybe portability.
> >
> > What about the reason I've given 
> 
> Do any protocols actually provide a way to turn off encryption once
> it's on?

Not that I'm aware of.

But that's not my point. My proposal is to fork an SSL wrapper which sits 
in standby mode until asked to participate. There's no point in keeping it 
around if it's not to be used, so the mail daemon can send it one of two 
messages as soon as it's able - take over I/O and start SSL wrapping, or 
die - 'y' or 'n'. It makes no sense to try to send those two different 
messages using SIGCONT - what would you do, two signals in a row or one? 
Or would you leave the idle SSL wrapper until the mail daemon exits? And 
then, how would you kill it?

Nah, SIGCONT just doesn't fly.

> Regardless, I tried coding something up using SIGCONT last night, and
> it didn't work outside of a simple example.  kill returned ESRCH,
> which doesn't really make any sense, and maybe is an early
> demonstration that this wouldn't be portable.

One working mechanism is sufficient, methinks. I can't think why a one 
byte message wouldn't be adequate.

---
Charlie