Adrien Dorsaz a écrit 948 commentaires

Si je reprends la conversation que l'on avait eu au sujet de l'attaque par homoglyphe, l'intention est bien de cacher les identifiants numériques pour ne rendre visible que les slugs:

Oui on a fait disparaître la plupart des identifiants des 'accounts' et des 'users', ce n'est pas pour les remettre maintenant.

D'ailleurs la redirection semble bien faire ça: si tu essaies de trouver un utilisateur par un identifiant numérique, alors tu es redirigé vers son url avec slug.

Donc, je dirai que ce comportement est voulu puisque l'on ne veut pas spécialement rendre publique les ids de la base de donnée.

Pour aller (presque¹ ) au bout de cette idée de cacher les ids de base de donnée, on pourrait remplacer la redirection par une erreur 404 et n'autoriser l'accès que via les slugs.

On risque d'être un site moins cool, puisque ça va casser les vielles urls comme https://linuxfr.org/users/4, mais bon ça fait depuis 2011 que linuxfr.org répond avec des redirections permanentes (HTTP 301) vers les slugs :)

---

1: presque, parce que les identifiants sont visibles lors de l'upload de l'avatar et de la feuille CSS si on connaît l'algorithme de création des dossiers.

Faut-il mettre à jour la gem qui gère la production du slug et/OU le routage suivant le slug ? Changer la règle de production du slug (même si on change la production de slug pour ajouter XXX123 quand on ouvre le compte id 123, on aura toujours une collision si on ouvre un compte login XXX123 de toute façon…) ?

Alors la documentation de friendly_id stipule clairement qu'elle ne gère que la partie base de donnée. Le routage est géré manuellement.

Avec LinuxFr, par exemple pour le controlleur de user, c'est géré comme ça:

# encoding: utf-8
class UsersController < ApplicationController
  before_action :find_user

  def show
    path = user_path(id: @user, format: params[:format])
    redirect_to path, status: 301 and return if request.path != path
    find_nodes([News, Diary])
    respond_to do |wants|
      wants.html
      wants.atom
    end
  end

[...]

protected

  def find_user
    @user = User.find(params[:id])
    raise ActiveRecord::RecordNotFound.new unless @user
    @contents = @user.nodes.visible.by_date.limit(20)
  end

[...]

end

Depuis le paramètre id qui vient du path de l'url (/users/:id), on cherche l'utilisateur qui correspond avec User.find (id peut être soit un slug, soit un l'identifiant numérique de l'utilisateur).

Si le path de l'utilisateur trouvé ne correspond pas au path courant, alors on redirige. Je ne connais pas assez Ruby On Rails pour savoir comment est géré la fonction user_path, mais j’admets qu'elle fonctionne correctement.

La gem friendly_id modifie la fonction find (parce que l'addon :finders est activé dans friendly_id.rb):

FriendlyId offers enhanced finders which will search for your record by friendly id, and fall back to the numeric id if necessary.

C'est pour ça que l'utilisateur avec un slug numérique aura la priorité sur l'utilisateur qui a l'identifiant qui correspond au slug.

Voilà, j'ai préparé une pull request ici pour ajouter une colonne "last_seen_on": https://github.com/linuxfrorg/linuxfr.org/pull/370

La valeur est NULL tant que le compte n'a pas été confirmé (et donc aussi pour Anonyme et Collectif). Si non, ce sera la date de la migration, parce qu'on ne peut pas savoir précisément la bonne date à mettre.

Là, j'ai l'impression de perdre tous les avantages de Silverblue et de devoir gérer une distribution finalement comme si j'utilisais Fedora Workstation.

Je ne vois pas trop des avantages dont tu parles en fait, tu peux étayer ?

Si jamais, je n'ai pas beaucoup de recul, car ça fais moins d'une semaine que j'essaie Silverblue et toolbox. C'est justement pour ça que je demandais des retours :)

Je pose comme hypothèse que Fedora Silverblue amène plus de stabilité et de facilité pour les mises à jours par rapport à Fedora Workstation. Fedora Workstation amène plus de flexibilité et moins d'assurance pour la QA.

Si j'installe des outils dans toolbox, alors ceux-ci seront installés dans une distribution de type Fedora Workstation: beaucoup de flexibilité, mais moins de stabilité.

Comme j'utilise tous les jours ces outils, de mon point de vue, c'est comme si j'avais installé Fedora Workstation sur ma machine: mes outils quotidiens ne bénéficient pas de la stabilité et des mises à jour de Fedora Silverblue.

En y réfléchissant, je serai dans la même situation avec rpm-ostree finalement, puisque l'ajout d'overlays de paquets RPM réduit aussi la stabilité du système.

En conclusion, je pense qu'il serait mieux que j'utilise toolbox, parce qu'il permet au moins de garder mon système principale stable et, en plus, il délie la mise à jour de ma machine de la mise à jour de mes outils.

Pour mes outils de base, je peux faire un Dockerfile pour simplifier les mises à jours.

J'aime bien aussi l'idée de pouvoir ponctuellement créer des environnements de développement jetable quand je donne un coup de main sur d'autres projets, comme expliqué par Psychofox plus haut.

Merci tout le monde pour les éclairages :)

Merci, je comprend l'idée, mais j'ai l'impression que si je suis vraiment ces conseils, je vais me retrouver avec beaucoup de logiciels installés dans mon toolbox.

Typiquement dans le toolbox que j'ai fais durant mes tests, j'ai: zsh, powerline, vim-X11, shellcheck, nodejs, git… La plupart de ces outils n'auront pas de Flatpak disponible et du coup il me reste le choix soit d'utiliser rpm-ostree, soit toolbox.

Si j'utilise toolbox, alors je vais devoir faire moi-même les mises à jour avec dnf ou la création d'un nouveau toolbox de zéro et donc réappliquer un script qui installe mes outils.

Là, j'ai l'impression de perdre tous les avantages de Silverblue et de devoir gérer une distribution finalement comme si j'utilisais Fedora Workstation. Bien que mon système principale fasse parti de la QA prévue par Fedora Silverblue, la plupart de mes outils ne seront pas couverts par cette QA.

Si j'utilise rpm-ostree, alors les mises à jours sont gérées directement par Fedora Silverblue et mes paquets sont réinstallés en tant que surcouche par dessus le système de base.

Comme dit plus bas, si je me limite à installer des paquets distribués par Fedora, mon système se retrouve finalement aussi dans un état prévu par Fedora, non ?

Ce n'est pas une très bonne idée d'utiliser rpm-ostree pour autre chose que des paquets obligatoires (drivers, …)

Donc distrobox ou toolbox, ça permet d'avoir un environnement pas en lecture seul justement.

J'avais entendu ça aussi au début, mais en lisant l'article de Colin Walters, je me suis rendu compte que le terme "en lecture seule" veut seulement dire que le répertoire "/usr" doit être considéré comme dossier géré par Fedora et non pas que le système entier doit être en lecture seule.

Or, pour les RPMs distribués par Fedora, je pense qu'il n'y a pas de problème de les ajouter par dessus l'image de base fournie aussi par Fedora, non ?

Je pense ça, parce que même si mon installation s'éloigne effectivement un peu de la distribution de base, elle reste dans un état prévu par Fedora.

Avec la sortie de Fedora 38, j'ai aussi essayé d'installer Silverblue.

Je n'avais pas bien compris ce que c'était vraiment et j'ai cru que tout le système d'exploitation serait en lecture seule.

Heureusement, j'ai essayé et j'ai appris que "/etc" est toujours modifiable, ouf !

Finalement, c'est surtout /usr qui est en lecture seule: ça permet de laisser la gestion de ces données exclusivement à la distribution Linux et de permettre des mises à jour plus fiable, car personne ne touche à ce répertoire.

Colin Walters a bien expliqué sur son blog pourquoi cette propriété est intéressante.

Notamment, parce que, même si personnellement je ne touche pas à /usr, je ne suis pas à l'abri qu'un script d'installation y touche malgré moi.

Au début, j'avais aussi un peu peur par rapport à l'installation de service système: par exemple, j'ai besoin de pouvoir connecter mon ordinateur à un service VPN. Eh bien, avec rpm-ostree, on peut encore ajouter des composants systèmes via les RPM de Fedora.

Si j'ai bien compris le système ce n'est pas un soucis, car lors d'une mise à jour majeur, rpm-ostree fera un rebase des paquets RPMs installés à la main sur la nouvelle version de Fedora. Autrement dit, ça ressemble exactement aux rebases quotidiens que je fais avec git durant mes développement, ça me plaît :)

L'utilisation des Flatpak de Flathub ça me plaît bien également, je l'utilisais déjà avec Debian et Fedora Workstation.

Il me reste enfin l'utilisation de toolbox dont je ne suis toujours pas trop sûr de l'intérêt. Vous avez des retours ?

J'ai installé mon environnement de développement dans toolbox comme conseillé. Mais je me dis que, quand je vais devoir mettre à jour le container toolbox, eh bien, j'aurai perdu tout l'intérêt de Silverblue : je vais repasser par les mises à jours via dnf avec un /usr potentiellement plein de modifications. Je ne ferais pas mieux d'utiliser les packages Fedora avec rpm-ostree ?

Est-ce que l'idée est de pouvoir juste délier la mise à jour de l'hôte et des containers ? Par exemple, ça me permettrait d'activer les mises à jour automatique de Fedora Silverblue sur l'hôte sans prendre de risque de casser mes outils de développement tout le temps ?

Bon, j'ai essayé et j'ai compris que timeoutable semble tracker l'activité avec des données directement dans le cookie et non pas en base de donnée. Ça ne serait donc pas si utile que ça.

J'ai testé avec un timeout par exemple d'une minute et, en fait, tant que je navigue sur le site, le cookie reste valable et la base de donnée n'est pas mise à jour. C'est parce qu'il détruit la session seulement si l'utilisateur est inactif un certain temps et non pas après une certaine durée de session.

Devise ne semble pas proposer de forcer un temps maximal de session, du coup, je pense que ça ne sert pas à grand chose de changer sa configuration et il vaut mieux implémenter la proposition de nud.

L'initiative peut venir d'un peuple directement à condition de récolter un nombre suffisant de signatures en faveur de l'initiative dans un certain temps. Je ne me souviens plus des chiffres exacts.

appeler au combat me semble peut démocratique surtout les combat pour son intérêt personnel, en France il y a se qu'un appel un bulletin de vote et entre deux il faut attendre.

Alors, en Suisse, nous votons environ tous les 6 mois, c'est pas mal pour donner son avis.

En France, il n'y a jamais eu de votation, mais uniquement des élections tous les 5 ans, non ?

Il ne faut pas confondre élections où on élit les représentants du peuple pour une certaine durée et les votations où le peuple donne son avis et/ou ses ordres directement.

Pour info, CFF est une entreprise semi-privée (je ne suis pas sûr de l'appellation): c'est une Société Anonyme (SA), mais dont le capital est détenu par la Suisse.

Je ne sais pas comment est géré la SNCF, votre équivalent Français je crois, mais je pense que ce style de structure dépendante de l'État fait qu'ils doivent plus facilement prendre en compte l'avis des associations de consommateurs.

Edit: ah je n'avais pas vu le commentaire de Glandos juste en dessous, désolé pour le bruit ;)

Je n'ai pas accès à la production pour voir ce qui s'est passé, mais c'est effectivement étrange: si on regarde la liste de tous tes commentaires: https://linuxfr.org/users/epeios/comments

Seul la première page contient le détail des votes: ça, c'est normal, c'est stocké uniquement temporairement dans Redis si je me souviens bien.

Dans tous les commentaires qui ont encore le détail, seul celui que tu as pointé à une différence entre les + et - qui est différent de 2.

Je ne sais pas pourquoi, je voulais juste partager ce constat.

Je veux un systeme qui utilise seulement Alsa.

Pourquoi est-ce que tu poses cette restriction ? Ça m'intrigue de savoir pourquoi tu t'imposes l'utilisation d'outils de bas niveau alors que tu souhaites utiliser Firefox en même temps.

Je pense que si tu n'as ni les APIs de PulseAudio, ni de Jack, Firefox risque de ne pas pouvoir fonctionner mieux, puisque ces APIs sont là justement pour résoudre les problèmes de latence (en tout cas pour Jack) et éviter que chaque logiciel doive coder la gestion audio.

L'avenir de la pile audio + vidéo de Linux est Pipewire et du coup, je pense que c'est vraiment chercher des ennuis à moyen terme, surtout.

J'ajouterai simplement une étiquette "tuto_vidéo" ou simplement "vidéo" sur les liens pour avoir tous les contenus "vidéos" disponible, non ?

Même une tablette avec Android avec un petit clavier, franchement, ça fait une bonne petite station de développement.

Vu la nature d'Android, son système de fichier en lecture seule et son sanboxing, il ne faut pas rêver, ça ne peut pas vraiment être utilisé pour le développement.

J'avais essayé avec une tablette Android et un clavier externe. Même pour du python (donc sans grosse chaine de compilation), c'était pas terrible. Le sandboxing ne fonctionne vraiment pas bien pour le développement, parce qu'il faut passer par des moyens non conventionnel pour installer les outils de développement.

J'avais aussi essayé avec Ubuntu Touch, mais l'OS utilisait aussi le sandboxing et j'ai finalement abandonné.

D'après les commentaires de reddit, il n'y a pas grande chance que les promesses soient tenues: https://www.reddit.com/r/shittykickstarters/comments/10pcecq/storaxa_nas_and_wifi_router/

La timeline semble trop courte, il n'y a pas d'obligations de résultat, les logiciels sont incompatibles (openwrt est un os pour routeur, proxmox est un os de gestion de machines virtuelle et truemas-scale est à installer sur des clouds), les prix beaucoup trop bas par rapport à la concurrence, le cpu Intel certainement pas assez véloce pour de l'Ethernet à 2.5 Gbps…

En plus, ils veulent proposer un "upgrade" vers AMD, mais ça leur demandera de recréer une carte mère complète…

Ah, c'est encore plus simple, il faut ajouter la fonctionnalité :timeoutable à devise et la configurer, la valeur par défaut est de 30 minutes d'inactivité, c'est peut être un peu court.

Par contre, je n'arrive pas à savoir avec leur doc, si ça se repose juste sur le expiration time du cookie ou si c'est aussi fait niveau serveur.

C'est pour corriger la fonctionnalité quand la case "se souvenir de moi" n'est pas cochée.

Quand on fera le script de nettoyage il faudra bien penser à verifier les 2 champs "current_sign_in_at" et "remember_created_at".

Pas sûr de ce qu'est cette dernière colonne, si ça ne joue pas, rememberable permet d'ajouter un callback "after_remembered".

Coucou les gens qui ne se connectent à certains sites que d'un même point (par exemple moi toujours du même poste perso chez moi) et de surcroit conservent la session active (en plus d'avoir coché la case.)

Si tu coches la case "se souvenir de moi", la session est automatiquement renouvelée au bout d'un certain temps et nous pouvons le voir côté serveur via une colonne dédiée. Donc pas de soucis pour ce cas d'usage, il faudra juste impérativement cocher la case.

Apparemment cette solution est proposée dans la partie sécurité du gzide de Rails pour s'assurer que les sessions expirent au bout d'un moment : https://guides.rubyonrails.org/security.html#session-expiry

Si jamais, j'ai crée une entrée de suivi pour discuter de comment faire, ça n'a pas l'aire simple effectivement: https://linuxfr.org/suivi/pouvoir-determiner-si-un-compte-a-eu-de-l-activite-recemment

La configuration actuelle du tracking fait par l'outil devise ne permet pas de bien suivre l'activité du site si l'option "Restaurer mes onglets / Conserver ma session" est activée dans le navigateur web: Firefox ne supprime plus les Cookies de Session dans ce cas et donc l'utilisateur peut ne jamais repasser par le formulaire de login, même s'il n'a pas coché la case "se souvenir de moi".

Merci pour le partage, l'article est très intéressant.

J'y ai appris que Rust avait un Garbage Collector au début et qu'ils ont réussi à le supprimer avant de créer une version stable du langage. Il y a bien un système de comptage de référence, mais l'article laisse entendre que c'est bien plus léger qu'un GC.

L'article explique bien aussi que le tour de force du langage est de réussir à réunir 2 mondes avec un seul outil: le monde de l'embarqué qui doit avoir une gestion fine de la mémoire et celui des gros logiciels d'entreprise qui doivent laisser tomber la gestion fine de la mémoire.

Je pense que c'est vraiment ça qui doit être mis en avant: le language, grâce a ses nouveaux concept de gestion de mémoire, peut être utilisé dans chacun des mondes.

Ça m'encourage vraiment à vouloir essayer ce langage, parce que je sais maintenant qu'avec cet outil je serai embauchable dans tous les domaines informatique à long terme :)

Un dernier point qui n'est pas des moindre que l'article soulève est l'accueil chaleureux de la communauté grâce à un Code of conduct appliqué très tôt dans son développement. Ça me parle beaucoup car je souhaite être ouvert à toutes les particularités de chacun.

L'article induit en plus qu'une des conséquences de ce code de conduite est d'avoir créé un compilateur qui guide l'utilisateur dans la résolution de bug au lieu d'avoir un compilateur comme en C/C++ qui pointe juste les erreurs avec des messages abscons.

Dans la conversation sur les commentaires, on avait cet argument :

Il y a aussi une question de cohérence, le champ au dessus parle de « XMPP » et pas de « Conversations » ou « Gajim ».

Une option qui me paraîtrait plus saine serait de mettre le protocole, et quelque part (entre parenthèses, en dessous ou n'importe où où ça serait visible) des exemples de client connus.
Exemple : ActivityPub (Mastodon, Pleroma, Mobilizon, etc)

Et du coup la même chose pour XMPP.

Finalement si ActivityPub impose HTTP, on a peut être fait une erreur en créant le champ Mastodon: tous ces systèmes peuvent déjà être mis dans le champ "site Web personnel".

On pourrait la renommer "page Web personnelle" et lui ajouter l'attribut rel="me", comme le demande Mastodon.

Est-ce qu'ActivityPub impose à chaque réseau de fournir une adresse de profile en HTTP ?

Hello,

Comme discuté là bas, la fonctionnalité Mastodon est liée à la gestion de vérification des liens de profile Mastodon et non pas à ActivityPub.

Je suis donc a priori contre le changement de nom, mais je suis ouvert à l'ajout d'autres réseaux ;)

Je pense qu'ouvrir la possibilité de renseigner plusieurs réseaux serait plus adéquat. Surtout sachant que tout le monde peut avoir plusieurs profils ActivityPub à renseigner (Mastodon, Peertube…). De part sa nature, le réseau ActivityPub pousse à avoir plusieurs comptes, non ?