GitHub : impossible de rechercher du code sans se connecter

 (github.com/orgs)
1 points par GN⁺ 2023-11-29 | 1 commentaires | Partager sur WhatsApp
  • Dans une discussion GitHub Community, le fait que même la recherche de code dans les dépôts publics ne soit plus utilisable sans connexion a été pointé comme un problème, et l’auteur de la question critique une atteinte à l’accessibilité du code public et à l’utilité de l’open source
  • Un mainteneur de GitHub a répondu que la recherche sur l’ensemble des dépôts nécessitait déjà une connexion depuis longtemps, et qu’au début de 2023, avec le renforcement des fonctions de recherche, l’exigence de connexion a aussi été étendue à la recherche dans un dépôt individuel
  • Selon GitHub, la raison est de supporter la charge de recherche destinée aux développeurs et de réduire les situations où les serveurs sont submergés par des requêtes anonymes provenant notamment de bots
  • Les participants à la discussion ont mis en doute le fait que l’obligation de se connecter suffise à bloquer les bots, puisque les dépôts publics peuvent toujours être clonés puis fouillés localement, et ont évoqué des alternatives comme le rate limit, les CAPTCHA ou une simple limitation des recherches
  • En pratique, les utilisateurs non connectés ne peuvent plus ouvrir directement des liens de recherche dans du code public, ce qui a conduit à discuter aussi de méthodes de contournement comme grep.app, github1s, grep en local, les moteurs de recherche généralistes ou le mirroring sur plusieurs Git forge

L’obligation de connexion s’applique à la recherche dans le code public

  • La GitHub Community Discussion #77046, intitulée “Can no longer search code without being logged in”, traite de la situation où il est impossible de rechercher du code sans être connecté
  • L’auteur de la question explique qu’il voulait chercher quelque chose dans son dépôt depuis un ancien appareil, mais n’a pas pu aller plus loin à cause de l’obligation de se connecter
    • Il a dû accéder à son gestionnaire de mots de passe, passer par la 2FA et utiliser une YubiKey, mais son vieux portable n’avait pas de port USB-C, ce qui l’a bloqué
    • Il précise qu’il voulait permettre à d’autres de pouvoir utiliser la recherche dans le code de ses dépôts publics
  • L’auteur critique le fait qu’un dépôt public puisse toujours être cloné puis analysé avec des outils dédiés, ce qui rend selon lui difficile à justifier l’exigence de connexion pour la recherche de code sur le Web
  • La discussion a été marquée comme Answered à la suite de la réponse de GitHub, et la page affiche 19 commentaires et 58 réponses

Réponse de GitHub et justification officielle

  • Le mainteneur GitHub martinwoodward s’est excusé pour la gêne occasionnée et a répondu que la recherche sur l’ensemble des dépôts demandait déjà une connexion depuis longtemps
  • Il explique qu’au début de 2023, lors du renforcement des fonctions de recherche, l’exigence de connexion a aussi été étendue à la recherche dans des dépôts individuels
  • L’objectif principal, selon lui, est de soutenir la charge de recherche pour les développeurs GitHub et d’empêcher que les serveurs soient submergés par des requêtes anonymes de bots, entre autres
  • Pendant la discussion, un autre participant a partagé le lien vers The technology behind GitHub’s new code search, qui présente la nouvelle implémentation de la recherche de code de GitHub

Le cœur des critiques : dépôts publics et accessibilité de l’open source

  • Plusieurs participants estiment que, puisque le code des dépôts publics peut être cloné sans connexion, le fait de bloquer aussi la recherche dans le code public par une connexion est une mesure excessive
  • Un participant explique qu’il est gênant d’imposer une connexion GitHub à des personnes externes simplement pour consulter son code source public
    • Il donne en exemple des requêtes de recherche comme repo:USER/REPO, path:..., AND NOT path:**/_externals, qu’il voulait partager via une URL unique ou un bouton
    • À cause de l’obligation de connexion, il dit devoir les remplacer par plusieurs URL directes vers des fichiers
  • D’autres participants soulignent la tension entre la communication de GitHub comme “world's largest open source community” et la restriction de la recherche dans le code public
  • Certains commentaires se souviennent qu’une limitation similaire existait déjà avant le rachat par Microsoft et rétorquent donc que cette restriction n’est pas entièrement nouvelle

Débat sur les bots et le coût

  • GitHub invoque la charge liée aux requêtes anonymes de bots, mais certains participants affirment que l’obligation de connexion ne suffit pas à décourager les opérateurs de bots dédiés
  • Comme alternative, il est proposé d’appliquer d’abord un rate limit, puis d’exiger un CAPTCHA ou une connexion une fois la limite atteinte
  • D’autres rétorquent que, puisque les dépôts publics peuvent être clonés anonymement, les bots peuvent simplement basculer vers une recherche locale
    • Un autre participant répond que le clone n’utilise pas la puissance de calcul de recherche de GitHub et réduit donc un vecteur de déni de service
    • Il est aussi noté que des données clonées peuvent devenir rapidement obsolètes
  • Si le coût de la recherche est élevé, certains suggèrent aussi de fournir aux utilisateurs non connectés des requêtes simples via un mécanisme plus léger, et de réserver les requêtes complexes aux utilisateurs connectés

Limites de la fonction de recherche elle-même et comparaisons

  • Un participant indique que même en étant connecté, une recherche sur tous les dépôts publics avec path:contributing.md ne renvoie que 5 pages de résultats
    • Un autre précise qu’il ne s’agit pas d’un problème propre à cette requête, mais d’une limite actuelle de la recherche, et mentionne à ce propos la GitHub Community Discussion #9868
  • Un autre participant compare le fonctionnement de la recherche sur SourceForge, Google Code archive, GitLab et Bitbucket
    • Il affirme que SourceForge et Google Code archive n’ont pas de fonction de recherche
    • GitLab exigerait une connexion pour la recherche globale, tout en permettant la recherche par dépôt
    • La recherche de Bitbucket redirigerait vers une connexion, mais permettrait une recherche sans connexion une fois le dépôt trouvé

Méthodes de contournement et services alternatifs

  • Pour rechercher rapidement dans un dépôt unique sans être connecté, une procédure utilisant un clone local puis grep est proposée
    • aller dans /dev/shm
    • git clone https://github.com/user/repo
    • entrer dans le dépôt puis lancer grep -r "pattern" .
    • supprimer le dépôt après la recherche
  • Pour rechercher un motif sur l’ensemble de GitHub, il est suggéré d’utiliser un moteur de recherche généraliste avec "pattern" site:github.com
    • Il est toutefois précisé que cette méthode n’est pas aussi puissante que la recherche intégrée de GitHub et que certains morceaux de code peuvent ne pas être indexés
  • grep.app est cité comme outil alternatif ou complémentaire, capable de rechercher dans des dépôts sans connexion
  • Une autre astuce partagée consiste à remplacer github.com par github1s.com dans une URL GitHub pour ouvrir le dépôt dans une interface de type VS Code en ligne
  • Comme Git forge alternatifs, GitLab, Framagit, Gitea, Forgejo, Codeberg et Gogs sont mentionnés, certains permettant d’activer la recherche dans le code en auto-hébergement

Conseils sur l’hébergement des projets

À lire aussi

1 commentaires

 
GN⁺ 2023-11-29
Avis sur Hacker News

  • En considérant cette affaire sous l’angle le plus charitable, la nouvelle recherche de code GitHub est, à l’usage, vraiment excellente et pourrait être une fonctionnalité très consommatrice de ressources, car elle fait en interne bien plus de choses qu’un moteur de recherche généraliste
    La limiter aux comptes connectés peut faire économiser énormément de ressources serveur qui auraient autrement été consacrées aux crawlers. Le compromis semble ici se résumer à dépenser 3 à 4 fois plus, voire davantage, pour l’infrastructure de recherche, ou bien à se faire critiquer pour exiger une connexion. J’ai moi-même créé un outil de recherche de code pour les dépôts GitHub, mais la recherche de code GitHub par défaut est tellement utile que je ne m’en sers presque plus : https://simonwillison.net/2020/Nov/28/datasette-ripgrep/

    • La raison la plus réaliste semble être que les gens râleront puis finiront par créer un compte, et que GitHub pourra se vanter d’une croissance du nombre de nouveaux utilisateurs
      À l’inverse, les utilisateurs existants peuvent être irrités de ne même plus pouvoir chercher sans être connectés. Sur le PC de quelqu’un d’autre, un ordinateur public, un onglet privé, ou quand l’authentification à deux facteurs prend du temps, c’est assez pénible. GitHub aurait pu laisser aux utilisateurs non connectés une recherche basique, peu coûteuse et rapide, mais ne l’a pas fait
    • Les raisons techniques sont intéressantes, mais ce n’est pas le cœur du sujet
      Au final, il devient impossible de participer à « l’open source hébergé sur GitHub » sans s’inscrire à GitHub
    • Plusieurs raisons sont avancées, mais il semble très probable qu’en réalité ils veuillent, ou doivent, éviter le scraping de contenu par des entreprises et chercheurs liés à l’IA
    • Si c’est intentionnel, Microsoft est vraiment détestable ; si c’est simplement de l’incompétence, il n’est pas surprenant qu’ils aient raté quelque chose d’aussi simple
      grep est un outil vieux de 50 ans, il n’est pas nécessaire d’écrire son propre code pour faire de la recherche textuelle, il suffit d’utiliser du logiciel libre. On ne parle pas d’une startup amateur avec une appli CRUD et trois développeurs, mais de l’une des entreprises technologiques les plus grandes et les plus riches au monde, incapable de fournir correctement une recherche textuelle sans connexion : c’est consternant. S’il existe une troisième explication, je serais curieux de l’entendre
    • En interne, la recherche de code, c’est simplement Elasticsearch, donc il n’y a rien de spécial
      Les explications de GitHub sonnent globalement comme du baratin. Imposer une authentification sur un endpoint public n’est pas une solution adaptée au problème qu’ils prétendent résoudre. Les créateurs de bots intéressés par cet endpoint n’ont qu’à les faire se connecter avec des comptes gratuits, donc cela ne réduit pas significativement la charge serveur

  • Cela a commencé il y a au moins 6 mois et a été annoncé dans le journal des changements : https://github.blog/changelog/2023-06-07-code-search-now-req...
    Discussion HN : https://news.ycombinator.com/item?id=36230929

    • Je suis surpris que cela soit présenté comme une nouveauté. J’ai l’impression que cela date déjà de plusieurs années, au point de ne plus vraiment me souvenir de la dernière fois où j’ai fait une recherche sans être connecté
      Du point de vue business, je comprends parfaitement pourquoi ils l’ont fait. Cela transforme littéralement les gens en utilisateurs, tout en augmentant l’engagement des utilisateurs

  • Il faut arrêter de traiter GitHub comme une plateforme ouverte
    GitHub est un jardin clos comme les autres services. Le fait qu’il héberge beaucoup de projets open source que nous utilisons ne le rend pas meilleur ; cela peut même le rendre pire. Car nous avons contribué à placer une partie de l’infrastructure de contribution de ces projets derrière le verrou d’un compte d’entreprise

    • Du point de vue de l’utilisateur, qu’il faille créer un « compte d’entreprise », un compte GitLab auto-hébergé quelconque, ou des comptes Bugzilla, wiki et autres systèmes git, c’est la même chose
      Parmi ces options, je pense même qu’un compte GitHub est préférable. Il permet de participer à un nombre presque illimité de projets sans devoir sans cesse créer de nouveaux comptes ni se connecter ailleurs. Il est difficile de dire que GitHub bloque quoi que ce soit de substantiellement différent des autres options dans ce domaine. GitHub a créé de bons logiciels et les a fournis gratuitement, les a gardés assez ouverts et accessibles, a suivi les standards lorsqu’il en existait, a fourni des API pour le reste, et a offert gratuitement aux projets open source d’énormes capacités de stockage et de calcul
    • Il faut aussi rappeler que GitHub a aidé énormément de projets open source à grandir
      Il propose l’hébergement Git, l’hébergement de wikis, les issues, GitHub Actions, GitHub Pages, ainsi qu’une API correcte. Il y a beaucoup de très bonnes raisons de mettre un projet open source sur GitHub

  • En 2023, le Web s’est vraiment refermé. StackOverflow, Reddit, GitHub et Twitter ont tous freiné le scraping et l’accès aux API
    Le déclencheur a été la combinaison de la volonté d’empêcher l’entraînement de l’IA et de la pression sur la rentabilité. Il y avait aussi des réalités commerciales comme le ralentissement du secteur tech, les nouveaux propriétaires de Stack et de X, ou encore la préparation de l’IPO de Reddit. À long terme, je pense que le marché des données propriétaires va prendre de l’ampleur. Les moteurs de recherche, les outils d’IA et tous ceux qui ont besoin de données devront payer pour accéder aux flux de données sources ou aux API ; et si seules les entreprises les plus riches peuvent acheter ces données, cela pourrait déboucher sur des problèmes antitrust

    • Au bout du compte, tout le monde finira probablement par trouver normal que « StackOverflow, Reddit, GitHub, Twitter » vendent l’accès à des contenus créés et possédés par d’autres
      Si quelque chose relève vraiment de données propriétaires, la rémunération devrait revenir au propriétaire, pas à un opérateur quelconque de serveur Git. Le prix et les conditions devraient aussi être fixés par le propriétaire, pas par l’opérateur du serveur. Si le serveur doit gagner de l’argent, il peut facturer le service de base lui-même. À l’inverse, si quelqu’un a créé quelque chose dans l’intention de le partager, et que la plateforme de l’époque fournissait un canal efficace pour cette diffusion tout en se présentant elle-même comme adaptée à ce partage, changer les règles en cours de route revient moralement à pirater le travail de cette personne. Une grande partie des contenus de ces plateformes n’aurait probablement jamais été mise en ligne si leurs véritables propriétaires avaient anticipé des restrictions arbitraires et des frais d’accès. Pour réécrire radicalement les règles, les contenus existants ne devraient être vendus que si l’auteur original y a explicitement consenti. Or Reddit a même activement restauré des publications que leurs auteurs avaient supprimées en masse pour empêcher ce genre d’abus
    • Cette tendance existait depuis plus longtemps, mais cette année, beaucoup plus de choses ont été verrouillées
      https://theoatmeal.com/comics/reaching_people
    • Pour être juste, GitHub fournit encore la plupart de ses fonctionnalités, hors recherche de code, via des endpoints d’API publics anonymes
      Les limites de débit y sont simplement beaucoup plus strictes. Créer un compte GitHub est gratuit et plutôt peu intrusif. Même connecté, on ne peut de toute façon pas faire tomber les serveurs, car toutes les API ont des limites de débit. C’est pour cela que des outils comme https://gitstar-ranking.com/ ont du mal lorsqu’ils tentent de récupérer les étoiles GitHub de tous les dépôts avec un compte gratuit. Les données réellement importantes, à savoir le code source, peuvent être clonées anonymement via un endpoint HTTPS, puis on peut effectuer la recherche de code localement. Des sites tiers comme https://grep.app/ fonctionnent aussi de cette façon. Dans le cas de Reddit/Twitter, les données sources — publications, commentaires, votes, tweets — ne sont plus fournies via API, ce qui rend difficile ou impossible la création d’outils tiers ; avec GitHub, la situation est assez différente, car les données sources restent facilement accessibles et seule la couche auxiliaire qu’est la recherche est bloquée pour les utilisateurs non connectés
    • C’est à la fois vrai et faux. ExpertsExchange était célèbre pour garder ses réponses « derrière un mur » et ressemblait à StackOverflow
      Je me souviens qu’au lancement de StackOverflow, on le comparait à expertsexchange tout en le jugeant « ouvert ». Il est maintenant temps de passer de services centralisés à une architecture plus distribuée et fondée sur les microtransactions. Beaucoup de gens sur HN détesteront ça, mais les forums de questions-réponses, l’agrégation de liens d’actualité et de commentaires, l’hébergement Git avec flux de validation, wikis et systèmes de tickets peuvent — et devraient — être implémentés de manière entièrement distribuée. Des approches comme les technologies Kademlia/BitTorrent, IPFS ou des CryptoTokens pour les paiements par microtransactions sont possibles. Passer au 100 % distribué est la seule façon de garder ces choses « ouvertes » et à l’abri de la cupidité des entreprises. Même quand un fondateur démarre avec de bonnes intentions, à long terme le produit finit souvent par être vendu et les comptables prennent les commandes

  • En interprétant cela de bonne foi, la recherche exige pas mal de calcul, et peut donc devenir un gros vecteur d’attaque par déni de service
    Je ne sais pas combien de données comportementales GitHub peut collecter auprès des utilisateurs connectés, ni à quel point elles sont utiles par rapport au code déjà public. Elles peuvent servir à déterminer quelles parties du code sont importantes, mais il est difficile d’y voir des informations propres à chaque utilisateur

    • C’est un vrai problème pour quiconque propose une fonction de recherche
      Environ 0,5 % seulement du trafic de mon moteur de recherche vient d’humains. Je ne connais pas beaucoup de moteurs de recherche qui n’aient pas des statistiques similaires
    • Cette collecte de données comportementales est exactement la méthode Microsoft, donc inutile d’appliquer une interprétation charitable
      Depuis le jour du rachat par MS, je ne vois plus de raison valable pour qu’un projet open source reste sur cette plateforme. Ce n’est pas comme s’il n’existait pas de bonnes alternatives accessibles avec un simple git clone
    • Autre facteur : si l’on autorise anonymement la recherche par regex à facettes sur un énorme corpus de code, des acteurs malveillants peuvent trouver des identifiants codés en dur pour accéder à d’autres systèmes, sans laisser de piste d’audit correcte
      Il existe donc plusieurs explications possibles au verrouillage de l’API

  • Quand je ne suis pas connecté, j’utilise Sourcegraph. Par rapport à l’ancienne recherche, il a même l’avantage d’être bien meilleur
    C’est aussi simple que de coller l’URL d’un dépôt en partant de github.com. Par exemple, on peut rechercher unit dans ce dépôt sur sourcegraph.com/github.com/rust-lang/rust/

  • Une partie du fossé IA de Microsoft consiste à contrôler la capacité des concurrents à exploiter les informations de GitHub
    Je ne serais pas surpris qu’ils commencent ensuite à limiter même git clone

    • Je serais surpris qu’ils limitent git clone, car cela casserait beaucoup trop de systèmes de CI
      Il faudrait dire adieu à une grande partie de NPM, à la gestion des paquets Go, aux scripts Jenkins, etc.
    • Je me demande si, même lorsque le code est derrière une connexion, voire derrière un abonnement payant, on peut encore l’appeler open source au regard de la licence du dépôt
      Dans mon souvenir, GitHub applique déjà des limites de débit pour ralentir les usages excessifs de clone ou d’API

  • Même si je suis d’accord avec la position de la personne qui a posé la question, je ne vois pas bien s’il était nécessaire de le dire comme ça
    Je ne suis pas non plus entièrement d’accord avec cette position, dans la mesure où la recherche n’est pas forcément bon marché et peut être utilisée pour des attaques de type DOS. Je ne vois pas en quoi des phrases du genre « comme si monétiser jusqu’à chacun de mes passages aux toilettes ne suffisait pas, maintenant vous voulez suivre quelles lignes de code je regarde » peuvent aider. Il faut se calmer. L’argument de fond n’est pas non plus très solide. Les dépôts eux-mêmes ne sont pas bloqués derrière une connexion : les dépôts publics restent accessibles publiquement, y compris via clone. Si l’auteur souhaite que son dépôt et son code soient utiles au public, au-delà du simple téléchargement et de la recherche, dès qu’un contributeur crée une issue ou envoie une PR, il devra de toute façon se connecter

    • Il est très souvent nécessaire de pouvoir rechercher rapidement dans le code source
      C’est utile pour comprendre comment quelque chose fonctionne, ou pour en discuter ailleurs que dans les issues GitHub. Un clone est généralement rapide, mais pas pour les très gros dépôts, et il se peut aussi qu’on n’ait pas assez d’espace sur l’appareil en cours. En plus, si beaucoup de gens se mettent à cloner à chaque fois au lieu de se connecter — d’autant que la connexion à GitHub est pénible à cause de l’authentification à deux facteurs — je me demande si la charge système diminuerait vraiment. Tout le monde n’a pas non plus envie d’avoir un compte GitHub

  • HackerNews : il devient impossible de consulter la première page sans tomber sur des plaintes disant qu’un service gratuit et sans publicité n’est pas fourni aux utilisateurs non connectés

    • L’adage « si c’est gratuit, c’est vous le produit » est vrai dans la plupart des cas
      Dans ce cas-ci, votre code sert notamment à entraîner Copilot. Et même si ce n’était pas le cas, et que le service était vraiment aussi bien intentionné que vous le croyez, peut-on applaudir en voyant le service se dégrader pour pas mal d’utilisateurs ? Est-ce quelque chose d’intéressant et d’enthousiasmant ?
    • Y a-t-il des éléments pour étayer cet argument ? Je consulte HN presque tous les jours, mais les posts du type « on ne peut pas faire X sans se connecter » ne me semblent pas particulièrement populaires
      Le seul exemple qui me vient à l’esprit est le changement d’API de Reddit, mais c’était il y a un bon moment et ce n’est lié à la connexion que de manière assez lâche

  • Si vous voulez continuer à faire des recherches dans l’open source, https://sourcegraph.com/search ne nécessite pas de connexion et inclut aussi de grands projets qui ne sont pas sur GitHub
    Pour info, je suis le CTO de Sourcegraph

    • Comme je ne veux pas me connecter avec mon compte GitHub personnel sur l’ordinateur de l’entreprise, j’utilise toujours Sourcegraph quand j’ai besoin de rechercher dans des dépôts
      Avant, j’espérais que la recherche GitHub puisse rivaliser avec git clone + grep, mais je ne pensais pas que cela se paierait par une barrière de connexion. Dans mon souvenir, la connexion n’était requise que parce que c’était une fonctionnalité bêta, et je m’attendais à ce qu’elle soit supprimée une fois la recherche de base disponible
    • Je me demande pourquoi vous avez choisi d’autoriser la recherche sans connexion, tout en exigeant une connexion pour Cody