certsync: Please test patches on systems < 10.9

[Eric Gallager]

On 6/5/14, Clemens Lang <cal at macports.org> wrote:
> Hi,
>
> Thanks for the feedback everyone. More details inline below:
>
>
>> Like we do with the Portfiles in trunk, could you split the patch between
>> the whitespace changes and the functionality changes?
>
> I could, but it would mean extra work for me because our version control
> system does not support generating (or committing) partial patches. So I'm
> just not going to bother.
>
>> Right now with the two of them together, it is kind of harder to know
>> which sections of the patch to focus on when reading it...
>
> Looking at the patch, it's not very hard to ignore the whitespace-only
> hunks,
> especially since they're mostly separated from the changes in the code.
> Reading the diff isn't very helpful anyway, though, because I completely
> swapped one function with a different one, making the diff pretty
> meaningless.
>
>
>> Fails to build on Snow Leopard:
>>
>> <built-in>:0: warning: Mac OS X version 10.5 or later is needed for use
>> of the new objc abi
>
> I'm not sure what that means.

"new" means "64-bit" in that case. You get that warning when you
compile for a 64-bit architecture with '-mmacosx-version-min=' set to
'10.4' or lower.

>
>> certsync.m:226: warning: implicit declaration of function
>> ‘SecTrustGetTrustResult’
>> Undefined symbols:
>>   "_SecTrustGetTrustResult", referenced from:
>>       _certificatesForTrustDomain in ccQPWJhT.o
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>
> I've removed the call to SecTrustGetTrustResult. Its result was unused
> anyway.
>
>
>> Leopard:
>>
>> certsync.m:162: warning: implicit declaration of function
>> ‘SecPolicyCreateBasicX509’
>
> I've provided an alternative implementation of the same behavior for
> systems
> without SecPolicyCreateBasicX509. The source of SecurityTool [1] was very
> helpful for this.
>
>
>> and Tiger:
>>
>> certsync.m:28:25: error: Availability.h: No such file or directory
>
> That would require a configure script to fix, but …
>
>> certsync.m:294: warning: implicit declaration of function
>> 'SecTrustSettingsCopyTrustSettings'
>> certsync.m: In function 'exportCertificates':
>> certsync.m:402: warning: implicit declaration of function
>> 'SecCopyErrorMessageString'
>
> … since I think those have been present before my changes, I'm not sure I'm
> going to bother. It looks like it's just a matter of wrapping the call to
> SecTrustSettingsCopyTrustSettings in an if that checks for the function's
> availability and just consider the certificate trusted if there aren't any.
>
> The calls to SecCopyErrorMessageString could probably be replaced by a
> dummy
> message on systems that don't have the function.
>
>
> Please test again (and feel free to patch for Tiger, especially if you can
> test on this system, because I'm fishing in muddy waters there, given I
> can't verify only the *trusted* roots are exported).
>
> [1]
> http://opensource.apple.com/source/SecurityTool/SecurityTool-40596/verify_cert.c
>
> --
> Clemens Lang
>