x32-edit 4.3 (new cask)

[mooogah]

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused (add your cask's name to the end of the search field).
• brew audit --cask --new <cask> worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

[bevanjkay]

This should probably be failing the notarization audit on CI, I'm not sure why it is passing.

@krehel any ideas?

[khipp]

We changed the notarization audit in Homebrew/brew#17031 to handle Apps differently. However, the assessment type install seems to be stricter and runs additional checks:

$ spctl --assess --type execute -vv /Applications/X32-Edit.app
X32-Edit.app: accepted
source=Developer ID
origin=Developer ID Application: Music Group Research UK Limited (KZ84TRLT54)

$ spctl --assess --type install -vv /Applications/X32-Edit.app
X32-Edit.app: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: Music Group Research UK Limited (KZ84TRLT54)

[p-linnane]

We may need to change our notarization check per the above. Thoughts @Homebrew/brew & @Homebrew/cask?

[krehel]

Doing this would essentially put the audit back prior to the changes made a few months back, but I believe I made those changes because this was tripping false positives on new cask.

It's probably better to add an additional step to check notarization since this is what Apple recommends, but it's unclear why this one specifically is "passing"

[MikeMcQuaid]

I think we're going to have to accept either false positives or false negatives with this check and have workarounds for either.

[khipp]

The app seems to pass the assessment based on rule 6, which does not check whether the app is notarized.
I found that Apple uses the OID 1.2.840.113635.100.6.1.33 for the developer ID date and checks if it predates the updated notarization requirements introduced in macOS 10.14.5. The timestamp is missing from the certificate, which is also acceptable under this rule.

$ spctl --list --label "Developer ID"
9[Developer ID] P4 allow lsopen
    anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists and legacy
7[Developer ID] P4 allow install
    anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists and (certificate leaf[field.1.2.840.113635.100.6.1.14] or certificate leaf[field.1.2.840.113635.100.6.1.13]) and legacy
6[Developer ID] P4 allow execute
    anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists and (certificate leaf[timestamp.1.2.840.113635.100.6.1.33] absent or certificate leaf[timestamp.1.2.840.113635.100.6.1.33] < timestamp "20190408000000Z")

$ spctl --assess --type execute --raw /Applications/X32-Edit.app
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>assessment:authority</key>
    <dict>
        <key>assessment:authority:flags</key>
        <integer>2</integer>
        <key>assessment:authority:row</key>
        <integer>6</integer>
        <key>assessment:authority:source</key>
        <string>Developer ID</string>
    </dict>
    <key>assessment:remote</key>
    <true/>
    <key>assessment:verdict</key>
    <true/>
</dict>
</plist>