About Patches

[Jim Xochellis]

Hi,

On Monday, June 23, 2003, at 11:48 PM, D J Hawkey Jr wrote:

> In article <5BC51B1E-A558-11D7-B54A-003065C4E486_escape.gr at ns.sol.net>,
> 	dxoch at escape.gr writes:
>> Hi List,
>>
>> I need to apply some security patches to my FreeBSD(i386) 4.7-RELEASE
>> box and I am concerned about the possibility that I could actually 
>> harm
>> my system while trying to apply this patches. (I am not a Unix guru
>> actually)
>
> Is there any particular reason you don't want to use cvsup(1) against
> the "security" or "current" branches? Release 4.7 is still supported by
> the Security Team, after all. See the Handbook if you don't know what
> this means.
>

Recompiling the whole system seems a little scary to me, but I thing 
that I am going to do it anyway!

>> 1) Do I have to apply the security patches in a specific order?
>
> Sometimes, yes, sometimes, no. It will depend on whether any one source
> module has been updated (or not, more to the point) before.
>
>> 2) Is there a chance were a patch requires a previous one? (In my case
>> some patches are not applicable)
>
> Yup; see above, especially where the kernel is concerned. Even if a 
> patch
> is for source a module that has never been patched before, it might 
> depend
> on function asdf() in another source module being "proper" from it's 
> (the
> patch's) own point-of-view.
>
>> 3) What if the code is not in the state that the patch requires? (For
>> instance if I have updated that port)
>
> Um, this is a tricky question. The answer could go either way. The 
> nasty
> situation is when a source module isn't current enough for the patch to
> apply, but it should have the patch's functionality.
>
>> 4) Are the patches clever enough to protect me from harming my system?
>
> Yes. If you use the patch(1) utility judiciously (correctly?), it 
> can/will
> rename the existing file(s) being patched to *.bak.
>
> The script(1) utility is a Good Thing(tm) if you're patching things in 
> an
> ad hoc manner; it'll let you "go back" further than the scroll-back of 
> a
> console or xterm to see what was actually done.
>
>> 5) Is there a safe way to undo a patch?
>
> Yup; see above. The patch(1) utility also understands "reverse 
> patches",
> though I've not used that functionality.
>
> Note: I'm not a developer or committer. I'm just another hack who has 
> some
> experience doing this sort of thing. I have a web page for patching 
> EOL'd
> kernels against more recent security alerts [and other stuff]. It has a
> section that you might find helpful:
>
>     http://www.visi.com/~hawkeyd/freebsd-backports.html
>

Thank you very much.

> You should become familiar with reading a patch file before trying to
> patch things in an ad hoc fashion, both the contextual and unified diff
> formats. I can almost guarantee that you'll have to dissect something,
> somewhere, sometime. Please [re-]evaluate my opening question before
> proceeding.
>
> Please CC me when replying to the list; I'm not subscribed. HTH,
> Dave
>
> -- 
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet?
>


Thanks for helping me (Great list indeed)

Jim Xochellis