Re: cvs: temporary file handling fixes

Solar Designer wrote:

>However, looking at 1.12.1, I notice that the only two scripts which
>will now use mktemp (if enabled at configure time) are cvsbug and
>rcs2log, and the uses by cvsbug are buggy in that the file name in
>$TEMP will be re-used multiple times.  Yes, Red Hat has this bug in
>their patch too.
>
>I don't understand why you consider our fixing the other scripts in
>contrib/ and the documentation misguided.
>

I forget why, I'll see if I can find time to review them again soon.

>>The fixes that 
>>might be usable are going to need at least ChangeLog entries to 
>>accompany them,
>>    
>>
>
>Obviously, but:
>
>- it doesn't make sense to write full ChangeLog entries before we know
>the fixes are even getting in (and I don't expect you to include them
>without any changes at all);
>

Well, yes it does when I can't figure out the purpose of your changes. 
 A more complete abstract would help immensly in this case as well, but 
if I can't decipher the reason for any part of a patch when reviewing 
it, I find ChangeLog entries can be useful.

>- CVS is just one of over 120 packages in Owl and we're primarily
>concerned with making our distribution better; we also like to share
>our changes with upstream maintainers, but we can't afford to spend
>much extra time on the integration of our changes upstream.
>

If I don't understand the reason for your changes I am hardly going to 
incorporate them.  If you plan on continuing to maintain a distribution 
of CVS, I expect it would be useful to you to have those changes 
incorporated upstream.

>>some may need more documentation or tests in sanity.sh, 
>>and all will need to have their purposes explained more fully to be 
>>accepted.  Please see the HACKING file in the top level of the CVS 
>>source distribution for more on how to submit patches.  Please note in 
>>particular that they should be sent to the <[email protected]> mailing 
>>list and not directly to me.
>>    
>>
>
>This all is fine with me (although I won't necessarily have the time
>to submit any of this officially), but it doesn't make a valid
>procedure for reporting security problems and proposing fixes to them.
>In particular, I was looking for a (security) bug reporting address
>that wouldn't automatically reach a public mailing list, -- but it
>seems you find unsafe temporary file handling to be a minor enough
>issue to be discussed in public.  This is OK with me, but I thought
>that some vendor-sec members could prefer to handle it differently.
>  
>

Again, sorry for bouncing a possibly sensitive email to bug-cvs so 
quickly, but unless clearly and believably labeled as sensitive, it is 
practically a reflex action for me to bounce emails about CVS from 
senders I don't recognize to [email protected] when they contain patches. 
 I get a lot of email and have little enough free time as it is.

Derek

-- 
                *8^)

Email: [email protected]

Get CVS support at <http://ximbiot.com>!
--
There are no absolutes.