Update dependencies for setup.exe following BoringSSL switch.

Update dependencies for setup.exe following BoringSSL switch.

BUG=338884, 127233
R=gab@chromium.org

Committed: https://crrev.com/c8d3f9f9d419230e5d05a1477962cc44afa544d9
Cr-Commit-Position: refs/heads/master@{#308368}

[gab, 2014-12-15 16:51:21]

I can't find references to why this change will work, but I assume this was
simply done by manually testing what component setup.exe requires to launch (as
I did in the original CL).

Also, a component version of test_mini_installer would have caught this
regression :-(, one more thing on our todo list..!

[gab, 2014-12-15 16:51:40]

On 2014/12/15 16:51:21, gab wrote:
> I can't find references to why this change will work, but I assume this was
> simply done by manually testing what component setup.exe requires to launch
(as
> I did in the original CL).
> 
> Also, a component version of test_mini_installer would have caught this
> regression :-(, one more thing on our todo list..!

Oh and lgtm of course :-)!

[grt (UTC plus 2), 2014-12-15 17:03:14]

The CQ bit was checked by grt@chromium.org

[commit-bot: I haz the power, 2014-12-15 17:05:09]

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

[commit-bot: I haz the power, 2014-12-15 17:54:38]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-12-15 17:55:19]

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

[grt (UTC plus 2), 2014-12-15 18:16:15]

On 2014/12/15 16:51:21, gab wrote:
> I can't find references to why this change will work,

It replaces the old NSS DLLs with the new BoringSSL DLL (see
http://crbug.com/338884).

> but I assume this was
> simply done by manually testing what component setup.exe requires to launch
(as
> I did in the original CL).

Of course. :-)

> Also, a component version of test_mini_installer would have caught this
> regression :-(, one more thing on our todo list..!

I had the same thought. Filed: http://crbug.com/442400.

[Ryan Sleevi, 2014-12-15 20:30:45]

On 2014/12/15 18:16:15, grt wrote:
> On 2014/12/15 16:51:21, gab wrote:
> > I can't find references to why this change will work,
> 
> It replaces the old NSS DLLs with the new BoringSSL DLL (see
> http://crbug.com/338884).
> 
> > but I assume this was
> > simply done by manually testing what component setup.exe requires to launch
> (as
> > I did in the original CL).
> 
> Of course. :-)
> 
> > Also, a component version of test_mini_installer would have caught this
> > regression :-(, one more thing on our todo list..!
> 
> I had the same thought. Filed: http://crbug.com/442400.

Can someone explain why setup.exe depends on BoringSSL? We're specifically
maintaining a set of Windows-API only interfaces for setup.exe to avoid any
dependency on BoringSSL (or NSS). This definitely seems like it might be a real
bug/issue we should fix.

[grt (UTC plus 2), 2014-12-15 22:39:16]

On 2014/12/15 20:30:45, Ryan Sleevi wrote:
> Can someone explain why setup.exe depends on BoringSSL? 

I'd be delighted to. setup.exe requires crcrypto.dll for
crypto::SHA256HashString (installer/setup/install.cc calls into
installer/util/auto_launch_util.cc, which uses SHA256). crcrypto.dll requires
boringssl.dll for a great many of its exports.

> We're specifically
> maintaining a set of Windows-API only interfaces for setup.exe to avoid any
> dependency on BoringSSL (or NSS). This definitely seems like it might be a
real
> bug/issue we should fix.

The code in auto_launch_util.cc is used by both setup.exe and chrome.exe. We
could switch to using CryptoAPI as long as the AES provider (in which SHA256 is
implemented) is available on all versions of Windows we support (I don't
remember if/when it was available on XP). I'm happy to learn if there's a better
way.