Quoi de neuf côté LinuxFr.org

Posté par  (site web personnel) . Édité par ZeroHeure, patrick_g et Nils Ratusznik. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
85
4
juin
2015
LinuxFr.org

La dernière dépêche de cette catégorie LinuxFr.org qui ne soit pas une dépêche récurrente type « Les meilleurs journaux du mois » ou « Les prix du mois » ou « Les statistiques de l'année » remonte à mai 2014 pour une mise à jour du serveur. Voici donc, à l'aube de l'été, quelques actualités de type « en coulisses ».

Sommaire

Suppression du spam dans les contenus et commentaires

Il est possible que beaucoup d'entre vous ne le remarque jamais ou rarement, mais l'équipe de modération supprime très régulièrement du spam dans les contenus et commentaires. Certains se donnent du mal pour ennuyer les autres, que cela passe par des bots créant des comptes et postant des contenus générés automatiquement, des humains payés pour faire la chose manuellement et des pénibles en SEO venant établir des liens vers leurs sites.

Mises à jour de sécurité suite aux différentes failles

Une autre partie de l'activité récurrente concerne les mises à jour de serveur, et en particulier celles suite aux diverses failles touchant la cryptographie (Heartbleed, POODLE, BEAST, etc.) ou même le reste (Shellshock). Bref, il y a régulièrement de l'apt dans l'air pour les mises à jour, et aussi des configurations à revoir pour supprimer des protocoles ou des algorithmes de crypto obsolètes par exemple.

Dans la catégorie mise à jour, on peut aussi citer le passage en Jessie du serveur zobe (non critique) courant mai, qui s'est bien déroulée jusqu'au redémarrage. Il est pour l'instant indisponible jusqu'à une prochaine intervention au datacenter.

Faille ElasticSearch sur juin/juillet 2014

Le texte qui suit a été écrit en août 2014, mais n'avait pas été publié jusqu'ici.

Début juin 2014 (*), les deux serveurs web de test et de production du site LinuxFr.org ont été victime d'une attaque, ayant permis l'exécution de processus arbitraires par un compte non privilégié. Plusieurs tentatives d'élévation de privilèges ont eu lieu, sans succès, et le compte concerné n'a pas eu accès aux données utilisateur du site. Seuls deux containeurs LXC sont concernés et l'attaque n'a touché ni les autres conteneurs, ni les deux serveurs physiques. Les conteneurs attaqués ont malheureusement été utilisés pour un déni de service. Le service concerné (elasticsearch, utilisé pour le moteur de recherche interne du site, dans une configuration non sécurisée) a été arrêté dès l'identification du problème de sécurité.

(*) pour autant que l'on puisse être sûr dans ce genre de circonstances.

L'erreur de configuration vient de la fonction de scripts dynamiques, ouverte par défaut (voir Scripting and Security le 9 juillet 2014, précédemment sur Scripting).

Cette intrusion est arrivée au pire moment possible (loi de Murphy) : un admin dans les cartons d'un déménagement et sans accès internet correct, un autre en vacances hors ligne, un autre en surchauffe, etc. le tout autour du pont du 14 juillet (ce qui a laissé perduré le premier diagnostic d'un simple problème réseau), dans la torpeur estivale post-RMLL.

Une analyse post-mortem a été faite par précaution, avec une comparaison de deux fois 75 Go de sauvegardes et une comparaison avec une réinstallation. La fonctionnalité de recherche interne n'a cependant pas été remise en service.

Liens :

Chronologie reconstituée :

Quelques traces laissées :

/tmp/linux64 (binaire 64 bits statique, DDOS/amplification trojan)
MD5SUM a4eecf76f4c90fb8065800d4cad391df
SHA1SUMee6e21332b77fd5ff45e6dd84c0ab670b09c47d7
Modify (alpha): 2014-06-16 18:50:24.000000000 +0200
Change (alpha): 2014-07-01 00:04:19.212510027 +0200
Modify (prod): 2014-06-16 18:50:24.000000000 +0200
Change (prod): 2014-07-01 02:31:31.368760889 +0200
Changt (prod, version précédente) : 2014-06-28 15:53:43.477456943 +0200
Changt (alpha, version précédente): 2014-06-28 15:53:07.431067208 +0200

/tmp/linux64.1 (le même sans les droits d'exécution)
Modify (alpha,prod): 2014-06-16 18:50:24.000000000 +0200
Change (alpha): 2014-07-01 00:04:13.784431599 +0200
Change (prod): 2014-07-01 02:31:26.332687560 +0200

/tmp/2618.c (code d'exploit)
SHA1SUM3b9ebf99ec0c331a4f98f46f7724d42b287ee0c9
MD5SUM aa0a0fea5d681acca154a37125252db9
Modify (alpha,prod): 2014-07-08 18:20:21.000000000 +0200
Change (alpha): 2014-07-09 03:54:48.727879711 +0200
Change (prod): 2014-07-09 03:54:52.427932224 +0200

/tmp/zero.pl (script perl pour avoir un shell via le réseau)
SHA1SUM 7d77d06d1e3d9ce7aed43e6d5a7a75f9af310daa
MD5SUM c3fd28831d9fc683000273643b5bef12
Modify: 2014-07-05 23:41:31.000000000 +0200
Change (alpha): 2014-07-09 03:54:46.831852803 +0200
Change (prod): 2014-07-09 03:54:54.695964414 +0200

/tmp/32.out (exploit 64 bits statique, connu comme Unix.Exploit.Fsheep)
SHA1SUM 0e76f4c72295fe851b775dac8c49ec53108f1df6
MD5SUM ff1e9d1fc459dd83333fd94dbe36229a
Modify (alpha,prod): 2014-07-08 15:04:42.000000000 +0200
Change (alpha): 2014-07-09 03:55:51.760774344 +0200
Change (prod): 2014-07-09 03:55:22.968365680 +0200

/tmp/12.txt  (contient "1233", présent depuis le 23 mai dans des exploits sur des sites asiatiques)
SHA1SUM 416f8f6e105370e7b9d0fd983141f00b613477f8
MD5SUM e034fb6b66aacc1d48f445ddfb08da98
Modify (alpha): 2014-07-12 02:30:42.084255080 +0200
Chang (alpha): 2014-07-12 02:30:42.084255080 +0200
Modify (prod): 2014-07-12 00:55:14.060062158 +0200
Change (prod): 2014-07-12 00:55:14.060062158 +0200
Modif. (prod, version précédente): 2014-06-07 10:34:30.280153412 +0200
Changt (prod, version précédente): 2014-06-09 20:03:34.372893780 +0200
Modif. (alpha, version précédente) : 2014-06-07 20:15:05.675547255 +0200
Changt (alpha, version précédente) : 2014-06-09 20:00:16.113258887 +0200

/tmp/bins (identique à zero.pl)
Modify (alpha,prod): 2014-07-05 23:41:31.000000000 +0200
Change (alpha): 2014-07-11 13:47:50.492585215 +0200
Change (prod): 2014-07-12 05:53:16.175681015 +0200

/tmp/mempodipper.c (fichier vide)
SHA1SUM 271a0a0e06d67f285fdc4d5c7e535255ead28880
MD5SUM 4206e8b780cf3758baa76b1002e61792
Modify (alpha): 2014-07-11 13:47:59.220714584 +0200
Change (alpha): 2014-07-11 13:47:59.220714584 +0200
Modify (prod): 2014-07-12 05:53:19.935737099 +0200
Change (prod): 2014-07-12 05:53:19.935737099 +0200

/tmp/2618 (prod seulement; exploit 32 bits, a priori non issu du .c à côté)
MD5SUM 17b2ee66918319a3ac9435aef7c5e2dc
SHA1SUM 3942d8cf47800e3595194cdaf6b645fc6c8c8e71
Modify (prod): 2013-03-31 21:25:08.000000000 +0200
Change (prod): 2014-07-12 05:53:24.559806071 +0200

/tmp/269 (prod seulement, exploit 32 bits)
MD5SUM a3e718751e600c4e8503ac6836b84aba
SHA1SUM ec22fac0510d0dc2c29d56c55ff7135239b0aeee
Modify (prod): 2014-07-11 16:50:42.000000000 +0200
Change (prod): 2014-07-12 05:53:25.067813648 +0200

/tmp/2632 (prod seulement; exploit 32 bits)
MD5SUM 29f8b6e0ed968e0bf32a24835a7b386f
SHA1SUM 5faf7d6c41e79c20e1551588c74df9bf72293c12
Modify (prod): 2014-07-11 16:50:22.000000000 +0200
Change (prod): 2014-07-12 05:53:25.715823314 +0200

/tmp/.Linux_time_y_2015 (exploit 32 bits)
Modify (alpha): 2014-07-11 13:48:14.292937981 +0200
Change (alpha): 2014-07-11 13:48:14.292937981 +0200
Modify (prod): 2014-07-12 05:53:38.992021336 +0200
Change (prod): 2014-07-12 05:53:38.992021336 +0200

Gestion d'une plainte pour harcèlement et usurpation d'identité

Le site LinuxFr.org a été utilisé (parmi d'autres, dont tous les sites de réseaux sociaux, de diffusion de vidéos, Wikipédia ainsi que plusieurs hébergeurs web gratuits) par une personne menant visiblement une campagne de harcèlement en ligne tendance « revenge porn ». Une plainte ayant été déposée pour harcèlement et usurpation d'identité, nous avons échangé par téléphone et courriel avec les autorités compétentes et avons fourni les informations en notre possession.

C'est le premier cas dans l'histoire du site (et de l'association LinuxFr) où nous sommes concernés par une plainte formelle (même si ici nous ne sommes pas directement concernés mais simplement un « service de communication au public en ligne édité à titre non professionnel au sens de l'article 6, III, 2° de la loi 2004-575 du 21 juin 2004. »). Jusqu'ici, le seul cas nous concernant directement et présentant un aspect formel est la mise en demeure de mai 2013.

Stand LinuxFr.org aux RMLL 2015 Beauvais

LinuxFr.org aura un stand aux RMLL 2015 à Beauvais. Cela sera l'occasion de venir discuter avec des membres de l'équipe, voire de signer des clés GPG ou d'obtenir des accréditations CAcert.

Changement de certificat X.509 et d'autorité de certification

Le certificat utilisé par LinuxFr.org arrive à échéance dans le 5 juin 2015. Nous utilisions jusqu'ici l'autorité de certification communautaire CAcert. Suite aux retraits des certificats racine des distributions libres, l'assemblée générale de l'association LinuxFr du 6 mai 2015 a décidé d'opter pour une autre autorité de certification (la société Gandi). Les différentes pages d'aide sur X.509/SSL/TLS ont été mises à jour (1, 2 et 3).

  • # Jusqu'au redémarrage

    Posté par  . Évalué à 6.

    Dans la catégorie mise à jour, on peut aussi citer le passage en Jessie du serveur zobe (non critique) courant mai, qui s'est bien déroulée jusqu'au redémarrage. Il est pour l'instant indisponible jusqu'à une prochaine intervention au datacenter.

    Donc ça ne s'est pas bien déroulé en fait?

  • # L'âge de raison?

    Posté par  (site web personnel) . Évalué à -10.

    l'assemblée générale de l'association LinuxFr du 6 mai 2015 a décidé d'opter pour une autre autorité de certification (la société Gandi).

    Et surtout, une autorité crédible.
    Je n'osais même pas espérer ça en 2015…
    Encore un troll qui dégage (mais ça aura mis le temps, l'espoir en CACert qui serait crédible "demain" ayant duré bien longtemps ;-), LinuxFr étant le seul site que je connaissais encore "en résistance").
    (et oui, ça me fait bien sourire vu les souvenirs que j'ai des discussions à ce sujet)

    • [^] # Re: L'âge de raison?

      Posté par  (site web personnel) . Évalué à 10.

      Je t'ai expliqué de multiple fois que ce sont les autres autorités de certifications qui ne semblent pas crédibles et je t'ai même collé de multiple fois le mail du dev Debian qui expliquait tout ça.
      Mais bon tu ne veux rien écouter et tu as une vision purement idéologique de la chose alors à quoi bon te donner des liens vers des discussions factuelles….

      • [^] # Re: L'âge de raison?

        Posté par  (site web personnel) . Évalué à -9.

        tu as une vision purement idéologique

        Tellement idéologique que "l'assemblée générale de l'association LinuxFr du 6 mai 2015 a décidé d'opter pour une autre autorité de certification (la société Gandi)", donc dans mon "idéologie", du coup il faut croire que "l'assemblée générale de l'association LinuxFr du 6 mai 2015" est tombée elle aussi dans l'idéologie identique à la mienne… Quelle accusation!
        Ca m'amuse.

        Mais bon tu ne veux rien écouter

        Ha? Et tu ne t'es jamais demandé si cette phrase ne s'appliquait pas à toi? C'est un peu facile d'accuser les autre ne pas écouter quand ils sont simplement pas convaincus de ce que tu dis.
        Je peux te retourner le compliment, si tu veux jouer aux attaque persos.
        Ne pas accepter n'importe quel argument != ne pas écouter.
        C'est une manœuvre classique pour éviter le débat la… Un peu gros non?

        PS : d'habitude, on m'accuse de pragmatisme, j'avoue ne pas comprendre l'accusation d'idéologisme quand c'est bien l’idéologisme qui avait fait choisir CACert contre tout le reste du monde qui est pragmatique et a vu que CACert n'était pas du tout crédible comme alternative. Ca fait un peu inversion de genre, ou l'idéologiste accuse le pragmatiste d'idélogisme que lui n'aurait pas. heu… J'avoue ne pas comprendre non plus comment l'idéologisme sur CACert peut amener à raconter ça. Pourquoi cette focalisation sur CACert? Mystère… Toujours est-il que CACert est mort (ou en coma si on préfère être gentil), c'est factuel, et que dans un an on fera comme si ça n'avait jamais existé.

        • [^] # Re: L'âge de raison?

          Posté par  (site web personnel) . Évalué à 10. Dernière modification le 04 juin 2015 à 18:22.

          Ça me fatigue de te répondre encore une fois alors que tu ne veux même pas lire les liens qu'on te donne.

          https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#239

          Là le mec qui écrit il a fait l'audit de CAcert. Je vois mal qui pourrait être plus qualifié que lui pour analyser cette problématique et évaluer si CAcert est crédible ou pas. Certainement pas toi ni moi.
          Est-ce que tu pourrais donc faire preuve d'un peu de modestie et lire les arguments de quelqu'un qui connait tout ce processus sur le bout des doigts ?

          • [^] # Re: L'âge de raison?

            Posté par  (site web personnel) . Évalué à -10. Dernière modification le 04 juin 2015 à 18:48.

            Est-ce que tu pourrais donc faire preuve d'un peu de modestie et lire les arguments de quelqu'un qui connait tout ce processus sur le bout des doigts ?

            Est-ce que tu pourrais donc faire preuve d'un peu de modestie et lire les arguments de quelqu'un qui connait tout ce processus sur le bout des doigts ?
            Par exemple Debian, Canonical, Mozilla… Tous stupides en refusant d'intégrer le certificat CACert? Tous ces gens qui ont une responsabilité en sécurité qui décident de virer cACert pour le plaisir mais patrick_g, qui n'a aucune responsabilité de sécurité, a raison?

            Expliquer != ne pas avoir de modestie. Désolé de voir que LinuxFr fait exactement ce dont je parlais depuis des années. Je ne fais que constater. Et de m'en amuser car la page d'explication se mort la queue maintenant ("c'est des méchants, on est trop en résistance, mais bon en fait on fait pareil maintenant").

            Ha oui, excuse-moi, seuls tes arguments sont valides, les autres sont nuls… Quels arguments! Mais bon, on se répète, les mêmes "excuses" reviennent sur la table, ça sert à rien de contre-argumenter, la conclusion est déjà faite.
            Mais ce qui est rigolo en nouveauté aujourd'hui est que "l'assemblée générale de l'association LinuxFr du 6 mai 2015" a pourtant décidé de ne plus suivre et se jeter chez un méchant oligopole autrefois décrié… Preuve que la décision précédente était mauvaise (tout comme Mozilla a lâché leur refus de H264 pour prendre un autre exemple, mais eux ont lâché après 1 an). Pourquoi ne pas accepter que non, ça n'était pas très intelligent avant et qu'on corrige maintenant? La ça fait "j'ai raison contre tous les autres, mais bon en fait je fais comme les autres", hum… Qui parle ensuite d'idéologisme?

            Passons… On n'en parlera plus de toutes façons, CACert étant maintenant dégagé, il n'y aura plus de problèmes (Gandi fait partie de oligopole décrié mais accepté partout) et plus personne n'en parlera bientôt (plus de questions "mais pourquoi ça fait un gros truc rouge?", "mais pourquoi pas les images?" etc). L’incohérence disparaitra d'elle-même après cette dépêche, et on fera plus tard comme si ça n'avait jamais existé.

            Mais sérieux, balancer des "tu ne veux pas écouter" et "fais preuve de modestie" juste parce que la personne en face n'est pas d'accord avec toi, en attaquant la personne plus que les idées, ça ne fait pas très crédible : ça fait imaginer qu'il n'y a rien derrière. Ce n'est pas comme ça qu'on peut convaincre (à moins qu'on veut convaincre du contraire de ce qu'on dit).

            Passons… Et oublions : la bataille qui a trop durée est terminée.

            • [^] # Re: L'âge de raison?

              Posté par  (site web personnel) . Évalué à 10.

              Preuve que la décision précédente était mauvaise (tout comme Mozilla a lâché leur refus de H264 pour prendre un autre exemple, mais eux ont lâché après 1 an).

              En quoi est-ce une "mauvaise décision" de faire acte de résistance et de parier sur quelque chose ?
              Leur position est pour moi infiniment plus respectable que celle qui consiste à adopter la solution la moins éthique mais la plus pragmatique parce que "bin c'est comme ça, c'est les plus forts, inutile de lutter".

            • [^] # Re: L'âge de raison?

              Posté par  . Évalué à 10.

              Je ne souhaite pas vraiment prendre de position sur cette question de l’autorité de certification que devrait utiliser linuxfr.org mais cela m’aurait intéressait d’avoir un peu plus d’informations sur les arguments qui ont fait que l’assemblée à préférer Gandi à CaCert pour le nouveau certificat. Est-ce parce que les distributions l’ont retiré ? Pour éviter les problèmes que rencontrent les utilisateurs ? Une fonctionnalité supplémentaire ? Un meilleur support ? Autre ?

              Sinon, en passant :

              Preuve que la décision précédente était mauvaise

              Une prise de position défavorable à un instant t n’est pas forcément l’aveu que la position inverse à un instant t-1 était mauvaise, il y a également le contexte et l’historique à prendre en compte. Les choses évoluent et cela serait idiot que tes positions ne changent jamais au fil du temps.
              Tu m’as sorti ce (juste) argument hier concernant l’évolution des qualités des œuvres ;)

              • [^] # Re: L'âge de raison?

                Posté par  (site web personnel, Mastodon) . Évalué à 10.

                cela m’aurait intéressait d’avoir un peu plus d’informations sur les arguments qui ont fait que l’assemblée à préférer Gandi à CaCert pour le nouveau certificat. Est-ce parce que les distributions l’ont retiré ? Pour éviter les problèmes que rencontrent les utilisateurs ? Une fonctionnalité supplémentaire ? Un meilleur support ? Autre ?

                Je ne vais pas parler pour les autres votants, mais je n'ai aucun problème à dire que j'ai voté pour l'utilisation de Gandi plutôt que CAcert. Pourquoi ? Ce n'est pas une question de support, de fonctionnalité ou d'une quelconque garantie. Ce qui m'a intéressé dans le certificat de Gandi, c'est la disponibilité du certificat de l'autorité racine dans la quasi-totalité des navigateurs modernes du marché. J'estime que de la sorte, il sera plus facile de promouvoir LinuxFr.org auprès du public sans avoir à expliquer le pourquoi du comment que non, le site n'est pas en rade, que tout fonctionne comme il le doit et que l'ordinateur ne va fondre parce qu'on clique sur « je comprends les risques ».

                Alors certes, on peut m'accuser de céder face à un oligopole d'autorités de confiance, en qui on ne pourrait pas avoir tant confiance que ça. Sauf que personne n'est parfait, que ce soit CAcert ou les autorités commerciales. Le certificat fourni par Gandi est valide jusqu'au 3 juin 2018. D'ici là, cela laisse le temps de voir comment évoluent CAcert, les autres autorités de certification, ou même Let's Encrypt ! Rien ne nous empêche de changer de solution dans 3 ans, et rien ne m'empêche non plus de changer d'avis.

            • [^] # Re: L'âge de raison?

              Posté par  (site web personnel) . Évalué à 10.

              Par exemple Debian, Canonical, Mozilla… Tous stupides en refusant d'intégrer le certificat CACert? Tous ces gens qui ont une responsabilité en sécurité qui décident de virer cACert pour le plaisir

              Encore une fois tu n'as rien lu. Tu écris comme si l'auteur du post dont j'ai donné le lien protestait contre le fait de virer CAcert. En fait il approuve la décision de Debian de s'aligner sur Mozilla et de virer CAcert :

              Firstly, that this is probably what you have to do: follow Mozilla's lead.

              Il dit que c'est la décision pragmatique à prendre et qu'il faut bien s'aligner (ce qu'à aussi fini par faire LinuxFr).
              Mais il explique aussi très bien que c'est le poids économique des CAs et l'absence de moyen de Debian et la MoFo qui conduisent à cet alignement. Ce n'est pas du tout que les gros CAs sont plus crédibles (comme tu le dis) puisque les garanties qu'ils offrent ne valent rien :

              Whereas, other CAs have totally buried recourse. They disclaim
              liability totally for everything, they hide it from you, and they market
              certificates as if you can rely on them. Try it! If you ask about
              the legal contract, the shutters go up. It might be an American
              paranoia to never talk about liability, but in practice this is what
              happens—no CA will talk about its liabilities to you. It is
              impossible to talk seriously about the benefit to the user without
              talking about the liability when something goes wrong, and it is
              therefore impossible to talk seriously to any CA or vendor about the
              real meaning of the certificates or reliance in effect as opposed to the
              wordage.

            • [^] # Re: L'âge de raison?

              Posté par  . Évalué à 8.

              Personnellement, j'ai apprécié que Mozilla ait refusé H264 pendant un temps. Je pense qu'il était plus dans leur rôle que quand il pousse Pocket …

              Idem pour Cacert, on peut pas reprocher à un site communautaire de pousser une solution communautaire.

              Enfin, c'est sûr que c'est pas forcément pragmatique ;)

              • [^] # Re: L'âge de raison?

                Posté par  (site web personnel) . Évalué à -4.

                Personnellement, j'ai apprécié que Mozilla ait refusé H264 pendant un temps. Je pense qu'il était plus dans leur rôle que quand il pousse Pocket

                Proposer une alternative et la pousser sont dans leur rôle.
                Refuser l'existant n'est pas dans leur rôle (qui est de répondre au besoin aussi afin d'avoir des utilisateurs, sans utilisateurs on ne fiat pas grand chose). D'ailleurs, ils ont vite compris que ça ne le ferait pas.

                on peut pas reprocher à un site communautaire de pousser une solution communautaire.

                Je n'ai jamais reproché ça. Merci de ne pas me faire dire ce que je n'ai pas dit.
                Une CA communautaire serait super. CACert n'est malheureusement pas une CA (factuellement, ce n'est pas une "autorité", personne ou presque y croyant, et personne n'osant faire passer de certification pour que ça change). Pour dire autrement, je ne conteste absolument pas de prioriser le communautaire (la façon de faire), ce que je conteste est de ne pas fournir une chaine de confiance (ce qu'il faut faire).
                Pour prendre une analogie, une roue carrée communautaire est-elle vraiment utile et faut-il l'utiliser pour (essayer de) rouler "parce que c'est communautaire"? Et pire, faut-il passer du temps à essayer de rendre la roue ronde si on pense que les roues sont la mauvaise solution pour aller d'un point A à un point B? CACert n'est pas allé plus loin que la roue carrée avec des gens ayant pour discours que les roues c'est mal, ça peut difficilement marcher pour amener du monde.

                Enfin, c'est sûr que c'est pas forcément pragmatique ;)

                C'est surtout tellement idéologique qu'on en oublie les bases. Et c'est bien dommage.

                • [^] # Re: L'âge de raison?

                  Posté par  . Évalué à 2.

                  D'ailleurs, ils ont vite compris que ça ne le ferait pas.

                  Je pense qu'il savait ce qu'il faisait et l'idée était sans doute un peu de mettre en évidence que le choix du H264 n'était pas parfait (cf. http://fr.wikipedia.org/wiki/H.264#Brevets).

                  CACert n'est malheureusement pas une CA

                  Tu as raison "factuellement" elle ne l'est pas.
                  Elle a été un peu reconnue à une époque quand même ;) Disons que c'est quand même mieux qu'une roue carrée.

                  C'est surtout tellement idéologique qu'on en oublie les bases. Et c'est bien dommage.

                  J'aime bien cette idéologie donc je suis perdu :/

  • # Toujours 100% open source ?

    Posté par  . Évalué à 1.

    Le site est il toujours 100% open source , crée avec 100% d'outils et de lib open source ?

    • [^] # Re: Toujours 100% open source ?

      Posté par  (site web personnel) . Évalué à 9.

      Oui

    • [^] # Re: Toujours 100% open source ?

      Posté par  (site web personnel) . Évalué à -1.

      Le site est il toujours 100% open source

      Pour troller, même l'image en haut à gauche est open source maintenant (il fût un moment où l'image n'était pas libre, de souvenir en -NC), donc 100% open source semble correspondre à l'heure d’aujourd’hui.

      • [^] # Re: Toujours 100% open source ?

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        (il fût un moment où l'image n'était pas libre, de souvenir en -NC)

        Ah celle d'avant était en NC?

        En tous cas, comme je disais en contribuant l'image courante, même après la fin du financement, vous êtes les bienvenus pour la garder (au contraire même, Aryeom serait très heureuse si son image reste un long moment ici!).

        Vous avez le XCF, donc vous pouvez aussi faire très facilement après coup une version qui ne garde que Tux et GNU si vous le souhaitez (bien que si vous gardez Marmotte aussi, comme un beau symbole de l'Art Libre, nous en serions très heureux aussi!).
        En plus c'est une image relax, et ça c'est cool! :-)

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Toujours 100% open source ?

          Posté par  (site web personnel) . Évalué à 1.

          Ah celle d'avant était en NC?

          Aucune idée, je n'ai pas fait attention.
          "il fût un moment" se réfère à il y a plus longtemps. De tête (je ne garanti pas, c'est vieux), c'était ceux de Ayo que tu peux retrouver sur https://linuxfr.org/images/logos/ . C'est très vieux, je ne garantie pas la précision de ma mémoire (et je n'en retrouve pas trace, je crois que son compte a été supprimé à sa demande)

  • # On ne le dit pas assez…

    Posté par  (site web personnel) . Évalué à 10.

    Alors un grand MERCI aux admins/dev/… pour le fantastique boulot que vous faite pour faire tourner le site.

    • [^] # Re: On ne le dit pas assez…

      Posté par  (site web personnel) . Évalué à 10.

      On peut aussi ajouter un grand BRAVO à tous les modérateurs qui font preuve d'une infinie patience et d'une pédagogie hors-norme envers des trolls que leur esprit obtus et étriqué empêche d'évoluer au delà d'une conscience de moule.

  • # https sans certificat

    Posté par  . Évalué à 2. Dernière modification le 04 juin 2015 à 23:19.

    Bonjour,

    Est-il normal que https://linuxfr.org/news.atom ne soit pas chiffré et n'ait pas de certificat ?

    Si ma question est bête, oubliez.

    • [^] # Re: https sans certificat

      Posté par  (site web personnel) . Évalué à 5. 

      $ curl -v -o /dev/null https://linuxfr.org/news.atom
(...)
* Connected to linuxfr.org (88.191.250.176) port 443 (#0)
(...)
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
(...)
< HTTP/1.1 200 OK

      De fait ça marche moins bien sans vérification possible de certificat :

      $ curl -v -o /dev/null --cacert /dev/null https://linuxfr.org/news.atom
(...)
* Connected to linuxfr.org (88.191.250.176) port 443 (#0)
* found 0 certificates in /dev/null
(...)
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification failed. CAfile: /dev/null CRLfile: none

      Et pour comparaison, le flux Atom Wikipédia. En fait c'est Firefox qui choisit de ne pas afficher la page de rendu Atom comme du HTTPS classique (chromium le fait par exemple).

      • [^] # Re: https sans certificat

        Posté par  . Évalué à 2.

        La page de rendu Atom contient une image OpenSMTPD avec le protocole http et non pas https.
        La page n'est donc pas "full" https, Firefox ne doit pas aimer cette lacune.

    • [^] # Re: https sans certificat

      Posté par  . Évalué à 4. Dernière modification le 05 juin 2015 à 00:19.

      C'est étrange en effet puisque de mon coté :

      curl m'indique ceci :

      * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*    server certificate verification OK
*    server certificate status verification SKIPPED
*    common name: *.linuxfr.org (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: OU=Domain Control Validated,OU=Gandi Standard Wildcard SSL,CN=*.linuxfr.org
*    start date: Tue, 02 Jun 2015 00:00:00 GMT
*    expire date: Sat, 02 Jun 2018 23:59:59 GMT
*    issuer: C=FR,ST=Paris,L=Paris,O=Gandi,CN=Gandi Standard SSL CA 2
*    compression: NULL

      chromium :

      Common Name (CN)    *.linuxfr.org
Organization (O)    <Not Part Of Certificate>
Organizational Unit (OU)    Domain Control Validated
Serial Number   00:FC:EE:49:C0:97:E1:77:95:F6:17:51:8E:E8:7D:CF:10
Issued By

Common Name (CN)    Gandi Standard SSL CA 2
Organization (O)    Gandi
Organizational Unit (OU)    <Not Part Of Certificate>
Validity Period

Issued On   6/2/15
Expires On  6/2/18
Fingerprints

SHA-256 Fingerprint E0 55 49 BD 8B 5D E1 07 15 4A C6 33 81 27 31 A8 19 E7 D7 B3 4D 7F 11 2F 1E 9F AE C3 90 A3 13 D0
SHA-1 Fingerprint   76 E7 95 FF 88 7C 1D 83 2F E5 70 B1 4F 1C B2 41 A6 4E DD 51

      midori m'affiche bien une connexion HTTPS valide.

      et firefox m'indique que c'est une connexion en clair ?!
      Non, je pense que c'est un bug de firefox, car il semble bien faire une connexion HTTPS si j'en crois les outils de développement.

  • # CAcert

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Bon déjà je (re)dis à mon tour un grand merci à toute l'équipe derrière ce site qui est la référence pour moi, autant au niveau de l'éthique que du contenu, et sites en langue anglaise compris.

    Pour CAcert on est un peu embêtés, parce qu'on garde un certificat CAcert sur notre projet, et la FAQ de DLFP nous permettait de justifier ce choix. Maintenant on va se sentir un peu seuls, et la plupart des gens ne comprennent pas pourquoi ils voient un message d'avertissement en allant sur la démo de Libervia.

    J'avais pourtant l'impression de revoir une activité de ce côté: présence d'un stand CAcert au Fosdem par exemple, il me semble avoir lu que Debian allait (ou a ?) ré-intégrer les certificats racine (pas trop le temps de vérifier ça maintenant, ni de risquer une mise à jour sur ma SID aujourd'hui).

    Bref, on se pose sérieusement la question de garder CAcert ou pas, j'ai l'impression de trahir un (petit) peu nos convictions si on le fait, mais maintenant que même DLFP lâche le morceau, on se sent plus seuls.

    • [^] # Re: CAcert

      Posté par  (site web personnel) . Évalué à 9.

      J'avais pourtant l'impression de revoir une activité de ce côté: présence d'un stand CAcert au Fosdem par exemple, il me semble avoir lu que Debian allait (ou a ?) ré-intégrer les certificats racine (pas trop le temps de vérifier ça maintenant, ni de risquer une mise à jour sur ma SID aujourd'hui).

      J'ai aussi lu que le nombre d'accréditeurs CAcert avait augmenté. Et pour Debian, il s'agit du paquet ca-cacert, annoncé par CAcert.

      Bref, on se pose sérieusement la question de garder CAcert ou pas, j'ai l'impression de trahir un (petit) peu nos convictions si on le fait, mais maintenant que même DLFP lâche le morceau, on se sent plus seuls.

      Tu peux utiliser le CCC comme référence si tu veux. On a toujours/encore des accréditeurs CAcert dans l'équipe et on a aussi un certificat CAcert wildcard valide au besoin ou pour des tests.

      Et à titre personnel qui n'engage que moi, et indépendamment du fait que ça soit peut-être un bon choix pragmatiquement parlant, « j'ai l'impression de trahir un (petit) peu [mes] convictions ». J'avais le même sentiment quand l'April a abandonné CAcert (en ayant de vraies bonnes raisons car l'asso gère des paiements en ligne par exemple) ou quand l'April continue à utiliser du vote électronique ou quand je devais installer un JDK propriétaire pour déclarer mes revenus ou quand j'utilise un microcode ou un BIOS propriétaire ou quand je dois passer par du Flash propriétaire ou…

    • [^] # Re: CAcert

      Posté par  (site web personnel) . Évalué à 10.

      Bref, on se pose sérieusement la question de garder CAcert ou pas, j'ai l'impression de trahir un (petit) peu nos convictions si on le fait

      Je ne sais pas quelles sont tes convictions, mais si tu n’apprécies pas le système actuel des CA, la solution n’est pas, à mon sens, de soutenir une CA alternative mais de soutenir une alternative aux CA.

      Par exemple, prendre un certificat quelconque (venant de CAcert ou de n’importe quelle autre CA, ou même autosigné) et :

      • l’épingler dans les en-têtes HTTP (ça ne protège pas la première connexion, mais ça protège les suivantes : rien que ça, c’est déjà mieux que ce que le système PKIX a à offrir) ;
      • le publier dans le DNS et expliquer aux utilisateurs comment utiliser DANE (ce n’est pas plus idiot que de leur expliquer qu’ils doivent ajouter le certificat racine de CAcert dans le magasin de leur navigateur) ;
      • le publier dans la toile de confiance OpenPGP et expliquer aux utilisateurs comment utiliser Monkeysphere ;
      • expliquer aux utilisateurs comment utiliser Convergence.

      Alors, oui, ça demande un peu plus de boulot que simplement se tourner vers une CA qui a l’air un peu plus cool que les autres (mais qui malheureusement, en tant que CA, fait partie du problème, quand bien même elle serait mille fois plus digne de confiance que les autres). À voir maintenant ce que valent les « convictions »…

      • [^] # Re: CAcert

        Posté par  (site web personnel, Mastodon) . Évalué à 9.

        Je ne sais pas quelles sont tes convictions, mais si tu n’apprécies pas le système actuel des CA, la solution n’est pas, à mon sens, de soutenir une CA alternative mais de soutenir une alternative aux CA.

        CAcert ne fonctionne pas comme les autres, c'est pas juste un « CA qui a l'air un peu plus cool que les autres », c'est un système communautaire avec validation en se rencontrant physiquement, le web de confiance. Nos convictions, pour ce cas, c'est surtout favoriser le communautaire et avoir un système plus sécurisé.

        Les choses dont tu parles sont des choses annexes, qui sont envisageables en plus, mais il faut aussi pouvoir gérer au niveau du temps disponible.

        Alors, oui, ça demande un peu plus de boulot que simplement se tourner vers une CA qui a l’air un peu plus cool que les autres (mais qui malheureusement, en tant que CA, fait partie du problème, quand bien même elle serait mille fois plus digne de confiance que les autres). À voir maintenant ce que valent les « convictions »…

        Par contre je ne suis pas super fan du ton que tu emploies. « ça demande un peu plus de boulot que simplement [bla bla bla] » ==> je crois que t'as pas idée du boulot qu'on a à essayer de bien faire les choses justement, et cette façon de tourner la phrase du genre on fait juste un truc à l'arrache pour se donner bonne conscience est légèrement vexante.

        À voir maintenant ce que valent les « convictions »…

        On n'est pas et ne sera jamais irréprochables, mais on essaye de faire au mieux avec les moyens qu'on a. Chaque chose à ajouter, c'est une quantité du boulot derrière, et on en a déjà pas mal, du boulot. Donc petit à petit on améliore ce qu'on peut, on écoute au maximum les commentaires, mais ça prend du temps et de l'énergie.

        • [^] # Re: CAcert

          Posté par  (site web personnel) . Évalué à 7.

          CAcert ne fonctionne pas comme les autres,

          Ça n’a strictement aucune importance. Le problème ne vient pas de CAcert ni d’aucune autre CA prise individuellement. CAcert pourrait bien être absolument parfait, ça ne changerait toujours rien.

          Le problème, c’est le principe même de faire une confiance absolue à des CA qui peuvent signer des certificats pour n’importe qui (et encore, je ne parle pas de la possibilité de signer des sous-CA).

          c'est surtout favoriser le communautaire et avoir un système plus sécurisé.

          Favoriser le communautaire, OK.

          Mais en quoi est-ce plus sécurisé ? Même si CAcert a procédé a une vérification rigoureuse avec multiples rencontres physiques avant de signer ton certificat, ça n’empêche pas le premier pékin venu d’obtenir un certificat frauduleux pour ton site auprès de n’importe quelle CA.

          En tant qu’hôte, tu n’as pas plus de garantie avec CAcert qu’avec n’importe quelle autre CA que personne ne va jouer à l’homme du milieu entre ton site et tes visiteurs. En tant que visiteur, pareil : Mallory peut me présenter un certificat bidon que mon navigateur acceptera sans broncher.

          Ce n’est que si je sais, via un autre canal, que ton certificat est supposé être signé par CAcert et personne d’autre, que je pourrais détecter un homme du milieu avec un certificat frauduleux. Et il n’y a là rien de spécifique à CAcert : par exemple, je sais maintenant que le certificat de DLFP est supposé être signé par Gandi, Mallory ne peut pas me présenter un certificat frauduleux obtenu auprès de insérez ici une CA aux pratiques douteuses sans me mettre la puce à l’oreille.

          En fait, les « alternatives aux CA » dont je parle ne font justement rien d’autre que de fournir cet « autre canal » par lequel un site peut annoncer à ses visiteurs « voici mon certificat (ou le certificat de la CA qui a signé le mien) ».

          Je suis désolé, mais la valeur ajoutée par CAcert et sa communauté est nulle, et ce indépendamment de tous leurs efforts. CAcert n’apporte aucune sécurité parce que le système PKIX dans son ensemble n’apporte aucune sécurité (sauf contre un attaquant passif, mais pour ça même un certificat autosigné est suffisant).

          cette façon de tourner la phrase du genre on fait juste un truc à l'arrache pour se donner bonne conscience est légèrement vexante.

          Tu peux le prendre comme ça. Tu peux aussi voir que je constate que tes choix ne correspondent pas à certaines de tes convictions — celle de vouloir « un système plus sécurisé » (en revanche, je n’ai rien à redire sur la conviction « je préfère un système communautaire ») — et que je ne me contente pas de te le faire remarquer mais je te propose aussi des alternatives pour corriger ça.

          Je ne prétends pas que les alternatives que j’évoque se mettent en place facilement et sans efforts (j’ai mis en œuvre DNSSEC et DANE sur mon serveur, je sais que je n’ai pas fait ça en cinq minutes), mais quelqu’un qui veut un système plus sécurisé que PKIX devrait au moins les considérer.

          En attendant, choisir CAcert, au moins pour le motif « parce que c’est plus sécurisé » (encore une fois, je ne critique pas le choix motivé par l’aspect communautaire), c’est à la fois une solution de facilité et une fausse solution par-dessus le marché.

          • [^] # Re: CAcert

            Posté par  (site web personnel) . Évalué à -5. Dernière modification le 05 juin 2015 à 13:38.

            Ça n’a strictement aucune importance. Le problème ne vient pas de CAcert ni d’aucune autre CA prise individuellement. CAcert pourrait bien être absolument parfait, ça ne changerait toujours rien.

            Bon courage, parce que je m'y suis cassé les dents bien des fois, et à chaque fois les mêmes arguments" reviennent…
            CACert a une seule chose pour lui, c'est sa gratuité (bien mise à mal par StartSSL et en théorie Let's Encrypt bientôt), tout le reste ne change rien aux problèmes dont ses défenseurs parlent, je n'ai jamais compris pourquoi ça revient à chaque fois sur la table (les CA c'est pourri, oui OK, et on propose une alternative qui ne change rien aux problèmes, euh…).

          • [^] # Re: CAcert

            Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 06 juin 2015 à 14:10.

            Tu peux le prendre comme ça. Tu peux aussi voir que je constate que tes choix ne correspondent pas à certaines de tes convictions — celle de vouloir « un système plus sécurisé » (en revanche, je n’ai rien à redire sur la conviction « je préfère un système communautaire ») — et que je ne me contente pas de te le faire remarquer mais je te propose aussi des alternatives pour corriger ça.

            Mais je suis tout à fait OK pour qu'on me dise quand les choix ne sont pas bons, je suis juste très (peut être trop ?) sensible à la forme, et je n'aime pas qu'on me dise qu'on fait les trucs par facilité alors qu'on sait très bien qu'il suffirait de 5 min pour faire un certificat qui ne fasse pas d'avertissement et que justement on prend une autre solution, plus compliquée (c'est facile de faire un certificat CAcert, mais plus compliqué d'expliquer aux gens pourquoi il y a un message de sécurité) parce qu'elle nous semble mieux nous correspondre. Peut-être qu'on ne fait pas le bon choix, et on va en discuter.

            Et je trouve très bien de regrouper sur un commentaire les liens pour qu'on voit facilement ce qu'on peut faire en plus, d'ailleurs ça serait utile d'en fait un journal/une dépêche (un peu comme les dépêches sécurité de Skhaen).

            Bon passons pour ce point.

            Maintenant ces solutions on va les étudier, et on va voir ce qu'il est possible de faire, mais on a aussi beaucoup d'autres choses sur le feu, et ça prend du temps ne serait-ce que de lire les journaux, puis les spécifications, puis chercher des implémentations ou les faire si besoin.

            En attendant, choisir CAcert, au moins pour le motif « parce que c’est plus sécurisé » (encore une fois, je ne critique pas le choix motivé par l’aspect communautaire), c’est à la fois une solution de facilité et une fausse solution par-dessus le marché.

            Ok pour le côté pas plus sécurisé (mais par pour le côté solution de facilité, enfin bref). Pour nous l'aspect communautaire est un point très important, essentiel même, donc le choix de CAcert reste justifié, mais la discussion n'est pas close.

      • [^] # Re: CAcert

        Posté par  (site web personnel) . Évalué à 9. Dernière modification le 05 juin 2015 à 11:56.

        Il y a 3 points différents (plus ou moins entrelacés cependant) dans lesdites convictions, présentés ici sans classement particulier :

        1. la sécurité et le modèle foireux des CA
        2. le logiciel libre
        3. la décentralisation, disons l'indépendance et le fait de ne pas devoir passer par un oligopole pour avoir le droit d'exister en ligne

        Sur le point 1, oui, complètement d'accord sur les alternatives que tu évoques. Pour le moment les points bloquants restent le temps disponible (plus de gens pour vouloir faire des choses ou pour dire comment les faire que pour les faire) et les logiciels disponibles sur nos serveurs. Et je bats ma coulpe et j'aurais préféré bosser sur les alternatives que de me taper le changement de CA par exemple.
        Sur le point 2, signalons quand même que CAcert publie son code sous licence libre, permettant potentiellement à d'autres CA de se créer. L'association LinuxFr a pour « objectif de promouvoir les Logiciels Libres » donc ça reste un point important. On peut considérer que l'on régresse sur ce point en passant par une CA qui à ma connaissance ne publie pas son code.
        Sur le point 3, CAcert offre des fonctions de toile en confiance en plus des classiques certificats. Le site tournant avec une équipe de bénévoles, le fait de devoir demander la permission (payante) à quelqu'un d'autre d'exister en ligne me choque (mais les certificats autosignés ont été voués aux gémonies par les navigateurs).

        • [^] # Re: CAcert

          Posté par  (site web personnel) . Évalué à 0.

          le fait de devoir demander la permission (payante) à quelqu'un d'autre d'exister en ligne me choque

          Pour accéder au grand Internet, on a l'habitude de payer aussi, ou emprunter la connexion de quelqu'un d'autre.
          SSL, c'est pareil : soit on paye soit-même, soit on emprunte celui d'un autre (une petit endroit réservé sur un autre site).
          L'un te choque, mais tu ne parles jamais de l'autre… Et je pourrai trouver plein d'exemple où il faut payer (bon, la carte d'identité n'est plus payante il me semble, le passeport pour pouvoir simplement voyager dans le monde oui, sans compter les visas, désolé ça me dérange bien plus que de devoir payer quelques Euros quand je perd mon certificat que j'ai eu d'une manière automatisée et gratuite)

          Au fait, faut de suite remettre en cause les noms de domaine, tu n'as pas besoin d'un certificat si tu n'as pas de domaine mais te focalises sur le SSL, c'est où qu'on a des domaines gratuits et sans permission, ha ha.
          Bref, c'est incohérent.

          Sur le point 2, signalons quand même que CAcert publie son code sous licence libre, permettant potentiellement à d'autres CA de se créer.

          A mon avis, le code source du CA c'est un tout petit bout du problème (avoir des admins comptants en sécu, passer tous les audits…)
          Pourquoi donc s'obstiner dans une voie sans issue?

          Oui, ça serait mieux d'avoir un truc qui soit gratuit et qui marche. Mais voila, il faut proposer un truc viable plutôt qu'une alternative qui n'en est pas une (ce qu'est CACert, "defective by design" du fait du manque de moyens et qu'il ne corrige aucun problème des CA).

          Vivement DANE ou autre du style, sur lequel il serait mieux de se focaliser quand on dit qu'on veut corriger le problème des CA.

          • [^] # Re: CAcert

            Posté par  . Évalué à 3.

            Pour accéder au grand Internet, on a l'habitude de payer aussi, ou emprunter la connexion de quelqu'un d'autre.
            SSL, c'est pareil : soit on paye soit-même, soit on emprunte celui d'un autre (une petit endroit réservé sur un autre site).
            L'un te choque, mais tu ne parles jamais de l'autre…

            C’est pourtant bien différent comme services. Le premier a des coûts « nécessaires » (équipement réseau, moyens humains, travaux, etc.) pour pouvoir transmettre l'information que tu souhaites entre toi et le reste du monde. Le deuxième est de fournir une identité, cela a bien entendu un coût cependant il n’est pas forcément financier.

            GPG fournit également une identité mais ne te coûte rien, si ce n’est un peu de temps quand tu rencontres des gens.

            Pense-tu que la valeur se résume au coût ?

      • [^] # Re: CAcert

        Posté par  (site web personnel) . Évalué à 4.

        Pour Convergence : le plugin Firefox sous GPLv3, mais non dispo dans les extensions Firefox et malheureusement le site n'est pas dispo en https (il pointe en fait sur whispersystems.org, avec un certificat pour ce domaine). Et le code ne semble pas maintenu. https://github.com/moxie0/Convergence

        On peut trouver Convergence Extra, un fork du précédent, plus récent. Malheureusement il est lui-même annoncé comme « Should not work with firefox 31+, needs compatibility update. » et https://github.com/mk-fg/convergence « Not maintained here since ~2014 and does not work with newer FIrefox versions. »

        Du coup ça me semble difficile d'en faire la promotion en l'état.

  • # recherche interne retour envisagé ?

    Posté par  . Évalué à 2.

    La fonctionnalité de recherche interne n'a cependant pas été remise en service.

    C'est prévu de remettre cela en place un jour ?
    Merki.

    • [^] # Re: recherche interne retour envisagé ?

      Posté par  (site web personnel) . Évalué à 4.

      C'est envisageable, mais pas prioritaire (il y a pas mal d'autres entrées de suivi à gérer avant par exemple).

      • [^] # Re: recherche interne retour envisagé ?

        Posté par  (site web personnel) . Évalué à 4.

        Plus précisément, non, ce n'est pas envisagé pour le moment. Cela demanderait pas mal de temps pour la remettre en place (admin/sys principalement), pour un bénéfice qui ne semble pas très important : on a eu vraiment très peu de personnes qui nous ont signalé que la recherche interne leur manquait (beaucoup moins que ceux qui nous disaient passer par google plutôt que la recherche interne lorsqu'elle existait, notamment). Bref, ce n'est pas à l'ordre du jour, mais si suffisamment d'utilisateurs nous le demande, on le fera.

        • [^] # Re: recherche interne retour envisagé ?

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          On fait avec, mais la solution actuelle ne casse vraiment pas trois pattes à un canard. Les tags ne sont pas mis en avant, il n'y a pas de tri par date ou pertinence… et à moins de connaître les bons mots clés pour retrouver un contenu précis, on ne peut pas dire qu'elle nous soit d'un grand secours.

          On ne peut pas non plus obtenir une vision d'ensemble sur un sujet de donné. Par exemple, si je m'intéresse soudainement à
          G'MIC, j'aurai bien aimé obtenir une timeline avec les différents articles publiés par David Tschumperlé dans l'ordre chronologique de leur parution, plutôt que d'obtenir des résultats en vrac, en me demandant ce que j'ai bien pu rater.

          L'autre gros souci, c'est que l'on obtient des résultats pêle-mêle concernant les dépêches, les journaux, le forum… Je n'ai pas trouvé s'il y avait moyen de restreindre ou de pouvoir obtenir des résultats mieux classés, mais selon ce que l'on cherche, les résultats sont vite pollués, je trouve.

  • # Spam

    Posté par  . Évalué à 2.

    Il est possible que beaucoup d'entre vous ne le remarque jamais ou rarement, mais l'équipe de modération supprime très régulièrement du spam dans les contenus et commentaires.

    Justement vu que je tombe sur ce genre de messages de temps en temps, comment faire pour les signaler ? Ca doit être mes yeux mais je ne trouve rien.

    • [^] # Re: Spam

      Posté par  (site web personnel) . Évalué à 3.

      Les signaler directement : tribune de rédaction, courriel à moderateurs@, IRC ou XMPP ou tribune sur un modérateur/admin, etc.
      Les signaler indirectement : taguer le contenu spam (malheureusement ça signale aussi bien ce qui sont du spam que ceux qui parlent du spam et des antispams), sur lequel certains ont des alertes.

  • # rédaction et assistance en amont

    Posté par  (site web personnel) . Évalué à 3.

    Je reste tout de même étonné du peu d'interaction entre modérateurs et rédacteurs. Je connais les différences, je connais le contexte de validation (et les difficulté de modération, selon la définition reconnue sur pas mal de forums, qui est complètement différente sur LinuxFr.org…).

    Si un jour il faut promouvoir la rédaction, il faudrait peut-être y participer (ce que font beaucoup de modérateurs, en créant des dépêches), pour autant il me semble que l'assistance en rédaction est délaissée ? (je vois ZeroHeure et tankey régulièrement, les autres modos uniquement ponctuellement :/).

    Même si c'est une tribune supplémentaire, je n'ai toujours pas compris l'invalidation de https://linuxfr.org/suivi/tribune-redaction-a-rendre-plus-visible-pour-plus-de-monde :

    • un inscrit à LinuxFr.org pourrait l'ajouter à gauche (comme ce qu'ont les modérateurs avec la tribune de modo)
    • un rédacteur régulier ou irrégulier pourrait l'ajouter, à sa convenance de contribution et de suivi de LinuxFr.org
    • cela mettrait la rédaction en avant pour certains, tout comme la modération l'est pour certains (ce serait la même colonne utilisée)

    Bref, même si je repassais modo, cela me serait bien utile :D
    Et, en tout cas, bravo pour le boulot effectué, je sais la charge que cela peut être et je vois tous les correctifs effectués sur dépêches et journaux après coup (le plus souvent par Oumph< d'ailleurs, parfois par patrick_g ou tankey mais rarement :/).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.