Date: Thu, 25 Sep 2014 18:40:04 -0400 From: Rick Miller <vmiller@hostileadmin.com> To: Guido Falsi <mad@madpilot.net> Cc: freebsd-ports <freebsd-ports@freebsd.org>, Bryan Drewery <bdrewery@freebsd.org> Subject: Re: Poudriere Build of pkg_* repos? Message-ID: <CAHzLAVG%2B2450Dt=1VkhdMdZo-aob9sMBnn=EqpsaBAC7tmN6rw@mail.gmail.com> In-Reply-To: <CAHzLAVE7mPSp2dHwT0a_mYA5e5nOi9Swairt1tmn1Q%2BTCoVLHQ@mail.gmail.com> References: <CAHzLAVGcGPQP3NvaSpe6%2BidLdEWM4hrQyPwP6YVPvOO-J823Fw@mail.gmail.com> <54233850.2070807@FreeBSD.org> <CAHzLAVFsmaD_wx%2B2%2B9oug3hCOYG_kxBAi--R9FmmBOPG2PcZ4A@mail.gmail.com> <54242A0E.6000507@madpilot.net> <CAHzLAVFWv9Zz7dk2uF=3y-qJBpdEbXgWD_YoJXD0zcd%2BbxHCsQ@mail.gmail.com> <54246761.8060405@madpilot.net> <CAHzLAVHBRzKx7vEXuSpGAOZcNBM2tp6YUHibTvggQjM8wWkhoA@mail.gmail.com> <CAHzLAVE7mPSp2dHwT0a_mYA5e5nOi9Swairt1tmn1Q%2BTCoVLHQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 25, 2014 at 5:09 PM, Rick Miller <vmiller@hostileadmin.com> wrote: > > > On Thu, Sep 25, 2014 at 4:51 PM, Rick Miller <vmiller@hostileadmin.com> > wrote: > >> >> >> On Thu, Sep 25, 2014 at 3:05 PM, Guido Falsi <mad@madpilot.net> wrote: >> >>> On 09/25/14 20:57, Rick Miller wrote: >>> > On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi <mad@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 > After reading an extensive thread about this, I was able to "reliably" test the immediate threat which does mitigate the initial risk. Having said that, there is ongoing discussion about a more long term solution. -- Take care Rick Miller
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHzLAVG%2B2450Dt=1VkhdMdZo-aob9sMBnn=EqpsaBAC7tmN6rw>