Client evaluates relevance differently from QnA - Bug?

(imported topic written by JasonWalker)

Situation: I’m trying to import our company’s internal Certificate Authorities (3 of them) into the Java cacerts files.

Step 1 is to use a Task to export the current content of the cacerts file (using keytool) to a text file under the BESClient folder. Then I will parse that file with a Fixlet. If the file does not contain my company’s CA certificate, I will import the certificate using keytool, then regenerate the text export.

Task:

delete __appendfile
appendfile “{(value “InstallLocation” of keys whose (value “DisplayName” of it as string as lowercase contains “j2se runtime environment” OR value “DisplayName” of it as string as lowercase contains “runtimeenvironment” OR value “DisplayName” of it as string as lowercase starts with “java™” OR value “DisplayName” of it as string as lowercase starts with “java 7”) of key “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall” of native registry as string & “bin\keytool.exe”)}” -list -keystore “{(value “InstallLocation” of keys whose (value “DisplayName” of it as string as lowercase contains “j2se runtime environment” OR value “DisplayName” of it as string as lowercase contains “runtimeenvironment” OR value “DisplayName” of it as string as lowercase starts with “java™” OR value “DisplayName” of it as string as lowercase starts with “java 7”) of key “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall” of native registry as string & “lib\security\cacerts”)}” -storepass changeit > “{data folder of client as string & “\jre-certs-native.txt”}”

   delete GetCACert.cmd
   move "__appendfile" GetCACert.cmd
   waithidden cmd.exe /c GetCACert.cmd

The Task works correctly and creates the c:\Program Files (x86)\BigFix\BES Client__BESData\jre-certs-native.txt file. I can parse this file in Relevance to determine whether my company’s CA certificate is present:

exists it whose (it > 0) of (number of elements of it) of (set of (“Certificate fingerprint (SHA1): E9:15:D3:1C:BE:3A:D4:9F:4B:FD:32:DF:F5:61:2D:F9:EE:D7:67:F1”;“Certificate fingerprint (SHA1): 02:FF:F6:B3:FC:81:5C:57:E6:83:2D:FC:38:61:85:13:33:B0:C3:0B”;“Certificate fingerprint (SHA1): 76:A6:EA:A8:52:71:0E:00:B3:68:C4:10:80:E6:13:11:40:AA:F1:89”) - set of lines of it) of files (“jre-certs-native.txt”;“jre-certs-wow6432.txt”) of data folder of client

The Action downloads our CA certificates, uses keytool to import the certificates into our keystores, then regenerates the text file exports.

When I run the Action, it works correctly, the CA certificates are in the Java keystore, and the text file export correctly lists our certificate fingerprints. However the Action always returns “Failed”, and the Fixlet remains Relevant.

When I query in the Fixlet Debugger, the “exists” relevance above returns False.

I believe this is a Bug in the client, maybe some kind of bad file caching in the client, but Support won’t touch this because it’s custom content. Any ideas why the inspector would return False through QnA but True through the client?

(imported comment written by jeremylam)

This is expected; Fixlet Debugger / Relevance Debugger / QNA run as if they are their own client and do not interact with the actual running client on the local system.

You can see this clearly if you run this query in the Fixlet Debugger:

q: pathname of client

q: version of client

Fear not as you can run relevance expressions as if you were the running client on the local system. In the Debug Menu there is an “Evaluate Using >” option that allows you to change between local fixlet debugger context and local client context.

Alas I don’t think it exists for running actions in the Fixlet Debugger.

(imported comment written by JasonWalker)

Thanks, I understand that, but I’m running the Debugger in “Local Client Evaluation Mode”, the QnA responses indicate it’s looking at the correct files, it’s giving me the right values, and visual inspection of the files tells me the Fixlet Debugger is correct; only the BES Client is giving me an incorrect value.

q: pathname of data folder of client

A: C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData

T: 0.121 ms

I: singular string

q: exists files (“jre-certs-native.txt”;“jre-certs-wow6432.txt”) of data folder of client

A: True

T: 0.191 ms

I: singular boolean

q: exists it whose (it > 0) of (number of elements of it) of (set of (“Certificate fingerprint (SHA1): E9:15:D3:1C:BE:3A:D4:9F:4B:FD:32:DF:F5:61:2D:F9:EE:D7:67:F1”;“Certificate fingerprint (SHA1): 02:FF:F6:B3:FC:81:5C:57:E6:83:2D:FC:38:61:85:13:33:B0:C3:0B”;“Certificate fingerprint (SHA1): 76:A6:EA:A8:52:71:0E:00:B3:68:C4:10:80:E6:13:11:40:AA:F1:89”) - set of lines of it) of files (“jre-certs-native.txt”;“jre-certs-wow6432.txt”) of data folder of client

A: False

T: 1.864 ms

I: singular boolean

Is there anything else the Client could be doing differently from the Fixlet Debugger? I started off by thinking the Client may cache a copy of the text files rather than re-reading them, or may be using a stale file handle, or something along those lines.

Now I wonder whether “lines of file” evaluates differently between Fixlet Debugger and the Client, and maybe the end-of-line characters are causing a conflict (similar to how an Action translates “%0d%0f” as CR/LF while Fixlet Debugger would display them literally)?

(imported comment written by jgstew)

what version of the client are you running?

(imported comment written by JasonWalker)

q: version of client

A: 9.0.835.0

T: 0.177 ms

I: singular version