On Thu, Sep 25, 2014 at 4:51 PM, Rick Miller <vmil...@hostileadmin.com> wrote:
> > > On Thu, Sep 25, 2014 at 3:05 PM, Guido Falsi <m...@madpilot.net> wrote: > >> On 09/25/14 20:57, Rick Miller wrote: >> > On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi <m...@madpilot.net> wrote: >> > [snip] >> > > >> > =======================<phase: patch >> >============================ >> > ===> Patching for bash-4.3.24 >> > ===> Applying distribution patches for bash-4.3.24 >> > ===> Applying extra patch /distfiles/local-patches/8_4-amd64/bash.patch >> > ===> Applying extra patch >> > /usr/ports/shells/bash/files/extrapatch-colonbreakswords >> > ===> Applying extra patch >> > /usr/ports/shells/bash/files/extrapatch-implicitcd >> > ===> Applying FreeBSD patches for bash-4.3.24 >> > >> =========================================================================== >> > >> > The first sign that something didn't appear to have gone as expected was >> > that the package was built as bash-4.3.24.tbz as opposed to >> > bash-4.3.25.tbz. The above test was executed observing the behavior of >> a >> > still vulnerable binary. >> >> The way you are applying the patch simply modifies the code being >> compiled by the port, you're not patching the port itself, so the port >> maintains the same version number. >> > > Makes sense > > > >> > The test was performed on an 8.4 host with a [unpatched] bash-4.3.24 >> after >> > forcefully removing the package and adding the new, patched package. It >> > complained of dependencies on packages that were already installed, but >> not >> > up to the version of the dependency. After manually fixing these >> > dependencies (forcefully deleting the existing dependencies and >> installing >> > the new ones), the test was executed once again to the same results. >> > >> > Could this be an issue of the order the patches were applied in or ?? >> >> You should check the build log and see if in the patching phase there >> was any error. >> > > The above log snippet is from the patch phase of the build indicating > success (well, at least no error). A build with the wrong patch was > attempted that did indicate errors, as expected. > > The full log can be viewed at http://pastebin.com/hwHwJAKK > > Is there some way in the log to identify if the source was patched and > built correctly? Does Poudriere [ I say Poudriere realizing that it likely > does not, but perhaps the system does? ] provide the ability to review the > source code after patching to actually verify the patch was applied? A > cursory search of the filesystem where Poudriere stores the jail turned up > no leads. > The patch does apply to evalstring.c which shows the following warnings in the build log though I am unfamiliar enough to know whether or not this would apply to this particular scenario. cc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I. -I/usr/local/include -O2 -pipe -fno-strict-aliasing evalstring.c evalstring.c: In function 'parse_and_execute': evalstring.c:208: warning: passing argument 1 of 'sigemptyset' discards qualifiers from pointer target type evalstring.c:209: warning: passing argument 3 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c:288: warning: passing argument 2 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c: In function 'parse_string': evalstring.c:444: warning: passing argument 1 of 'sigemptyset' discards qualifiers from pointer target type evalstring.c:445: warning: passing argument 3 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c:497: warning: passing argument 2 of 'sigprocmask' discards qualifiers from pointer target type -- Take care Rick Miller _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"