Mock the daemon and run tests against prod builds

[oskirby]

Description

This is something of a hobby project. The end goal is to try and run functional tests against production builds of the VPN client, and to get there we need a way to mock out the controller a little better. The first checkpoint of which is to write a mock daemon and replace the DummyController with it.

Roughly speaking a high-level change log for this effort goes like this:

1. Implement a new MockDaemon class that mocks out the daemon APIs and creates a local socket server.
2. Replace the DummyController with a LocalSocketController that talks to the mocked daemon.
3. Extend the --testing option to automatically create the mock daemon.
4. Add a feature to disable Balrog.
5. Try to replace all #ifdef MZ_DUMMY with runtime switches triggered by --testing:

Then to get tests working on the production builds, we need to extend the --testing option to make the prod build act like the dummy build:

• Disable cryptosettings.
• Disable/reset glean telemetry.
• Mock out the AppListProvider class.
• Use a different settings file.

Reference

This is a prerequisite for the following JIRA tasks

• VPN-5768 - Automate functional tests for Windows
• VPN-3077 - Automate functional tests for iOS/Android

Checklist

• My code follows the style guidelines for this project
• I have not added any packages that contain high risk or unknown licenses (GPL, LGPL, MPL, etc. consult with DevOps if in question)
• I have performed a self review of my own code
• I have commented my code PARTICULARLY in hard to understand areas
• I have added thorough tests where needed

[strseb]

FANCY!

[mcleinman]

Thanks for this! Lots of questions, but all to make sure I better understand what I'm approving here.

[mcleinman]

Apologies for my lack of understanding - why can't we have encryption on our dummy builds?

[oskirby]

This was done for MacOS (and presumably iOS too?) - access to platform secrets is something that requires a signed executable, and we don't want to require codesigning to run tests. It used to be that the Crypto settings for MacOS were no-ops when compiled with MZ_DUMMY so this just kind of made it consistent for all platforms.

[oskirby]

After a bit of research, I think we could put this back if we add a check to disable crypto settings if the codesign is invalid on MacOS. Something to the tune of:

#include <sys/codesign.h>

MacOSCryptoSettings::MacOSCryptoSettings() : CryptoSettings() {
  int flags = 0;
  if ((csopts(getpid(), CS_OP_STATUS, &flags, sizeof(flags) == 0) && (flags & CS_VALID)) {
    m_keyVersion = CryptoSettings::EncryptedChachaPolyV1;
  } else {
    m_keyVersion = CryptoSettings::NoEncryption;
  }
}

[strseb]

Would that mean if somone bitflips a thing in our binary, therefore breaking codesign we would just disable encyption?
I actually like the specific-opt in :D

[mcleinman]

I think I prefer it to be aligned with code signing instead of a compile flag. Thinking about the ways a hidden adversary could exploit this down the line, it seems more likely to get a "build with a testing flag" out into prod than a "build that wasn't codesigned".

[oskirby]

I agree, it sounds much better to disarm the cryptosettings by checking for valid codesignatures.

Joke is on me though - we kind of all agree that it should be done this way... but it's actually turning out to be hard to do.

[oskirby]

I did it! See the PR here: #9679

Once that one is merged, I will rebase this and undo the crypto settings mocks.

[oskirby]

Rebase complete!

[mcleinman]

Thanks! Just one more thing before I feel comfortable approving.

[mcleinman]

I think I prefer it to be aligned with code signing instead of a compile flag. Thinking about the ways a hidden adversary could exploit this down the line, it seems more likely to get a "build with a testing flag" out into prod than a "build that wasn't codesigned".

[mcleinman]

👍🏻 Thanks!