jyes a écrit 907 commentaires

C’est la même rengaine que lors du journal sur GrapheneOS. Vous présentez une vision de la sécurité qui se focalise presque exclusivement sur la chaîne de confiance et particulièrement sur sa mise en œuvre cryptographique. Sur un site avec un lectorat (au moins en grande partie) libriste, forcément ça passe mal. Par exemple, en début de crise Covid les applications de visio comme Zoom étaient très décriées ici, la « sécurité » de les savoir signées par leurs développeurs plutôt que par le magasin d’applications n‘apporte pas plus que de savoir que ces applis tournent sur un système dont le boot est signé. Sur Android, la principale menace ce sont les applications, et une solution qui convainc forcément mieux les libristes que les signatures cryptographiques, c’est d’essayer de proposer des applications de qualité et respectueuses des utilisateurs.

Personnellement je suis convaincu que pour cela, publier le code source et effectuer un recensement des antifonctions comme le fait F-Droid est plus efficace qu’une solution crytpographique, aussi élégante soit elle sur le papier. Bien sûr, comme toujours, c’est limité par la faible capacité d’audit de la communauté. D’ailleurs, même dans des communautés beaucoup plus grandes que F-Droid il y a de jolis ratés (OpenSSL chez Debian, ça a marqué les esprits). Mais ce n’est pas en surprimant la possibilité d’auditer qu’on améliore la situation, comme le pointait Gil Cot dans son commentaire, ce à quoi j’ajoute que ce n’est pas en faisant signer par ses développeurs un paquet non audité qu’on l’améliore non plus.

Alors accuser F-Droid de “weakening the Android security model”, ouais, c’est biaisé et un peu génant quand même. De toutes les applis signées par leurs développeurs disponibles sur le Play Store, il n’y en a pas beaucoup que j’installerais sans craindre pour la sécurité de mes données et de ma vie privée.

Si je me rappelle bien, il y a quelques années, ils essayaient de mettre en place en plus un système de backups / restore automatique avec les snapshots de BTRFS.

Tu dois parler de « snapper ». C’est un outil développé pour OpenSUSE mais disponible dans les autres distributions maintenant (comme Debian). L’intégration dans OpenSUSE est excellente (j’ai testé il y a quelques temps mais ça m’étonnerait que ce soit moins bien avec le temps). Dans Debian, faut faire des trucs à la main (notamment pour restaurer les sauvegardes, ce n’est pas dur de les faire mais ce n’est que la moitié du boulot pour que ce soit utile). Freedombox (Debian Pure Blend) s’en sert aussi.

Personnellement, j’utilise Debian parce que c’est une distribution que je finis pas bien connaître, et comme ça toutes les machines que je touche fonctionnent pareil, qu’elles servent d’ordinateur pour le boulot, de serveur e-mail ou de plateforme vidéoludique avec Kodi, mais mes essais (qui datent un peu) d’OpenSUSE m’ont laissé un souvenir très positif.

Dans ma folle jeunesse, quand j’utilisais Debian testing, je faisais effectivement du pinning avec Sid pour pallier le problème que tu soulèves. Ça pouvait être pénible par moment, mais je trouvais que le filet de sécurité du délai de maturation avant migration dans testing évitait relativement efficacement les plus gros problèmes, et cette solution m’a convenu un certain temps.

Je ne sais pas ce qu'il en est aujourd'hui, mais je suis maintenant en Debian stable sur mon poste de travail et j’en suis très satisfait, j‘utilise même très peu les backports. Par exemple, je ne les ai pas activés depuis la sortie de Bullseye. Je le ferai peut-être quand je jugerai la version de LibreOffice de stable vraiment dépassée, mais je ne le fais en général pas avant au moins un an après la sortie de la dernière version stable de Debian. Ce monde va trop vite pour moi, mais Debian m’attend un peu et j’apprécie.

Moi aussi, j’ai un parcours tumultueux : Woody → Sarge → Etch → Lenny → Squeeze → Wheezy → Jessie → Stretch → Buster → Bullseye !

Cela peut faire penser à un « aspect » mais en fait on peut lancer le programme seul, avec lowriter pour reprendre le même exemple

Sauf que "lowriter" est un script qui lance "/usr/lib/libreoffice/program/soffice --writer". À la fin il n’y a bien qu’un seul programme "soffice.bin" qui fait tout tourner. Cependant, les modules (Calc, Base, Impress, etc) contiennent beaucoup de choses dont des bibliothèques. Donc même s’il a y un seul exécutable, il y a bien une distribution binaire différente pour les différents modules. Plus que des « aspects », ce sont de (gros) « plugins ». Mais ça ne me choque pas qu’on distribue les plugins à part, c’est bien l’intérêt de leur modularité par rapport à un exécutable lié statiquement avec tout dedans.

Ah, je croyais c’était le rôle du noyau, … ah non, celui de Compiz, ou celui mon administrateur système. Je ne sais plus. « Gérer ma machine » c’est tellement clair comme définition.

Pour mes identifiants utilisateurs, les seuls caractères que j’utilise sont [ejsy], donc je n’ai pas besoin de permettre d’autres caractères.

Après si c’est pour un système qui aura potentiellement d’autres utilisateurs que moi, il y une liste toute faite de caractères bien utiles.

Autre solution quand on héberge soit même ses courriels, c’est d’utiliser d’autres caractères que le + comme séparateur.
Dans mon master.cf (conf de postfix) :

recipient_delimiter = +-_

et le tour est joué !

Alors que la plupart des sites fonctionnent avec les polices par défaut.

Euh, non. Beaucoup de sites utilisent des polices pour afficher des logos et des images. Tu ne dois pas avoir beaucoup essayé. Mon navigateur ne charge pas les polices distantes pas défaut et en fait, ça casse beaucoup de sites, avec même des effets catastrophiques sur la mise en page complète dans des cas pas si rares que ça.

Why Don’t Developers Take Accessibility Seriously?

… sur une site dont la mise en page est codée en dur sur une largeur de 600px, indépendant de la taille de la police par défaut dans le navigateur. La preuve par l‘exemple ?

Beau boulot, et en plus, c’est dans Debian. Je viens de l’installer, on verra si je me mets à l’utiliser. Pour le moment, j‘utilise fcitx-table-latex pour saisir des caractères mathématiques directement (et j’avais fait mon tout premier journal de mon expérience, moins bonne, avec ibus). Ces approches sont pratiques (pas besoin d’interrompre la frappe) mais beaucoup moins complètes que ce que tu proposes. Je suis donc assez certain de faire usage de ton outil, merci donc pour la découverte et pour ce développement !

L'encryption proposée par rclone est faite fichier par fichier […] moins bien qu'une encryption bloc par bloc.

C’est là la raison d’être de logiciels comme CryFS qui me semble bien rentrer dans la conversation ici mais avec lequel j’avoue avoir trop peu d’expérience pour juger de sa qualité.

Et rien n’interdit au plus aventureux de gratiner leur saumon-poireau au reblochon.

Peut-être est-ce une politique générale du genre « tu ne me dis pas -funroll-loops alors je ne déroule pas parce que ça ferait grossir le binaire

La taille du binaire n’est pas le seul critère. J’ai participé à une formation de chez Intel où les formateurs nous expliquaient qu’au gré des versions (récentes) ils avaient fait le choix d’être de moins en moins agressifs sur la vectorisation automatique, car elle n’est pas aussi performante que la vectorisation manuelle (ou assistée par des instructions manuelles). Il ne suggéraient pas de dérouler les boucles à la main, mais d’utiliser des directives OpenMP pour indiquer quelles boucles pouvaient/devaient être déroulées et optimisées avec des instructions SIMD etc. C’est possible que l’argument ait aussi été entendu (et appliqué) chez GCC qui attend donc (sauf options contraire sur la ligne de commande) des directives du développeur pour dérouler/vectoriser les boucles.

Ça me contrarie à titre personnel car il va falloir repasser sur tout mon code pour ajouter les directives OpenMP idoines, mais si à la fin c’est vraiment la bonne solution, ce travail ne sera pas vain et me fera peut-être gagner davantage que la vectorisation automatique (qui repose sur des heuristiques très pifométriques). Chez OpenMP, ils ont beaucoup bossé sur la question, et si tout le monde a les experts ont l’air de tomber d’accord, je suis prêt à me fier à ce consensus.

YunoHost tourne très bien derrière un reverse-proxy, mais c’est à toi de bien le configurer (le reverse-proxy, pas YunoHost). La seule difficulté (pas énorme mais à ne pas oublier), c’est pour la mise à jour automatique des certificats Let’s Encrypt, il faut bien t’assurer que le reverse-proxy redirige bien les “challenges” et que le proxy utilise les bons certificats (ou alors tout faire sur le proxy, sans passer par YH). Sinon, je ne vois pas ce qui te bloque. Effectivement, tu ne trouves pas la configuration toute faite parce-que YunoHost se veut gérer lui-même le reverse-proxy des services qu’il héberge et qui en ont besoin, mais si tu veux faire un truc exotique (avec des proxys les uns derrière les autres), ça marche et rien ne t’en empêche. Il faudra juste faire davantage qu’un copier-coller d’un exemple de configuration sur un forum en ligne, mais à ce stade tu es censé savoir ce que tu fais.

Je te laisse apprécier ce passage extrait d’un site que je trouve assez chouette :

Le programme peut être lancé en tant qu’utilisateur simple, puisqu’un utilisateur simple peut accéder en lecture aux périphériques d’entrée. D’ailleurs, si vous vous disiez que Wayland vous protégeait des keyloggers parce que ça isole correctement les applications entre elles, eh bien c’est raté, la couche d’en dessous se charge de donner les accès.

À ce jeu là, la qualité (au dépend de la quantité) des applications est encore supérieure sur F-Droid, et c’est le seul magasin d’applications disponible sur mon téléphone. Je ne vois pas en quoi faire payer protège du « Frontend pour pigeon » puisque ces attrapes-pigeons visent des retombées financières, et sont donc bien positionnés pour que leur équilibre coût/bénéfice soit maintenu malgré un ticket d’entrée payant pour le magasin d’applications. Si tu veux limiter les velléités de prendre les utilisateurs pour des pigeons, un magasin qui liste tes « antifonctions » (comme F-Droid) ça me semble avoir déjà plus de sens.

Non, il a son émission où il choisit qui il invite et organise des débats entre gens tous d’accords. Mon rasoir d’Ockham me dit que quand on choisit ses contradicteurs, il n’y pas besoin d’être particulièrement brillant. Avant, il était « sniper », c’est à dire le gars relou qui défonce les invités sur les plateaux télés sans réelle occasion de réponse de leur part, et face à des interlocuteurs qui ne sont pas venus pour ça (pour rappel quand il répandait ses idées racistes chez Ruquier, il y était en tant que critique littéraire).

1. Un OS est davantage qu’un noyau et une lib C. Maintenant, en remplaçant tous les outils GNU on peut refaire un système d’exploitation (en les prenant chez les BSD par exemple) et effectivement certaines distributions Linux pourraient se revendiquer non GNU. N’utilisant pas Void, je ne sais pas d’où viennent ses outils en espace utilisateur.

2. Ces expérimentations étaient effectivement intitulées « Debian GNU/Hurd » et « Debian GNU/kFreeBSD ».

3. Si tu remplaces Bash, binutils, coreutils, GCC, grep, etc, à un moment tu pourras ne plus utiliser d’outils GNU, mais clairement pas sur une Debian qui, même minimale, repose sur le « userland GNU ».

4. Tu fais ce que tu veux…

5. … mais si tu utilises Debian, alors il va falloir te faire à l’idée que tu utilises indirectement beaucoup de GNU. Ensuite la pertinence du nom dépend des raisons qui motivent le choix. En l’occurrence chez Debian, ce qui a permis de faire un système d’exploitation et une distribution autonome, c’était bien de combiner les outils GNU et le noyau Linux, d’où le nom « Debian GNU/Linux ». Aujourd’hui, Debian empaquette tellement de paquets d’origines variées que tu peux juger ce nom peu pertinent, en attendant si le nom reste c’est que GNU et Linux sont les deux briques essentielles qui ont permis à Debian d’exister, à la fois historiquement et encore à ce jour assez significativement d’un point de vue technique. Effectivement, depuis, il y a d’autres briques importantes qui sont entrées dans Debian, mais je crois qu’aucune n’a eu l’importance de ce qu’ont pu être (et sont encore) les projets GNU et Linux pour Debian.

Des pilotes sous Linux qui sont automatiquement téléchargés par le système quand on branche un périphérique et qui donnent un accès root sans demander de mot de passe ? C’est quand-même d’un autre ordre, sous Linux les pilotes sont soit dans le noyau, soit l‘installation manuelle exige de devenir administrateur et n’est pas automatisée. Ce qui rend le bug grave ici n’est pas tant le bug dans le pilote lui même mais la manière dont sont gérés (ou plutôt non gérés) les pilotes par le système sous Windows.

Ça n'est pas très compliqué à mettre en place en soit et bon j'ai pu l'observer.

Justement, que les attaques s’adaptent c’est une chose, mais en attendant, ça diminue fortement leur chance de succès. La force brute limitée à 10 tests par jour a peu de chance de trouver un mot de passe réellement utilisé, alors qu’en centaines ou milliers de tests par seconde, c’est autre chose.

Merci pour toutes ces réponses !

si tu penses que ça peut valoir le coup pour une entité, faut qu'on parle ;-).

Je suis sûr que ça vaut le coup, quant à valoir le coût, l’entité que je vois susceptible d’être la plus intéressée est la recherche publique et elle a bien peu de deniers à partager : tu risques d’être déçu par nos éventuelles discussions. Néanmoins, parler ne coûte rien et les chercheurs y passent leur temps :-)

FFV1 prend en charge les images en niveau de gris, YUV ou RGB, avec ou sans canal alpha (transparence), sans limitation du nombre de bits par composante (en pratique 8 à 16 bits par composante sont utilisés), de n’importe quelle taille

Si je comprends bien ta prose, il est aisé d’encoder des données de n’importe quel type donc ça pourrait s’adapter à des données scientifiques pour compresser des données usuellement sauvées en HDF5. Il reste quelques points qui méritent d’être éclaircis pour ça (j’avoue ne pas avoir lu la spec) :
- existe-t-il des encodeurs/décodeurs qui peuvent travailler avec un nombre de bits quelconque (ou à défaut de vraiment quelconque qui peuvent manger du 64 bits par composante) ?
- est-il possible (voire facile) d’encoder/décoder des données qui ont (parfois beaucoup) plus que trois composantes ?

Ce sont les deux limites que j’anticipe pour convertir un format de stockage de vidéo en un format de stockage de données tabulées générique. Sinon, effectivement, l’idée soumise par THE_ALF_ pourrait avoir un gros potentiel.

C'est une vision orientée système, et non orientée application.

En même temps, c’est justement l’intérêt d’un OS de proposer une organisation à une échelle plus large que l‘application, parce-que si tu veux des applis les plus autonomes possibles qui font ce qu’elles veulent et que tu peux mettre où tu veux, tu vas finir par trouver que DOS est l’OS qui te convient le mieux.

Non, mais ne t’inquiète pas, sudo demande ton mot de passe donc c’est sécurisé.