Poudriere Build of pkg_* repos?

[Rick Miller]

On Thu, Sep 25, 2014 at 5:09 PM, Rick Miller <vmiller at hostileadmin.com>
wrote:

>
>
> On Thu, Sep 25, 2014 at 4:51 PM, Rick Miller <vmiller at hostileadmin.com>
> wrote:
>
>>
>>
>> On Thu, Sep 25, 2014 at 3:05 PM, Guido Falsi <mad at madpilot.net> wrote:
>>
>>> On 09/25/14 20:57, Rick Miller wrote:
>>> > On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi <mad at 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