Adrien Dorsaz a écrit 940 commentaires

Le livre n'a pas besoin de rétro éclairage à ce que je sache…

Et justement, les liseuses électroniques non plus, grâce à l'encre électronique.

C'est d'ailleurs le "seul" intérêt d'acheter ces machines à la place d'une tablette ou d'un smartphone (l'écran est lisible sans rétro-éclairage et nécessite beaucoup moins d'énergie).

Tiens, la lecture rapide m'a fait lire « travailleuse ». D'ailleurs j'ai dû relire 2 fois ton commentaire pour le comprendre et je m'était dit qu'un féminin tout seul dans ces propos était étrange.

La méthode avec les points centrés bloque la lecture fluide et cette méthode échoue fasse à la lecture rapide… ce n'est pas très efficace.

Bah, s'il en faut au moins un, voici le GTA04.

C'est un téléphone de bidouilleur (tinkerphones, le nouveau nom de la communauté OpenPhoenux autour de cet engin et de quelques autres). Son bootloader est libre, compilable, remplaçable et peut gérer plusieurs OS sur une même carte uSD. Il est encore en cours de production (une dernière production est en cours ou va bientôt commencer, le temps que les composants soient en stock chez le fabricant).

Le constructeur fournit les moyens de modifier tous les logiciels. Il fournit lui-même une version en test de Replicant avec le blob binaire wifi. La communauté Replicant a elle-même une version sans blob binaire (excepté celui du GSM, comme d'habitude).

PS: dans ces téléphones bidouillables, il y a également le Neo900, mais je n'ai pas trop suivit où en était le projet et si Android sera utilisable avec.

Merci pour les retours.

En effet, je n'ai pas pensé à mettre l'information sur les ressources DNS vérifiées, je vais l'ajouter car c'est très important pour correctement configurer son serveur DNS.

Pour l'update-ploicy, je vais aussi le mettre à jour dans l'exemple d'utilisation avec bind9. J'ai cherché un moyen pour créer une règle du style wildcard _acme-challenge.*.example.com, mais ce n'est pas possible.

Du coup, comme j'avais le nez dans ce problème, je n'ai pas pensé à chercher des solutions plus simples. Le problème de self est qu'il oblige à utiliser des CSR avec un seul domaine (et donc de faire un CSR et une configuration acme-dns-tiny par domaine à vérifier).

Je pense que je vais plutôt montrer un exemple de ce style:

key "_acme-challenge" {
    …
};

zone "example.com" {
    type master;
    file "example.com.zone";
    update-policy {
        grant _acme-challenge name _acme-challenge.example.com TXT;
        grant _acme-challenge name _acme-challenge.www.example.com TXT;
    };
};

C'est un peu moins rapide à mettre en place que zonesub s'il y a beaucoup de sous-domaines à vérifier, mais c'est beaucoup plus sécurisé car les autorisations sont restreintes au minimum.

Merci pour SIG(0), je ne connaissais pas ce protocole. Malheureusement, le module dnspython que j'utilise ne l'implémente pas : https://groups.google.com/forum/?hl=fr#!topic/dnspython-users/ZnssFZlA48o

Je répondais surtout à la phrase:

rigolo de voir que quand Apple fait c'est mal mais quand Mozilla fait c'est bien.

Tu ne peux pas dire que Mozilla fait la même chose qu'Apple.

Le premier laisse clairement utiliser son logiciel sans DRM, à la condition de le reconstruire ou d'utiliser une version instable. Le second ne laisse aucun choix.

Et je ne porte pas de jugement sur "mal" ou "bien", c'est surtout 2 cas différents.

Aux dernières nouvelles, Apple empêche d'installer une version alternative de magasin d'application et empêche la recompilation d'iOS pour enlever ces limites.

Ou même sortir ton iPhone, ton windows phone, ton Samsung, ton Sony, ton Tizen, ton OpenMoko, ton N900, ton Open-C, ton n-ième phone à 100€ … et commencer à coder des clients « natifs » pour chacune de ces plateformes (et racheter les nouvelles versions à chaque fois, n'oublie pas d'acheter les licences de développement [pour ton portable et le serveur d'intégration] et d'utilisation des Store).

Franchement, un client natif pour Movim ne peut apporter beaucoup plus que le site Web, si ce n'est une intégration au système de notification et de cache de l'environnement. Mais même pour ces 2 points les navigateurs web modernes sont déjà capable de bien s'intégrer.

Ce qu'il faut surtout comprendre, c'est que Movim est une interface à XMPP, tout le travail de serveur est fait par XMPP (Pubsub, Carbon, MAM, …). En plus, la structure de Movim est telle que le navigateur web a un minimum de travail à faire, car c'est le daemon de Movim qui se charge de communiquer avec les serveurs XMPP (si j'ai bien compris, les parties clientes nécessaires à XMPP sont aussi gérées par le daemon).

Du coup, je vois mal ce que peut apporter un client "natif" en plus sur un téléphone ou une tablette. Mozilla a déjà prouvé que les technologies web pouvaient être utilisées pour faire un système d'exploitation complet pour smartphone (bien que Firefox OS n'a pas eu le succès escompté, des téléphones fonctionnent avec leur système).

PS: J'ai oublié de dire qu'il semble possible pour le EEEPC 900 de changer le disque (voir ifixit). Il faudrait voir si le EEEPC 700 a aussi le disque sur une carte externe où s'il est soudé directement sur la carte mère…

Mais ça ne règlera pas le problème du CPU et du GPU.

Si je me souviens bien, le EEEPC 700 a aussi un lecteur de carte SD. Vu que ça se fait pour les Raspbery Pi, j'essaierai de faire une installation sur une carte SD (attention à choisir un modèle compatible, donc du SD normal, pas HC ni XC je pense, il faut vérifier la spécification des différents modèles). Pour faire l'installation, ça devrait jouer de démarrer l'installateur sur une clé usb et de sélectionner la carte SD comme disque de destination.

J'utilise encore un EEEPC 900 (le modèle suivant) qui avait un disque SSD de 20 Go et 1 Go de RAM. J'avais demandé à Asus et ils m'ont dit que l'on pouvait au maximum mettre 2 Go de RAM pour ce modèle, j'espère que tu pourras mettre aussi 2Go de RAM avec les spécificités du modèle 700.

J'ai donc pu installer Debian sid/unstable avec la version minimale netinstall et y ajouter le bureau LXQt (le renouveau de LXDE) avec OpenBox et Firefox.

J'utilise ce pc principalement en nomade dans le train avec une connexion Edge/3G/HSPA et j'ai en général un terminal avec SSH d'ouvert et 1-2 onglets dans Firefox. Ça va pour lire un peu de doc sur le web, lire des blogs et administrer mon serveur, mais je n'essaierai pas de lire des vidéos sur le Web, car les transitions entre Firefox et le terminal sont déjà lentes.

Je viens de vérifier et glxinfo me dit que mon eeepc sait faire uniquement de l'OpenGL 2, malgré ma Debian très à jour et qui devrait permettre de faire de l'OpenGL 3. En même temps, c'était les premières générations de GPU Intel, donc on ne peut pas trop en demander.

Comme j'ai 2Go de RAM et un SSD de 20 Go, je pense que ce qui ralentit le plus la machine est le processeur 32 bits à 900MHz et sa faible capacité graphique.
Du coup, 700MHz devient vraiment très peu à mon avis.

Pendant 2 ans, j'avais utilisé cette machine comme serveur mail/web et là, ça fonctionnait plutôt bien, j'en étais assez content. Je pense que ça pourrait aussi être une piste d'exploration comme recyclage de la machine.

Apparemment, ça devrait être la version 3.14:

nautilus (1:3.18.4.is.3.14.3-0ubuntu4) xenial; urgency=medium

Ubuntu avait décidé de ne plus suivre les changements de Gnome sur Nautilus lorsque Gnome a complètement revu le code.

Ce qui est dommage, car récemment (je ne sais plus si c'est sur la 3.18 ou 3.20), Gnome a modifié justement la manière de renommer les fichiers pour utiliser des Popover avec une validation du nouveau nom à la volée (et éviter un message de dialogue en cas d'erreur).

Pour pouvoir aider, il faudrait savoir comment se passe la modification du nom du fichier. Est-ce qu'un popover est affiché ou est-ce simplement le nom qui est édité directement dans la sélection ?

Edit: ah, finalement, c'est pour une autre raison qu'Ubuntu n'a pas suivi les versions actuelles (d'après le même changelog):

• Revert to the previous serie, the new one is going to need more work which is not going to be done this cycle (some issues/regressions are being handled upstream in 3.20 but we can do that update with our GTK version, also the new copy dialog is a bit much of a change and upstream confirms it's creating problems that they try to address with more UI changes) (lp: #1541954)

Peut-on coupler une IPv6 fixe sur le réseau local avec une IPv6 temporaire/dynamique pour les communications internet?

Tiens, je ne sais pas si l'auto-configuration IPv6 exclue la configuration statique de certaines adresses, mais je pense que les deux peuvent être utilisés sur une même machine (en tout cas, la configuration automatique et DHCPv6 sont clairement indiqués comme complémentaires dans l'introduction de la RFC 4862).

Par contre, il faut bien comprendre avec IPv6 qu'il n'y a plus de nécessité d'avoir un réseau local entre les machines d'un même réseau. Comme elles ont toutes leurs propres adresses publiques, autant utiliser celles-ci directement.
Il existe bien le réseau local avec le préfixe fe80:: pour pouvoir débuter les communications entre le routeur et les membres du réseau et il peut être utilisé pour communiquer entre membres du réseau, mais je ne pense pas qu'il apporte plus d'avantages que le réseau publique.

Pour protéger les machines du réseau, c'est un firewall qu'il faudra configurer correctement afin de ne pas exposer directement toutes les machines directement sur Internet.

Par exemple j'ai un service web accessible depuis internet à travers un reverse proxy apache2 (qui a besoin d'une ip fixe*1) et directement via Tor Hidden Service (pour qui une IPv6 dynamique serait un meilleur gage de sécu*2)

Dans ce cas, les RFCs de cette dépêche gardent le concept d'adresses IP stables pour les fonctionnalités de type serveur.
Typiquement, apache2 n'écoutera pas les adresses IP temporaires, mais uniquement les adresses stables.
La première RFC indique bein que c'est pour les communications sortantes qu'il faut utiliser de préférence les adresses temporaires

L'idée de la seconde RFC de la dépêche est de dissimuler un peu plus les adresses stables: au lieu de restreindre les suffixes à l'utilisation de la plage d'adresses MAC, la RFC propose d'utiliser toute la plage disponible (tout en gardant cette adresse stable sur le réseau). Ainsi, un attaquant qui voudrait trouver les fonctionnalités serveurs d'un réseau devra scanner une plus grande plage d'adresse IP (ou passer par un autre moyen).

Pour Tor, je ne connais ce réseau que de nom, mais il faudrait pouvoir avertir dynamiquement le service Tor quand les adresses IPs actuelles vont devenir obsolètes et transmettre les nouvelles adresses IPs lors de leur création.

PS: merci pour la dépêche intéressante :)

Merci aussi à la communauté LinuxFR de m'avoir relancé 2-3 fois pour la terminer :) Ça faisait 6 mois qu'elle traînait dans l'espace de rédaction ^^

C'est ce qu'utilise random.org. Je me suis toujours demandé si au fin fond d'un datacenter c'était une source fiable et abondante ?

Mmmh, c'est une bonne question. Pour mon besoin, ça va très bien car ce serait pour une machine dans mon appartement et comme il y a pas mal de réseaux sans fil dans l'immeuble et les immeubles voisins, ça devrait bien marcher.

Cependant, OneRNG permet de configurer quelles sources utiliser (soit une, soit l'autre, soit les deux).
Donc, si on ne fait pas confiance à l'environnement radio du data center, on peut utiliser uniquement l'« avalanche diode ».

Le end to end ne peux pas être maintenu avec des NATs: il faut pouvoir répondre au cas d'usage du commentaire de Xavier Claude, plus haut.

Le NAT44 permet aussi de faire de la correspondance m à n, mais l'usage est d'avoir m=1 (car le problème résolu avec NAT est le nombre d'adresses disponibles).

Le NAT64 permet de réduire la taille du n de manière plus raisonnable, puisque tu souhaites cacher ton réseau interne et surtout que le principal avantage de l'IPv6 n'est pas maintenu (le end to end).

La RFC propose en effet que la durée d'utilisation de l'adresse temporaire par la machine soit de 1 jour, mais c'est configurable.

Je pense que l'on se bat contre une chimère : vouloir des connexions end to end avec de la confidentialité de la structure réseau à chaque point. De plus, une écoute active du réseau permettra toujours de pouvoir tirer des informations avec les statistiques avec plus ou moins d'incertitudes.

Ce qui me plaît avec ces RFCs, c'est que ça garde possible l'utilisation du end to end tout en améliorant la confidentialité des activités de la machine à postériori. La RFC propose de créer des plages d'adresse temporaire, donc les logs du serveur X générés par le client A à l'instant T peuvent être différents des logs du serveur Z au même instant T. Ça dépend uniquement de la gestion des adresses par le client et c'est déjà disponible en pratique.

Merci, on est bien d'accord sur le fonctionnement d'un routeur (même d'un switch en fait).

Je ne comprends vraiment pas ce qu'apporte de plus un NAT66 à la place des adresses temporaires.
La seule différence que je vois est que la table de correspondances du NAT serait publique à un certain moment avec les adresses temporaires.

Si tu souhaites absolument garder cette confidentialité du NAT, pourquoi ne pas faire plus simplement du NAT64 ?
Ça impliquera des tables de correspondances beaucoup plus petites que du NAT66. De toute façon, si tu souhaites "cacher" ton réseau derrière un NAT autant garder une structure réseau IPv4, puisque les avantages de l'IPv6 seront perdues (plusieurs adresses IP atteignables de l'extérieur du réseau par machine).

Avec les adresses temporaires il est toujours possible de récupérer de l'information qui était plus difficile à extraire avec du NAT44 comme par exemple le nombre de machines internes.

Désolé, mais je ne vois pas comment on retrouve le nombre de machines internes par les adresses temporaires utilisées. Toutes les machines ne se connectent pas en même temps sur Internet et n'ont pas une connexion permanente.

Qu'est-ce qui peut te confirmer ou infirmer que l'adresse X utilisée il y a 3 minutes appartient à la même machine que l'adresse Y utlisée actuellement ? Si tu arrives à me répondre, alors il faut proposer une correction de la RFC, car l'algorithme prévoit que la prochaine adresse utilisée ne peut pas être devinable par quelqu'un d'extérieur.

Pour la mascarade, je ne comprends toujours pas quelles sont les avantages d'avoir des adresses internes et externes ? Que cherches-tu à cacher / protéger ?
Comment penses-tu que les outils de P2P fonctionnent actuellement si la machine était vraiment "cachée" par une mascarade ?

L'idée proposée est bien d'utiliser la TOTALITÉ de la plage disponible en attribuant aléatoirement une IP non-utilisée pour empêcher justement la connaissance du nombre de machines. Cela peut se faire sans trop de ressource par le routeur, un générateur de nombre aléatoire suffit (la probabilité que le générateur sorte 2 fois la même IP sur deux connexions sortantes en cours est extrêmement faible ), pas de gestion de collisions à se soucier car seul le routeur attribue les IPs externe.

Évidemment, puisque l'on ne serait plus dans le cas d'un réseau auto-configuré. Ces 2 RFCs ne traitent que des cas de réseaux IPv6 auto-configurés (avec un préfixe réseau suffisamment petit).

Ce que tu décris là, n'est pas une configuration de routeur, mais un serveur DHCPv6, si j'ai bien compris. Ça ne nécessite quand même pas de NAT et de mascarade pour pouvoir fonctionner, mais ça demande plus de travail sur la structure du réseau.

L'entropie disponible est une estimation de la disponibilité des nombres aléatoires.

Le commentaire au dessus a un lien sur un bon article qui explique ça avec la différence entre /dev/random et /dev/urandom.

Pour l'interface graphique, je ne suis pas sûr.

Dans l'article, ils parlent des paramètres ipv6.ip6-privacy, pour les adresses temporaires (je pense que la capture d'écran correspond à ça), et ipv6.addr-gen-mode, pour les adresses stables opaques avec la valeur stable-privacy.

Pour être sûr, j'ai regardé sur ma Debian dans le dossier /etc/NetworkManager/system-connections et j'ai trouvé cette section dans le fichier de configuration de mon réseau:

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=2
method=auto

NAT est un protocole qui est utilisé pour pallier au manque d'adresses IPv4 disponible.

En IPv6, tout un chacun pourra utiliser énormément d'adresses, il n'y a donc plus besoin de résoudre ces anciens problèmes.

La question serait plutôt: pourquoi penses-tu avoir absolument besoin de la complexité du NAT ?

Si c'est pour une question de réseau "privé", alors les 2 RFCs de cette dépêche proposent des solutions tout à fait viable qui garantissent la même vie privée qu'avec l'utilisation de NAT.
De plus, leur solution ne complexifie pas la gestion de la structure du réseau, puisque ce sont les appareils du réseau qui les activent.

Si c'est une question de protection contre des attaquants, alors la solution est la configuration d'un Firewall à l'entrée de ton réseau. Il suffit de définir les bonnes règles (interdire par défaut le trafic entrant initié par l'extérieur) et le réseau sera aussi bien protégé qu'en IPv4.

Alors quel dogme l'empêche à chaque connexion sortante de la machine X du réseau local vers les nets de tirer au hasard une IP Y dans sa plage et faire une masquarade de Y vers X le temps de la connexion ? C'est beaucoup plus simple que du NAT44.

Je ne vois pas bien l'intérêt de cette solution : ça fera juste croire que la machine X a l'adresse Y, mais ça ne changera rien par rapport à la confidentialité et ça demandera plus de travail au routeur (maintient d'une table de correspondance des adresses "réelles" avec les adresses "montrées"). Quel est l'intérêt de ne pas montrer l'adresse "réelle" ?

Ici, les propositions sont que chaque machine du réseau change régulièrement elle-même ses adresses, ça revient au même que ta proposition et ça ne complexifie pas la structure du réseau.

Hello,

J'ai les 2 protocoles sur mon réseau et j'utilise l'extension Firefox SixOrNot pour avoir une petite idée de ce qui est disponible en IPv6.

Personne ici ne pourra répondre à ta question s'il est effectivement en IPv6 seulement: LinuxFR n'est connecté qu'à IPv4 ;)

Sinon, Google, Facebook et quelques autres gros sites sont disponible en IPv6, mais Github, par exemple, n'est disponible que en IPv4 (alors que Gravatar est disponible en IPv6).

Au niveau des services webs, c'est très disparate. Il faudrait déjà que les hébergeurs proposent des hébergements connectés aux 2 réseaux avant que ce soit utile (SixXS tient une liste des hébergeurs IPv6) et que les fournisseurs de strcutures de type "cloud" soient également compatibles.

Google tient des statistiques sur l'utilisation d'IPv6 par leurs visiteurs, ça à l'aire déjà de bien progresser de leur côté (depuis janvier, on est passé de 4% du trafic à 10% environ).

Oui, c'est bien une erreur qui s'est glissée. Je voulais bien dire au reste d'Internet.

Oui, c'est ça.

Pour la gestion des adresses, le protocole IPv6 prévoit déjà que toutes les adresses utilisées ne sont louées que pour un certain temps. Si je me souviens bien, il n'y a pas vraiment de limite maximale de temps par défaut.

Ici, pour les adresses temporaires, le respect de la RFC requiert juste que la machine connectée déprécie elle-même régulièrement la location de ces adresses et en calcule de nouvelles pour continuer d'utiliser le réseau.

Apparemment, le routeur pourrait avoir un ajustement si le mainteneur du réseau décide de refuser l'utilisation d'adresses temporaires (il faut bien que le routeur bloque le trafic de ses adresses). Sinon, si le mainteneur ne souhaite pas bloquer, il n'y aurait pas besoin d'ajustement.

Pour les adresses stables, c'est juste qu'au lieu d'utiliser uniquement l'adresse MAC pour trouver un identifiant d'interface, la machine doit créer une clé secrète et calculer l'identifiant pour chaque réseau auquel elle se connecte. Donc là non-plus, il n'y a pas besoin d'ajuster la structure du réseau.

C'est ce qui m'a bien motivé pour la dépêche quand j'ai lu l'annonce de Network-Manager: si le réseau IPv6 a été configuré pour que les machines se configurent automatiquement, il suffit d'activer ces options dans Network-Manager pour préserver un peu plus la vie privée des utilisateurs de la machine.

mon entropie disponible chute souvent¹

Un appel de note sans la note correspondante, c’est triste…

Ah oui, j'ai oublié de l'enlever. La note a été transformée en paragraphe dans le texte (celui à propos de mon dev actuel).

Par ailleurs, si le programme tape par défaut dans /dev/random (c’est le cas de dnssec-signzone il me semble), il ne faut pas hésiter à lui dire d’aller voir du côté de /dev/urandom.

Je peux confirmer que lorsque je fais un lsof /dev/random, je vois named constamment (de temps en temps un autre logiciel, mais ce n'est que quelques instants).

random-device The source of entropy to be used by the server. Entropy is primarily needed for DNSSEC
operations, such as TKEY transactions and dynamic update of signed zones. This options speci-
fies the device (or file) from which to read entropy. If this is a file, operations requiring entropy
will fail when the file has been exhausted. If not specified, the default value is /dev/random (or
equivalent) when present, and none otherwise. The random-device option takes effect during the
initial configuration load at server startup time and is ignored on subsequent reloads.
(documentation de Bind 9.9)

Merci, je n'avais même pas pensé que ça pouvait être configurable dans bind et le lien pour /dev/urandom est très intéressant !

Super, ils espèrent produire 1000 pièces pour le mois d'août 2016.

Si j'ai bien compris leur documentation, leur source est aussi une paire de transitors :

• 20V noise source
  • AP3015A boost regulator
  • back-to-back 3904 transistor noise

Par contre, je ne sais pas quelle est la différence avec la source correspondante de la OneRNG.

Il faut que je regarde la vidéo de la Debconf 16 chez moi pour comprendre.

Merci !

C'est un peu différent, puisque les versions de développements ont le second nombre impaire.
Dans une version de développement, on s'attend bien à ce que les patchs ajoutent/enlèvent des fonctionnalités.

Au moment de la release, ce sera bien une version 2.10.x (ou 3.x) qui indiquera bien que, depuis la dernière version stable, des fonctionnalités ont été ajoutées / enlevées. GNOME a le même genre de gestion de version et Linux l'avait aussi à l'époque.

Oui, mais je suis assez maladroit et je n'ai jamais appris à faire des soudures, alors je préfère ne pas tenter ce genre d'expérience :)