pam_google used to install /etc/login_trust_root.pem, and then this script would
modify it. We no longer install pam_google, so we need to create this file
de-novo now.
BUG=None
TEST=build_image, then mod for test. Check that /etc/login_trust_root.pem exists, contains one cert, and has the right permissions. For maximum goodness, run login_LoginSuccess
Change-Id: I409ffeea4b30905cf9e0506650b67556fa5ec80e
Review URL: http://codereview.chromium.org/3185024
BUG=5130
TEST=create a test image, boot it on a device, and run "sudo nsscertutil -d "sql:/etc/fake_root_ca/nssdb" -L -n FakeCert | less". Look at the section of the output marked "Validity:" and make sure the Not Before and Not After sections indicate dates that are 3 weeks apart
Change-Id: I67cf7e71027147f83c1bc916557bc06ef66fa0e0
Review URL: http://codereview.chromium.org/3075025
mod_image_for_test.sh now passes the target architecture to the subscripts
mod_for_test_scripts/710enableAuthTesting generates the /etc/fake_root_cert
databases by running nsscertutil under QEMU.
BUG=3310
TEST=Built autotest enabled images for x86 and arm. On arm, the browser no
longer crashes trying to read the fake root certs.
Review URL: http://codereview.chromium.org/2878033
After discussing with drewry, we can't come up with a better way to inject these root certs. We considered putting them on the stateful partition, but that opens up an avenue of attack (if you can get a root cert into the magic directory, then you can MITM login). Thus, we put it on the rootfs instead. The script that sets up the hashes for vboot will verify that this directory is not present in production images. That work is tracked here: http://code.google.com/p/chromium-os/issues/detail?id=2693
Review URL: http://codereview.chromium.org/1566055
