Alors, la, c'est pas exactement la faute de litellm, ça aurait pu arriver quand même n'importe ou vu que le souci était (sauf erreur de ma part) via une action github. Si un soft que tu utilises est backdooré, ç'est un peu mort.
Mais sinon, j'ai commencé à regarder le code de litellm, parce que j’étais curieux de voir comment il y a pu y avoir autant de code par une équipe si petite en si peu de temps. 382 PR en 1 semaine, 58 auteurs, 19 releases par semaine, il y a clairement de l'automatisation à un moment.
Sans surprise, j'imagine qu'il y a beaucoup de LLM, et c'était l'occasion de voir ce que le code donne (j'avais regardé le depot d'openclaw et j'avais été choqué de voir le bordel à la racine). Et j'ai pas été déçu.
En ouvrant au pif des fichiers, je tombe sur ce code ou j'ai le sentiment que les variables correspondent pas exactement à leur nom. Il y a un deepcopy sans bonne raison, l'organisation des structures semble pifométrique, etc. De même, la fonction get_llm_provider semble faire plus que juste donner le provider, vu que ça donne aussi une clé d'api et une base (et pas un objet provider propre).
les structures de données semblent assez visiblement inefficaces vu que je vois 3 fois le concept de région (une fois pour aws, une fois pour waston x et une fois pour le reste). Peut être qu'il y a des subtilités qui m'échappe, mais je doute.
Et à la racine, il y a un fichier uv.lock, mais aussi un poetry.lock, et un requirements.txt, en même temps. 3 fichiers pour agents (CLAUDE.md, GEMINI.md, AGENTS.md). Le nettoyage existe pas.
Donc bon, on peut pas blâmer litellm pour la compromission résultant d'un vendeur tierce et sans doute de limitation de Github, mais ça reste en effet du code un peu moche et trop complexe.
# Relecture
Posté par Misc (site web personnel) . En réponse au journal Supply chain attack : La faille chez Trivy entraîne des fuites massives par LiteLLM. Évalué à 10.
Alors, la, c'est pas exactement la faute de litellm, ça aurait pu arriver quand même n'importe ou vu que le souci était (sauf erreur de ma part) via une action github. Si un soft que tu utilises est backdooré, ç'est un peu mort.
Mais sinon, j'ai commencé à regarder le code de litellm, parce que j’étais curieux de voir comment il y a pu y avoir autant de code par une équipe si petite en si peu de temps. 382 PR en 1 semaine, 58 auteurs, 19 releases par semaine, il y a clairement de l'automatisation à un moment.
Sans surprise, j'imagine qu'il y a beaucoup de LLM, et c'était l'occasion de voir ce que le code donne (j'avais regardé le depot d'openclaw et j'avais été choqué de voir le bordel à la racine). Et j'ai pas été déçu.
En ouvrant au pif des fichiers, je tombe sur ce code ou j'ai le sentiment que les variables correspondent pas exactement à leur nom. Il y a un deepcopy sans bonne raison, l'organisation des structures semble pifométrique, etc. De même, la fonction get_llm_provider semble faire plus que juste donner le provider, vu que ça donne aussi une clé d'api et une base (et pas un objet provider propre).
les structures de données semblent assez visiblement inefficaces vu que je vois 3 fois le concept de région (une fois pour aws, une fois pour waston x et une fois pour le reste). Peut être qu'il y a des subtilités qui m'échappe, mais je doute.
Et à la racine, il y a un fichier uv.lock, mais aussi un poetry.lock, et un requirements.txt, en même temps. 3 fichiers pour agents (CLAUDE.md, GEMINI.md, AGENTS.md). Le nettoyage existe pas.
Donc bon, on peut pas blâmer litellm pour la compromission résultant d'un vendeur tierce et sans doute de limitation de Github, mais ça reste en effet du code un peu moche et trop complexe.