Adrien Dorsaz a écrit 952 commentaires

Je pense qu'on s'est tous fait "bousculer" un jour dans les commentaires […], suffit d'aller faire un tour, boire un verre d'eau, et réaliser qu'aussi passionantes soient les discussions sur DLFP ça reste essentiellement du hobby.

Je pense que tu soulèves un point très important et pas toujours facile à appliquer quand les sentiments sont à vif.

Il faut clairement apprendre à prendre du recul par rapports aux commentaires des autres sur Internet (et aussi par rapport aux systèmes de notation).

Un problème est que les silos à publicité comme les réseaux sociaux font leur beurre sur le fait de nous faire réagir très vite et de manière inconsidérée : ça leur fait plus de contenu, plus de pages affichées (et donc de pub) et plus de revenu au final.

Du coup ils forcent les gens à ne plus prendre de recul et quand ils arrivent ici, les utilisateurs ont l'impression que le karma est le point essentiel de LinuxFr.

Alors que non, bien au contraire: pour moi, LinuxFr n'est pas un réseau sociale, mais un site de partage d'informations (l'espace de rédaction collaborative est vachement bien fait !) et d'entre-aide.

L'essentiel est donc dans le contenu, pas dans le jugement des autres via le système de karma (par contre le contenu des commentaires fait parti du contenu créé par la communauté).

Bon, si j'ai bien compris tes commentaires, ce correctif devrait rendre plus lisible le site:
https://github.com/linuxfrorg/linuxfr.org/pull/248

Je me réjouis de voir un nouveau journal pour m'expliquer que les polices sont devenus trop énorme :D

Je ne te trouve pas assez ambitieux: l'user agent devrait faire lui-même les CSS pour tous les sites.

Oui, j'ai vu ce matin, ma question pour Zenitram et arnaudus est: est-ce que c'est bien de ce changement que tu parles ?

Si c'est ça, j'arrive à reproduire et je pourrais faire un correctif :-)

Est-ce que tu peux répondre à ce commentaire stp ?

Je n'avais pas vu la différence quand j'ai changé la police. Il semble bien que le rendu est un peu plus petit et du coup que les interlignes semblent plus grand.

Comme ça je peux voir si Zenitram et toi, vous parlez du même problème.

Dis-moi, le soucis de taille, est-ce que tu le vois dans cette comparaison (après / avant):

Si c'est bien de ce genre de changement que tu parles, je ne l'avais pas vu effectivement (même quand j'ai fait cette capture d'écran).

Si non, je ne suis vraiment pas capable de reproduire ton problème.

L'idéal serait de proposer le nouveau design d'un coup, oui.

Mais je n'ai pas le temps ni la motivation ni les moyens de tout faire. Même si c'était possible pour moi, ce n'est pas forcément le cas pour mjourdan et Bruno Michel.

On a déjà fait des tests pour l'espace de rédaction et c'est vite énorme les changements à mettre en place: https://github.com/linuxfrorg/linuxfr.org/pull/242

Pour moi, c'est beaucoup plus rassurant de casser ce bloc de modifications en plus petit morceaux. C'est plus facile à repérer les problèmes (autant système qu'utilisateur).

D'ailleurs, je n'ai qu'un écran avec densité de pixel non-élevée. Je ne peux donc ni reproduire ni corriger ce genre de bug.

Par contre la solution de PsychoFox me semble très pertinente :-)

Hier, j'avais oublié de mettre les polices alternatives système serif et sans-serif.

Du coup, quand on bloquait les polices web, tout le site était en serif.

C'est donc possible qu'il y aie eu des rendus avec des polices à empattement uniquement.

De rien, c'est amusant de bidouiller le code :-)

Merci à Bruno également pour les mises en production rapides !

J'avais oublié en effet de définir la police comme "cherche d'abord sur le disque, si non télécharge".

C'est corrigé.

Remarquez que la police n'est pas téléchargée à chaque chargement de page: le navigateur la garde en cache. Donc les 250 Kio et 0.5ms d'attentes, c'est 1 fois ;-)

Enfin, j'ai aussi ajouté les alternatives système (serif et sans-serif). On devrait être au top maintenant.

Oups, je me suis trompé dans tout le texte:

s/Lota/Lato/

désolé :)

Ton analyse est tout juste :-)

J'avais essayé avec "Lota Regular", pour avoir une idée, regardez le commentaire plus bas.

Hello,

J'essaie par petits pas de faire passer LinuxFr au nouveau design proposé par mjourdan, il y a déjà quelques temps.

Pour aller par petits pas, je voulais déjà changer les polices, car c'est déjà faisable avec le design actuel. J'ai bien aimé l'idée d'utiliser une police à empattement pour les titres et une police sans empattement pour les contenus.

Tu vois donc déjà, que, tout le site n'est pas à empattement au contraire de ce que pourrais faire penser ton journal. Ce que j'aime bien avec la police à empattement, c'est que le rendu permet de se passer du gras pour les titres, car la police et la taille les distingue bien du contenu.

Maintenant, c'est vrai que j'ai eu un doute quand j'ai installé la police "Lato Light" au lieu de "Lato". Le rendu tel que vous le voyez maintenant, est bien celui prévu (la couleur de la police est bien noir, mais la police est plus fine.

Lato Light	Lato

(Cliquez sur les images pour les télécharger)

Je trouve que Lato (Light ou non) est déjà plus lisible que la police "Sans" précédente, je distingue mieux les lettres personnellement.

En regardant ces 2 rendus, je trouve que les boutons et menus sont mieux avec "Lato Light" (surtout pour le pied de page). Je voulais donc proposer une solution ou on garde "Lato Light" pour le site en général, mais que l'on utilise "Lato" pour les contenus.

Tiens, tout ça mériterait un sondage pour avoir un avis globale :-)

PS: Pour tester en live ce que ça donne avec "Lato", il vous faut ouvrir la console web et remplacer "Lato Light" par "Lato" dans le style CSS.

Ça marche aussi avec les domaines dynamique du style dyndns ?

Je ne sais pas, je n'utilise pas ce genre de service. Je te laisse chercher.

Si la machine qui demande le certificat est sur un réseau A et le serveur DNS sur un réseau B qui gère le domaine (les deux étant relié par une liaison quelconque), ça peut fonctionner ?

Tant que ta machine sur le réseau A peut donner un ordre de mise à jour DNS au serveur le réseau B, oui.

L'autre condition est que la machine du réseau A puisse envoyer des requêtes HTTPS sur Internet pour communiquer avec le serveur ACME.

Non, mais tu a annoncés:

1. "J'utilise VPN pour connecter mes machines en direct"
2. "Je n'ai pas besoin d'HTTPS sur mes machines grâce à VPN"
3. "Je maîtrise l'utilisation de TLS, SSH, …"

Du coup, excuse-moi, mais j'en ai déduit effectivement que tu utilisais SSH entre tes machines.

Mais c'est vrai que tu ne l'as pas dit. Donc peut-être que tu maîtrises tellement ton VPN que tu utilises directement telnet entre tes machines. Ce serait au moins cohérent avec les autres phrases du style "il y a des risques de sécuriser les communications dans un tunnel sécurisé".

Franchement, je vais m'arrêter sur ce sujet tant que tu ne structures pas plus ce que tu nous dis et que tu places des phrases du genre "Pour un site censé être peuplé de gens callés, c'est fort kikoolol.". Ça m'attriste et, maintenant, j'ai même un peu peur du contenu existant dans le wiki de LinuxFr.

Ok, je vois, mais stp, arrête de dire que Let's Encrypt ne sait utiliser que du port 80 ou 443: c'est tout bonnement faux.

De souvenir quand tu utilises un port non standard, alors ce port est inséré dans le nom de domaine (par exemple HelloWorld.com:8666 et le certif n'est alors pas utilisable sans alerte pour HelloWorld.com).

Pour le challenge HTTP ("montre moi que tu peux poser un fichier sur un serveur web accessible avec ce domaine"), oui, c'est bien le port 80 qui est requis et ce simplement pour prouver que tu maîtrises l'infrastructure Web du nom de domaine.

Tu peux utiliser le challenge DNS ("montre moi que tu peux créer une ressource DNS pour ce domaine"), eh bien, c'est le port 53 qui est utilisé.

Pour l'instant, ces 2 challenges sont les seuls disponibles et donc les ports 53 et 80.

Si tu veux pouvoir créer des certificats tu dois donc nécessairement avoir un de ces 2 ports accessibles sur Internet, si non, ça veut dire que tu n'es pas capable de prouver que ces domaines t'appartiennent.

Serait-ce utilisable pour jean-kévin qui voudrait sécuriser l'accès à la WEBUI de sa seedbox Deluge ?

Je ne sais pas ce qu'est une seedbox Deluge, mais si tu es capable d'y associer un nom de domaine oui, tu peux la sécuriser par une des 2 techniques proposées par le protocole ACME.

Mon outil, acme-dns-tiny, par exemple nécessite une machine avec un service DNS qui est capable de faire de la mise à jour dynamique des ressources DNS grâce à TSIG. Sur une autre machine (ta seedbox par exemple), tu as juste besoin d'avoir python3 (avec les modules dnspython et requests) et openssl d'installé. Tu peux voir la documentation pour configurer ta seedbox et le serveur avec bind9 dans le wiki.

Cet outil, n'est pas le seul à savoir faire des certificats avec le challenge DNS, je te laisse chercher sur le web celui qui te convient le mieux.

---

Pour la partie certificats auto-signés, je vois donc que ce n'est pas facilement cassable si tu sais gérer les certificats installés sur tes machines (donc en les pré-installant sur les machines concernées pour ne pas avoir à faire des comportements dangereux comme "accepter par défaut tous les certificats auto-signés"). Et comme ce serait pour utiliser dans un réseau local, ça devrait le faire assez facilement et donc l'excuse "j'utilise un VPN" n'est pas du tout un bon argument.

Note d'ailleurs que SSH a exactement le même défaut si tu n'installes pas les clés de l'hôte dans des ressources DNS sécurisées par DNSSEC: tu dois manuellement vérifier les fingerprint des certificats utilisé par SSH.

Ok, je vois, mais stp, arrête de dire que Let's Encrypt ne sait utiliser que du port 80 ou 443: c'est tout bonnement faux. D'ailleurs avec le challenge DNS, Let's Encrypt n'a même pas besoin d'accéder à tes machines autres que celles qui gèrent tpn service DNS.

Perso, même si c'est pour du réseau "local", je ne ferais quand même rien passer en claire, car tu ne peux jamais être sûr de la santé des machines connectées au réseau.

J'ai voulu confirmer cette affirmation avec Stack Overflow et la réponse rappelle d'ailleurs qu'ARP est facilement cassé et donc qu'une machine malveillante peut "piquer" ton IP.

J'ai vu sur StackOverflow également que tu peux faire des certificats autos signés pour des adresses IP.

Pourquoi dis tu que les communications avec certificats auto-signé sont facilement cassées ? Est-ce aussi simple que l'ARP spoofing ?

Enfin, depuis le début, on parle de Chrome et de Firefox pour la désactivation d'HTTPS: ce sont des outils destinés au grand publique et je comprend bien qu'ils se sentent obligés et responsables d'activer le HTTPS partout. Surtout avec les possibilités offertes par ACME. Maintenant tu nous parles de curl, qui lui, clairement est un outil de technicien et aurait très peu de raisons de désactiver HTTP.
As tu vraiment besoin de Firefox ou Chrome dans ta situation qui n'est pas "grand publique" ?

J'ai l'impression que tout ces cas de figures sont mélangés dans tes commentaires et que c'est pour ça que l'on a de la peine à s'entendre…

Pour Let's Encrrypt, il faudrait arrêter de dire qu'ils ne veulent que communiquer sur le port 80 et 443. C'est un des différents moyens d'automatiser la gestion des certificats.

Un des autres moyens que je pense assez bien connaitre est l'automatisation par la preuve de gestion de resources DNS. C'est hyper utile pour gérer ses serveurs, entre autre grâce à la mise à jour dynamique des resources DNS bien gérée par bind9 (entre autre, je ne connais pas les autres) et l'utilisation des CNAME.

J'entend bien l'argument de la flemme pour mettre en place HTTPS, mais je t'avouerai que ça me ferait poser de sacré doutes sur la gestion de la sécurité du chiffrement de tes autres services comme le VPN.

En plus, si tu te plante sur la config du VPN ou des plages IPs autorisées, le trafique réseau passe alors en claire et ca c'est un risque réel et pas "potentiel".

J'avais déjà lu ce genre d'article et oui le texte fonctionne bien pour le choix général de la langue du site. Ça fonctionne parce que ça n'apparaît qu'à un ou deux endroits en dehors du contenu.

Mais là, je pense qu'il faut avoir une meilleure propisition en terme d'interface utilisateur: dans le cas des liens des dépêches, on va avoir 6-8 fois le texte (fr) ou (en) affiché, donc ça va alourdir la section "Aller plus loin".

Par exemple, on peut simplement enlever complètement le drapeau et utiliser un attribut HTML du style alt ou title pour préciser la langue.

On pourrait aussi faire des sous-sections "En français", "En anglais" dans la section "Aller plus loin".

Tiens, je viens d'avoir cette idée de sous-sections, il faut que je teste à mon retour de vacances.

Hello,

Étant Suisse, je vois bien le problème, mais je trouverai assez moche d'ajouter du texte comme (fr) derrière les liens.

De mon point de vue, ce n'est pas évident que ces 4 caractères désigne la langue du texte derrière le lien.

Tu aurais une idée ou un exemple de design qui évite l'utilisation des drapeaux ?

As you might know, enabling the snap plugin also enables the "Snap
Store" which seemingly violates the same rules which prevent us
installing Flathub by default (enabling access to nonfree software,
and software with patent restrictions). Without the Snap Store the
snap support is pretty useless, as snapd is so tied to the snapcraft
ecosystem, and because you can't actually run your own instance of the
snap store, unlike Flatpak.

L'emphase est de moi et ça me paraissait assez claire: snap est bien trop lié à snapcraft (le store d'Ubuntu si j'ai bien compris) et du coup, ce n'est pas utilisable avec un autre store.

Richard Hugues est bien un des auteurs de Gnome Software et, vu les arguments qu'il donne pour le retrait de Snap dans le Gnome Software de Fedora, j'imagine que ce sera pour actif ensuite pour Gnome Software directement (l'emphase est de moi à nouveau):

The existing snap plugin is not very well tested and I don't want to
be the one responsible when it breaks. At the moment enabling the snap
plugin causes the general UX of gnome-software to degrade, as all
search queries are also routed through snapd rather than being handled
in the same process. The design of snapd also means that packages just
get updated behind gnome-software's back, and so it's very hard to do
anything useful in the UI, or to make things like metered data work
correctly.

Il dit clairement que Gnome Software ne sert pas à grand chose quand Snap est utilisé, que c'est mal testé et qu'il ne veut pas être responsable le jour où ça sera cassé (dû au choix d'Ubuntu de faire son propre application pour accéder au Snap Store).

Cette remarque me vient de Richard Hugues qui maintient GNOME Software: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O4CMUKPHMMJ5W7OPZN2E7BYTVZWCRQHU/

Dans ce mail, il explique pourquoi également il souhaite retirer le support de Snap dans GNOME Software.

De ce que j'ai vu:

Snap permet d'installer tout type de logiciel alors que Flatpak se limite aux applications pour Desktop. Snap peut donc être utilisé sur des serveurs comme alternative à Docker par exemple.

Snap n'a qu'un seul dépôt centralisé: celui fournit par Canonical et le client ne fonctionne qu'avec lui. Flatpak est capable d'utiliser plusieurs dépôts et il est possible de créer son propre dépôt.

Flatpak utilise OSTree comme gestionnaire de version des runtime. Je ne sais pas si Snap sait aussi faire du téléchargement différentiel.

Ubuntu souhaitait, avant de détruire son développement pour tablettes, proposer un système d'exploitation en lecture seul Ubuntu Core avec le minimum d'outils. Tout le reste devait provenir des Snaps.

Fedora a une même idée avec Silverblue comme OS et Flatpak pour les applications.

Si j'ai bien compris, la GPL n'est pas une licence, mais un copyright.

Du coup, le titre devrait être : "une violation de droit d'auteur est une rupture de contrat et non pas une contrefaçon"

Il me semble qur ça détruit la notion de contrefaçon et que du coup on peut faire tout ce qu'on veut avec toutes les oeuvres xD

PS: je ne suis pas juriste et je n'ai lu que le titre du journal ;-)