notarization vs MacPorts apps

[Saagar Jha]

Comments inline again.

Saagar Jha

> On Apr 13, 2019, at 22:54, Mojca Miklavec <mojca at macports.org> wrote:
> 
> Can you please reply to the list or is there a good reason not to?

Thanks for the reminder, I’ve re-CC’d macports-dev.

> I'm not saying we should notarize the apps because we have to, but it would not hurt to do some additional security checks in case our compiler gets compromised in some way or if we happen to build some suspicios software / malware.

This check is happening on MacPorts’s servers, right (as opposed to locally on user’s computers when they build from source)? You’re building ports and signing them with a hypothetical “MacPorts Project” developer certificate, then submitting them to be notarized and making the app bundle with a notarization ticket stapled to it available to download by users?

> Mojca
> 
> V ned., 14. apr. 2019 02:09 je oseba Saagar Jha <saagar at saagarjha.com <mailto:saagar at saagarjha.com>> napisala:
> 
> Saagar Jha
> 
>> On Apr 13, 2019, at 08:12, Mojca Miklavec <mojca at macports.org <mailto:mojca at macports.org>> 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.
>> 
>> I assume that if I use rsync to get the binaries as opposed to
>> fetching them via web browser, they might work OK.
> 
> From my understanding of the WWDC Session 702 from last year <https://developer.apple.com/videos/play/wwdc2018/702/>, if your app is signed (which seems the case based on your response) and is notarized, then it will need to opt into the Hardened Runtime and as add one of the entitlements (com.apple.security.cs.allow-jit, probably) to give it the ability to function correctly. However, if MacPorts is fetching or building the binary itself then I don’t see why notarization is required at all, since I think it should be possible to control whether the com.apple.quarantine xattr exists and hence whether GateKeeper actually checks for a valid notarization ticket stapled to the binary/package/whatever (unless the check is actually performed at every launch, regardless of the extended attribute’s existence?).
> 
>> I don't have a payed developer account, so I probably cannot test
>> anything. But I assume there might be a way to individually notarize
>> individual binaries inside MacPorts packages. While this might not be
>> needed at this very moment, it might be that by putting a certificate
>> on the buildslave, we could:
>> - sign the debugger (which currently needs additional steps to work at all)
> 
> I don’t think this actually requires a paid account–signing with any valid certificate in your keychain works IIRC.
> 
>> - get an additional automated safety check for any malware that might
>> have creeped into the source code unnoticed (with tens of thousands of
>> packages that's not impossible), which cannot hurt
>> 
>> 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.
> 
> I’m pretty sure you can get a standard ($99) developer account membership for organizations.
> 
>> These are just some random ideas, it would be nice to get a more
>> realistic response from someone who's more knowledgable in this area.
>> 
>> Mojca
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190414/c2a6f394/attachment-0001.html>