Mac Relevance OK in QNA, Fails on Client

Content Authoring
1

The end result is to see if there is a certificate installed on the Mac OS. Couldn’t find any other way of doing this in pure relevance, and the solution I found to work in QNA is not working when evaluated with the client.

The code looks at the lines of the binary file “/Library/Keychains/System.keychain”, and tries to match a unique string. I know that looking in the system keychain via “lines” is not ideal, but I would like to avoid using the action to create a file for everything I want to do with the Macs.

Does anyone know why the code would work in QNA, but fail when run on the client itself?

if mac of operating system then 
if exists lines whose (it contains "Apple Root CA0%1e%17") of file "/Library/Keychains/System.keychain" 
then true 
else false 
else error "Not a Mac"

Thanks in advance.

Chris

2

It appears to have something to do with the “%”, though I have tried putting the %25 in it’s place and it still fails. But remove the items after the % sign and it starts to work.

JG’s % Solution, but it doesn’t work. I am just putting this here for reference.

3

So are you actually looking for percents in the string or for the %1E value?

The client percent decodes strings as it parses as the server will percent encode most things. This should be transparent however.

4

Right, I can understand having a hard time handling a %. What I am not understanding is why the QNA tool responds one way, but the client responds a different way. I would have thought that the QNA and the Client engine would respond the same.

Ideally I would be able to take a look inside of the system keychain without needing to revert to using “strings” or lines to do it. But as that is most likely not going to happen I would settle for one or both of the following:

  1. Is there a proper way to interpret the % signs returned in a binary file when viewed as lines?
  2. Is there a way to get the Mac OS X QNA tool to mimic what the BES Client will do?
5

Well they do actually respond the same but the response is geared towards how a client actually “reports”. You are getting a fairly raw interpretation of the reporting of the inspector. This used to be much more “percenty” before the 9.5 release and UTF8 answers.

QnA probably needs to have a command line switch added to it to behave like FixletDebugger does with regards to percent encoding.