À part ça ton commentaire sonne comme si tu avais tout fait en sous-marin sans demander une prise en chage / aide par le service informatique pour t'expliquer ce que tu ne savais pas (informations de connection citrix, comment te logger à ton mac depuis le bureau Citrix, etc…). Faut pas vraiment se plaindre si on ne cherche pas à se faire aider et je n'ai pas vraiment l'impression que le problème est dans les outils cloud/pas cloud libres/proprios.
Bah quand le service informatique te répond, lorsque tu leur demandes de l’aide pour configurer le client sous GNU/Linux, de consulter le guide fourni alors que le guide en question ne contient d’instructions que pour les versions Windows et Mac OS X, puis ferme le ticket lorsque tu leur fais remarquer ça… je suis désolé mais tu comprends rapidement qu’il n’y a pas grand’chose à attendre d’eux.
Je ne doute pas que OneDrive doit bien marcher sous Windows (encore heureux aurais-je envie de dire).
Sous Mac OS X, ben… comme expliqué dans le journal le client ne se lance même pas !
Et d’après certains commentaires sur l’Apple Store ou uservoice.com, même quand le client fonctionne il n’a pas l’air terrible, franchement…
Ce que j’adore, c’est
les fan-boys Apple qui disent que c’est de la faute de Microsoft, qui saboterait délibérément les versions Mac OS de ses logiciels pour pousser les gens à passer sous Windows ;
les fan-boys Microsoft qui disent que c’est de la faute d’Apple, dont le système serait programmé pour détecter les logiciels Microsoft et délibérément saboter leurs performances afin de pousser les gens à n’utiliser que des softs Apple.
Franchement, les deux explications me semblent tout aussi plausibles l’une que l’autre, c’est dire l’opinion que j’ai de ces deux éditeurs… :D
Une solution aurait pu consister dans un tunnel RDP via Citrix entre ta machine perso et ta machine pro (si elle reste allumée) : ça existe, et ça peut se faire de manière sécurisée, avec citrix…
Ben d’après ce que j’avais compris, c’était bien ça, la solution — en théorie. Citrix Workspace était supposé me donner accès à ma machine (d’ailleurs les consignes données par le labo nous disaient « veillez à laisser vos machines allumées avant de partir en confinement, sinon ça ne marchera pas », et le Citrix Receiver est bien installé sur ladite machine), pas à un bureau virtuel quelconque.
Ce qui se passe en réalité, à mon avis, c’est que pour une raison ou pour une autre Citrix Workspace ne marche pas quand le bureau distant auquel on veut se connecter est un bureau Mac OS X. Soit que ce n’est simplement pas prévu, soit c’est prévu mais c’était en option (payante), soit c’est prévu mais c’est buggé, que sais-je ?
Du coup, je suppose que quand le client Citrix tente de se connecter à un bureau distant et qu’il réalise que ah zut, c’est du Apple, ben il se rabat sur la connexion à un bureau virtuel Windows « générique » par défaut, d’où j’ai quand même accès à mes données (mais sans pouvoir les faire sortir du bureau virtuel, ce qui les rend inutile) mais pas aux logiciels installés sur le bureau Mac OS X.
Quand j’étais au CNRS il y a quelques années, leur solution était basée sur Owncloud, qui à l’époque utilisait exactement le même client desktop que Nextcloud (ou plutôt c’est le contraire, c’est Nextcloud qui utilisait le client desktop de Owncloud — le fork du client est intervenu plus tard). Et pareil, ça marchait plutôt bien dans mon souvenir.
Euh… il n'y a pas que les logiciels propriétaires qui sont disponibles sous forme de service.
Absolument. Si un des critères considérés pour la sélection de la solution était « il faut que ça a l’air corporate, que ça coûte cher », je suis sûr que Nextcloud GmbH ou l’un quelconque de leurs partenaires se serait fait un plaisir de facturer une prestation avec plein de zéros avant la virgule.
Ceci dit, je suis un grand fan de ssh, et pourquoi ne pas avoir utilisé un bon vieux ssh avec redirection de port dans tous les sens?
J’aurais bien aimé ! Seulement… port 22 fermé et machines complètement inaccessibles depuis l’extérieur du réseau local. Seul HTTPS passe, et évidemment seulement dans le sens machine→Internet, pas le contraire (c’est compatible avec Nextcloud parce qu’en pratique c’est toujours le client Nextcloud qui initie une connexion avec le serveur, même si une fois la connexion ouverte les données peuvent être synchronisées dans les deux sens).
Je suppose qu’il aurait été possible de faire passer du SSH dans du HTTPS, mais ① je ne sais pas faire, ni ne suis motivé pour apprendre ça ② pour le coup ça aurait vraiment été une violation flagrante de la politique IT du labo (fermer le port 22, ça veut bien dire « on ne veut pas que vous fassiez du SSH », même si l’interdiction n’est explicitement formulée nulle part).
Par contre, avec ta solution NextCloud, et à moins que tu aies eu un accord avec la sécu de ta boite, tu te mets possiblement en faute professionnelle lourde en partageant des données de ton entreprise sur une solution de cloud public non autorisée, et en récupérant tes données sur une machine perso. Avec tous les risques associés.
On a explicitement l’autorisation d’utiliser nos données sur nos machines persos. :)
Initialement cette autorisation n’était accordée que sur demande dûment justifiée, mais depuis l’épidémie elle a été automatiquement donnée à tout le personnel.
La seule exception est pour ceux de mes collègues qui manipulent des données en provenance de patients, qui même anonymisées font l’objet de contraintes et de responsabilités particulìeres. En toutes circonstances (i.e même en cas de pandémie) ces données ne peuvent être manipulées que sur des machines apprêtées par le labo — ceux qui veulent travailler avec ces données depuis chez eux doivent utiliser un PC portable spécialement fourni par le service IT.
Je ne manipule pas ce genre de données. Mes seuls patients sont des drosophiles, qui dans un exemple flagrant de spécisme ne sont pas considérées comme des data subjects par le GDPR. :) Je ne me serais pas permis d’utiliser ma solution dans le cas contraire, je ne suis pas (si) fou.
Le seul point éventuellement litigieux concerne le passage par mon serveur perso, mais là-dessus j’argumenterai que :
C’est moins litigieux que le passage par OneDrive, qui est explicitement interdit.
Mon serveur perso est tout autant ma machine que mon PC portable personnel ; certes je le loue à un hébergeur, mais so what ? Je ne suis pas non plus propriétaire de mon appartement, ne suis-je pas chez moi pour autant ?
Je ne fais pas ça en loucedé, c’est un administrateur qui a installé le client Nextcloud sur mon poste professionnel — pas le choix, on est pas administrateur sur nos machines, tous les logiciels doivent être installés en personne par un administrateur ; soit le sysadmin savait parfaitement ce que je lui demandais d’installer et n’y a vu aucun problème, soit il ne savait pas ce qu’était ce « Nextcloud desktop » et dans ce cas c’est pas ma faute s’il a accepté de m’installer ça sans poser la moindre question.
L'utilisateur qui signe ses mails avec PGP et ayant connaissance de ce problème doit donc prendre soin d'envoyer ses mails dans un encoding autre que 8bit.
Ou alors l’utilisateur peut simplement utiliser PGP/MIME, défini depuis… 2001 et qui adresse entre autres ce problème.
Si l’utilisateur tient absolument à utiliser PGP/Inline, alors oui c’est à lui de prendre soin de ces détails.
J'ai rêvé ou sans vraiment l'annoncer officiellement slackware est devenue de facto une distro rolling release avec slackware-current ?
Non. Slackware-current peut être utilisée comme une rolling release, mais la distribution utilise toujours un modèle de point releases, où -current n’est rien d’autre que la version de développement.
Les versions stables remontant au moins jusqu’à la 14.0, publiée en 2013, sont toujours activement supportées et reçoivent toujours des mises à jour de sécurité, ce qu’on ne verrait pas dans un modèle purement rolling release.
Il est clair que Slackware 15.0 se fait attendre, beaucoup plus que les versions précédentes, mais elle sortira… « quand elle sera prête », comme on dit chez une autre distribution.
Leur site web fait toujours croire que le projet est mort.
Le site aurait besoin d’être rafraîchi en effet, mais ce n’est pas la priorité de Pat pour le moment.
Tu cherches quelque chose d’« intéressant » à apprendre, et tu as l’impression de ne plus pouvoir compter sur Linux pour ça parce qu’il est arrivé à un point où tout marche tout seul sans que tu aies besoin de bidouiller quoi que ce soit ?
D’après moi, ce n’est pas parce que tout marche « out of the box » qu’il ne reste rien à apprendre, si c’est ça que tu cherches.
Comprendre pourquoi et comment un système fonctionne « tout seul » est à mon sens aussi intéressant que de comprendre comment faire marcher soi-même un système qui ne fonctionne pas tout seul.
Tu peux certes essayer une autre distribution ou un autre système (comme suggéré dans d’autres commentaires), mais je ne suis pas du tout convaincu que ce soit nécessaire pour continuer à découvrir des choses. Ça fait quinze ans que j’utilise Slackware, et je n’ai pas du tout l’impression d’en avoir « fait le tour », si je veux j’ai encore plein de choses à apprendre dessus.
Par exemple, Slackware a récemment intégré PAM. L’intégration a évidemment été faite correctement (merci Pat !) et du coup ça marche tout seul sans que j’ai eu à faire quoi ce soit, mais j’ai quand même saisi cette occasion pour apprendre comment fonctionne PAM — en particulier, j’étais curieux de comprendre l’interaction entre PAM et GNOME Keyring, pour savoir comment et pourquoi mon trousseau était automatiquement « ouvert » au démarrage d’une session. Je n’avais pas besoin de ça pour que ça marche, mais ça n’en demeure pas moins intéressant.
Si jamais l’envie te prend d’essayer d’y comprendre quelque chose, mon conseil (sans prétention, simplement de la part de quelqu’un qui a longtemps été réfractaire à GRUB et n’a abandonné (e)LILO qu’après être tombé sur une machine trop moderne pour que ce dernier accepte de la faire démarrer) :
Un simple grub.cfg écrit à la main n’est pas fondamentalement plus difficile à comprendre qu’un bon vieux lilo.conf, et marchera tout aussi bien. Fais l’impasse sur toute la couche de grub-mkconfig (/etc/default/grub, les scripts /etc/grub.d/XX_zzzzzz, os-prober, etc.), et GRUB devient subitement très simple. :)
Il y a un marché pour un OS plus petit que Linux pour fonctionner dans des VM
Un système d’exploitation conçu pour ne fonctionner que dans des VM peut-il encore être qualifié de « système d’exploitation » ?
Dans toutes les définitions usuelles de « système d’exploitation », on trouve l’idée que l’OS sert d’« intermédiaire entre le matériel et les logiciels », « gère les ressources matérielles », ou plus généralement « permet l’utilisation d’un ordinateur »…
Un « OS pour machine virtuelle » est sans doute un exercice intéressant et c’est peut-être même utile, mais s’il dépend entièrement d’un « vrai » OS sous-jacent pour faire tout le boulot difficile, je trouve ça un peu gonflé d’appeler ça un « OS » et de le comparer à Linux, BSD & Co.
Au-delà de la boutade, il est intéressant de noter qu’apparemment (d’après un rapide coup d’œil sur la documentation et les dépôts du projet) le système n’utilise pas, ni ne compte utiliser, l’userland GNU (rendant une appellation GNU/Redox totalement injustifiée). Le projet a en effet :
Mettons que mon site a un certificat émis par la CA X. La CA Y émet aussi un certificat pour mon domaine. Grâce à CT, tout le monde peut voir que deux CA ont émis un certificat pour mon domaine. Et après ?
CT ne dit pas quelle CA a émis le certificat illégitime (on ne peut pas se baser sur la date d’émission du certificat, le premier certificat n’est pas forcément le certificat légitime, par exemple si j’ai renouvellé mon certificat depuis que la CA frauduleuse a émis le sien). CT ne dit même pas si un des certificats est réellement illégitime — si ça se trouve c’est moi-même qui ai demandé un certificat à une autre CA, il y a des raisons parfaitement légitimes de vouloir faire ça.
Alors certes, moi je sais que la CA Y a émis un certificat frauduleux (c’est mon site, je sais encore à quelle CA je demande un certificat, je ne suis pas gâteux à ce point — pas encore, du moins). Mais à quoi ça me sert ? Tu crois que si je signale à Microsoft, Google, Mozilla, Apple que la CA Y a émis un certificat frauduleux ils vont la virer de la liste des CA de confiance ?
Les visiteurs qui tombent sur un site qui se fait passer par le mien grâce au certificat de la CA Y, ils sont protégés comment ? Par rapport à HPKP ou DANE, que Google au mieux a fait mine d’ignorer, voire a saboté activement ?
Une partie du problème vient probablement de ce que l’interface de gestion des certificats clients est entièrement à la charge du navigateur, c’est hors de contrôle du site web visité.
Si le navigateur a une interface non-intuitive pour gérer les certificats (spoiler : c’est le cas de tous les navigateurs ; les certificats clients sont tellement peu usités que ceux qui s’en servent sont automatiquement supposés être des connaisseurs qui savent ce qu’ils font), ben… le site web qui choisit d’utiliser des certificats pour authentifier ses visiteurs ne peut pas y faire grand’chose, à part peut-être avoir une page d’aide la plus claire possible (ce qui n’était pas le cas, me semble-t-il, de impots.gouv.fr à l’époque où ils utilisaient ce système).
C’est un des trucs qui aurait du être clairement expliqué, oui. « Vous aurez besoin de ce certificat pour votre déclaration de l’année prochaine, conservez-le précieusement et n’oubliez pas le mot de passe associé ».
Je crois me souvenir qu'à une époque c'était utilisé pour déclarer ses impôts en France, si on faisait la déclaration depuis un autre ordinateur l'année suivant ça posait problème.
Oui, ça a été utilisé par le fisc aux alentours de 2008–2010, et oui, ça a posé pas mal de problèmes. En gros ça ne marchait bien que dans le cas idéal (même machine utilisée d’une année sur l’autre, sans réinstallation entre deux déclarations, et un utilisateur qui n’oublie pas le mot de passe du fichier PKCS#12 contenant le certificat et sa clef privée). Dommage, un tout petit peu plus d’explications de la part du service des impôts aurait pu rendre ça viable.
Ça ne résout aucun des problèmes posés par le système des CA et ne sert en fait qu’à assoir un peu plus ce système en coupant l’herbe sous le pied à toute tentative facilitant l’utilisation de certificats non-émis par une CA du cartel (par exemple DANE ou HPKP).
C’est une énorme arnaque, mais comme elle a été poussée par Google, ben on doit se la farcir…
Sinon, un avantage des CA actuellement, c'est les CRL et OCSP pour pouvoir révoquer une clef volée
Euh, présenter les CRL et OCSP comme un avantage des CA, c’est un peu fort, sachant que
les CRL n’ont jamais vraiment été pratiques, au point que la plupart des navigateurs modernes ne les supportent plus ;
OCSP pose au moins autant de problème qu’il n’en résout, entre le fait que la CA prend connaissance des visiteurs des sites pour lesquels elle a émis un certificat et le fait que le serveur OCSP est un SPOF.
Il a fallu inventer l’OCSP Stapling pour avoir un truc qui tienne à peu près la route et fasse à peu près ce qu’on attend.
(bon, c'est un avantage assez léger vu que personne ne l'utilise).
Pour une fois que des technos pourries ne sont pas utilisées, je ne vais pas m’en plaindre, perso. Si Certificate Transparency pouvait connaître le même sort, ce serait parfait.
Absolument, c’est l’un des problèmes du protocole OCSP appliqué aux sites web.
C’est pourquoi aujourd’hui on recommande une variation du protocole, l’agrafage OCSP (OCSP stapling). Le principe est que c’est le serveur web (et non plus le client du visiteur) qui effectue périodiquement (tous les quelques jours en moyenne) une requête OCSP auprès de la CA qui a délivré le certificat ; la réponse OCSP est alors « agrafée » au certificat, pour être présentée au client en même temps que le certificat lui-même lors de l’établissement de la connexion TLS.
En gros, avec OCSP « normal », on a :
— Client : Hello Serveur, j’aimerais voir ton certificat.
— Serveur : Le voilà.
— Client : Hello CA, ce certificat que tu as émis est-il toujours valide ?
— CA : Oui, tiens voilà un papier tamponné qui en atteste.
— Client : OK Serveur, voilà ma requête.
Alors qu’avec l’agrafage OCSP, on a :
— Serveur : Hello CA, mon certificat est toujours valide, hein ?
— CA : Oui, tiens voilà un papier tamponné qui en atteste, valable 7 jours.
— Client : Hello Serveur, j’aimerais voir ton certificat.
— Serveur : Le voilà, avec en prime une attestation de la CA, de moins de 7 jours, qui dit qu’il est toujours valide.
— Client : OK Serveur, voilà ma requête.
L’agrafage OCSP résout deux problèmes majeurs d’OCSP :
le problème de vie privée que tu mentionnes (désormais les requêtes OCSP proviennent des serveurs web et non plus des visiteurs desdits serveurs) ;
la vulnérabilité induite par le fait qu’on peut faire un DDoS sur le serveur OCSP de la CA et ainsi soit provoquer un déni de service indirect sur le serveur web (si les clients sont configurés en mode hard-fail, il suffit de faire tomber le serveur OCSP pour interdire toute connexion au serveur web), soit rendre la vérification OCSP inutile (si les clients sont configurés en mode soft-fail, en faisant tomber le serveur OCSP on interdit toute vérification effective de la validité du certificat).
Mais l’agrafage OCSP n’est pas vraiment applicable dans le cas où les certificats sont utilisés pour authentifier des applications et non des serveurs web…
À ma connaissance, aucune. C’est le même protocole, il est juste utilisé dans un but différent.
Les clients web utilisent OCSP pour vérifier que le certificat d’un site web n’a pas été révoqué avant de continuer à s’y connecter ; Mac OS X utilise OCSP pour vérifier que le certificat d’une application n’a pas été révoqué avant de l’autoriser à s’exécuter.
S'il est avéré que les ordinateurs à la pomme se comportent comme décrit dans l'article
Ce comportement est avéré. Apple ne s’en cache même pas d’ailleurs, c’est une feature, pas un bug. Le but est supposément d’empêcher l’exécution de malware.
L’incident du 12 novembre a seulement mis en évidence une des conséquences possibles de ce comportement (parmi d’autres), mais il était déjà bien connu.
Quant à savoir pourquoi tout le monde s’en fich(e|ait), boaf… je dirais simplement que plus rien ne m’étonne.
Comment se comportent les ordinateurs de cette dernière s'ils sont connectés à un réseau ne permettant pas d'apple_er leur maître ?
D'après la description, non connectés ils fonctionnent sans problème. Mais s'ils sont connecté à un réseau sans accès vers leur centre de contrôle ?
S’il n’est pas possible de contacter le service (parce que pas d’accès à Internet, ou parce que les connexions vers le serveur sont bloquées d’une manière ou une autre sur le trajet), il ne se passe rien : la vérification échoue en mode soft-fail et, dans le doute, Mac OS X autorise l’application à se lancer.
Mais s’il est possible de contacter le serveur mais que celui-ci échoue à répondre, alors Mac OS X attend indéfiniment, tout simplement.
En clair, ces génies de chez Apple ont apparemment bien prévu le coup que les autres gens, tous ceux situés entre l’utilisateur et Apple (par exemple les différents opérateurs réseaux) pouvaient merder et qu’il leur fallait gérer ça gracieusement, mais l’idée que leur propre service puisse être en rade (atteignable via le réseau mais pas en état de répondre) ne leur est jamais venu à l’esprit… Ou s’ils y ont pensé ils ont immédiatement éliminé l’hypothèse comme absurde…
Et sans même parler des problèmes évidents liés aux concepts obsolètes de vie privée et de maîtrise de sa propre machine, voici un exemple de problème pratique posé par cette politique :
Pendant plusieurs heures, impossible de lancer la moindre application sur un Mac parce que Apple n’est pas fichu d’encaisser le Distributed Denial of Service au centre duquel la compagnie s’est elle-même placée en demandant à toutes ses machines de la contacter. Admirez une des plus grosses boîtes d’IT au monde, mesdames et messieurs.
[^] # Re: euh, ssh?
Posté par gouttegd . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 4.
Non non, le SSH sortant ne passe pas non plus. C’est généralement la première chose que je teste quand j’arrive sur un nouveau réseau. :)
[^] # Re: Attention patrouille sécurité
Posté par gouttegd . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 8.
Bah quand le service informatique te répond, lorsque tu leur demandes de l’aide pour configurer le client sous GNU/Linux, de consulter le guide fourni alors que le guide en question ne contient d’instructions que pour les versions Windows et Mac OS X, puis ferme le ticket lorsque tu leur fais remarquer ça… je suis désolé mais tu comprends rapidement qu’il n’y a pas grand’chose à attendre d’eux.
[^] # Re: OneDive n'est pas aussi mauvais que ça
Posté par gouttegd . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 5.
Je ne doute pas que OneDrive doit bien marcher sous Windows (encore heureux aurais-je envie de dire).
Sous Mac OS X, ben… comme expliqué dans le journal le client ne se lance même pas !
Et d’après certains commentaires sur l’Apple Store ou uservoice.com, même quand le client fonctionne il n’a pas l’air terrible, franchement…
Ce que j’adore, c’est
les fan-boys Apple qui disent que c’est de la faute de Microsoft, qui saboterait délibérément les versions Mac OS de ses logiciels pour pousser les gens à passer sous Windows ;
les fan-boys Microsoft qui disent que c’est de la faute d’Apple, dont le système serait programmé pour détecter les logiciels Microsoft et délibérément saboter leurs performances afin de pousser les gens à n’utiliser que des softs Apple.
Franchement, les deux explications me semblent tout aussi plausibles l’une que l’autre, c’est dire l’opinion que j’ai de ces deux éditeurs… :D
[^] # Re: Attention patrouille sécurité
Posté par gouttegd . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 6. Dernière modification le 17 décembre 2020 à 11:10.
Ben d’après ce que j’avais compris, c’était bien ça, la solution — en théorie. Citrix Workspace était supposé me donner accès à ma machine (d’ailleurs les consignes données par le labo nous disaient « veillez à laisser vos machines allumées avant de partir en confinement, sinon ça ne marchera pas », et le Citrix Receiver est bien installé sur ladite machine), pas à un bureau virtuel quelconque.
Ce qui se passe en réalité, à mon avis, c’est que pour une raison ou pour une autre Citrix Workspace ne marche pas quand le bureau distant auquel on veut se connecter est un bureau Mac OS X. Soit que ce n’est simplement pas prévu, soit c’est prévu mais c’était en option (payante), soit c’est prévu mais c’est buggé, que sais-je ?
Du coup, je suppose que quand le client Citrix tente de se connecter à un bureau distant et qu’il réalise que ah zut, c’est du Apple, ben il se rabat sur la connexion à un bureau virtuel Windows « générique » par défaut, d’où j’ai quand même accès à mes données (mais sans pouvoir les faire sortir du bureau virtuel, ce qui les rend inutile) mais pas aux logiciels installés sur le bureau Mac OS X.
Du moins, c’est ce que je comprends.
[^] # Re: Client nextcloud
Posté par gouttegd . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 3.
Pour ce que ça vaut, j’ai jamais observé ça…
Quand j’étais au CNRS il y a quelques années, leur solution était basée sur Owncloud, qui à l’époque utilisait exactement le même client desktop que Nextcloud (ou plutôt c’est le contraire, c’est Nextcloud qui utilisait le client desktop de Owncloud — le fork du client est intervenu plus tard). Et pareil, ça marchait plutôt bien dans mon souvenir.
[^] # Re: dans mon labo …
Posté par gouttegd . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 5.
Absolument. Si un des critères considérés pour la sélection de la solution était « il faut que ça a l’air corporate, que ça coûte cher », je suis sûr que Nextcloud GmbH ou l’un quelconque de leurs partenaires se serait fait un plaisir de facturer une prestation avec plein de zéros avant la virgule.
[^] # Re: euh, ssh?
Posté par gouttegd . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 3.
J’aurais bien aimé ! Seulement… port 22 fermé et machines complètement inaccessibles depuis l’extérieur du réseau local. Seul HTTPS passe, et évidemment seulement dans le sens machine→Internet, pas le contraire (c’est compatible avec Nextcloud parce qu’en pratique c’est toujours le client Nextcloud qui initie une connexion avec le serveur, même si une fois la connexion ouverte les données peuvent être synchronisées dans les deux sens).
Je suppose qu’il aurait été possible de faire passer du SSH dans du HTTPS, mais ① je ne sais pas faire, ni ne suis motivé pour apprendre ça ② pour le coup ça aurait vraiment été une violation flagrante de la politique IT du labo (fermer le port 22, ça veut bien dire « on ne veut pas que vous fassiez du SSH », même si l’interdiction n’est explicitement formulée nulle part).
[^] # Re: Attention patrouille sécurité
Posté par gouttegd . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 9.
On a explicitement l’autorisation d’utiliser nos données sur nos machines persos. :)
Initialement cette autorisation n’était accordée que sur demande dûment justifiée, mais depuis l’épidémie elle a été automatiquement donnée à tout le personnel.
La seule exception est pour ceux de mes collègues qui manipulent des données en provenance de patients, qui même anonymisées font l’objet de contraintes et de responsabilités particulìeres. En toutes circonstances (i.e même en cas de pandémie) ces données ne peuvent être manipulées que sur des machines apprêtées par le labo — ceux qui veulent travailler avec ces données depuis chez eux doivent utiliser un PC portable spécialement fourni par le service IT.
Je ne manipule pas ce genre de données. Mes seuls patients sont des drosophiles, qui dans un exemple flagrant de spécisme ne sont pas considérées comme des data subjects par le GDPR. :) Je ne me serais pas permis d’utiliser ma solution dans le cas contraire, je ne suis pas (si) fou.
Le seul point éventuellement litigieux concerne le passage par mon serveur perso, mais là-dessus j’argumenterai que :
[^] # Re: Autohébergement
Posté par gouttegd . En réponse au journal Linux ne m'intéresse plus. Évalué à 7.
Ou alors l’utilisateur peut simplement utiliser PGP/MIME, défini depuis… 2001 et qui adresse entre autres ce problème.
Si l’utilisateur tient absolument à utiliser PGP/Inline, alors oui c’est à lui de prendre soin de ces détails.
[^] # Re: Pas sûr de comprendre le problème…
Posté par gouttegd . En réponse au journal Linux ne m'intéresse plus. Évalué à 4.
Non. Slackware-current peut être utilisée comme une rolling release, mais la distribution utilise toujours un modèle de point releases, où -current n’est rien d’autre que la version de développement.
Les versions stables remontant au moins jusqu’à la 14.0, publiée en 2013, sont toujours activement supportées et reçoivent toujours des mises à jour de sécurité, ce qu’on ne verrait pas dans un modèle purement rolling release.
Il est clair que Slackware 15.0 se fait attendre, beaucoup plus que les versions précédentes, mais elle sortira… « quand elle sera prête », comme on dit chez une autre distribution.
Le site aurait besoin d’être rafraîchi en effet, mais ce n’est pas la priorité de Pat pour le moment.
Pour suivre l’actualité de la distribution, il faut consulter les changelogs et la section Slackware de LinuxQuestions.org.
# Pas sûr de comprendre le problème…
Posté par gouttegd . En réponse au journal Linux ne m'intéresse plus. Évalué à 7.
Tu cherches quelque chose d’« intéressant » à apprendre, et tu as l’impression de ne plus pouvoir compter sur Linux pour ça parce qu’il est arrivé à un point où tout marche tout seul sans que tu aies besoin de bidouiller quoi que ce soit ?
D’après moi, ce n’est pas parce que tout marche « out of the box » qu’il ne reste rien à apprendre, si c’est ça que tu cherches.
Comprendre pourquoi et comment un système fonctionne « tout seul » est à mon sens aussi intéressant que de comprendre comment faire marcher soi-même un système qui ne fonctionne pas tout seul.
Tu peux certes essayer une autre distribution ou un autre système (comme suggéré dans d’autres commentaires), mais je ne suis pas du tout convaincu que ce soit nécessaire pour continuer à découvrir des choses. Ça fait quinze ans que j’utilise Slackware, et je n’ai pas du tout l’impression d’en avoir « fait le tour », si je veux j’ai encore plein de choses à apprendre dessus.
Par exemple, Slackware a récemment intégré PAM. L’intégration a évidemment été faite correctement (merci Pat !) et du coup ça marche tout seul sans que j’ai eu à faire quoi ce soit, mais j’ai quand même saisi cette occasion pour apprendre comment fonctionne PAM — en particulier, j’étais curieux de comprendre l’interaction entre PAM et GNOME Keyring, pour savoir comment et pourquoi mon trousseau était automatiquement « ouvert » au démarrage d’une session. Je n’avais pas besoin de ça pour que ça marche, mais ça n’en demeure pas moins intéressant.
# GRUB2
Posté par gouttegd . En réponse au journal Linux ne m'intéresse plus. Évalué à 6.
Si jamais l’envie te prend d’essayer d’y comprendre quelque chose, mon conseil (sans prétention, simplement de la part de quelqu’un qui a longtemps été réfractaire à GRUB et n’a abandonné (e)LILO qu’après être tombé sur une machine trop moderne pour que ce dernier accepte de la faire démarrer) :
Un simple
grub.cfgécrit à la main n’est pas fondamentalement plus difficile à comprendre qu’un bon vieuxlilo.conf, et marchera tout aussi bien. Fais l’impasse sur toute la couche degrub-mkconfig(/etc/default/grub, les scripts/etc/grub.d/XX_zzzzzz,os-prober, etc.), et GRUB devient subitement très simple. :)[^] # Re: Pas de pilotes...
Posté par gouttegd . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 4. Dernière modification le 08 décembre 2020 à 12:34.
Un système d’exploitation conçu pour ne fonctionner que dans des VM peut-il encore être qualifié de « système d’exploitation » ?
Dans toutes les définitions usuelles de « système d’exploitation », on trouve l’idée que l’OS sert d’« intermédiaire entre le matériel et les logiciels », « gère les ressources matérielles », ou plus généralement « permet l’utilisation d’un ordinateur »…
Un « OS pour machine virtuelle » est sans doute un exercice intéressant et c’est peut-être même utile, mais s’il dépend entièrement d’un « vrai » OS sous-jacent pour faire tout le boulot difficile, je trouve ça un peu gonflé d’appeler ça un « OS » et de le comparer à Linux, BSD & Co.
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par gouttegd . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 10.
Au-delà de la boutade, il est intéressant de noter qu’apparemment (d’après un rapide coup d’œil sur la documentation et les dépôts du projet) le système n’utilise pas, ni ne compte utiliser, l’userland GNU (rendant une appellation GNU/Redox totalement injustifiée). Le projet a en effet :
[^] # Re: Discussion
Posté par gouttegd . En réponse au lien Le protocole Gemini, revenir à du simple et sûr pour distribuer l'information en ligne ? - Botzmeyer. Évalué à 4. Dernière modification le 04 décembre 2020 à 11:09.
Super. Et ça change quoi au juste ?
Mettons que mon site a un certificat émis par la CA X. La CA Y émet aussi un certificat pour mon domaine. Grâce à CT, tout le monde peut voir que deux CA ont émis un certificat pour mon domaine. Et après ?
CT ne dit pas quelle CA a émis le certificat illégitime (on ne peut pas se baser sur la date d’émission du certificat, le premier certificat n’est pas forcément le certificat légitime, par exemple si j’ai renouvellé mon certificat depuis que la CA frauduleuse a émis le sien). CT ne dit même pas si un des certificats est réellement illégitime — si ça se trouve c’est moi-même qui ai demandé un certificat à une autre CA, il y a des raisons parfaitement légitimes de vouloir faire ça.
Alors certes, moi je sais que la CA Y a émis un certificat frauduleux (c’est mon site, je sais encore à quelle CA je demande un certificat, je ne suis pas gâteux à ce point — pas encore, du moins). Mais à quoi ça me sert ? Tu crois que si je signale à Microsoft, Google, Mozilla, Apple que la CA Y a émis un certificat frauduleux ils vont la virer de la liste des CA de confiance ?
Les visiteurs qui tombent sur un site qui se fait passer par le mien grâce au certificat de la CA Y, ils sont protégés comment ? Par rapport à HPKP ou DANE, que Google au mieux a fait mine d’ignorer, voire a saboté activement ?
[^] # Re: le but ?
Posté par gouttegd . En réponse au lien Le protocole Gemini, revenir à du simple et sûr pour distribuer l'information en ligne ? - Botzmeyer. Évalué à 5.
Une partie du problème vient probablement de ce que l’interface de gestion des certificats clients est entièrement à la charge du navigateur, c’est hors de contrôle du site web visité.
Si le navigateur a une interface non-intuitive pour gérer les certificats (spoiler : c’est le cas de tous les navigateurs ; les certificats clients sont tellement peu usités que ceux qui s’en servent sont automatiquement supposés être des connaisseurs qui savent ce qu’ils font), ben… le site web qui choisit d’utiliser des certificats pour authentifier ses visiteurs ne peut pas y faire grand’chose, à part peut-être avoir une page d’aide la plus claire possible (ce qui n’était pas le cas, me semble-t-il, de impots.gouv.fr à l’époque où ils utilisaient ce système).
[^] # Re: le but ?
Posté par gouttegd . En réponse au lien Le protocole Gemini, revenir à du simple et sûr pour distribuer l'information en ligne ? - Botzmeyer. Évalué à 3.
C’est un des trucs qui aurait du être clairement expliqué, oui. « Vous aurez besoin de ce certificat pour votre déclaration de l’année prochaine, conservez-le précieusement et n’oubliez pas le mot de passe associé ».
[^] # Re: le but ?
Posté par gouttegd . En réponse au lien Le protocole Gemini, revenir à du simple et sûr pour distribuer l'information en ligne ? - Botzmeyer. Évalué à 3.
Oui, ça a été utilisé par le fisc aux alentours de 2008–2010, et oui, ça a posé pas mal de problèmes. En gros ça ne marchait bien que dans le cas idéal (même machine utilisée d’une année sur l’autre, sans réinstallation entre deux déclarations, et un utilisateur qui n’oublie pas le mot de passe du fichier PKCS#12 contenant le certificat et sa clef privée). Dommage, un tout petit peu plus d’explications de la part du service des impôts aurait pu rendre ça viable.
[^] # Re: Discussion
Posté par gouttegd . En réponse au lien Le protocole Gemini, revenir à du simple et sûr pour distribuer l'information en ligne ? - Botzmeyer. Évalué à 2.
Ça ne résout aucun des problèmes posés par le système des CA et ne sert en fait qu’à assoir un peu plus ce système en coupant l’herbe sous le pied à toute tentative facilitant l’utilisation de certificats non-émis par une CA du cartel (par exemple DANE ou HPKP).
C’est une énorme arnaque, mais comme elle a été poussée par Google, ben on doit se la farcir…
[^] # Re: Discussion
Posté par gouttegd . En réponse au lien Le protocole Gemini, revenir à du simple et sûr pour distribuer l'information en ligne ? - Botzmeyer. Évalué à 3.
Euh, présenter les CRL et OCSP comme un avantage des CA, c’est un peu fort, sachant que
Il a fallu inventer l’OCSP Stapling pour avoir un truc qui tienne à peu près la route et fasse à peu près ce qu’on attend.
Pour une fois que des technos pourries ne sont pas utilisées, je ne vais pas m’en plaindre, perso. Si Certificate Transparency pouvait connaître le même sort, ce serait parfait.
[^] # Re: Question bête
Posté par gouttegd . En réponse au lien Mac OS X contacte Apple chaque fois que vous lancez une application. Évalué à 9. Dernière modification le 15 novembre 2020 à 22:30.
Absolument, c’est l’un des problèmes du protocole OCSP appliqué aux sites web.
C’est pourquoi aujourd’hui on recommande une variation du protocole, l’agrafage OCSP (OCSP stapling). Le principe est que c’est le serveur web (et non plus le client du visiteur) qui effectue périodiquement (tous les quelques jours en moyenne) une requête OCSP auprès de la CA qui a délivré le certificat ; la réponse OCSP est alors « agrafée » au certificat, pour être présentée au client en même temps que le certificat lui-même lors de l’établissement de la connexion TLS.
En gros, avec OCSP « normal », on a :
— Client : Hello Serveur, j’aimerais voir ton certificat.
— Serveur : Le voilà.
— Client : Hello CA, ce certificat que tu as émis est-il toujours valide ?
— CA : Oui, tiens voilà un papier tamponné qui en atteste.
— Client : OK Serveur, voilà ma requête.
Alors qu’avec l’agrafage OCSP, on a :
— Serveur : Hello CA, mon certificat est toujours valide, hein ?
— CA : Oui, tiens voilà un papier tamponné qui en atteste, valable 7 jours.
— Client : Hello Serveur, j’aimerais voir ton certificat.
— Serveur : Le voilà, avec en prime une attestation de la CA, de moins de 7 jours, qui dit qu’il est toujours valide.
— Client : OK Serveur, voilà ma requête.
L’agrafage OCSP résout deux problèmes majeurs d’OCSP :
Mais l’agrafage OCSP n’est pas vraiment applicable dans le cas où les certificats sont utilisés pour authentifier des applications et non des serveurs web…
[^] # Re: Question bête
Posté par gouttegd . En réponse au lien Mac OS X contacte Apple chaque fois que vous lancez une application. Évalué à 3.
À ma connaissance, aucune. C’est le même protocole, il est juste utilisé dans un but différent.
Les clients web utilisent OCSP pour vérifier que le certificat d’un site web n’a pas été révoqué avant de continuer à s’y connecter ; Mac OS X utilise OCSP pour vérifier que le certificat d’une application n’a pas été révoqué avant de l’autoriser à s’exécuter.
[^] # Re: Question bête
Posté par gouttegd . En réponse au lien Mac OS X contacte Apple chaque fois que vous lancez une application. Évalué à 6.
Ce comportement est avéré. Apple ne s’en cache même pas d’ailleurs, c’est une feature, pas un bug. Le but est supposément d’empêcher l’exécution de malware.
L’incident du 12 novembre a seulement mis en évidence une des conséquences possibles de ce comportement (parmi d’autres), mais il était déjà bien connu.
Quant à savoir pourquoi tout le monde s’en fich(e|ait), boaf… je dirais simplement que plus rien ne m’étonne.
[^] # Re: Conséquences
Posté par gouttegd . En réponse au lien Mac OS X contacte Apple chaque fois que vous lancez une application. Évalué à 10. Dernière modification le 14 novembre 2020 à 20:45.
S’il n’est pas possible de contacter le service (parce que pas d’accès à Internet, ou parce que les connexions vers le serveur sont bloquées d’une manière ou une autre sur le trajet), il ne se passe rien : la vérification échoue en mode soft-fail et, dans le doute, Mac OS X autorise l’application à se lancer.
Mais s’il est possible de contacter le serveur mais que celui-ci échoue à répondre, alors Mac OS X attend indéfiniment, tout simplement.
En clair, ces génies de chez Apple ont apparemment bien prévu le coup que les autres gens, tous ceux situés entre l’utilisateur et Apple (par exemple les différents opérateurs réseaux) pouvaient merder et qu’il leur fallait gérer ça gracieusement, mais l’idée que leur propre service puisse être en rade (atteignable via le réseau mais pas en état de répondre) ne leur est jamais venu à l’esprit… Ou s’ils y ont pensé ils ont immédiatement éliminé l’hypothèse comme absurde…
# Conséquences
Posté par gouttegd . En réponse au lien Mac OS X contacte Apple chaque fois que vous lancez une application. Évalué à 10.
Et sans même parler des problèmes évidents liés aux concepts obsolètes de vie privée et de maîtrise de sa propre machine, voici un exemple de problème pratique posé par cette politique :
https://arstechnica.com/gadgets/2020/11/macos-big-sur-launch-appears-to-cause-temporary-slowdown-in-even-non-big-sur-macs/
Pendant plusieurs heures, impossible de lancer la moindre application sur un Mac parce que Apple n’est pas fichu d’encaisser le Distributed Denial of Service au centre duquel la compagnie s’est elle-même placée en demandant à toutes ses machines de la contacter. Admirez une des plus grosses boîtes d’IT au monde, mesdames et messieurs.