Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jun 2003 15:48:15 -0500 (CDT)
From:      hawkeyd@visi.com (D J Hawkey Jr)
To:        dxoch@escape.gr, freebsd-questions@freebsd.org
Subject:   Re: About Patches
Message-ID:  <200306232048.h5NKmF700943@sheol.localdomain>
In-Reply-To: <5BC51B1E-A558-11D7-B54A-003065C4E486_escape.gr@ns.sol.net>
References:  <5BC51B1E-A558-11D7-B54A-003065C4E486_escape.gr@ns.sol.net>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <5BC51B1E-A558-11D7-B54A-003065C4E486_escape.gr@ns.sol.net>,
	dxoch@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.

> 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

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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306232048.h5NKmF700943>