Peter Eisentraut <peter_e@gmx.net> writes:
> Given that this doesn't affect "make check" anymore, I'm unsure about
> this patch. There is a lot of magic in the configure change. I don't
> know what to pass as the configure option argument, so can't really
> evaluate that. I'd like to see an explanation for what is done there.
As I said, I'd not written any docs. The argument that would get passed
there is just a name identifying the signing certificate you want to use.
Most of the documentation would be about how to create such a cert, no
doubt. (It's pretty simple to make a self-signed cert using Apple's
keychain utility, but it would require some explanation.)
> I'm afraid there is security ridicule potential. We are essentially
> adding an option to patch out an operating system security feature that
> the user chose. Some might find that neat and ship binaries built that
> way. Because it's "--with-codesign" and not
> "--with-codesign-for-devel-dont-use-in-production".
Yeah, that would be a risk :-(. However, for the typical case of a
self-signed certificate, nothing much would happen because no one
else's machine would even have the same certificate let alone trust it.
> Have we dug deep enough into the firewall configuration to evaluate
> other options? Can we, for example, exclude a port range?
Not that I've been able to detect. Any simple way to do that would
presumably open up exactly the security hole Apple is trying to close,
so I'd bet against there being one. (It is annoying that the firewall
triggers on ports bound to 127.0.0.1, though --- it's not apparent why
that's a security risk. Perhaps there's some way to adjust that choice?)
> I could see adding this as a contrib script if we don't find a better way.
Meh. That's just a less convenient packaging of the same code, with
the same potential for misuse.
regards, tom lane
