(This e-mail could be viewed by some as flame response, but it actually
isn't.)

Jared D. McNeill wrote:
> I've seen programs use their PID to write files to /tmp before (I can't
> remember any off-hand), I guess this makes things just a little bit harder
> for people to exploit that. In risk of being flamed, I have to admit that
> I do like some of the OpenBSD features such as this one. There isn't much
> overhead, and every little bit helps I guess.

Random unimportant scripts do that. Some older programs use mktemp() (though
almost all NetBSD code is already moved to mk?temp()), ~all modern and
important stuff was fixed to use mkstemp()/mkdtemp().

If you rely on just the pid to make unique files, you lose.

Doing a race attack is ~equally easy for sequential as for
pseudo-random pids. I do not want to make process creation any
more difficult than it is now, if the benefit is not worth it.

There is a thing called system engineering. People caring about OS design
should have enough discipline to avoid bloating the system with
needless features. The only reason for features like this (pseudo random
pids, pseudo random XID and other) is to create stuff OS advocates can use
to claim their OS is better. I believe NetBSD is about ~proper system
engineering.  We have plenty of our own, important stuff we can be proud
of.  We don't need to implement such ... things ... just to prove we
actually do something of our own.

BTW, there is more than couple of cool NetBSD projects (both bigger and
smaller) which are worth your time more than this. I'd be glad to compile
my personal list :)

Jaromir (expressing personal opinions, not speaking for the project)

P.S. Heh, found a way this feature could be good - once people get used
  to the slower system, take it away and claim you optimized process
  creation! :-)
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, damn!  @@@@