Sign Mac diff patcher tools: goobspatch, xzdec, liblzma_decompress.dylib

Sign Mac diff patcher tools: goobspatch, xzdec, liblzma_decompress.dylib

BUG=559322
Committed: https://crrev.com/72ee18e78031d6a4535e074d4f271105c78f5828
Cr-Commit-Position: refs/heads/master@{#361127}

[Mark Mentovai, 2015-11-20 21:59:31]

mark@chromium.org changed reviewers:
+ kerrnel@chromium.org

[Greg K, 2015-11-23 15:28:39]

https://codereview.chromium.org/1470503002/diff/1/chrome/installer/mac/sign_i...
File chrome/installer/mac/sign_installer_tools.sh (right):

https://codereview.chromium.org/1470503002/diff/1/chrome/installer/mac/sign_i...
chrome/installer/mac/sign_installer_tools.sh:34:
enforcement_flags="restrict,library-validation,kill"
I'm all about setting library-validation on the installer tools, but I assume
this means we are confident that they have no need to load plugins or third
party code?

[Mark Mentovai, 2015-11-23 15:42:28]

https://codereview.chromium.org/1470503002/diff/1/chrome/installer/mac/sign_i...
File chrome/installer/mac/sign_installer_tools.sh (right):

https://codereview.chromium.org/1470503002/diff/1/chrome/installer/mac/sign_i...
chrome/installer/mac/sign_installer_tools.sh:34:
enforcement_flags="restrict,library-validation,kill"
Greg Kerr wrote:
> I'm all about setting library-validation on the installer tools, but I assume
> this means we are confident that they have no need to load plugins or third
> party code?

Right. The tools are just goobspatch and xzdec. They both link against
liblzma_decompress.dylib, which we also sign here with the same certificate.
Other than that, they only use system libraries.

goobspatch is so simple, it’s just a single source file:
https://chromium.googlesource.com/chromium/src/+/b12075910604ddb2b8c79b366784...

xzdec is also a single source file:
http://git.tukaani.org/?p=xz.git;a=blob;f=src/xzdec/xzdec.c;h=5cb7530afce4dfe...

Running nm -u on liblzma_decompress.dylib to see what it uses from other
libraries, it’s really the simplest stuff:

___stack_chk_fail
___stack_chk_guard
_free
_malloc
_memcmp
_memcpy
_memmove
_memset_pattern16
_pthread_once
_sysctl
dyld_stub_binder

I don’t envision any problems with library validation here, but if there are,
we’ll hear about the errors by seeing an increase in Omaha pings with the
discrete failure codes that correspond to dirpatcher failures (failed diff
update applications). Users won’t be stuck because the updater will just fall
back to a full update.

[Greg K, 2015-11-23 15:45:00]

On 2015/11/23 15:42:28, Mark Mentovai wrote:
>
https://codereview.chromium.org/1470503002/diff/1/chrome/installer/mac/sign_i...
> File chrome/installer/mac/sign_installer_tools.sh (right):
> 
>
https://codereview.chromium.org/1470503002/diff/1/chrome/installer/mac/sign_i...
> chrome/installer/mac/sign_installer_tools.sh:34:
> enforcement_flags="restrict,library-validation,kill"
> Greg Kerr wrote:
> > I'm all about setting library-validation on the installer tools, but I
assume
> > this means we are confident that they have no need to load plugins or third
> > party code?
> 
> Right. The tools are just goobspatch and xzdec. They both link against
> liblzma_decompress.dylib, which we also sign here with the same certificate.
> Other than that, they only use system libraries.
> 
> goobspatch is so simple, it’s just a single source file:
>
https://chromium.googlesource.com/chromium/src/+/b12075910604ddb2b8c79b366784...
> 
> xzdec is also a single source file:
>
http://git.tukaani.org/?p=xz.git;a=blob;f=src/xzdec/xzdec.c;h=5cb7530afce4dfe...
> 
> Running nm -u on liblzma_decompress.dylib to see what it uses from other
> libraries, it’s really the simplest stuff:
> 
> ___stack_chk_fail
> ___stack_chk_guard
> _free
> _malloc
> _memcmp
> _memcpy
> _memmove
> _memset_pattern16
> _pthread_once
> _sysctl
> dyld_stub_binder
> 
> I don’t envision any problems with library validation here, but if there are,
> we’ll hear about the errors by seeing an increase in Omaha pings with the
> discrete failure codes that correspond to dirpatcher failures (failed diff
> update applications). Users won’t be stuck because the updater will just fall
> back to a full update.

I think you've done enough investigation for us to be confident about this.
LGTM.

[Mark Mentovai, 2015-11-23 16:13:32]

The CQ bit was checked by mark@chromium.org

[commit-bot: I haz the power, 2015-11-23 16:13:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1470503002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1470503002/1

[commit-bot: I haz the power, 2015-11-23 17:14:19]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-11-23 17:16:12]

Patchset 1 (id:??) landed as
https://crrev.com/72ee18e78031d6a4535e074d4f271105c78f5828
Cr-Commit-Position: refs/heads/master@{#361127}