Tests: Fix SNTRuleTableTest in the presence of local static rules

google · Mar 19, 2024 · 3b8ac34 · 3b8ac34
1 parent 77d191a
commit 3b8ac34
Show file tree

Hide file tree

Showing 3 changed files with 19 additions and 6 deletions.
diff --git a/Source/santad/BUILD b/Source/santad/BUILD
@@ -901,6 +901,7 @@ santa_unit_test(
         "@FMDB",
         "@MOLCertificate",
         "@MOLCodesignChecker",
+        "@OCMock",
     ],
 )
 

diff --git a/Source/santad/DataLayer/SNTRuleTable.m b/Source/santad/DataLayer/SNTRuleTable.m
@@ -368,7 +368,7 @@ - (SNTRule *)ruleForIdentifiers:(struct RuleIdentifiers)identifiers {
   //
   // The intended order of precedence is CDHash > Binaries > Signing IDs > Certificates > Team IDs.
   //
-  // As such the query should have "ORDER BY type DESC" before the LIMIT, to ensure that is the
+  // As such the query should have "ORDER BY type ASC" before the LIMIT, to ensure that is the
   // case. However, in all tested versions of SQLite that ORDER BY clause is unnecessary: the query
   // is performed 'as written' by doing separate lookups in the index and the later lookups are if
   // the first returns a result. That behavior can be checked here: http://sqlfiddle.com/#!5/cdc42/1
@@ -383,8 +383,8 @@ - (SNTRule *)ruleForIdentifiers:(struct RuleIdentifiers)identifiers {
   [self inDatabase:^(FMDatabase *db) {
     FMResultSet *rs =
       [db executeQuery:@"SELECT * FROM rules WHERE "
-                       @"   (identifier=? and type=500) "
-                       @"OR (identifier=? and type=1000) "
+                       @"   (identifier=? AND type=500) "
+                       @"OR (identifier=? AND type=1000) "
                        @"OR (identifier=? AND type=2000) "
                        @"OR (identifier=? AND type=3000) "
                        @"OR (identifier=? AND type=4000) LIMIT 1",

diff --git a/Source/santad/DataLayer/SNTRuleTableTest.m b/Source/santad/DataLayer/SNTRuleTableTest.m
@@ -14,8 +14,10 @@
 
 #import <MOLCertificate/MOLCertificate.h>
 #import <MOLCodesignChecker/MOLCodesignChecker.h>
+#import <OCMock/OCMock.h>
 #import <XCTest/XCTest.h>
 
+#import "Source/common/SNTConfigurator.h"
 #import "Source/common/SNTRule.h"
 #import "Source/common/SNTRuleIdentifiers.h"
 #import "Source/santad/DataLayer/SNTRuleTable.h"
@@ -24,6 +26,7 @@
 @interface SNTRuleTableTest : XCTestCase
 @property SNTRuleTable *sut;
 @property FMDatabaseQueue *dbq;
+@property id mockConfigurator;
 @end
 
 @implementation SNTRuleTableTest
@@ -33,6 +36,13 @@ - (void)setUp {
 
   self.dbq = [[FMDatabaseQueue alloc] init];
   self.sut = [[SNTRuleTable alloc] initWithDatabaseQueue:self.dbq];
+
+  self.mockConfigurator = OCMClassMock([SNTConfigurator class]);
+  OCMStub([self.mockConfigurator configurator]).andReturn(self.mockConfigurator);
+}
+
+- (void)tearDown {
+  [self.mockConfigurator stopMocking];
 }
 
 - (SNTRule *)_exampleTeamIDRule {
@@ -296,15 +306,17 @@ - (void)testFetchCDHashRule {
 }
 
 - (void)testFetchRuleOrdering {
+  NSError *err;
   [self.sut addRules:@[
     [self _exampleCertRule], [self _exampleBinaryRule], [self _exampleTeamIDRule],
-    [self _exampleSigningIDRuleIsPlatform:NO], [self _exampleCDHashRule]
+    [self _exampleSigningIDRuleIsPlatform:NO], [self _exampleCDHashRule],
   ]
          ruleCleanup:SNTRuleCleanupNone
-               error:nil];
+               error:&err];
+  XCTAssertNil(err);
 
   // This test verifies that the implicit rule ordering we've been abusing is still working.
-  // See the comment in SNTRuleTable#ruleForBinarySHA256:certificateSHA256:teamID
+  // See the comment in SNTRuleTable#ruleForIdentifiers:
   SNTRule *r = [self.sut
     ruleForIdentifiers:(struct RuleIdentifiers){
                          .cdhash = @"dbe8c39801f93e05fc7bc53a02af5b4d3cfc670a",