Apple a modifié les règles du jeu pour la distribution de logiciels sur Mac. Avec macOS Sierra, il ne reste plus que deux canaux autorisés par défaut : le Mac App Store et les applications signées avec un certificat Apple. Jusque-là , on pouvait désactiver totalement Gatekeeper et ouvrir n'importe quelle application sans sécurité. Mais l'option " N'importe où " a été retirée des Préférences Système avec macOS 10.12.
Je ne crois pas que ça change grand chose en pratique, parce qu'il n'était pas sage de permettre à n'importe quelle appli de s'installer.
Je constate que même de grosses boites ne signent pas leurs applications (ex.: Deezer) et pour moi, c'est là que se situe le problème. Même dans notre toute petite structure, nous les signons, et ça n'a rien de compliqué. ça évite de de devoir expliquer aux utilisateurs qu'il faut faire un clic droit sur l'icône de l'appli, etc.
La prochaine étape sera de n'autoriser que les applications qui viennent de l'AppStore !
Non ça m'étonnerai beaucoup. Apple est consciente des limitations du Mac AppStore, en teÌmoigne les annonces relatives à l'ouverture d'iCloud et consorts aux applications hors AppStore (mais signées).
De plus la signature d'une app ça n'a rien de vraiment choquant. L'informatique ayant évolué aussi bien dans le bon sens que dans le mauvais il n'est pas si saugrenu de vouloir savoir d'ouÌ€ vient un truc qu'on exeÌcute sur sa machine. Si on a pas les sources bien entendu. Maintenant j'aurai plus tendance à faire confiance à une app signée qui peut être deÌsactiveÌe qu'aÌ€ un code open source que je n'aurai pas le temps d'analyser et compilerait les yeux fermeÌs...
Je pense (j'espère) que la prochaine modification des comptes développeurs va permettre de signer des apps avec un compte gratis et reÌserver les AppStores aux comptes payants. C'est raccord avec les limitations de Sierra et l'ouverture de Swift-pour-tout-le-monde-coder-c'est-facile-et-trop-cool !
Je pense (j'espère) que la prochaine modification des comptes développeurs va permettre de signer des apps avec un compte gratis et reÌserver les AppStores aux comptes payants. C'est raccord avec les limitations de Sierra et l'ouverture de Swift-pour-tout-le-monde-coder-c'est-facile-et-trop-cool !
Le fait de devoir payer impose une certaine traçabilité de la personne derrière le compte. Si n'importe qui peut signer n'importe quoi en se créant un compte bidon cela perd du sens non?
Fut un temps où je devais déployer des apps sur des centaines de machines distantes par scripting et ssh. J'ose pas imaginer le merdier de devoir valider tous les premiers lancements d'apps sur de Mac en mode kiosque.
Le fait de devoir payer impose une certaine traçabilité de la personne derrière le compte. Si n'importe qui peut signer n'importe quoi en se créant un compte bidon cela perd du sens non?
Oui et non. .. Ce n'est pas difficile pour un malveillant organisé d'avoir une carte de crédit non traçable (vol d'identité, carte au nom d'un trust dans un paradis fiscal, etc). Et de créer un compte développeur payant avec cette carte.
En 20 ans je n'ai jamais été développeur "payant". Je ne programme que pour mon plaisir et je mets à disposition gratuitement sur un site une partie de ce que je fais. je ne gagne pas un sou avec ça. C'est entendu, ce n'est pas transcendant ! Mais payer plein pot juste pour pouvoir se torturer les neurones et exercer ses facultés de réflexion, ça ne me parait pas intéressant du tout.
App Transport Security. En gros, l'obligation d'utiliser https au lieu de http.
Déjà fait pour mon propre serveur.
Mais si on pointe des liens vers des services externes ou autre ressources en http dont on n'a pas le contrôle ? (je ne pense pas que ce soit mon cas cependant)
Une petite chose : si on s'intègre à la recherche spotlight (apparue dans iOS 9), dans iOS 10, on peut également utiliser l'index spotlight dans sa propre app.
The new CSSearchQuery class supports in-app searches of content that you index using existing Core Spotlight APIs. Using this API can eliminate the need to maintain your own separate search index and lets you take advantage of Spotlight's powerful search technology and matching rules to allow users to search for content without leaving your app, just as they do within Mail, Messages, and Notes.
Ca va vraiment être obligatoire à partir de iOS 10 ?
De toute façon, pour moi, c'est une très bonne pratique.
Quand le service change quelque chose dans son JSON, tu prends en compte la modif sur ton serveur... en temps réel. Ce qui évite d'avoir à envoyer une MAJ !
edit : En fait, NSPersistentContainer c'est encore plus que ça. Il permet de lancer des backgroundTask, il permet de créer des queues, etc. Bref, c'est un MagicalRecord killer j'ai l'impression.
edit 2 : il y a des méthodes de classes sur les sous-classes de NSManagedObject pour avoir l'entité ou créer un nouveau ManagedObject " ça c'est des choses que faisait mogenerator.
Pour chaque WWDC, regardez State of the Union plutôt que la Keynote.
La Keynote est devenue trop "pub publique" tellement relayée par les médias pour les non-développeurs que c'est devenu finalement une messe... pour les non-développeurs, ou presque. J'ai été déçu de la Keynote. Puis j'ai regardé la State of the Union. Et j'ai eu des étoiles pleins les yeux et ça m'a rassuré.
J'ai mis mon article de blog un peu à jour pour rajouter d'autres choses que je découvre dans les nouveautés développeurs au fur et à mesure. Mais ne vous invite de toute façon à regarder les vidéos.
Notamment celle sur "What's New in Security" qui explique les changements sur Apple Transport Security depuis que ça a été mis en place (ça me fait peur de lire ici qu'il y en a parmi ceux qui développent des applications iOS communiquant avec le net, qui ne sont pas au courant de ce qu'est ATS... ;-) ). En particulier non pas le fait que maintenant ça sera obligatoire pour tous les cas, mais le fait que désactiver ATS devra être justifié par autre chose que "pfff j'ai eu la flemme de passer mon serveur en HTTPS alors je l'ai désactivé comme tout le monde". Vous pourrez toujours faire une application qui communique avec un serveur tiers non sécurisé, mais seulement si vous justifiez que vous n'avez pas la main dessus pour le sécuriser, si c'est votre propre serveur (l'application SuperMarqueConnue.ipa qui communique avec www.super-marque-connue.com...) vous n'avez pas d'excuse valable (et c'est tant mieux, vive la sécurité).
@klog il y a des outils pour tester si les serveurs que tu appelles sont conformes aux normes de sécurité ATS.
Regarde la vidéo 706 dont je parle plus haut pour en savoir plus, et utilise aussi les outils fournis par Apple dédiés à ça qu'ils indiquent, notamment la commande "nscurl --ats-diagnostics" (cf aussi ce thread d'un ingé Apple sur les forums Apple par exemple) entre autres. Ca répondra directement à ta question et te donnera même tous les détails sur le niveau de sécurité pour ton serveur en particulier.
Réponses
fais péter le selfie
A choisir, il vaut mieux, je le répète, regarder platform of the union.
On a les mêmes nouveautés, mais vu côté développeur, avec du code, des démos dans Xcode, etc
Par contre, cela demande un meilleur niveau d'Anglais, parce que les accents sont à couper au couteau.
Spèce de Geek !
Mala et Klog vont hurler à la mort ..
http://www.macg.co/os-x/2016/06/gatekeeper-sierra-nacceptera-que-les-logiciels-signes-94565
Un petit extrait de l'article de MacGeneration :
La prochaine étape sera de n'autoriser que les applications qui viennent de l'AppStore !
Je suis inscrit comme développeur "gratuit" chez apple depuis Mac OS 6 !!! mais :
>:D De verrouillage en verrouillage, je ne vais plus programmer, ni avoir de Mac ! Raz le bol d'Apple.
Je constate que même de grosses boites ne signent pas leurs applications (ex.: Deezer) et pour moi, c'est là que se situe le problème. Même dans notre toute petite structure, nous les signons, et ça n'a rien de compliqué. ça évite de de devoir expliquer aux utilisateurs qu'il faut faire un clic droit sur l'icône de l'appli, etc.
Non ça m'étonnerai beaucoup. Apple est consciente des limitations du Mac AppStore, en teÌmoigne les annonces relatives à l'ouverture d'iCloud et consorts aux applications hors AppStore (mais signées).
De plus la signature d'une app ça n'a rien de vraiment choquant. L'informatique ayant évolué aussi bien dans le bon sens que dans le mauvais il n'est pas si saugrenu de vouloir savoir d'ouÌ€ vient un truc qu'on exeÌcute sur sa machine. Si on a pas les sources bien entendu. Maintenant j'aurai plus tendance à faire confiance à une app signée qui peut être deÌsactiveÌe qu'aÌ€ un code open source que je n'aurai pas le temps d'analyser et compilerait les yeux fermeÌs...
Je pense (j'espère) que la prochaine modification des comptes développeurs va permettre de signer des apps avec un compte gratis et reÌserver les AppStores aux comptes payants. C'est raccord avec les limitations de Sierra et l'ouverture de Swift-pour-tout-le-monde-coder-c'est-facile-et-trop-cool !
Le fait de devoir payer impose une certaine traçabilité de la personne derrière le compte. Si n'importe qui peut signer n'importe quoi en se créant un compte bidon cela perd du sens non?
Fut un temps où je devais déployer des apps sur des centaines de machines distantes par scripting et ssh. J'ose pas imaginer le merdier de devoir valider tous les premiers lancements d'apps sur de Mac en mode kiosque.
Oui et non. .. Ce n'est pas difficile pour un malveillant organisé d'avoir une carte de crédit non traçable (vol d'identité, carte au nom d'un trust dans un paradis fiscal, etc). Et de créer un compte développeur payant avec cette carte.
Ouaip... bein on est pas sortie de l'auberge... Manque plus que la suppression du support de Carbon ::)
Bon maintenant c'est qu'une beta... Et rien ne dit que l'option sera toujours absente dans les prochaines versions.
Moi aussi je suis content, même si je suis moins émerveillé que d'autres années.
En 20 ans je n'ai jamais été développeur "payant". Je ne programme que pour mon plaisir et je mets à disposition gratuitement sur un site une partie de ce que je fais. je ne gagne pas un sou avec ça. C'est entendu, ce n'est pas transcendant ! Mais payer plein pot juste pour pouvoir se torturer les neurones et exercer ses facultés de réflexion, ça ne me parait pas intéressant du tout.
Ce selfie là ?
Ali a dit :
At the end of 2016, Apple will make ATS mandatory for all developers who hope to submit their apps to the App Store.
C'est quoi ATS ?
(Source : http://alisoftware.github.io/conferences/2016/06/20/ios-10-api-diff/)
App Transport Security. En gros, l'obligation d'utiliser https au lieu de http.
Déjà fait pour mon propre serveur.
Mais si on pointe des liens vers des services externes ou autre ressources en http dont on n'a pas le contrôle ? (je ne pense pas que ce soit mon cas cependant)
Comme des périphériques locaux : Freebox, TV Universal PNP, etc.
Une petite chose : si on s'intègre à la recherche spotlight (apparue dans iOS 9), dans iOS 10, on peut également utiliser l'index spotlight dans sa propre app.
ouais ou des APIs météo par exemple. La plupart sont en HTTP...
Alternative: appeler son serveur en HTTPS qui lui appelle le lien officiel HTTP (et parser sur son serveur du coup) ?
Mouais...
Ca va vraiment être obligatoire à partir de iOS 10 ?
Aujourd'hui on a le choix entre désactiver complètement ATP ou activer ATP avec des exceptions.
Peut-être qu'ils vont obliger à activer ATP mais continuer à accepter les exceptions.
De toute façon, pour moi, c'est une très bonne pratique.
Quand le service change quelque chose dans son JSON, tu prends en compte la modif sur ton serveur... en temps réel. Ce qui évite d'avoir à envoyer une MAJ !
Pour ceux qui utilisent CoreData, il y a du neuf.
En particulier une nouvelle classe vient encapsuler le cluster MOC+coordinator+Model.
C'est NSPersistentContainer. ça rend le code de l'initialisation de stack CoreData très court !
Autres changement :
- meilleure gestion des faults
- meilleure gestion des opérations concurrentes
La vidéo
edit : En fait, NSPersistentContainer c'est encore plus que ça. Il permet de lancer des backgroundTask, il permet de créer des queues, etc. Bref, c'est un MagicalRecord killer j'ai l'impression.
edit 2 : il y a des méthodes de classes sur les sous-classes de NSManagedObject pour avoir l'entité ou créer un nouveau ManagedObject " ça c'est des choses que faisait mogenerator.
Ouais ça j'ai vu mais c'est sierra et iOS10 only.
Je trouve ça dommage parce qu'on ne va pas proposer directement des apps pour ces OS seulement...
La Keynote est devenue trop "pub publique" tellement relayée par les médias pour les non-développeurs que c'est devenu finalement une messe... pour les non-développeurs, ou presque.
J'ai été déçu de la Keynote. Puis j'ai regardé la State of the Union. Et j'ai eu des étoiles pleins les yeux et ça m'a rassuré.
J'ai mis mon article de blog un peu à jour pour rajouter d'autres choses que je découvre dans les nouveautés développeurs au fur et à mesure. Mais ne vous invite de toute façon à regarder les vidéos.
Notamment celle sur "What's New in Security" qui explique les changements sur Apple Transport Security depuis que ça a été mis en place (ça me fait peur de lire ici qu'il y en a parmi ceux qui développent des applications iOS communiquant avec le net, qui ne sont pas au courant de ce qu'est ATS... ;-) ). En particulier non pas le fait que maintenant ça sera obligatoire pour tous les cas, mais le fait que désactiver ATS devra être justifié par autre chose que "pfff j'ai eu la flemme de passer mon serveur en HTTPS alors je l'ai désactivé comme tout le monde". Vous pourrez toujours faire une application qui communique avec un serveur tiers non sécurisé, mais seulement si vous justifiez que vous n'avez pas la main dessus pour le sécuriser, si c'est votre propre serveur (l'application SuperMarqueConnue.ipa qui communique avec www.super-marque-connue.com...) vous n'avez pas d'excuse valable (et c'est tant mieux, vive la sécurité).
Quelqu'un sait-il si le SSL fourni par défaut sur le mutualisé d'OVH est suffisant ?
Regarde la vidéo 706 dont je parle plus haut pour en savoir plus, et utilise aussi les outils fournis par Apple dédiés à ça qu'ils indiquent, notamment la commande "nscurl --ats-diagnostics" (cf aussi ce thread d'un ingé Apple sur les forums Apple par exemple) entre autres. Ca répondra directement à ta question et te donnera même tous les détails sur le niveau de sécurité pour ton serveur en particulier.
Merci pour ces infos !