notarization vs MacPorts apps

[Joshua Root]

On 2019-4-14 01:12 , Mojca Miklavec wrote:
> Hi,
> 
> On Sat, 13 Apr 2019 at 08:47, Joshua Root  wrote:
>> On 2019-4-13 07:57 , Jack Howarth wrote:
>>>      What will be the situation with 10.14.5 and its enforcement of
>>> notarization for Applications and kernel extensions for MacPorts? In
>>> particular, will the new notarization requirement limit users to the
>>> MacPorts build machine copies of such packages which have applications
>>> rather than being able to build those packages locally?
>>>         Jack
>>
>> The MacPorts installer pkg will need to be submitted, but I don't think
>> much else will change. Using MacPorts-built kernel extensions is already
>> impossible because of signing requirements (we don't have a kext signing
>> certificate and I don't think we qualify for one.)
>>
>> For general apps, Gatekeeper doesn't prevent running locally built ones
>> due to them being unsigned, and I gather than notarization is only
>> required in the same circumstances as signing.
> 
> The developer of MacTeX (which is basically a collection of a large
> number of command-line tools + really small set of GUI apps) started
> researching this in more detail. In the past it would have been
> sufficient to only sign the whole package (dmg) once. Now he needs to
> take care of every single binary inside the package. From what I
> understood it can be automated, some of the binaries require
> additional privileges (I assume that luajittex requires some kind of
> "JIT" privileges etc). There were some issues with ghostscript which
> needs to be additionally hardened etc.

FYI, I submitted the MacPorts 2.5.4 installer package for Mojave and it
was accepted. It did generate these warnings, which indicate things that
may become a problem in future:

    {
      "severity": "warning",
      "code": null,
      "path":
"MacPorts-2.5.4-10.14-Mojave.pkg/MacPorts-2.5.4-component.pkg
Contents/Payload/opt/local/libexec/macports/bin/tclsh8.5",
      "message": "The binary is not signed.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "warning",
      "code": null,
      "path":
"MacPorts-2.5.4-10.14-Mojave.pkg/MacPorts-2.5.4-component.pkg
Contents/Payload/opt/local/libexec/macports/bin/tclsh8.5",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "warning",
      "code": null,
      "path":
"MacPorts-2.5.4-10.14-Mojave.pkg/MacPorts-2.5.4-component.pkg
Contents/Payload/opt/local/libexec/macports/bin/tclsh8.5",
      "message": "The executable does not have the hardened runtime
enabled.",
      "docUrl": null,
      "architecture": "x86_64"
    },

(the same 3 warnings were generated for every binary in the pkg)

I never did figure out how to codesign something that isn't a bundle. If
we can sign the binaries, a secure timestamp is very easy to include.
OTOH, the documentation covering how to enable the hardened runtime just
says to check some boxes in the Xcode GUI...

> I don't know if a certificate can be issues to a project instead of
> private person and to what extent one can secure it on the servers.

Certainly a certificate can be issued to an organisation provided that
it is a legal entity (and it pays its fee to Apple).

- Josh