La notarisation des apps bientôt obligatoire pour les nouveaux développeurs inscrits
Une mesure de sécurité de macOS Mojave actuellement optionnelle pour les développeurs inscrits va bientôt être rendue obligatoire pour les nouveaux venus. « À partir de macOS 10.14.5, toutes les extensions kernel et tous les logiciels des nouveaux développeurs distribuant avec un Developer ID doivent être notariés pour pouvoir être exécutés », indique la documentation d’Apple.
La « notarisation », c’est un nouveau système de certification des applications qui vient prolonger le système du Developer ID, la carte d’identité numérique du développeur. L’Apple Notary Service vérifie la présence de composants malveillants avant de signer l’application, qui est alors considérée comme « certifiée ». Ce système permet de répondre au cas de figure où une app est corrompue à l’insu de son développeur : plutôt que le certificat du développeur, c’est l’app individuelle qui est révoquée.
« Dans une future version de macOS, la notarisation sera requise par défaut pour tous les logiciels », indique ensuite Apple. Le « par défaut » laisse entendre qu’il devrait toujours y avoir une option pour exécuter des logiciels non signés/notariés, comme actuellement (même si c’est de plus en plus caché).
Je ne connaissais pas le mot, mais effectivement rien à voir avec mon notaire ... !
@Armand07
Avec la fonction juridique du notaire, sans doute que si puisque c’est bien le notaire qui certifie la validité d’un acte ou d’un contrat.
@Finouche
Je suis notaire et n ai jamais vu ce mot !
@Grahamcoxon
Il existe pourtant !
Notarisation : Action de validation d’un document.
?
@Finouche
Mouais justement on ne valide pas des documents. On certifie des signatures à la limite. Mot étrange j irai chercher son origine
@Grahamcoxon
J’ai juste cherché rapidement sur Google. Le mot est commun semble-t-il.
@Finouche
La définition exacte est : « Enregistrement des éléments essentiels d’un contrat, d’une transaction entre deux parties qui en acceptent les mentions et les signent devant un notaire qui, lui-même par sa signature, authentifie celle des parties. »
@Zara2stra
Dans la
Profession on parle plus d’authentification. Cela sonne mieux je trouve
Sous couvert de la sécurité, Apple fait le choix de restreindre la production d'applications hors de son réseau.
Il avait déjà commencé dans ses outils de développement (Xcode) et des briques logicielles qu'il met à disposition (Cocoa).
À mon avis, il joue gros. Il va dégager les petits développeurs, ce qui faisaient toute la force d'une plate-forme de développement moderne. J'ai arrêté net le développement d'applications macOS avec Objective-C car j'ai constaté que les changements et les choix technologiques ne permettaient pas de pérenniser les développements. Combien de fois, j'ai dû intervenir sur du code à chaque mises à jour majeures de macOS ! Des changements stupides ont été éffectués dans Cocoa; il y a eu quelques échos dans la presse comme pour le PDFKit; il y en eu beaucoup d'autres.
Ne coyez pas que je suis contre le changements. Je les ai toujours salués, lors des versions de Jaguar, de Panther et particulièrement de Snow Léopard, qui à mon avis est le meilleur de tous.
Retourne dormir.
Quésaco ?
@ eric210766 : « Il avait déjà commencé dans ses outils de développement (Xcode) et des briques logicielles qu'il met à disposition (Cocoa). »
Mais encore ?
Parce que là, dans cette phrase, il n’y a rien qui nous explique ce qu’Apple aurait soi-disant fait dans Xcode et Cocoa qui viserait à « restreindre la production d'applications hors de son réseau. »
Comme je suis curieux de nature, j’aimerais bien une explication. Merci. :-)
@BeePotato
La restriction provient du fait qu'il devient nécessaire d'accéder à des informations que l'on ne retrouve que dans le circuit d'abonnement Apple. En d'autres termes, Apple complexifie ses outils de façon à rendre le developpement plus difficile sans l'aide de documentation payante. Les nouvelles versions des documentations Apple (aide en ligne) sont de plus en plus complexes sans pour autant les justifier. Je suis sorti du circuit il y deux ans.
@ eric210766 : « La restriction provient du fait qu'il devient nécessaire d'accéder à des informations que l'on ne retrouve que dans le circuit d'abonnement Apple. »
?!
Comme quoi ?
Pour ma part, je ne suis jamais tombé sur un telle situation dans le cadre du développement d’applications pour MacOS (depuis le passage à MacOS X ; avant, c’était une autre histoire).
« En d'autres termes, Apple complexifie ses outils de façon à rendre le developpement plus difficile sans l'aide de documentation payante. »
Même remarque que ci-dessus. Quelle documentation est payante ?
« Les nouvelles versions des documentations Apple (aide en ligne) sont de plus en plus complexes sans pour autant les justifier. »
Ah. Pourtant, pas mal de gens (dont moi) trouvent au contraire que les nouvelles versions sont bien trop simples. Carrément simplistes. Heureusement qu’il reste possible d’accéder aux anciens guides, encore utiles pour un moment.
@BeePotato
Comme je l'ai dit plus haut, mon histoire chez Apple s'est arrétée il y a environ deux ans.
"Comme quoi ?
Pour ma part, je ne suis jamais tombé sur un telle situation dans le cadre du développement d’applications pour MacOS (depuis le passage à MacOS X ; avant, c’était une autre histoire)."
Il faut un DevelopperID payant pour accéder à des exemples de codes, des explications. Les autres infos disponibles sur le net se sont également taries, je pense à StackOverflow ou encore CocoaControls.
« En d'autres termes, Apple complexifie ses outils de façon à rendre le developpement plus difficile sans l'aide de documentation payante. »
J'ajouterai qu'il supprime des fonctionalités originales comme les Distributed Objects ou encore les services de bas niveau du runtime de l'objective-c comme objc-msgsend.
Ils ont tellement été limités par la suppression de transfert d'informations. D'autres solutions plus intelligentes pour contrer la malveillance auraient été plus appropriées.
« Les nouvelles versions des documentations Apple (aide en ligne) sont de plus en plus complexes sans pour autant les justifier. »
Un exemple me vient à l'esprit, il concerne l'obligation de recourir à des vues (NSView et dérivée) dans les objets NSTableView. Des usines à gaz pour simplement personnaliser une colonne avec icone+texte éditable.
Je passe sur les messages ou les alertes, … inquiétants.
En ce qui concerne ta facilité à comprendre les choses, je te félicite et je t'encourage à poser ta candidature chez Apple !
A l'époque, je consultais les forums d'aide comme StackOverflow, et à chacune des mes interogations, il y avait plusieurs threads. Je ne suis donc pas le seul idiot sur la planète !
Je débaterai bien avec toi mais le temps m'est compté.
Bonne continuation.
@ eric210766 : « Comme je l'ai dit plus haut, mon histoire chez Apple s'est arrétée il y a environ deux ans. »
Oui, j’ai bien vu ça. Mais vu que ça ne t’empêche apparemment pas de continuer à en parler, je me disais que ça ne t’empêcherait pas de répondre à mes questions sur le sujet. :-)
« Il faut un DevelopperID payant pour accéder à des exemples de codes, des explications. »
Lesquels ?
J’aimerais bien un exemple, vraiment, parce que je suis surpris, n’ayant jamais été confronté à ça (ce qui paraît normal vu l’approche adoptée par Apple depuis un bon moment).
« Les autres infos disponibles sur le net se sont également taries, je pense à StackOverflow ou encore CocoaControls. »
Ça, ça n’a pas tellement de rapport.
« J'ajouterai qu'il supprime des fonctionalités originales comme les Distributed Objects ou encore les services de bas niveau du runtime de l'objective-c comme objc-msgsend. »
Euh… objc_msgsend, ça n’a pas disparu (et c’est bien normal).
Les DO, oui, c’était une technologie très élégante. Elle me manque… mais juste pour le principe. Car elle n’était pas si utilisée que ça et elle a été remplacée par d’autres systèmes de communication inter-applications, qui n’ont certes pas la même élégance mais qui fonctionnent bien (et n’ont pas les problème liés à ladite élégance, à savoir le fait de masquer qu’on fait un appel distant).
« Un exemple me vient à l'esprit, il concerne l'obligation de recourir à des vues (NSView et dérivée) dans les objets NSTableView. Des usines à gaz pour simplement personnaliser une colonne avec icone+texte éditable. »
Ben ce n’est pas plus compliqué que l’utilisation des NSCell — au contraire, même, quand on veut faire des choses compliquées.
D’autre part, l’usage des NSCell est toujours d’actualité pour les cas où on préfère cette approche (les cas simples, justement).
Enfin, tout ça n’a rien à voir avec une complexification injustifiée de la documentation. Ce sont les API qui se sont complexifiées (surtout multipliées). Pas la doc des anciennes API qui aurait été soudain retouchée et compliquée sans raison.
« Je passe sur les messages ou les alertes, … inquiétants. »
Gné ?
« En ce qui concerne ta facilité à comprendre les choses, je te félicite et je t'encourage à poser ta candidature chez Apple ! »
Je ne vois pas bien le rapport : ils ne sont pas intéressés par tous les développeurs tiers qui savent utiliser correctement les API qu’ils leur fournissent, et il existe plein de développeurs tiers qui savent (et prennent plaisie à) utiliser ces API correctement sans pour autant être intéressés par un boulot chez Apple.
« Je débaterai bien avec toi »
En fait, j’étais moins intéressé par un débat que par juste quelques exemples (pertinents).
« mais le temps m'est compté. »
N’est-ce pas notre lot à tous ? :-)
Bonne journée.
usant.
J’adore ?
Entre ça et le passage en 64 bit comment élaguer sec l'ensemble des applications tournant sur Mac...
Pas faux et surtout toutes les applis anciennes ou jeux ne seront plus installables.
C'est le monde merveilleux du online et des maj forcées plus ou moins.
Un code logiciel étant un « texte » rédigé dans un langage informatique, le mot « notarisation » me convient bien. Le passage par un tiers de confiance est systématique dès lors qu’on souhaite parvenir à un niveau de confiance élevé.
Sauf que là, le tiers de confiance s'impose petit à petit comme le seul possible.
Je sais pas pour vous, mais ma confiance repose rarement sur un seul acteur, central.
Et revoilà les Nostradamus de fêtes foraines pour nous prédire le pire sur macOS.
Toujours la même bande de bozos.
Et une fois de plus leurs prédictions se réaliseront. Ya que les aveugles pour ne pas vouloir le voir. :)
« une fois de plus » ?
Je voudrais bien savoir quand les propos inutilement alarmistes de ces imbéciles ont eu un semblant de vérité.
Jamais concernant le Mac App Store en tout cas, depuis 2011 qu’ils nous répètes à l’envie les mêmes absurdités.
Et avoir le droit de choisir le notaire de son choix, c'est pour quand ?
@byte_order
Ça change quoi ?
Avoir le choix change quoi, c'est ça votre question !?
La difference entre le service notaire d’Apple et un autre
Le notaire d'Apple ne peut authentifier que la version d'une application squi lui a été soumise et qu'elle distribue via l'AppStore.
Si Apple va trop loin dans ce sens (en ne permettant plus d'utiliser une application non "notarisee"), c'est la fin des plateformes telles que Steam et la fin de la distribution directe par les développeurs eux-même (alors qu,autoriser plusieurs tiers de confiance pour "notariser" les applications permettrait de conserver ces modes de distribution)
Cela dit, on n'en est pas encore là tant que l'utilisateur peut forcer l'utilisation d'une application même si le "notaire" de macOS ne la reconnaît pas.
@SyMich
Pourtant "le notaire" est disponible pour les apps hors appstore.
Moi je comprend que ce "notaire" va devenir obligatoire uniquement pour les apps distribuées avec un certificat developper ID. Des apps du style Transmission le client torrent.
@ SyMich : « Le notaire d'Apple ne peut authentifier que la version d'une application squi lui a été soumise et qu'elle distribue via l’AppStore. »
« […] la fin de la distribution directe par les développeurs eux-même »
La notarisation, c’est justement pour les applications distribuées hors AppStore, directement par les développeurs.
@ SyMich
Est-ce que ça va aussi permettre la fin des plateformes gratuites peu scrupuleuses (genre 01.net et Clubic) bien connues pour distribuer des logiciels obsolètes et vérolés dans lesquels sont ajoutés volontairement des adwares et autres malwares ?
Si c'est le cas, c'est peut-être une bonne chose car quand on recherche un logiciel à télécharger (quel que soit le moteur de recherche) ce sont surtout 01.net et Clubic qui arrivent en tête, avec tous les dangers que ça implique pour les utilisateurs grand-public non-informaticiens... et peu méfiants !
1) avoir le choix en qui on fait confiance
2) ne pas dépendre d'un tiers incontournable (ou en voie de le devenir)
@byte_order
Là c’est comme si tu disais seul Apple peut distribuer des mises à jour pour ses OS, et qu’il y a besoin de concurrence..
@reborn
On parle pas d'OS à distribuer ici, mais d'apps développées par des tiers.
@byte_order
Qui d’autre qu’Apple pourrait offrir ce service d’authentification ?
@reborn
Qui d'autre que le constructeur de votre véhicule pourrait offrir ce service de contrôle technique ?
Oh, wait.
@byte_order
Rien à voir...
Et rien n’empêche Norton ou mcafee d’offrir un service d’authentification des apps
@reborn
> Rien à voir...
Et pourtant, c'est l'idée qui se cache derrière ce concept.
La pub "Qui d'autre que Renault peut entretenir votre Renault ?" essaye d'inscrire la même idée dans le consommateur, mais fort heureusement cela s'arrête là, juste un slogan marketing. Le consommateur conserve le droit de faire certifier que son véhicule est conforme aux normes de sécurité auprès de qui il veut, et y'a concurrence. Pire, pour éviter les conflits d'intérêts évidents, les garagistes, (et donc les constructeurs) *ne* peuvent *plus* être agréé à faire du CT.
Alors qu'ici, c'est pas du marketing, c'est bel et bien un verrou, bien réel.
Le constructeur est celui qui contrôle.
Cela a, en effet, rien à voir : on est *déjà* dans une situation bien au delà de ce que les constructeurs automobiles n'ont *jamais* obtenu, mais alors que cela choquerais pour un constructeur de voiture, ici cela n'a choqué personne pour un constructeur de terminal informatique...
> Et rien n’empêche Norton ou mcafee d’offrir un service d’authentification des apps
Dès lors que macOS ne sait gérer *que* les mécanismes propriétaires d'Apple pour vérifier l'authenticité et la conformité d'une application avant de l'installer ou de la lancer, et ne propose aucun moyen à un mécanisme tiers pour le faire, *si si*, tout l'empêche.
@byte_order
Tu reproche à Apple le fait qu’étant propriétaire de l’OS ils sont les seuls à fournir ce certificat non obligatoire pour l’exécution d’une application.
C’est comme si tu leur reproche d’être les seuls à pouvoir fournir des mises à jour de sécurités pour leur propres OS et que personne d’autres ne peut le faire.
@reborn
> Tu reproche à Apple le fait qu’étant propriétaire de l’OS
De l'OS, mais pas de sa licence d'utilisation, qui inclut la fonctionnalité fondamentale de pouvoir installer des applications tierces et de les exécuter. Cette licence d'utilisation, Apple la vend en même temps que le Mac, pour rappel.
Le fait que Apple soit propriétaire de l'OS ne lui donne pas le droit de s'intercaler entre vous et votre licence d'utilisation de l'OS. D'autant que celle-ci, contrairement à iOS, n'inclut pas depuis le début de limite sur le droit à lancer des applications tierces de manière non opposable par Apple.
> ils sont les seuls à fournir ce certificat non obligatoire pour l’exécution d’une application.
Non obligatoire *maintenant*, mais qui le sera *par défaut* rapidement et, comme pour les apps non signées, deviendra quasi-obligatoire quand Apple aura viré l'option pour désactiver ce contrôle par défaut et fait tout son travail de marketing pour convaincre les utilisateurs trop curieux que c'est vraiment mieux ainsi, cherchez pas, faites nous confiance (et ne faite confiance qu'au MacAppStore, hein).
Mais, oui, je vois pas pourquoi Apple serait plus légitime que quiconque pour certifier qu'une application est bien celle qu'elle prétend être et qu'elle ne cache pas des trucs.
Attention, je ne suis pas contre la certification, bien au contraire, mais je n'approuve pas qu'un acteur unique se rende incontournable sur l'usage d'une certification. Cela lui donne un pouvoir bien trop grand, sans contrôle extérieur.
Regardez déjà comment Apple se sert de l'annulation de la signature de certaines versions de macOS pour rendre difficile le retour en arrière de version d'OS. Elle le fait parce que cela sert ses intérêts à elle, en se contrefoutant de la volonté du propriétaire de l'ordinateur *et* de la licence d'utilisation de l'OS vendue avec.
@byte_order
Je confirme que tu ne comprend pas ce système qui n’est qu’une prolongation des apps bénéficiant d’un certificat developper ID.
Renseigne toi sur le sujet
Les reglages par défaut de maOS désormais imposent :
- soit que l'app provienne du MacAppStore d'Apple (et uniquement ce store)
- soit que l'app soit signée par un certificat de DeveloperID valide, que Apple (et uniquement elle) contrôle unilatéralement.
Pour un utilisateur lambda qui ne connait pas les arcanes techniques (c'est un peu le coeur de cible d'Apple, en plus), cela s'arrête là.
Il lui faudra être plus curieux que la moyenne pour découvrir qu'il existe et comment accéder à la troisième possibilité, cachée derrière un combo magique au lancement et/ou une commande Terminal pour se voir offrir la possibilité de désactiver la vérification par Apple si cela lui chante.
La notarisation ajoute un certificat par application en plus du certificat DeveloperID, qui sera évidement lui aussi sous le contrôle opaque et unilateral d'un seul acteur, par ailleurs juge et parti puisqu'il est également éditeur d'applications macOS lui aussi, et donc potentiellement un concurrent.
Et ce nouveau duo de certificats sera requis par défaut très prochainement. Et encore, on ignore pendant combien de temps ce comportement par défaut sera éventuellement contournable si besoin est, mais le fait est que pour un utilisateur lambda - et donc pour la clientèle potentielle d'un éditeur, même pour distribuer une app macOS, Apple s'intercale désormais très fortement entre l'éditeur et le propriétaire de la licence d'utilisation de macOS.
Faut être aveugle pour ne pas voir que derrière l'argument sécuritaire - valable *mais* qui n'a jamais requis un acteur unique en position central, comme le démontre l'usage des certificats dans les multiples dépôts de packages du monde Linux et autres BSD, pourtant souvent au coeur des services d'Internet et donc critiques - c'est surtout pousser fortement les éditeurs à enfin adopter le MAS en jouant sur le sentiment d'insécurité des utilisateurs face aux apps qui ne sont pas sur le MAS.
Avec l'arrivée de Marzipan, l'enjeu financier d'imposer *son* store sur macOS est assez évident.
@byte_order
T’en fais des tonnes pour rien. La notarisation est un processus automatique qui ne prend que quelques minutes pour être effectué. Ce n’est pas un processus de validation à la Appstore.
Qui valide les extensions de kernel sous macOS ? Apple
Qui valide les pilotes sous windows ? Microsoft
Tu veux exécuter une app non signé ? Eh bien tu désactive Gatekeeper pour cette app, macOS t’explique la marche à suivre en allant dans réglage>sécurité pour ensuite cliquer sur l’app à exécuter. On ne parle pas de désactiver SIP donc pas besoin de Terminal
Tu nous la joue à la c1rc3c là..
@reborn
> La notarisation est un processus automatique qui ne prend que quelques minutes
> pour être effectué. Ce n’est pas un processus de validation à la Appstore.
Où ai-je dis le contraire ?
> Qui valide les extensions de kernel sous macOS ? Apple
Par définition, cela touche aux parties critiques de l'OS, une extension.
C'est pas le cas du code d'une application.
Et où ai-je dis que ce contrôle supplémentaire me gênait pour les kexts ?!
Depuis le début je parle d'applications tierces, moi.
> On ne parle pas de désactiver SIP donc pas besoin de Terminal
Où ai-je dis que c'était obligatoire ?
J'ai dit "soit combo magique et/ou commande terminal.".
Encore une fois, c'est pas le contrôle qui me gène, c'est qui a ce contrôle, et le pouvoir que cela lui donne. Un seul acteur central qui a le contrôle final ou dans la grande majorité des cas, ce que l'utilisateur lambda acceptera de facto, c'est la porte ouverte aux abus qu'on constate déjà dans l'écosystème iOS. D'autant que l'acteur en question est à la fois juge et partie.
Quand on voit les libertés avec les règles de validation des apps qu'Apple s'autorise avec son app Apple News iOS alors qu'elle rejette n'importe quelle app qui aurait le culot de citer simplement une autre plateforme mobile que les siennes, je ne trouve pas sain de faire croire que le contrôle implique de le céder à un acteur unique, qui y trouve en plus un intérêt concurrenciel.
La sécurité centralisée, c'est surtout de la centralisation avant d'être de la sécurité...
> Tu veux exécuter une app non signé ?
Non. Moi je sais le faire, et surtout je sais ne pas prendre peur quand Apple m'envoie une alerte avant de pouvoir le faire.
Mais l'utilisateur lambda, lui, il fait confiance à Apple, et Apple en profite pour renforcer sa mise sous tutelle, ce qui met au passage les éditeurs (via le certificat DeveloperID) sous son contrôle arbitraire mais désormais également chaque production de ces éditeurs (via le certificat par application, nouveau), lui aussi sous le contrôle arbitraire d'Apple.
Qui se trouve être juge et partie, puisque Apple est également éditeur d'applications pour macOS, elle aussi.
@byte_order
Tu n’as pas compris ce qu’est ce service de notaire
@byte_order
Mais on peut choisir son notaire. Enfin avec la loi Macron je ne sais pas pour combien de temps ...
En tout cas cela préfigure tout simplement du rapprochement vers iOS où il est également impossible d installer des applications sans validation par Apple. Logique puisque les applications vont être communes
@Grahamcoxon
Logique qu'un vendeur obtienne le contrôle final sur les applications installables par un propriétaire d'un ordinateur !?
Un terminal loué, oui.
Vendu, déjà nettement moins.
Mais un ordinateur personnel, clairement, non.
Soit c'est vraiment personnel, soit c'est une mise sous tutelle.
Pages