> mktemp() IS NOT insecure. The way it has been used over the years Yep, it does what's on the tin and people plain used it wrong, decades of wrong, bad wrong. So it got deprecated and turned into a warn to wake people up :)
> Writing your own random filename generator > be less secure (potentially due to insufficient randomness, etc.) Given O_EXCL (if it works, and checking the result) is what actually neuters the race, then the X's exist not for security but give: a) a better chance of first (early) success in the loop creating the file against whatever else the user/users/system/racer is doing in the hier. b) a nice litter pile to help debug, or crash recover, once it's noticed. For me in my stuff, yeah, I'd likely roll something in place of mktemp merely to avoid the warn, even if only for my downstream. > It's unfortunate if there are redundant code blocks, but that is not a > bug, per se. It might be worth opening a bug to get them cleaned up. > > If there are calls to fopen() which are for writing, these should be > looked at, and if they're correct, a comment to that effect is > probably worthwhile, in similar fashion to the sprintf() comments... The multiple places to look for made it harder for me, a non-auditor, to begin to look at. It seemed that some future win could be had by sortof collapsing the warn, redundancy, comments, auditability, into what might become single function. I'm not qualified to weigh that. >> It's the O_EXCL that protects you, not the stats. I think I saw a stat() coded, then later on, the O_EXCL, which might fail (properly) due to any interim race. So the utility of the stats was unclear, when I looked, sleepily. > the combination of O_EXCL AND the file mode that protects you Yes of course. Didn't mean for the topic to run or clutter the actual tech in the ticket. We're all on the same page I'm sure :)
