certsync: Please test patches on systems < 10.9

[Clemens Lang]

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.

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: certsync.m.diff
Type: text/x-patch
Size: 17043 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140606/91c8aa0a/attachment-0001.bin>