dxoch at escape.gr
Tue Jun 24 01:54:46 PDT 2003
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
>> my system while trying to apply this patches. (I am not a Unix guru
> 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
> is for source a module that has never been patched before, it might
> on function asdf() in another source module being "proper" from it's
> 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
> 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
> rename the existing file(s) being patched to *.bak.
> The script(1) utility is a Good Thing(tm) if you're patching things in
> ad hoc manner; it'll let you "go back" further than the scroll-back of
> 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
> though I've not used that functionality.
> Note: I'm not a developer or committer. I'm just another hack who has
> experience doing this sort of thing. I have a web page for patching
> kernels against more recent security alerts [and other stuff]. It has a
> section that you might find helpful:
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
> Please CC me when replying to the list; I'm not subscribed. HTH,
> 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)
More information about the freebsd-questions