1) Ca m'intéresserait de savoir pourquoi MPlayerX a besoin d'autant de privilèges pour exécuter ses actions. S'il a été refusé du MAS parce que son appli nécessite trop de privilèges, pour moi c'est limite une bonne chose, une appli qui a plus de privilèges que nécessaire, c'est la porte ouverte pour qu'elle fasse des choses sans mon accord. S'il a besoin de privilèges particuliers pour certaines de ses actions spécifiques (droit d'admin pour installer une nouvelle version automatiquement par exemple), il y a tout ce qu'il faut d'expliqué dans la doc Apple pour faire un process dédié et communiquer avec lui via XPC. Manifestement, ils n'ont pas pris cette voie dans MplayerX.
Bon à moins que ce soit un cas particulier genre utilisation d'un framework privé pour la vidéo qu'Apple n'a pas ouverte alors qu'il n'y a pas de raison de le garder privé, mais là ce ne serait pas une question de privilèges.
Bref, cela ne me choque pas du tout. Pour moi c'est pas logique qu'une appli ait plus de privilèges que nécessaires, c'est la porte ouverte à n'importe quoi.
2) Ca n'empêchera pas MplayerX d'exister, et de tourner sous Mountain Lion & co, s'ils continuent de signer l'application avec leur DeveloperID (et je ne vois pas pourquoi ils ne le feraient pas). Ils distribueront l'appli par leur site web à la place, mais ça restera compatible avec GateKeeper.
Je ne sais pas exactement à quelles ressources il s'intéressait, mais :
MPlayerX will lose so many features if it adopted Sandboxing, it could not load the subtitle automatically, it could not play the next episode for you automatically, it could not save the snapshots to the place where you want to, etc. Without those features, MPlayerX were just another lame Quicktime X, which I could not accept.
J'ignore si c'est réaliste. Mon fils (qui développe sur PC) m'affirme que la sandbox n'est utile que si le programmeur est honnête. Si le développeur est un hackeur, sont seul problème sera de passer l'examen chez Apple, après plusieurs lancements l'application pourra faire n'importe quoi du genre fabriquer ou dupliquer des processus invisibles .... etc
la sandbox n'est utile que si le programmeur est honnête.
Ca tombe bien, elle n'a pas été conçu pour protéger l'utilisateur contre le développeur malhonnête. C'est la signature numérique qui protège l'utilisateur contre le développeur malhonnête, car sa signature numérique l'identifie clairement.
La sandbox et le confinement des process par limitation des privilèges ont été conçus pour protéger l'utilisateur contre les attaques extérieures et les défaillances logicielles involontaires (les bugs quoi) qui pourraient mettre en péril ses données personnelles (Autant en terme de corruption, de destruction que de vol de ces données).
C'est la signature numérique qui protège l'utilisateur contre le développeur malhonnête, car sa signature numérique l'identifie clairement.
Donc, tout ceux qui ont une signature numérique sont honnêtes et les signatures numériques ne sont pas copiables ou piratables. Là j'ai de forts doutes.
Bon j'agite un peu des idées, juste pour faire réagir!
Les signatures numériques sont à priori de bonnes assurances de l'identité de l'utilisateur. Pour voler une signature numérique, il faut voler la clé privée de l'utilisateur, chose que justement tu ne partages jamais.
C'est un peu comme si avant les portes de maison n'avaient pas de serrure, et que maintenant on en mettais une, tu dirais "ouais mais qui te dit que qqun ne va pas te voler ta clé ?" déjà tu laisses pas ta clé traà®ner à la portée de tout le monde, et en plus c'est quand même mieux que de laisser ta porte ouverte.
Donc dans l'absolu je dirais que non, les signatures numériques "ne sont pas piratables". Bien sûr qu'en réalité elles le sont, rien n'est à l'abri du piratage, mais bon soit il faut un vol caractérisé (personne qui récupère ta clé privée que tu gardes normalement uniquement chez toi sur ton mac et que tu mets pas sur le net ou quoi), soit il faut que le pirate ait un ordi suffisamment puissant (genre Cray) et suffisamment de temps (plusieurs jours/mois de processing ?) pour casser ta propre clé privée.
Je ne sais pas quelles sont la longueur des clés privées utilisées pour faire du CodeSigning avec un Developer ID Apple, mais je suppose qu'ils en sont à utiliser des clés (asymétriques) RSA de 2048 bits, donc y'a vraiment de la marge. En plus j'ai remarqué que depuis Mountain Lion, quand on générait une bi-clé genre RSA 2048 bits (je l'ai fait l'autre jour), maintenant l'algo de chiffrement de la clé était du SHA-256 et non plus du SHA-1...
les signatures numériques ne sont pas copiables ou piratables.
Clairement pas si le possesseur de la signature (enfin plutôt de la clé privée) est sensibilisé au fait que cette clé ne doit être divulguée à personne (voir détails du fonctionnement de l'algorithme RSA).
D'ailleurs cette clé privée ne quitte jamais le poste de l'utilisateur. Elle n'est jamais transmise à Apple, même pour la génération du certificat (c'est la clé publique qui est transmise), et mathématiquement il quasiment impossible de retrouver la clé privée à partir de la clé publique si cette clé fait plus de 768 bits: Il faut donc essayer de la deviner par essais successifs (brute force), ce qui, pour les machines accessibles au commun des mortels, prend actuellement plusieurs centaines/milliers d'années.
De même, il est impossible de créer un faux certificat, puisqu'il faut qu'il soit signé par la clé privée d'Apple, clé évidemment gardée bien au chaud. Par contre, évidemment, si Apple se fait voler sa clé privée, tout devient possible...
Bon ben je viens rajouter un pavé dans la marre. Certes ça n'est pas lié à la sécurité qu'apporte le Sandboxing, mais c'est suite à la discussion du retrait de MPlayerX.
Mon application (Ecoute) ne peut pas voir sa mise à jour disponible sur le Mac App Store pour la raison suivante:
We've determined that one or more temporary entitlement exceptions requested for this app are not appropriate and will not be granted:
Pourquoi j'avais besoin de cette autorisation ? Tout simplement pour les mêmes raisons que MPlayerX, sauf que sur le coup ça fait partie de l'essentiel du fonctionnement de mon lecteur musical.. Bah oui, tout le monde n'a pas sa musique située dans ~/Music/ !
D'où la raison de cette exception sur / directement.
Après un appeal, toujours pareil. Je dois trouver une autre solution. Que me propose Apple? Utilise une boà®te de dialogue pour ouvrir les fichiers.
Sachant que mon application va lire la library iTunes pour récupérer les infos des morceaux, comment diable puis-je envisager de demander, en plus, à l'utilisateur de sélectionner à la main sa musique /huh.gif' class='bbc_emoticon' alt='???' />
Je ne suis vraiment pas contre le sandboxing, mais sur OS X on manque clairement d'API sur certains niveaux. Dans ce cas précis, il manque une API iTunes, comme il y a une API MediaPlayer sur iOS qui permet, entre autre, d'accéder à la musique de l'iPod.
Aussi, l'autre solution aurait été de pouvoir utiliser des expressions régulières dans les entitlements, ce qui m'aurait permis de cibler tous les volumes du système, mais uniquement certaines extensions (MP3, M4A, ..)
Bref, Apple m'a foutu un gros coup de blues sur le coup. Déjà qu'elle m'en a fait baver pour la version iOS... (3 mois pour valider)
@devulder: Le sandboxing n'était pas obligatoire quand l'application fut publiée. Les applis existantes continuent de fonctionner comme avant. Le sandboxing est exigée pour les nouvelles publications.
@devulder: Le sandboxing n'était pas obligatoire quand l'application fut publiée. Les applis existantes continuent de fonctionner comme avant. Le sandboxing est exigée pour les nouvelles publications.
Merci de cette précision, hum hum vraiment spéciale leur politique chez apple ! /smile.png' class='bbc_emoticon' alt=':)' />
Bah le pire c'est surtout que la version actuelle de Ecoute sur le store UTILISE le sandboxing !! Avec la même "exception" (comme ils appellent) sur / directement. Juste qu'apparemment depuis le 1er Juin les règles concernant le sandboxing ont changé. Super hein ? En gros je vais me faire voir et tant pis pour les utilisateurs qui n'auront pas le droit à des mises à jour.
Apple commence sérieusement à me décevoir. Entre leurs procès à tout va et très souvent discutables, et leur politique en matière de validation sur l'App Store qui a l'air de durcir de jour en jour..
Jusqu'à présent, en absence de solution, ils accordaient des dérogations. Maintenant, il n'y a toujours pas de solution, mais ils n'accordent plus de dérogation non plus.
Si je comprends bien, ce serait donc à l'utilisateur de trouver le fichier iTunes Library ? Est-ce que ça te paraà®t insurmontable pour tes clients ? Il me semble qu'iTunes ne procédait pas autrement quand on faisait certaines mises-à -jour.
Jusqu'à présent, en absence de solution, ils accordaient des dérogations. Maintenant, il n'y a toujours pas de solution, mais ils n'accordent plus de dérogation non plus.
Si je comprends bien, ce serait donc à l'utilisateur de trouver le fichier iTunes Library ? Est-ce que ça te paraà®t insurmontable pour tes clients ? Il me semble qu'iTunes ne procédait pas autrement quand on faisait certaines mises-à -jour.
Non non, le fichier iTunes y'a déjà une boite de dialogue qui s'ouvre si il n'est pas à l'emplacement par défaut (~/Music/iTunes/).
Le problème c'est TOUTE la musique répertoriée dans ce bête XML.. En gros c'est une array de dictionnaire, qui contient diverses infos (moins lourd à traiter que de lire les tags ID3 du coup), dont le chemin de chaque fichier audio. C'est là que ça pêche.. Il faudrait demander à l'utilisateur d'ouvrir 1 à 1 les fichiers audio oO Ou alors de le faire sélectionner LE dossier qui contiendrait toutes les musiques. Mais encore une fois, certains utilisateurs ont leur musique éparpillée un peu partout, c'est bcp trop complexe. Je sais même pas si le sandboxing autorise l'ouverture d'un dossier (comme NSOpenPanel le gère, je suppose que oui.. mais garde-t-on l'autorisation de lecture/ecriture à "vie" ?)
Bref, fait chier, bordel de merde.
Faut que je me rencarde sur cette histoire de dossier à ouvrir.. si ça donne l'autorisation tant que l'application est ouverte c'est mort. Si l'autorisation granted à "vie" je pourrai à la limite parcourir le XML et chercher les dossiers racines et ainsi les proposer en default path dans chaque NSOpenPanel.
C'est IGNOBLE, mais si y'a pas le choix... tant pis.
Pour l'ouverture de fichier c'est effectivement la merde lorsque tu as des ressources liés. Et vu le fonctionnement de l'API tu ne va pas t'en sortir sauf si tu peux faire l'ouverture d'un dossier complet.
Bah je peux ouvrir le dossier, mais je suis autorisé le lire que pendant la durée de vie du process.. Si faut sélectionner le dossier à chaque lancement c'est pas la peine..
Bah je peux ouvrir le dossier, mais je suis autorisé le lire que pendant la durée de vie du process.. Si faut sélectionner le dossier à chaque lancement c'est pas la peine..
Normalement il y a un système dans l'API qui permet de se souvenir des ouvertures précédentes (pour la fonction fichier récent). Check bien l'API à ce niveau, voir si tu n'aurais pas un token à enregistrer ou un truc du genre.
C'est bon ça marche. C'est vachement laid comme façon de faire mais bon.. J'espère sincèrement qu'Apple fera un effort. Je suis sûr que l'idée d'exceptions sur des extensions reste sécurisé.. surtout en read-only.
C'est bon ça marche. C'est vachement laid comme façon de faire mais bon.. J'espère sincèrement qu'Apple fera un effort. Je suis sûr que l'idée d'exceptions sur des extensions reste sécurisé.. surtout en read-only.
Quand l'exception porte sur /, non c'est pas sécurisé, même en read only tu peux voler des données.
Par contre il faudrait qu'ils mettent en place un système permettant d'indiquer au système les ressources associés à l'ouverture d'un fichier de référence qui ne se trouve pas dans un bundle.
Ton problème va se retrouver pour toute application qui interprète du XML, on ne peut pas publier en l'état de navigateur Internet qui supportent l'ouverture de fichier locaux, ni même d'éditeur HTML...
Jusqu'à présent, en absence de solution, ils accordaient des dérogations. Maintenant, il n'y a toujours pas de solution, mais ils n'accordent plus de dérogation non plus.
Loll /smile.png' class='bbc_emoticon' alt=':)' /> Je ne devrais pas en rire. Mais c'est tellement absurde comme situation. /smile.png' class='bbc_emoticon' alt=':)' /> Pas facile de travailler avec Apple...
À mon avis le serrage de vis ne fait que commencer /sad.png' class='bbc_emoticon' alt=':(' />
Réponses
1) Ca m'intéresserait de savoir pourquoi MPlayerX a besoin d'autant de privilèges pour exécuter ses actions. S'il a été refusé du MAS parce que son appli nécessite trop de privilèges, pour moi c'est limite une bonne chose, une appli qui a plus de privilèges que nécessaire, c'est la porte ouverte pour qu'elle fasse des choses sans mon accord. S'il a besoin de privilèges particuliers pour certaines de ses actions spécifiques (droit d'admin pour installer une nouvelle version automatiquement par exemple), il y a tout ce qu'il faut d'expliqué dans la doc Apple pour faire un process dédié et communiquer avec lui via XPC. Manifestement, ils n'ont pas pris cette voie dans MplayerX.
Bon à moins que ce soit un cas particulier genre utilisation d'un framework privé pour la vidéo qu'Apple n'a pas ouverte alors qu'il n'y a pas de raison de le garder privé, mais là ce ne serait pas une question de privilèges.
Bref, cela ne me choque pas du tout. Pour moi c'est pas logique qu'une appli ait plus de privilèges que nécessaires, c'est la porte ouverte à n'importe quoi.
2) Ca n'empêchera pas MplayerX d'exister, et de tourner sous Mountain Lion & co, s'ils continuent de signer l'application avec leur DeveloperID (et je ne vois pas pourquoi ils ne le feraient pas). Ils distribueront l'appli par leur site web à la place, mais ça restera compatible avec GateKeeper.
Source
Ca tombe bien, elle n'a pas été conçu pour protéger l'utilisateur contre le développeur malhonnête. C'est la signature numérique qui protège l'utilisateur contre le développeur malhonnête, car sa signature numérique l'identifie clairement.
La sandbox et le confinement des process par limitation des privilèges ont été conçus pour protéger l'utilisateur contre les attaques extérieures et les défaillances logicielles involontaires (les bugs quoi) qui pourraient mettre en péril ses données personnelles (Autant en terme de corruption, de destruction que de vol de ces données).
Bon j'agite un peu des idées, juste pour faire réagir!
C'est un peu comme si avant les portes de maison n'avaient pas de serrure, et que maintenant on en mettais une, tu dirais "ouais mais qui te dit que qqun ne va pas te voler ta clé ?" déjà tu laisses pas ta clé traà®ner à la portée de tout le monde, et en plus c'est quand même mieux que de laisser ta porte ouverte.
Donc dans l'absolu je dirais que non, les signatures numériques "ne sont pas piratables". Bien sûr qu'en réalité elles le sont, rien n'est à l'abri du piratage, mais bon soit il faut un vol caractérisé (personne qui récupère ta clé privée que tu gardes normalement uniquement chez toi sur ton mac et que tu mets pas sur le net ou quoi), soit il faut que le pirate ait un ordi suffisamment puissant (genre Cray) et suffisamment de temps (plusieurs jours/mois de processing ?) pour casser ta propre clé privée.
Je ne sais pas quelles sont la longueur des clés privées utilisées pour faire du CodeSigning avec un Developer ID Apple, mais je suppose qu'ils en sont à utiliser des clés (asymétriques) RSA de 2048 bits, donc y'a vraiment de la marge. En plus j'ai remarqué que depuis Mountain Lion, quand on générait une bi-clé genre RSA 2048 bits (je l'ai fait l'autre jour), maintenant l'algo de chiffrement de la clé était du SHA-256 et non plus du SHA-1...
Heureusement qu'on a inventé les paillassons et les pots de fleurs, pour planquer les clés en toute discrétion..
Clairement pas si le possesseur de la signature (enfin plutôt de la clé privée) est sensibilisé au fait que cette clé ne doit être divulguée à personne (voir détails du fonctionnement de l'algorithme RSA).
D'ailleurs cette clé privée ne quitte jamais le poste de l'utilisateur. Elle n'est jamais transmise à Apple, même pour la génération du certificat (c'est la clé publique qui est transmise), et mathématiquement il quasiment impossible de retrouver la clé privée à partir de la clé publique si cette clé fait plus de 768 bits: Il faut donc essayer de la deviner par essais successifs (brute force), ce qui, pour les machines accessibles au commun des mortels, prend actuellement plusieurs centaines/milliers d'années.
De même, il est impossible de créer un faux certificat, puisqu'il faut qu'il soit signé par la clé privée d'Apple, clé évidemment gardée bien au chaud. Par contre, évidemment, si Apple se fait voler sa clé privée, tout devient possible...
Mon application (Ecoute) ne peut pas voir sa mise à jour disponible sur le Mac App Store pour la raison suivante:
Pourquoi j'avais besoin de cette autorisation ? Tout simplement pour les mêmes raisons que MPlayerX, sauf que sur le coup ça fait partie de l'essentiel du fonctionnement de mon lecteur musical.. Bah oui, tout le monde n'a pas sa musique située dans ~/Music/ !
D'où la raison de cette exception sur / directement.
Après un appeal, toujours pareil. Je dois trouver une autre solution. Que me propose Apple? Utilise une boà®te de dialogue pour ouvrir les fichiers.
Sachant que mon application va lire la library iTunes pour récupérer les infos des morceaux, comment diable puis-je envisager de demander, en plus, à l'utilisateur de sélectionner à la main sa musique
Je ne suis vraiment pas contre le sandboxing, mais sur OS X on manque clairement d'API sur certains niveaux. Dans ce cas précis, il manque une API iTunes, comme il y a une API MediaPlayer sur iOS qui permet, entre autre, d'accéder à la musique de l'iPod.
Aussi, l'autre solution aurait été de pouvoir utiliser des expressions régulières dans les entitlements, ce qui m'aurait permis de cibler tous les volumes du système, mais uniquement certaines extensions (MP3, M4A, ..)
Bref, Apple m'a foutu un gros coup de blues sur le coup. Déjà qu'elle m'en a fait baver pour la version iOS... (3 mois pour valider)
Sur le mac store tu as l'application gratuite IMedia Browser http://itunes.apple.com/fr/app/imedia-browser/id404126466?mt=12#
L'application trouve mes mp3 qui sont sur des disques externes
les sources sont sur GitHub https://github.com/karelia/iMedia
A voir ?
Merci de cette précision, hum hum vraiment spéciale leur politique chez apple !
Apple commence sérieusement à me décevoir. Entre leurs procès à tout va et très souvent discutables, et leur politique en matière de validation sur l'App Store qui a l'air de durcir de jour en jour..
Si je comprends bien, ce serait donc à l'utilisateur de trouver le fichier iTunes Library ? Est-ce que ça te paraà®t insurmontable pour tes clients ? Il me semble qu'iTunes ne procédait pas autrement quand on faisait certaines mises-à -jour.
Non non, le fichier iTunes y'a déjà une boite de dialogue qui s'ouvre si il n'est pas à l'emplacement par défaut (~/Music/iTunes/).
Le problème c'est TOUTE la musique répertoriée dans ce bête XML.. En gros c'est une array de dictionnaire, qui contient diverses infos (moins lourd à traiter que de lire les tags ID3 du coup), dont le chemin de chaque fichier audio. C'est là que ça pêche.. Il faudrait demander à l'utilisateur d'ouvrir 1 à 1 les fichiers audio oO Ou alors de le faire sélectionner LE dossier qui contiendrait toutes les musiques. Mais encore une fois, certains utilisateurs ont leur musique éparpillée un peu partout, c'est bcp trop complexe. Je sais même pas si le sandboxing autorise l'ouverture d'un dossier (comme NSOpenPanel le gère, je suppose que oui.. mais garde-t-on l'autorisation de lecture/ecriture à "vie" ?)
Bref, fait chier, bordel de merde.
Faut que je me rencarde sur cette histoire de dossier à ouvrir.. si ça donne l'autorisation tant que l'application est ouverte c'est mort. Si l'autorisation granted à "vie" je pourrai à la limite parcourir le XML et chercher les dossiers racines et ainsi les proposer en default path dans chaque NSOpenPanel.
C'est IGNOBLE, mais si y'a pas le choix... tant pis.
J'ai loupé un truc ou c'est vraiment ignoble le sandboxing?
Normalement il y a un système dans l'API qui permet de se souvenir des ouvertures précédentes (pour la fonction fichier récent). Check bien l'API à ce niveau, voir si tu n'aurais pas un token à enregistrer ou un truc du genre.
Quand l'exception porte sur /, non c'est pas sécurisé, même en read only tu peux voler des données.
Par contre il faudrait qu'ils mettent en place un système permettant d'indiquer au système les ressources associés à l'ouverture d'un fichier de référence qui ne se trouve pas dans un bundle.
Ton problème va se retrouver pour toute application qui interprète du XML, on ne peut pas publier en l'état de navigateur Internet qui supportent l'ouverture de fichier locaux, ni même d'éditeur HTML...
Loll
À mon avis le serrage de vis ne fait que commencer
En tout cas, ils ne distribuerons plus Ecoute !
La version 3 devient gratuite http://www.macg.co/n...devient-gratuit
Est-ce que les programmes gratuits et distribués hors App Store continueront à être exécutable sous 10.9, 10.x?
Faudra-t-il être inscrit obligatoirement au "programme développeur" pour continuer à faire ce genre de programme?
Pour l'instant, moi qui suis un "Gratuit" depuis 2003, je n'ai même pas pu obtenir une signature pour gatekeeper.