Alors, tout d'abord, je tiens à dire que l'on dit une espace insécable (au féminin), et non pas un espace insécable.
Ensuite, on utilise du markdown et le comportement observé correspond à la spécification de Markdown. Bref, ce n'est pas à proprement dit un bug, mais une spécification qui ne répond à tes attentes. La bibliothèque Markdown que l'on utilise est mal maintenue et difficile à modifier. Ça me paraît très improbable que quelqu'un fasse ce changement.
Par contre, il y a toujours la possibilité de mettre une espace normale entre la parenthèse fermante et le point-virgule et laisser LinuxFr.org transformer cette espace en une espace insécable.
Au sujet des attaques dites CSRF (Cross Site Request Forgery), il y a 2 moyens de s'en prémunir :
un jeton anti-CSRF dans les formulaires
vérifier l'entête HTTP Origin (quand il est disponible).
Rails fournit depuis très longtemps la première solution et un hack avait été mis en place pour aussi avoir la deuxième solution quand le jeton était absent. Depuis quelques versions, Rails fait les deux et j'ai donc retiré le code. J'ai ensuite testé avec curl, on pouvait bien poster sur la tribune sans le jeton.
Au sujet des cookies, ça fait longtemps que l'on a ces 2 cookies :
linuxfr.org_session est le cookie de session qui sert à authentifier l'utilisateur (et il contient le double du jeton anti-CSRF qui sert à la comparaison)
remember_account_token est un cookie persistant, qui n'est présent que pour les personnes ayant coché la case « Se souvenir de moi » à la connexion.
Quand quelqu'un ferme son navigateur, le cookie de session disparaît. La fois suivante, lorsqu'il revient sur le site, le cookie remember_account_token est utilisé pour recréer une nouvelle session et donc un nouveau cookie linuxfr.org_session.
Pour le problème pour poster sur la tribune, je n'ai pas compris précisément ce qui pose problème mais mon hypothèse principale est que les cookies de session ont été invalidés lors de la montée de version de Rails.
Ruby on Rails a une protection pour éviter les attaques dites CSRF (Cross Site Request Forgery). Cette protection se base sur un jeton envoyé via les formulaires. Il est également possible de s'appuyer sur l'entête HTTP Origin (quand il est disponible) pour détecter qu'une requête provient bien du site initial. C'est ce que le commit cité dans cette entrée de suivi faisait.
Depuis quelques versions, Rails a modifié son code et a intégré la vérification de l'entête HTTP Origin. Il n'est donc plus utile d'avoir ce hack. Pire, la documentation de Rails indique maintenant que c'est une mauvaise idée :
verify_authenticity_token()
The actual before_action that is used to verify the CSRF token. Don't override this directly.
Je n'arrive pas à reproduire la redirection vers img.linuxfr.org. Est-ce que cela se produit sous un navigateur particulier ? Est-ce pour une page spécifique ou pour toutes les pages ?
Ce n'est pas trop compliqué de passer du http au https ?
Le site propose depuis très longtemps du https. C'était à l'utilisateur de taper https://linuxfr.org dans la barre d'adresse de son navigateur s'il voulait accéder au https. Maintenant, nous avons mis en place une redirection de la partie http vers la partie https pour que les utilisateurs accèdent automatiquement en https au site (et il faut que je regarde pour mettre en place du HSTS).
Je suppose que cela concerne la page de rédaction d'une dépêche. Pour celle-ci, il y a toujours la liste avec les noms des contributeurs de la dépêche sur la ligne de méta-données de la dépêche (juste sous le titre). Et pour chaque avatar, il est possible de passer la souris dessus pour afficher le « title » qui donne le nom de cet utilisateur.
Pour les CSS alternatives, ma position est effectivement de ne pas vouloir les mettre en avant. Je me suis déjà posé la question de les retirer : pour le moment, je ne l'ai pas fait car en l'état, ça rend service à quelques personnes et ça ne me coûte pas grand chose de les laisser, mais si, dans le futur, on modifiera fortement le HTML du site et que cela casse les CSS alternatives, j'irais sûrement couper la fonctionnalité plutôt que passer du temps à réparer les CSS alternatives.
Concernant le suivi, et toujours conformément à ce problème de main d'œuvre, pourquoi maintenir le suivi plutôt que d'utiliser les outils fournis par la forge que l'on utilise ? C'est comme cela que fonctionne webcompat.com: ils ont un compte "bot" qui ajoute les bugs pour les non-membres de github.
Je ne suis pas sûr de bien comprendre cette proposition. Ça ne prend pas de temps de laisser les entrées dans l'outil de suivi actuel, alors qu'il faudrait prendre un peu de temps pour les envoyer sur github. Quel serait l'avantage de faire ça ?
D'ailleurs pour ce qui est de linuxfr-design, est-on censé utiliser le suivi ou bien reporter un bug sur github ?
Je laisse Mathieu répondre, peut-être qu'un commentaire sur cette dépêche peut aussi convenir.
Par ailleurs j'ai une PR qui moisit depuis 4 mois sans réaction aucune.
J'ai répondu dans l'entrée de suivi associée. Pour ma part, j'ai peu de temps à consacrer au site actuellement et je le partage entre l'espace de rédaction et le code. Pour la partie admin/sys, je laisse la main à mes collègues. A priori, ils n'ont pas non plus beaucoup de temps à consacrer au site et quelques autres sujets plus prioritaires. Par exemple, le certificat TLS expire dans quelques jours. Il faudrait le renouveler ou passer à Let's Encrypt, ce qui demande un peu de boulot (notamment parce que le certificat est également utilisé pour du SMTPS).
Je comprends bien, mais si je me lance dans la construction d'un serveur de build, que ça me prend plein de temps, que j'arrive avec mon truc et que vous me répondez « ah bah pourquoi t'as fait ça ? On a déjà un serveur de build ici… », ça ne va pas me motiver des masses :)
Perso, quand je contribue à des projets libres, je fais en général comme ça :
Pour des petits trucs, je fais et je propose ensuite (en sachant que de temps en temps, c'est refusé parce que ça ne rentre pas dans les plans du ou des mainteneurs).
Pour des contributions plus conséquentes, j'en parle avant : ça peut être un mail ou une entrée dans un outil de suivi. Je dis ce que je compte faire, comment et dans quels délais. J'indique que je suis prêt à en discuter si des personnes ont un peu de temps à y consacrer.
De ce que j'ai compris, le problème ne concerne pas trop Debian car on a plein de copies de chaque paquet, donc si on se retrouve avec une version corrompue, on peut facilement télécharger le même paquet depuis un autre endroit. L'auteur de l'article a plutôt l'air de parler de quelqu'un qui ferait des sauvegardes dans ce format : peu de copies et donc un risque plus grand de se retrouver dans quelques années avec juste une version corrompue. Et si on a une version corrompue, on risque de perdre beaucoup plus de choses avec xz qu'avec d'autres formats (ie pas juste un fichier dans l'archive qui est perdu, mais tout ce qu'il y a derrière aussi).
On a mis en place du rate limiting à cause d'un bot en Java qui fait à lui tout seul plus de requêtes que Google, Bing et les bots de tribune réunis. Le rate limiting se base sur le User-Agent et il se trouve que jb3 utilise le même user-agent que lui (même si c'est pas le bot en question, les adresses IP ne sont pas les mêmes). Du coup, je conseille de changer le User-Agent.
Cette entrée de suivi concerne un bug qui touche des utilisateurs du site. J'ai beau cherché, je n'arrive pas à trouver la cause de la désynchronisation entre les cookies et le token CSRF soumis en formulaire. Comme je n'arrive pas à reproduire, ce n'est pas facile à débugger. Mais je continue de chercher.
# Specifications
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi un lien déborde sur l'espace insécable qui le suit. Évalué à 3 (+0/-0).
Alors, tout d'abord, je tiens à dire que l'on dit une espace insécable (au féminin), et non pas un espace insécable.
Ensuite, on utilise du markdown et le comportement observé correspond à la spécification de Markdown. Bref, ce n'est pas à proprement dit un bug, mais une spécification qui ne répond à tes attentes. La bibliothèque Markdown que l'on utilise est mal maintenue et difficile à modifier. Ça me paraît très improbable que quelqu'un fasse ce changement.
Par contre, il y a toujours la possibilité de mettre une espace normale entre la parenthèse fermante et le point-virgule et laisser LinuxFr.org transformer cette espace en une espace insécable.
# Session invalidée ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Message d'intérêt public - reconfiguration nécessaire aux clients pour poster sur la tribune. Évalué à 5. Dernière modification le 26 juin 2018 à 18:45.
Au sujet des attaques dites CSRF (Cross Site Request Forgery), il y a 2 moyens de s'en prémunir :
Rails fournit depuis très longtemps la première solution et un hack avait été mis en place pour aussi avoir la deuxième solution quand le jeton était absent. Depuis quelques versions, Rails fait les deux et j'ai donc retiré le code. J'ai ensuite testé avec curl, on pouvait bien poster sur la tribune sans le jeton.
Au sujet des cookies, ça fait longtemps que l'on a ces 2 cookies :
linuxfr.org_session
est le cookie de session qui sert à authentifier l'utilisateur (et il contient le double du jeton anti-CSRF qui sert à la comparaison)remember_account_token
est un cookie persistant, qui n'est présent que pour les personnes ayant coché la case « Se souvenir de moi » à la connexion.Quand quelqu'un ferme son navigateur, le cookie de session disparaît. La fois suivante, lorsqu'il revient sur le site, le cookie
remember_account_token
est utilisé pour recréer une nouvelle session et donc un nouveau cookielinuxfr.org_session
.Pour le problème pour poster sur la tribune, je n'ai pas compris précisément ce qui pose problème mais mon hypothèse principale est que les cookies de session ont été invalidés lors de la montée de version de Rails.
# Non
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi La tribune ne permet plus aux clients externes de poster. Évalué à 3 (+0/-0).
Ruby on Rails a une protection pour éviter les attaques dites CSRF (Cross Site Request Forgery). Cette protection se base sur un jeton envoyé via les formulaires. Il est également possible de s'appuyer sur l'entête HTTP Origin (quand il est disponible) pour détecter qu'une requête provient bien du site initial. C'est ce que le commit cité dans cette entrée de suivi faisait.
Depuis quelques versions, Rails a modifié son code et a intégré la vérification de l'entête HTTP Origin. Il n'est donc plus utile d'avoir ce hack. Pire, la documentation de Rails indique maintenant que c'est une mauvaise idée :
# Autre demande similaire
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Fournir des données d'exemple. Évalué à 3 (+0/-0).
Cf https://linuxfr.org/suivi/dump-anonymise-de-la-base-de-donnees
# Autre demande similaire
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Dump anonymisé de la base de données. Évalué à 3 (+0/-0).
Cf https://linuxfr.org/suivi/fournir-des-donnees-d-exemple#comment-1320006
[^] # Re: http >> https
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un incident et des opérations de maintenance sur le site. Évalué à 3.
Oui, ça a l'air mais ça ne devrait pas. Je penche pour un bug de firefox (la prise en charge de SameSite est très récente) : https://bugzilla.mozilla.org/show_bug.cgi?id=1471137.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Impossible de faire une recherche. Évalué à 3 (+0/-0).
Merci pour le signalement. C'est corrigé, cf https://github.com/linuxfrorg/linuxfr.org/commit/b2dc2d3f80a4f21cbc239734a7157df7c67cb0bb
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Fonction recherche et filtrage du suivi. Évalué à 3 (+0/-0).
Merci pour le signalement. C'est corrigé, cf https://github.com/linuxfrorg/linuxfr.org/commit/b2dc2d3f80a4f21cbc239734a7157df7c67cb0bb
[^] # Re: Y'a pas que oauth.
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi API Oauth2 cassée?. Évalué à 3 (+0/-0).
Le daemon board plante toutes les quelques heures depuis hier, mais je n'ai pas encore réussi à trouver d'où vient le problème.
[^] # Re: http >> https
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un incident et des opérations de maintenance sur le site. Évalué à 5.
Je confirme, on avait testé HSTS à l'époque où LinuxFr.org avait un certificat cacert et ça donnait une page blanche sur la plupart des navigateurs.
[^] # Re: Ansible
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un incident et des opérations de maintenance sur le site. Évalué à 3.
Oui, mais il est privé pour le moment.
[^] # Re: redirection ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un incident et des opérations de maintenance sur le site. Évalué à 4.
Je n'arrive pas à reproduire la redirection vers img.linuxfr.org. Est-ce que cela se produit sous un navigateur particulier ? Est-ce pour une page spécifique ou pour toutes les pages ?
[^] # Re: http >> https
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un incident et des opérations de maintenance sur le site. Évalué à 9.
Le site propose depuis très longtemps du https. C'était à l'utilisateur de taper
https://linuxfr.org
dans la barre d'adresse de son navigateur s'il voulait accéder au https. Maintenant, nous avons mis en place une redirection de la partie http vers la partie https pour que les utilisateurs accèdent automatiquement en https au site (et il faut que je regarde pour mettre en place du HSTS).# Les noms sont toujours présents
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Affichage de l'avatar des contributeurs. Évalué à 3 (+0/-0).
Je suppose que cela concerne la page de rédaction d'une dépêche. Pour celle-ci, il y a toujours la liste avec les noms des contributeurs de la dépêche sur la ligne de méta-données de la dépêche (juste sous le titre). Et pour chaque avatar, il est possible de passer la souris dessus pour afficher le « title » qui donne le nom de cet utilisateur.
[^] # Re: Je me demandais…
Posté par Bruno Michel (site web personnel) . En réponse au message Internet par satellite - quels sont les FAI et lequel choisir ?. Évalué à 4.
J'ai retiré le lien vers la « page perso », qui n'a effectivement rien à faire ici.
[^] # Re: CSS Alternatives
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Refaire LinuxFr.org : résultats de l’enquête. Évalué à 4.
Pour les CSS alternatives, ma position est effectivement de ne pas vouloir les mettre en avant. Je me suis déjà posé la question de les retirer : pour le moment, je ne l'ai pas fait car en l'état, ça rend service à quelques personnes et ça ne me coûte pas grand chose de les laisser, mais si, dans le futur, on modifiera fortement le HTML du site et que cela casse les CSS alternatives, j'irais sûrement couper la fonctionnalité plutôt que passer du temps à réparer les CSS alternatives.
Je ne suis pas sûr de bien comprendre cette proposition. Ça ne prend pas de temps de laisser les entrées dans l'outil de suivi actuel, alors qu'il faudrait prendre un peu de temps pour les envoyer sur github. Quel serait l'avantage de faire ça ?
Je laisse Mathieu répondre, peut-être qu'un commentaire sur cette dépêche peut aussi convenir.
J'ai répondu dans l'entrée de suivi associée. Pour ma part, j'ai peu de temps à consacrer au site actuellement et je le partage entre l'espace de rédaction et le code. Pour la partie admin/sys, je laisse la main à mes collègues. A priori, ils n'ont pas non plus beaucoup de temps à consacrer au site et quelques autres sujets plus prioritaires. Par exemple, le certificat TLS expire dans quelques jours. Il faudrait le renouveler ou passer à Let's Encrypt, ce qui demande un peu de boulot (notamment parce que le certificat est également utilisé pour du SMTPS).
[^] # Re: compatibilité
Posté par Bruno Michel (site web personnel) . En réponse au lien Découvrir le nouveau moteur de synchronisation des favoris de Firefox nightly. Évalué à 3.
A priori, ça a l'air spécifique à Mozilla.
[^] # Re: Il y a un gros pb de markdown au milieu de l'article
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Partitions ext4 : ne gaspillez plus l’espace disque !. Évalué à 4.
Merci, c'est corrigé.
[^] # Re: quelques remarques
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Le Courrier du hacker, lettre d’information hebdomadaire résumant l’actualité FOSS francophone. Évalué à 2.
Je suppose que ça doit être les mêmes liens que sur les billets du blog : https://blog.journalduhacker.net/index.php?article161/liens-interessants-journal-du-hacker-semaine-19-2018 par exemple.
https://www.journalduhacker.net/rss
[^] # Re: Intégration
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche GIMP 2.10 roule au GEGL. Évalué à 10.
Perso, quand je contribue à des projets libres, je fais en général comme ça :
[^] # Re: Vieux débat (mais c'est dans les vieux débats…)
Posté par Bruno Michel (site web personnel) . En réponse au lien Le format de compression Xz serait « inadéquat pour l'archivage à long terme ». Évalué à 7.
De ce que j'ai compris, le problème ne concerne pas trop Debian car on a plein de copies de chaque paquet, donc si on se retrouve avec une version corrompue, on peut facilement télécharger le même paquet depuis un autre endroit. L'auteur de l'article a plutôt l'air de parler de quelqu'un qui ferait des sauvegardes dans ce format : peu de copies et donc un risque plus grand de se retrouver dans quelques années avec juste une version corrompue. Et si on a une version corrompue, on risque de perdre beaucoup plus de choses avec xz qu'avec d'autres formats (ie pas juste un fichier dans l'archive qui est perdu, mais tout ce qu'il y a derrière aussi).
[^] # Re: Individu⋅e⋅s ???
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Sauvons le partage de code ! Appel à signature de la lettre ouverte « Save Code Share ». Évalué à 6.
Corrigés ici aussi.
# Rate limiting
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Erreur 503 avec l'API https://linuxfr.org/api/v1/me. Évalué à 3 (+0/-0).
On a mis en place du rate limiting à cause d'un bot en Java qui fait à lui tout seul plus de requêtes que Google, Bing et les bots de tribune réunis. Le rate limiting se base sur le User-Agent et il se trouve que jb3 utilise le même user-agent que lui (même si c'est pas le bot en question, les adresses IP ne sont pas les mêmes). Du coup, je conseille de changer le User-Agent.
# Toujours d'actualité
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi 422 Unprocessable Entity (anti-CSRF). Évalué à 3 (+0/-0).
Cette entrée de suivi concerne un bug qui touche des utilisateurs du site. J'ai beau cherché, je n'arrive pas à trouver la cause de la désynchronisation entre les cookies et le token CSRF soumis en formulaire. Comme je n'arrive pas à reproduire, ce n'est pas facile à débugger. Mais je continue de chercher.
[^] # Re: Langue
Posté par Bruno Michel (site web personnel) . En réponse au lien [Python] Sortie de Flask 1.0. Évalué à 4.
Corrigé. Par contre, il y a aussi une dépêche en cours de rédaction, c'est un peu dommage de lui griller la politesse.