Comments inline again. Saagar Jha
> On Apr 13, 2019, at 22:54, Mojca Miklavec <[email protected]> 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 <[email protected] > <mailto:[email protected]>> napisala: > > Saagar Jha > >> On Apr 13, 2019, at 08:12, Mojca Miklavec <[email protected] >> <mailto:[email protected]>> 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 >
