Bug 1267318 - ignore cert expiration for mozilla-signed packages, r=dkeeler, a=lizzard
authorDaniel Veditz <dveditz@mozilla.com>
Tue, 26 Apr 2016 11:54:08 -0700
changeset 332622 d6d1b8b21016f5163ff5d1273f6080bd279481ba
parent 332621 3b60d399d4eef579688a499675c337a252a7bcac
child 332623 9989b1e6fce85f2c0dcae7eea00bf92e9c74ee07
push id6048
push userkmoir@mozilla.com
push dateMon, 06 Jun 2016 19:02:08 +0000
treeherdermozilla-beta@46d72a56c57d [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersdkeeler, lizzard
bugs1267318
milestone48.0a2
Bug 1267318 - ignore cert expiration for mozilla-signed packages, r=dkeeler, a=lizzard MozReview-Commit-ID: Lw6jGmK8gkS
security/apps/AppSignatureVerification.cpp
--- a/security/apps/AppSignatureVerification.cpp
+++ b/security/apps/AppSignatureVerification.cpp
@@ -646,16 +646,37 @@ VerifyCertificate(CERTCertificate* signe
   }
 
   rv = BuildCertChain(trustDomain, certDER, Now(),
                       EndEntityOrCA::MustBeEndEntity,
                       KeyUsage::digitalSignature,
                       KeyPurposeId::id_kp_codeSigning,
                       CertPolicyId::anyPolicy,
                       nullptr/*stapledOCSPResponse*/);
+  if (rv == Result::ERROR_EXPIRED_CERTIFICATE) {
+    // For code-signing you normally need trusted 3rd-party timestamps to
+    // handle expiration properly. The signer could always mess with their
+    // system clock so you can't trust the certificate was un-expired when
+    // the signing took place. The choice is either to ignore expiration
+    // or to enforce expiration at time of use. The latter leads to the
+    // user-hostile result that perfectly good code stops working.
+    //
+    // Our package format doesn't support timestamps (nor do we have a
+    // trusted 3rd party timestamper), but since we sign all of our apps and
+    // add-ons ourselves we can trust ourselves not to mess with the clock
+    // on the signing systems. We also have a revocation mechanism if we
+    // need it. It's OK to ignore cert expiration under these conditions.
+    //
+    // This is an invalid approach if
+    //  * we issue certs to let others sign their own packages
+    //  * mozilla::pkix returns "expired" when there are "worse" problems
+    //    with the certificate or chain.
+    // (see bug 1267318)
+    rv = Success;
+  }
   if (rv != Success) {
     return mozilla::psm::GetXPCOMFromNSSError(MapResultToPRErrorCode(rv));
   }
 
   return NS_OK;
 }
 
 nsresult