1. 11 Dec, 2009 5 commits
  2. 09 Dec, 2009 2 commits
  3. 08 Dec, 2009 1 commit
  4. 07 Dec, 2009 2 commits
  5. 04 Dec, 2009 1 commit
  6. 03 Dec, 2009 4 commits
  7. 02 Dec, 2009 3 commits
  8. 01 Dec, 2009 1 commit
  9. 30 Nov, 2009 2 commits
    • Juan Lang's avatar
      crypt32: Revert 8ed5a777. · 90c160c3
      Juan Lang authored
      Ordinarily removing tests seems like a bad idea, but in this case it
      seems the only rational response to the test failures the tests
      produce.  The tests check the state of three bits with a variety of
      certificate and CRL combinations.  One of these bits is apparently not
      set by any version of Windows for any of the tests.  Testing its
      absence doesn't seem correct, and I'll explain why in more detail in a
      second.  Every permutation of the remaining two bits appears on at
      least one Windows version, and no Windows version is obviously more
      correct than the rest, so testing them doesn't seem worthwhile.
      
      The one bit that doesn't appear to be set is the bit saying that a
      certificate is revoked.  I created CRLs that do in fact revoke some of
      the tested certificates, so it appears to me that the bit should be
      set.  It's possible that Windows doesn't bother checking the
      revocation status of a certificate whose anchor isn't trusted, but
      it's impossible to test this in an automated regression test suite,
      because adding a trusted certificate requires clicking OK (or its
      equivalent) in a dialog.  The dialog is invoked by the system process,
      so I can't use a dialog hook to suppress it.  I can test this
      hypothesis manually, but it isn't possible to do so in an automated
      way.
      90c160c3
    • Juan Lang's avatar
  10. 21 Nov, 2009 11 commits
  11. 20 Nov, 2009 7 commits
  12. 19 Nov, 2009 1 commit