Gestion des pisteurs



  • Bonjour,

    Actuellement les pisteurs sont gérés via une issue. J’ai du mal à mis retrouver, en particulier quels pisteurs ont été intégrés.

    J’ai rapidement évoqué l’idée sur IRC d’avoir un dépôts dédié à cela. Nous pourrions ainsi avoir un modèle d’issue et un suivi pour chaque pisteur.

    Je ne sais pas comment sont actuellement intégré les pisteurs, mais ça permettrait également d’avoir un outillage pour automatiser tout ça.

    Vous en pensez quoi ? Je peux aider à quel niveau ?


  • administrators

    Bonjour @Sanpi,

    Les pisteurs intégrés on l’icône « youpi » (le chapeau avec le mirliton). Pour l’instant les chasseurs de pisteurs ajoutent un élément å l’issue 40. ce qui permet de faire diverses vérifications manuelles avant une intégration dans le fichier, elle aussi manuelle, pour être certains que les informations ne sont pas erronées.

    Il serait sans doute possible de trouver un moyen de d’automatiser la mise dans la base. Mais il en va en fait de notre crédibilité de rester (pour l’instant, rien n’est figé dans le marbre) dans notre processus manuel.

    Cela ne veux pas dire que nous sommes fermés aux coups de mains 🙂


  • administrators

    Là où je rejoins l’initiative de @Sanpi est que disposer d’un dépôt dédié contenant un fichier par pisteur permettrait de rédiger collaborativement la description de chaque pisteur en suivant le schéma actuel de ceux déjà décrits : https://reports.exodus-privacy.eu.org/trackers/4/


  • administrators

    Il faudrait trouver un moyen simple d’inciter les dénicheurs de pisteurs de faire un fichier par pisteurs et de commiter. Je pense que c’est en plus compliqué que de faire une issue par pisteurs.
    À moins que ce soit à nous de transformer l’issue 40 en autant de fiche de pisteurs, qui serait sous git et récupérée tel que par le front-end.


  • administrators

    @Lovis_IX si nécessaire, je peux m’occuper de découper #40 et faire le nécessaire pour que le mode de contribution change.



  • @lovis_ix a dit dans Gestion des pisteurs :

    Les pisteurs intégrés on l’icône « youpi » (le chapeau avec le mirliton).

    Merci pour l’info 🙂

    Mais il en va en fait de notre crédibilité de rester (pour l’instant, rien n’est figé dans le marbre) dans notre processus manuel.

    Je pense que tu opposes deux choses qui ne sont pas contradictoires : l’automatisation et la vérification. Ça me semble d’ailleurs plus simple de faire une vérification poussée avec un dépôts séparés : on peux discuter longuement chaque pisteurs, utiliser le système d’approbation de github pour être sûr de bloquer l’intégration.

    @lovis_ix a dit dans Gestion des pisteurs :

    Il faudrait trouver un moyen simple d’inciter les dénicheurs de pisteurs de faire un fichier par pisteurs et de commiter.Je pense que c’est en plus compliqué que de faire une issue par pisteurs.
    À moins que ce soit à nous de transformer l’issue 40 en autant de fiche de pisteurs, qui serait sous git et récupérée tel que par le front-end.

    Si on vise un public qui n’est pas en mesure de faire une PR, j’imagine bien un système de modèle d’issue que l’on pourrait facilement transformer en json.


  • administrators

    L’idée est séduisante. Le process d’ajout dans la base à partir d’un json ne coûte pas « trop cher » (et parle en ressource et en temps, Je me range à cette idée.

    Serais-tu à même de mener ce chantier ? Sans doute sous la « direction » de @U-039b qui connaît son code sur le bout des doigts (qui à besoin de lâcher) ?


  • administrators

    @Sanpi j’ai commencé le développement de ETIP a.k.a εxodus tracker investigation platform.

    L’objectif est de disposer d’un outil collaboratif facilitant le travail des personnes dénicheuses de pisteurs. De plus, un dump de 4 234 171 noms uniques de classes Java tirés des 5000+ applications analysées par εxodus est téléchargeable : 24MB TGZ file. Ensuite, il suffit de le décompresser et de jouer avec grep:

    grep -E "com.safegraph.|com.openlocate" uniq_list
    

    com.safegraph.|com.openlocate est la code signature à tester.

    Une preview de démo est disponible temporairement.


  • administrators

    Whaou, quel boulot !



  • Beau boulot en effet, je sens que cette plateforme va devenir le centre de recherche de pas mal de gens concernant les trackers !



  • Je sors la tête des cartons 🙂

    Concernant le format d’entrée, je pensais simplement reprendre l’actuel :

    # Name
    
    * Description: xxxx
    * Short description: xxxx
    * Code signature: `xxx`
    * Network signature: `xxx.com`
    * Website: https://example.com
    * Capability:
        * xxxx
    * Advertising:
        * xxxx
    * Analytic:
        * xxxx
    * Network:
        * xxxx
    * Maven repository: https://example.com
    * Artifact ID: `xxx`
    * Group ID: `xxx`
    * Gradle: `xxx`
    

    J’ai bêtement repris les champs du modèle Tracker de ETIP, dites moi si j’en ai oublié. Il pourrait être pratique d’avoir un commentaire sur le rôles des champs (je n’ai aucune idée à quoi sert ceux en dessous de website).

    Pour faire le travail de conversion, markdown-to-json devrait faire le plus gros du travail.

    Et, en toute logique, la sortie de la moulinette va générer un fichier json par tracker prêt à être importé dans ETIP.

    Dans un second temps, j’imagine bien automatiser l’intégration via un webhook si l’issue porte un label particulier et possède au moins deux revues positives. Dans cette perspective, il faut que l’application ai un point d’entrée http. Du coup je verrais bien tout ça dans ETIP, vous en pensez quoi ?


  • administrators

    Coucou @Sanpi !
    En fait, ETIP avait pour objectif de remplacer l’issue #40 🙂 Et concernant les commentaires des champs, je peux les rajouter dans ETIP.



  • @u-039b Ah carrément, j’étais resté sur un dépôt github séparé 😅


  • administrators

    @sanpi tu veux un compte sur ETIP ou tu en as déjà un ?