Ciderport von EasyCash&Tax - Hilfe bei Icon und Signieren gesucht

Mankind75

Mankind75

Aktives Mitglied
Thread Starter
Dabei seit
28.06.2005
Beiträge
2.773
Reaktionspunkte
829
Hallo zusammen,

EasyCash&Tax ist eine Windows-Freeware, die demnächst in einer Mac-Version in den AppStore kommen soll. Ich selbst teste die Anwendung hin und wieder unter wine auf Linux und der Entwickler hat etwas Geld in die Hand genommen um einen wine-Wrapper / Ciderport (wine mit Äpfeln) zu erstellen.

Auf meinem Mac mini 2012 (macOS 10.14.6) installiert das Paket leider nur wenn ich den Entwickler explizit in den Sicherheitseinstellungen zulasse. Auch wollten wir das Standardicon (Block mit Stift) im Dock mit diesem Icon ersetzen.

Hat jemand vielleicht ein paar Tipps und Lösungsvorschläge?
 
Das Icon geht über die Info.plist in der App.
Was hattest du denn eingestellt?
Nur Appstore?
 
  • Gefällt mir
Reaktionen: Mankind75
Was hattest du denn eingestellt?
Danke für die Rückmeldung. Es war eine frische Installation von macOS 10.14.6 wo ich mir das .zip-Paket herunter geladen habe und dann installieren wollte. Standardmäßig meldete macOS, dass eine Installation nicht möglich sei. Danach habe ich in den Systemeinstellungen unter "Sicherheit" geschaut und dort die Downloadquelle gesehen und habe auf "dennoch erlauben" geklickt. Danach öffnete sich ein Fenster wo man die Anwendung in den Programme-Ordner kopieren konnte. Das habe ich dann auch gemacht.
 
Ist der denn zertifizierter Entwickler mit entsprechenden Zertifikat?
Ab Catalina ist das ja noch anders mit der Überprüfung.
 
Hat jemand vielleicht ein paar Tipps und Lösungsvorschläge?

Installiert euch mal Taccy (https://eclecticlight.co/taccy-signet-precize-alifix-utiutility-alisma/), damit lassen sich Apps ganz gut analysieren. Beim oben gennaten Paket wird ein fehlerhafter Symbolic Link im Bundle angemeckert...

EasyCT 2021-06-05 15-19-48.png
 
Hallo! ManKind75 hat mich informiert, dass er hier die Frage gestellt hat. Ich bin der Autor der besagten Software und hatte die
Frage auch schon auf Stackoverflow gestellt, bekam aber nur ein -1 Rating. Immerhin hat mein Codeweavers-Kontakt sich daraufhin noch einmal erbarmt mir ein Script zum Signieren zuzusenden:

Eine Korrektur: Ich habe das CodeWeavers-Produkt (sie haben es neuerdings in PortJump umbenannt) wohl anfangs missverstanden. Eine Veröffentlichung im App-Store ist wohl für dieses Projekt überhaupt nicht möglich -- das erstellte Paket muss schon selbst gehostet werden. Und es geht jetzt nur noch darum, den Apple-Signierungs- und Notarisierungs-Prozess zu durchlaufen, damit Gatekeeper sich nicht beschwert und eine Sicherheitsausnahmeregel erzwingt.

Code:
#!/bin/bash

MAC_SIGNING_IDENTITY="Developer ID Application:"
entitlements="wine32on64.entitlements"
app="$1"
product_id=
bundle_id=
SRCROOT=.

if [ ! -f $entitlements ]
then
    echo "$entitlements not found. Make sure it's in your working directory."
        exit 1
fi

if [ -z "$app" ]
then
    echo "You must specify the absolute path to the .app"
        exit 1
fi

if [ ! -d "$app" ]
then
    echo "The path You specify is invalid. Please provide the absolute path to the .app"
        exit 1
fi

if [[ ! "$app" = /* ]]
then
    echo "The path you specified is not an absolute path. Please provide the absolue path to the .app"
        exit 1
fi

if [ -z "$bundle_id" ]
then
    bundle_id=`defaults read "$app/Contents/Info.plist" CFBundleIdentifier`
    if [ -z "$bundle_id" ]
    then
        echo "Could not determine the product name from '$app'. Did you provide the absolute path to the .app?"
        exit 1
    fi
fi
echo "Bundle ID = \"$bundle_id\""

if [ -z "$product_id" ]
then
    product_id=`ls -d "$app/Contents/SharedSupport"/* | grep -v '/X11'`
    if [ ! -d "$product_id" ]
    then
        echo "could not determine the product id from '$app'"
        exit 1
    fi
    product_id=`basename "$product_id"`
    echo "$product_id" | LC_ALL=C egrep '^[a-zA-Z0-9_][a-zA-Z0-9_][a-zA-Z0-9_][a-zA-Z0-9_][a-zA-Z0-9_]*$' >/dev/null
    if [ $? -ne 0 ]
    then
        echo "the product id '$product_id' is not valid"
        exit 1
    fi
fi
echo "Product ID   = \"$product_id\""

keychain=$(security find-certificate -c "$MAC_SIGNING_IDENTITY" | grep keychain | awk 'gsub(/"/, "", $2) {print $2}')
locked=$(security show-keychain-info "$keychain" 2>&1 | grep "timeout")
if [ -z "$locked" ]
then
        echo "Failed to find unlocked keychain with required certificate. Is your certificate in an unlocked keychain in your keychain search path?"
        echo "Your keychain search path is:"
    security list-keychain
        exit 1
fi

if [ "$MAC_SIGNING_IDENTITY" != "-" ] ; then
    # Figure out the Organizational Unit (OU) from the signing identity
    ou=$(
        set -x
        security find-certificate -p -c "$MAC_SIGNING_IDENTITY" | \
            openssl x509 -inform PEM -subject -noout -nameopt sname,sep_multiline,space_eq | \
            awk '/ OU = / {print $3}'
    )

    if [ -z "$ou" ]; then
        echo "error: Could not determine OU from signing identity '$MAC_SIGNING_IDENTITY'"
        exit 1
    fi
fi

set -e

# Sign the app.  The designated requirements were obtained by watching what Xcode 4.3
# does when it signs for Developer ID.
function sign_one()
{
    file="$1"; shift
    identifier="$1"; shift
    if [ "$MAC_SIGNING_IDENTITY" = "-" ] ; then
        codesign --sign "$MAC_SIGNING_IDENTITY" \
            --force \
            "$file" "$@"
    else
        codesign --sign "$MAC_SIGNING_IDENTITY" \
            --force \
            --requirements "=designated => anchor apple generic and identifier \"$identifier\" \
               and ((cert leaf[field.1.2.840.113635.100.6.1.9] exists) or \
                    (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[subject.OU] = \"$ou\" \
                    ))" \
            "$file" "$@"
    fi
}

function sign_subdir()
{
  subdir="$1" ; shift
  id_component="$1" ; shift
    
  find "$subdir/" -type f \( -name "*.so" -o -name "*dylib" -o -exec sh -c 'file "$0" | fgrep -qsw Mach-O' {} \; \) -print0 |
    while IFS= read -r -d '' file ; do
      name=$(basename "$file")
      name="${name//[^-a-zA-Z0-9]/-}"
      if [ -z "${name/#[^a-zA-Z]*}" ] ; then
        name="a-$name"
      fi
      if [ -z "${name/%*[^a-zA-Z0-9]}" ] ; then
        name="$name-0"
      fi
      identifier="$bundle_id.$id_component.$name"
      sign_one "$file" "$identifier" --identifier "$identifier" "$@"
    done
}

set -x

# Sign Sparkle framework and pyobjc bundle separately from the app bundle
if [ -d "$app/Contents/Frameworks/Sparkle.framework" ]; then
  sign_one "$app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/finish_installation.app" "org.andymatuschak.sparkle.finish-installation" --options runtime
  sign_one "$app/Contents/Frameworks/Sparkle.framework" "org.andymatuschak.Sparkle"
fi

sign_subdir "$app/Contents/SharedSupport/$product_id/bin" "bin" --options runtime

for libdir in "$app/Contents/SharedSupport/$product_id"/lib* ; do
  sign_subdir "$libdir" "$(basename "$libdir")"
done

# The wine (pre)loaders were already signed with the bin directory, above, but
# we need to re-do it with entitlements

for i in "$app/Contents/SharedSupport/$product_id/bin"/wine*loader*; do
    sign_one "$i" "$bundle_id.wineloader" \
        --options runtime \
        --entitlements "$SRCROOT/wine32on64.entitlements"
done

sign_one "$app" "$bundle_id" --options runtime --entitlements "$SRCROOT/wine32on64.entitlements"

Mit etwas Hilfe habe ich mir auch ein kleines Script zum Notarisieren zusammengeschrieben:

Code:
ditto -c -k --keepParent EasyCT.app EasyCT.zip
output=$(xcrun altool --notarize-app --primary-bundle-id de.easyct.easyct --asc-provider "MYTEAMID" -u "my@apple.id" -p "abcd-efgh-ijkl-mnop" --file EasyCT.zip)
ticket_id=$(echo "$output" | grep RequestUUID | awk '{print $3}')

if [ -z "$ticket_id" ]
then
    echo "Error: No ticket id was returned.\n\n$output"
        exit 1
fi

echo "Notarization ticket: $ticket_id"
xcrun altool --notarization-info "$ticket_id" -u "my@apple.id" -p "abcd-efgh-ijkl-mnop"

xcrun stapler staple EasyCT.app

spctl --assess --type open --context context:primary-signature --verbose EasyCT.zip

Code:
thomas@Thomass-Mac-mini-2 easycashmac % ./notarize
Notarization ticket: e63220f6-6c9c-4337-8c39-83f35b8e2ef7
No errors getting notarization info.

thomas@Thomass-Mac-mini-2 easycashmac % xcrun altool --notarization-info "e63220f6-6c9c-4337-8c39-83f35b8e2ef7" -u "my@apple.id" -p "XXXXXXXXXX"
       Date: 2021-06-02 00:23:45 +0000
RequestUUID: e63220f6-6c9c-4337-8c39-83f35b8e2ef7
     Status: in progress

thomas@Thomass-Mac-mini-2 easycashmac % xcrun stapler staple EasyCT.app
Processing: /Users/thomas/Code/easycashmac/EasyCT.app
Processing: /Users/thomas/Code/easycashmac/EasyCT.app
The staple and validate action worked!

codesign sagt jetzt, dass es funktioniert hat:

Code:
thomas@Thomass-Mac-mini-2 easycashmac % codesign --verify --verbose EasyCT.app
EasyCT.app: valid on disk
EasyCT.app: satisfies its Designated Requirement

Aber Gatekeeper behauptet das Gegenteil:

Code:
thomas@Thomass-Mac-mini-2 easycashmac % spctl --assess --type open --context context:primary-signature --verbose EasyCT.zip
EasyCT.zip: rejected
source=no usable signature

Sogar nach einer Weile, nachdem der Notarisierungsprozess abgeschlossen ist, gibt spctl dieselbe Ausgabe:

Code:
thomas@Thomass-Mac-mini-2 easycashmac % xcrun altool --notarization-info "e63220f5-6c9c-4337-8c39-83f35b8e2ef7" -u "mielket@gmx.de" -p "XXXXXXXX"
No errors getting notarization info.

          Date: 2021-06-02 00:23:45 +0000
          Hash: 7177bff3aebf1e1e33b434316cfca1fc221e09b6692b7e1b66865ebe9c86b7c3
    LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma125/v4/0d/05/54/0d05544c-956a-cacd-1a17-3ac1ebd10447/developer_log.json?accessKey=1622789449_9022397155092694038_SPt6oil3xczftWtNJlfTczsZ96ClWZpAs7R3eFM3vw%2BMFUqx%2ByzzNgLmJlsuhzU8H%2BwLhOOnepRvi7H5pbtCZUep0h%2BcWD7tyFlCsPG0McWSG6HbIPM2tNdbh4Fq8%2BVXnVo9uXrLj%2FPJG%2FAygby%2B4DZBMAWBUrXa0UDrd7lDx8E%3D
   RequestUUID: e63220f6-6c9c-4337-8c39-83f35b8e2ef7
        Status: success
   Status Code: 0
Status Message: Package Approved

Der momentane Stand des Pakets kann hier heruntergeladen werden.

Ich hoffe, dass es in diesem Forum etwas mehr common sense gibt als auf StackOverflow... :)
 
Ich wusste bis jetzt noch nicht mal, dass das Zip-Format überhaupt symlinks beherrscht... Werde ich mal untersuchen. Danke für den Hinweis!
 
Danke! Aber was bedeutet das? Die developer id sieht mir korrekt aus...
Das Paket ist als "Hardenend Runtime" gekennzeichnet, läuft also in der Sandbox. Vermutlich zeigt ein Symlink auf etwas ausserhalb der Sandbox....

Es gibt ein wirklich hilfreiches Programm, um Programme zu signieren, notarisieren und (bei Bedarf) in den App Store einzustellen: AppWrapper 4 (https://www.ohanaware.com/appwrapper/). Einfach mal die Demoversion ausprobieren, da gibt es zu eigentlich allen Problemen mit dem Signieren/Notarisieren eine gute Hilfe...
 
Ich habe noch einmal versucht die ganz unveränderte Version des Pakets von Codeweavers zu benutzen, um auszuschließen, dass ich etwas vermurxt habe. Hatte ich aber nicht. Taccy gibt darau dieselbe Meldung aus. Die kaputten Symlinks habe ich mit

find . -type l ! -exec test -e {} \; -print )

herausbekommen und gelöscht -- waren nicht essenziell und werden von Crossover bei Bedarf wieder neu gesetzt:

./Contents/SharedSupport/easyct/support/easyct/drive_c/users/crossover/Templates
./Contents/SharedSupport/easyct/support/easyct/drive_c/users/crossover/Downloads

Taccy ist jetzt zwar happy, aber an "EasyCT.zip: rejected / source=no usable signature" von spctl --assess ändert es nichts.

Muss man noch irgendwelche speziellen Zertifizierungen über den Developer-Account beantragen? Ich habe jetzt nur ein ganz normales developer account und drücke dafür $99 im Jahr ab. Muss man irgendwo eine Zusatzoption buchen, so dass auch Gatekeeper mit abgedeckt ist und nicht nur der Notarisierungsprozess inklusive ist (obwohl ich eigentlich dachte, da geht es um dieselbe Sache)?
 
Muss man irgendwo eine Zusatzoption buchen, so dass auch Gatekeeper mit abgedeckt ist und nicht nur der Notarisierungsprozess inklusive ist (obwohl ich eigentlich dachte, da geht es um dieselbe Sache)?
Nein, musst du nicht.
Die Notarisierung ist für Apps außerhalb des App Stores.

aber an "EasyCT.zip: rejected / source=no usable signature" von spctl --assess ändert es nichts.
Warum checkst du das Zip?
Das hat auch keine Signatur.
 
Zuletzt bearbeitet:
Muss man noch irgendwelche speziellen Zertifizierungen über den Developer-Account beantragen? Ich habe jetzt nur ein ganz normales developer account und drücke dafür $99 im Jahr ab. Muss man irgendwo eine Zusatzoption buchen, so dass auch Gatekeeper mit abgedeckt ist und nicht nur der Notarisierungsprozess inklusive ist (obwohl ich eigentlich dachte, da geht es um dieselbe Sache)?
Nein, der normale Developer Account für 99,- im Jahr reicht völlig aus - damit stelle ich auch meine Apps in den Mac App Store bzw. verteile sie über meine Webseiten.

Wenn ich mich recht entsinne, musste der Developer Account bzw. die Notarisierung mit einer ZweiFaktor Authorisierung gesichert werden und außerdem alle Verträge abgenickt werden. Ansonsten fällt mir auf Anhieb nichts weiter ein.

Evtl. wäre es sinnvoll das Problem mal direkt mit Apple zu besprechen, als registrierter Entwickler hat man ja zwei Supportfälle im Jahr frei ;-)
 
Eine Korrektur: Ich habe das CodeWeavers-Produkt (sie haben es neuerdings in PortJump umbenannt) wohl anfangs missverstanden. Eine Veröffentlichung im App-Store ist wohl für dieses Projekt überhaupt nicht möglich -- das erstellte Paket muss schon selbst gehostet werden. Und es geht jetzt nur noch darum, den Apple-Signierungs- und Notarisierungs-Prozess zu durchlaufen, damit Gatekeeper sich nicht beschwert und eine Sicherheitsausnahmeregel erzwingt.
Willkommen an Bord!

Ich weiß nicht ob Du es auf dem Schirm hast aber notfalls hatte ich vor einiger Zeit mal eine "CrossTie" für CrossOver geschrieben. Das ist ein Skript, welches dann die .zip Datei für Windows herunterlädt und dann über CrossOver (egal ob Mac oder Linux) installiert.

Bei Codeweavers kann man auch einen Discountcode beantragen, welcher 30% auf die CrossOver Lizenz bringt und den man über die Webseite kommunizieren könnte. Ich bin sicher, dass Sie dir so etwas als Kunden auch einrichten. Insgesamt lässt sich sehr gut mit der Firma Codeweavers kommunizieren. Ich habe so auch einen Rabatt-Code bekommen und die Patches mit den Datentypen, die eingeflossen sind, sind insgesamt sehr wertvoll. Kann Dir gerne helfen, ein solches Schreiben zu formulieren. Habe einige Zeit lang in England studiert und gearbeitet.
 
Nein, musst du nicht.
Die Notarisierung ist für Apps außerhalb des App Stores.


Warum checkst du das Zip?
Das hat auch keine Signatur.
Du meinst dieses Zip hier (das Ergebnis nach den beiden Scriptdurchläufen) -- oder hast Du es aus Versehen mit diesem hier versucht, das wirklich roh und unsigniert ist? Ich bekomme ja überall Meldungen, dass es geklappt hat -- nur nicht beim spctl-Aufruf, der "no usable signature" sagt. Ich meine, es hätte eine gewisse Logik. Aber ich kann mir einfach nicht vorstellen, dass die Scripte so falsch sind...

Nein, der normale Developer Account für 99,- im Jahr reicht völlig aus - damit stelle ich auch meine Apps in den Mac App Store bzw. verteile sie über meine Webseiten.

Wenn ich mich recht entsinne, musste der Developer Account bzw. die Notarisierung mit einer ZweiFaktor Authorisierung gesichert werden und außerdem alle Verträge abgenickt werden. Ansonsten fällt mir auf Anhieb nichts weiter ein.

Evtl. wäre es sinnvoll das Problem mal direkt mit Apple zu besprechen, als registrierter Entwickler hat man ja zwei Supportfälle im Jahr frei ;-)
2FA habe ich eingerichtet. Guter Hinweis, das mit dem Support -- war mir noch nicht bewusst.
Willkommen an Bord!

Ich weiß nicht ob Du es auf dem Schirm hast aber notfalls hatte ich vor einiger Zeit mal eine "CrossTie" für CrossOver geschrieben. Das ist ein Skript, welches dann die .zip Datei für Windows herunterlädt und dann über CrossOver (egal ob Mac oder Linux) installiert.

Bei Codeweavers kann man auch einen Discountcode beantragen, welcher 30% auf die CrossOver Lizenz bringt und den man über die Webseite kommunizieren könnte. Ich bin sicher, dass Sie dir so etwas als Kunden auch einrichten. Insgesamt lässt sich sehr gut mit der Firma Codeweavers kommunizieren. Ich habe so auch einen Rabatt-Code bekommen und die Patches mit den Datentypen, die eingeflossen sind, sind insgesamt sehr wertvoll. Kann Dir gerne helfen, ein solches Schreiben zu formulieren. Habe einige Zeit lang in England studiert und gearbeitet.
Ja, habe ich auf dem Schrim. Der Vorteil am PortJump ist ja, dass man kein extra Crossover mehr braucht, sondern dass das alles im MacOS-Paket eingebaut ist. Englische Formulierungen sind auch nicht das Problem. Ich habe bei Codeweavers einfach den Eindruck, dass Hilfeanfragen bei vermeintlich einfachen Aufgaben wie Paketsignierungen und Notarisierung eher versickern. Man muss schon "echte Probleme" haben. Die werden dann auch gut gelöst. Naja, immerhin habe ich ja das Script zum Signieren geschickt bekommen...
 
So, glaube, dass ich es jetzt vernünftig im Kasten habe. Nachdem mit einem Codeweavers-Entwickler doch schließlich eine Remote-Session möglich war, stellte es sich als ein typischer Doppelfehler heraus: Der Symlink war das initiale Problem, aber weil ich nachher nur noch das zip mit spctl -a getestet habe und das auch nach dem Löschen der Symlinks nicht funktionierte, bin ich nicht weitergekommen. spctl scheint grundsätzlich ein Problem mit zips zu haben. Beim ungepackten .app-Verzeichnis war es zufrieden mit der Notarisierung. Hier mein Mac-Buildenvironment, für wen es von Interesse ist.

Dank an alle hier und besonders ThoRo!
 
spctl scheint grundsätzlich ein Problem mit zips zu haben. Beim ungepackten .app-Verzeichnis war es zufrieden mit der Notarisierung.
Ich weiß eh nicht warum du das Zip signieren willst.
So was ist doch bei Mac Apps gar nicht vorgesehen und findet man eher bei apk Dateien.
 
Ich weiß eh nicht warum du das Zip signieren willst.
So was ist doch bei Mac Apps gar nicht vorgesehen und findet man eher bei apk Dateien.
Du meinst .ipa, also iOS? .apk ist ja Android und eine ganz andere Welt. Soweit ich das überblicke gehört Softwaresignierung auch bei MacOS zum guten Ton. Ansonsten bekommt der Nutzer eine Warnung, dass das Programm aus unsicherer Quelle kommt, und muss auf wenig transparente Weise eine Sicherheitsausnahme für die Software einrichten.

Bei Paketen, die im App Store veröffentlicht werden sollen, gibt es wohl eine noch tiefergehende Prüfung. Da wird nicht nur oberflächlich nach Schadsoftware geschaut wie beim Notarisierungsprozess.
 
Soweit ich das überblicke gehört Softwaresignierung auch bei MacOS zum guten Ton.
Es wird halt als Sicherheit verkauft, aber dient womöglich auch nur zur Marktabschottung.
Bei Paketen, die im App Store veröffentlicht werden sollen, gibt es wohl eine noch tiefergehende Prüfung. Da wird nicht nur oberflächlich nach Schadsoftware geschaut wie beim Notarisierungsprozess.
Nicht wirklich, gibt einige Beispiele wo das glorreich versagt hat.
Erst die Tage gab es die Meldung einer Sodoku App, die eigentlich ein illegaler Streaming Client war.
 
  • Gefällt mir
Reaktionen: dg2rbf
Du meinst .ipa, also iOS? .apk ist ja Android und eine ganz andere Welt.
Gemeint ist sicher .pkg - das Format für Installationspakete auf dem Mac.

Soweit ich das überblicke gehört Softwaresignierung auch bei MacOS zum guten Ton.
Ja, gehört es inzwischen, spätestens seitdem in einer der letzten Betriebssystemversionen die Option "Installation aus unsicheren Quellen zulassen" aus den Sicherheitseinstellungen verschwunden ist (derzeit noch via Terminal erreichbar).

Codesigning ist inzwischen Pflicht und auch an der Notarisierung führt, wenn man für Endanwender entwickelt, kein Weg mehr vorbei. Ob das nun einen bedeutenden Sicherheitsgewinn bringt, mag ich hier jetzt nicht unbedingt diskutieren. Auf jeden Fall hat es die Softwareverteilung deutlich aufwendiger gemacht, zumindest wenn man Fehler suchen muss

Bei Paketen, die im App Store veröffentlicht werden sollen, gibt es wohl eine noch tiefergehende Prüfung.
Die Prüfung dreht sich aber eher um die verwendeten APIs (Apple wacht sehr genau darüber das keine "privaten" System APIs verwendet werden), um erweiterte Zugriffsrechte, Zugang zu den persönlichen Daten (Kontakte, Kalender etc.) des Anwenders via Entitlements und die grundlegenden Handhabung des Programms etc.

Vereinfacht gesagt: im App Store kontrolliert Apple die Einhaltung seiner Regeln, im Web wird durch Codesigning und Notarisation nur sichergestellt, das man die App notfalls blockieren kann (Entzug des Zertifikates) und das keine bekannte Malware drin steckt.
 
  • Gefällt mir
Reaktionen: dg2rbf
Zurück
Oben Unten