It seems that the intermittent failure we see on the login screen
is due to a sort of mixed-content error, where there's a failure
within the page to load some embedded resource due to a cert error.
Make the SSL cert we inject work for any google.com server to
work around this.
BUG=chromium-os:20323
TEST=login_CryptohomeMounted 50x, suite_Smoke
Change-Id: Ic8e5b9bec799cd19cccfeddd2990fe3a494d2184
Reviewed-on: http://gerrit.chromium.org/gerrit/8818
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Ready: Chris Masone <cmasone@chromium.org>
Tested-by: Chris Masone <cmasone@chromium.org>
This command was failing before (and the error getting swamped in log output)
resulting in a later command auto-creating the database and failing to
set the trust settings of the fake SSL cert we use in tests correctly.
BUG=chrome-os-partner:4923
TEST=build arm-generic test image, see that there are no error messages after "Generating a 1024 bit RSA private key" in the output log
Change-Id: I5b0c05d90e528aa5047cb12aa338cef176d233aa
Reviewed-on: http://gerrit.chromium.org/gerrit/5519
Reviewed-by: Chris Masone <cmasone@chromium.org>
Tested-by: Chris Masone <cmasone@chromium.org>
BUG=chromium-os:15989
TEST=build an image and mod it for test. See that there's no complaint about an 'Invalid Password'. Run suite_Smoke
STATUS=Fixed
Change-Id: I34bb47576ab8d5df11e79489f4996897ebf2ca3f
Reviewed-on: http://gerrit.chromium.org/gerrit/3694
Tested-by: Chris Masone <cmasone@chromium.org>
Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Various members of /dev are used (such as /dev/random) in this script,
and <() style redirection is used which requires a mounted /proc in the
image.
So bind-mount /dev and /proc while running so they work.
BUG=chromiumos:15951
TEST=examined output before/after
Change-Id: I3e8f0edef0da7e63b2af6736e8becfa1cd6d723d
Reviewed-on: http://gerrit.chromium.org/gerrit/1846
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Scott James Remnant <keybuk@chromium.org>
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
