HN Digest
Briefing personnel.

Lire vite.
Garder l'essentiel.

Les meilleurs longs formats de Hacker News, relus plus calmement.

11521 articles Page 997/1153 Sans filtre

Glassworm is back: A new wave of invisible Unicode attacks hits repositories

Une nouvelle vague d’attaques menée par le groupe Glassworm se propage désormais sur GitHub, npm et le VS Code Marketplace grâce à des caractères Unicode invisibles qui dissimulent le payload. Les injections reposent sur des caractères invisibles dans des chaînes entre backticks apparemment vides, dont le contenu est décodé et ensuite exécuté via eval. Le déploiement s’étend à des dépôts GitHub, des paquets npm et des extensions VS Code, ce qui élargit fortement le périmètre d’attaque. Le bilan évoque des centaines de dépôts compromis et des cibles de valeur, avec des commits de couverture réalistes générés par des modèles de langage. Des mesures de détection et de protection actives sont nécessaires, et des outils comme Aikido proposent une détection des injections invisibles et Safe Chain aide à bloquer les menaces en temps réel.

SpiceCrypt: A Python library for decrypting LTspice encrypted model files

Il s'agit d'une bibliothèque Python destinée à déchiffrer les fichiers LTspice chiffrés des modèles. Elle prend en charge deux formats de chiffrement distincts : le format texte DES et le format binaire, avec une détection automatique du format. L'installation peut se faire en tant qu'outil via uv ou en tant que dépendance d'un projet, et elle nécessite Python 3.10 ou plus sans dépendances externes. L'interface en ligne de commande offre une commande spice-decrypt permettant de déchiffrer vers stdout, vers un fichier ou en mode verbeux, et de traiter des données hex brutes. L'API Python expose des fonctions telles que decrypt et decrypt_stream pour déchiffrer des données en mémoire ou en flux, avec une détection automatique du format.

//go:fix inline and the source-level inliner

Go 1.26 met à disposition une nouvelle implémentation du sous-commande go fix, centrée sur un inliner au niveau source, pour aider à moderniser le code et à proposer des migrations d’API en libre-service. Cet inlining remplace un appel par une copies du corps de la fonction appelée, en substituant les arguments, ce qui modifie durablement le code source et se distingue de l’inlining du compilateur qui agit sur une représentation intermédiaire éphémère. Par exemple, on peut annoter des fonctions avec //go:fix inline pour que leurs appels soient remplacés par leurs homologues modernes, comme remplacer ioutil.ReadFile par os.ReadFile. Le système s’appuie sur six aspects techniques difficiles, dont l’élimination des paramètres, les effets de bord, les expressions constantes faillibles, l’ombre des noms, les variables inutilisées et le cas des defer. Ainsi, l’objectif est d’obtenir un code plus propre et sûr sans changer le comportement, mais l’inliner peut rester trop conservateur et nécessiter un nettoyage manuel, tout en invitant les développeurs à tester l’outil et à proposer des améliorations.

The Linux Programming Interface as a university course text

Bien que je n'aie pas ciblé spécifiquement le marché universitaire lors de la rédaction, j'ai reçu des courriels de professeurs utilisant l'ouvrage comme texte obligatoire ou recommandé dans des cours sur Linux ou la programmation système UNIX. Je suis très intéressé par obtenir des détails sur l'utilisation de cet ouvrage dans les cours universitaires afin d'envisager une édition future adaptée à ce marché. Si vous êtes un enseignant universitaire utilisant cet ouvrage comme manuel de cours, merci de me contacter pour m'informer de votre utilisation. Pourriez-vous me communiquer, autant que possible, le nom et l'URL de votre établissement, un aperçu du cours, le niveau du cours, le nombre d'étudiants et si l'ouvrage est utilisé comme texte obligatoire ou recommandé. En particulier, j'aimerais que vous répondiez à ces questions afin d'améliorer une prochaine édition pour le milieu universitaire.

Separating the Wayland compositor and window manager

Les anciens compositeurs Wayland présentent une architecture monolithique qui réunit serveur d'affichage, compositeur et gestionnaire de fenêtres dans un seul programme. La version 0.4.0 de river rompt avec cette approche en séparant le gestionnaire de fenêtres du compositeur dans un programme distinct. Le protocole stable river-window-management-v1 donne au gestionnaire de fenêtres le contrôle des positions, des raccourcis clavier et des politiques de gestion, tandis que river assure le rendu et les fonctions bas niveau. Cette séparation réduit les obstacles à l'écriture d'un gestionnaire de fenêtres et permet d'utiliser des langages plus lents ou à ramasse-miettes sans compromettre les performances. Quinze gestionnaires de fenêtres existent déjà pour river et le projet vise une version 1.0 avec rétrocompatibilité, tout en restant limité aux paradigmes 2D et sans VR pour l'instant.

Stop Sloppypasta

Partager une production brute d'IA équivaut à manger de la junk food: c'est facile et peut sembler satisfaisant, mais ce n'est pas dans votre intérêt. L'effort de lire ne change pas lorsque le texte est généré par une IA, tandis que l'effort d'écriture devient presque gratuit, ce qui crée un déséquilibre cognitif. Avant les LLMs, écrire impliquait réflexion et choix intentionnels qui soutenaient la compréhension et la mémoire du lecteur. Les LLMs peuvent produire des réponses convaincues sans vérification fiable, et leur augmentation de la verbosité accroît l'incertitude du lecteur. Ainsi, la confiance doit être vérifiée avec diligence et chacun doit exiger traçabilité et vérification pour éviter d'éroder la crédibilité collective.

How far can you go with IX Route Servers only?

Les points d'échange Internet (IX) relient des routeurs sur un même LAN pour faciliter le peering BGP et l'échange de trafic. Les route servers (RS) agissent comme des route reflectors BGP qui distribuent les routes reçues à tous les membres, évitant que chaque réseau ne forge des sessions individuellement. Le trafic n'est pas acheminé par les route servers eux-mêmes, les échanges se faisant au niveau du LAN et les RS coordonnant potentiellement d'importants volumes. La sécurité des RS est généralement meilleure que celle des sessions bilatérales, grâce à des pratiques renforcées comme l'IRR, le RPKI ROV, Peerlock et la validation de l'AS_PATH. Les résultats suggèrent qu'une part limitée des prefixes est atteignable via les RS, ce qui pousse certains opérateurs à privilégier les PNIs ou les liaisons privées pour le trafic entrant tout en utilisant les IX pour l'apprentissage des routes sortantes.