Hi Theo, * Theo de Raadt <[email protected]> wrote: > First off, to get that off the plate, we don't have the POSIX, no call > it what it is --- SVR4 -- pty stuff because it is a gigantic race. It > was designed in response to the pty race research by Dan Bernstein, > but the result was that the SVR4 guys still got it wrong.
Can you please explain why. As I mentioned a long time, our implementation on FreeBSD implements grantpt() and unlockpt() as no-ops, which will be allowed behaviour as of the next version of POSIX. Is FreeBSD's implementation also affected by this race? If not, why not implement something similar for OpenBSD? > But regarding the utmpx stuff, you've now sent us a diff which > - writes uninitialized stack data to the file (date.c, init.c, > perhaps more) No, it does not. Our implementation never writes inapplicable fields or data past terminating null bytes of strings to disk. If you want, I can add the memset() calls for you. > - delete etc/ttys.pty because you don't know what it is for There is really no use to store pseudo-terminals in /etc/ttys, since the utmpx implementation does not use any slot-based indexing. Apart from utmp, I've never seen any other pieces of code that use the slot numbering as well. > - removes an API from libc which you have not verified > is unused > - crank the minor of libc, without realizing that since you have > changed and removed interfaces, you would need to do a *major* > bump of libc, libutil, a few X libraries, and probably 20-30 > packages with libraries which will now detect the new interfaces > and potentially change the behaviour. Well, <utmp.h> and ttyslot() have been removed, since my experience has been that supporting both utmp and utmpx in fact causes more breakage. > - sneaks bits of incompatible behaviour into various programs > (ie. last) Can you please clarify? As I mentioned, take into account that the patch is not yet complete, finished, etc. > We have a utmp which was extended a decade ago to have much longer fields. > It works just fine. > > I don't see what benefit the extra junk in the utmpx file provides to > anyone. Oh, it's got a pid, so that you can send a signal to the wrong > process... I'm not saying utmpx is some kind of Endlvsung or anything. At least it's standardized by *something*. If there are things in your eyes wrong with standards like POSIX, why not discuss those issues with the Austin Group? -- Ed Schouten <[email protected]> WWW: http://80386.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
