Adrien Dorsaz a écrit 940 commentaires

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 ;-)

J'ai oublié d'avertir, que la modification a été fusionnée avec cet autre PR.

E.T. peut enfin téléphoner maison

Ce suivi est donc à clore :)

L'introduction de cette dépêche semble faire la même erreur que dans sa sœur ce serait la huitième edition du Kernel Recipes et pas la neuvième :-)

D'ailleurs, je pense que l'introduction est un peu malheureuse, parce qu'elle ne nomme pas l'Embedded Recipes qui semble être le sujet ici ;-)

Ce n'est pas toujours facile de persévérer pour contribuer à un projet. Le temps disponible n'est pas infini.

Un point important pour moi est donc que je puisse monter facilement un environnement de développement pour pouvoir bidouiller.

C'est ce qui m'a plu avec le code en C d'HomeBank: le langage est assez simple ce qui permet de monter facilement mon environnement et de modifier le code rapidement.

Avec LinuxFr, j'ai eu pas mal de peine à réussir à monter correctement mon poste de développement (j'ai essayé plusieurs fois ces dernières années et c'est avec Debian Stretch que j'ai eu la meilleur expérience). Par contre, quand j'ai réussi à le monter, j'ai eu accès à toutes les facilités offertes par Ruby on Rails: un serveur web local, un outil de gestion des mises à jour debase de donnée, de configuration des routes…

En plus, Ruby on Rails est une communauté avec une bonne documentation de ce que j'ai vu, c'est un second point important :-)

Pour la partie web, je dois dire aussi que Mozilla fait un très bon travaille de documentation d'HTML, de CSS et de JavaScript. C'est un point dont on ne parle pas souvent, mais je tombe souvent sur la documentation de Mozilla et jamais sur celle de Chrome (alors que je cherche via Google ;)).

Enfin, j'ai la chance de pouvoir travailler à 80% (donc environ 33h/semaines sur 4 jours, en Suisse) ce qui me laisse plus de temps pour m'amuser à bidouiller :-)

De rien :)

Ah pour le ratio de l'image, je vois maintenant que c'est du 3:1 qui a été prévu avec un affichage à 900x300 pour les grands écrans. Du coup, je vais faire les formats 300x100, 600x200 et 900x300.

Si jamais, j'ai réussi à avancer sur ce sujet: j'ai enfin réussi sur mon poste de dev d'ajouter des images dans le template de rédaction et de permettre leur modification (sans verrou).

Je vais préparer une branche propre avec cette proposition:

1. Je ne traite que les images sur les dépêches
2. L'image et sa référence seront enregistrés dans la table news (et news_version) avec une colonne chacun
3. L'image sera transformée pour avoir un ratio de 3.5:1 (avec les rendus à 350x100 pixels, 700x200, 1050x300 et 1300x400 pixels)
4. Le rendu ne sera pas fait en MarkDown, mais directement en HTML5 depuis les informations de la base de donnée

Tout commentaire est bienvenu sur ces décisions :)

Ouh la la, je suis bien content dene pas travailler dans ce genre de milieu :-)

Franchement, refuser même les mises à jour de sécurité de Debian, c'est quand même de la folie…

Debian Jessie à Firefox ESR 60 de disponible: je te conseille de faire les mises à jour, c'est risqué de butiner avec un vieux navigateur ;-)

Hello,

Grâce à ce commentaire à propos des boutons de download, je me rend compte qu'avant de se lancer dans l'implémentation du nouveau design, il faut d'abord choisir quels navigateurs on souhaite supporter.

Pour Chrome, c'est difficile de retrouver les anciennes versions, Google force les mises à jour et ne supporte que la dernière version. Je propose de supporter la version Chromium de Debian oldstable (soit la version 57): https://packages.debian.org/search?keywords=chromium

Pour Firefox, je propose de faire la même chose puisque Debian utilise déjà les version ESR, on peut utiliser la version ESR de Debian oldstable (soit la version 60): https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=firefox-esr

Pour Android c'est beaucoup plus compliqué, car le navigateur par défaut dépend des mises à jour des constructeurs (jusqu'à la version Lolipop). Si les utilisateurs ont la version L et le Google Play Store, alors leur webview suit les mises à jour de Chrome. Pour les autres, il faudrait soit installer "Chrome pour Android", soit "Firefox".

Pour iOS, je ne pourrais même pas tester et du coup, je ne sais même pas ce que je pourrais imaginer comme "version minimale" :/

J'avais déjà prévu une correction pour IE, il devrait aussi corriger l'affichage de ces anciens navigateurs: à la place d'utiliser les grid de CSS, je joue simplement avec la désactivation du float que l'on utilisait avant.

Le pull request est disponible ici: https://github.com/linuxfrorg/linuxfr.org/pull/235

Non c'est le navigateur de base.

Pour Android, le "navigateur par défaut/de base" n'existe pas par exemple sur les smartphones Samsung, c'est un navigateur spécial fait par Samsung (qui est sûrement crée au-dessus du WebView d'Android, mais ça ne change pas grand chose à mon problème: je ne peux pas tester, je n'ai pas le matériel).

En plus, ce genre de navigateur pose des problèmes de sécurité à cause de certains algorithmes indisponibles (par exemple, certains algorithmes de TLS) ou des failles de sécurité jamais corrigées. D'ailleurs, Google a décidé de ne plus lier le "navigateur par défaut" à Android, mais de livrer "Chrome pour Android" pour que les mises à jours du navigateurs ne doivent plus attendre les mises à jours Android des constructeurs (qui sont quasiment inexistantes).

Est ce que les version ESR de Firefox fonctionnent toutes ? voilà ce qu'il faut trouver le temps de tester.

Qu'est-ce que tu entends par "les versions ESR de Firefox fonctionnent toutes" ?

Il n'y en a qu'une seule (voire 2 pendant quelques semaines de chevauchement): https://wiki.mozilla.org/Release_Management/Calendar.

Par exemple, pour Firefox ESR 45, cette version est sortie en 2016 et n'est plus supportée par Mozilla depuis la version ESR 52.2 sortie en juin 2017. Cette version est elle-même remplacée par le support de la version ESR 60.2 sortie en septembre 2018. Cette version actuelle ESR perd son support cet automne.

Si tu veux vraiment les supporter "toutes", la première version ESR est sortie en janvier 2012 ;-)

PS: tu peux cliquer aussi sur le tritre des éléments pour lire la suite.

pas compris

Pour lire les articles au complet, je voulais dire que le titre des dépĉhes/journaux/liens/entrées de forum est aussi un lien cliquable pour voir l'article complet.

Pour Android, je n'ai pas de version 4 ou 5 sous la main et il dépend du constructeur si je me souviens bien.

Pour Debian Jessie, je veux bien regarder, mais bon, Stretch est disponible depuis 2 ans et Buster sera bientôt dispo…

PS: tu peux cliquer aussi sur le tritre des éléments pour lire la suite.