9,90 € TTC
p. 06 FrankenPHP : vers une nouvelle génération de serveurs PHP ?
p. 14 Gestion des releases avec JFrog Artifactory et Nexus
p. 32 Développement de macros en Rust
p. 44 Gestion des périphériques USB sous [Free|Net|Open]BSD
p. 58 Les codes fantastiques : co-vide
p. 60 Alpine.js : un framework JavaScript minimaliste
p. 68 Création d’un serveur web avec Erlang/OTP et inets httpd
Quelque chose m’inquiète (peut-être)...
Une publication sœur (MISC 131) a dernièrement publié un article fort intéressant concernant NYSM et mettant en lumière le danger que présentent des outils de post-exploitation basés sur eBPF, permettant relativement facilement à l’attaquant de dissimuler sa présence ainsi que celle des outils qu’il aura laissés derrière lui.
À la lecture de l’article, on peut naturellement se dire que ceci est relativement étrange. Pourquoi donc eBPF, ou n’importe quel mécanisme de traçage, profilage ou débogage, serait-il activé dans le kernel d’un système en production ? Après tout, la première chose que l’on fait pour un serveur bare metal n’est-elle pas de précisément recompiler un kernel parfaitement adapté au matériel et débarrassé de toutes fonctionnalités et de tous pilotes superflus, inutiles ou potentiellement contre-productifs (dangereux) ?
Il semblerait que non, en tout cas plus de nos jours, où les kernels de distribution sont tout simplement utilisés tels quel, sans autre forme de procès. On m’a même expliqué que c’était la norme et que, je cite « de toute façon, on ne peut plus attendre d’un SRE/SysOps/SysAdmin qu’il sache configurer et recompiler un noyau ». Il est vrai que lorsqu’on voit que la solution « normale » à une fuite mémoire d’un applicatif est un redémarrage récurrent du conteneur ou pod, il est évident que mon questionnement était, a posteriori, très naïf sinon stupide...
Honnêtement, je ne sais même pas si je dois en être inquiet, ou consterné ou simplement me résigner à cette réalité, en me disant que si je n’administre plus de serveurs (et ne veux plus) comme par le passé, préférant m’intéresser au code et uniquement au code, il y a de bonnes raisons. Celle-ci en est clairement une et je vous avouerai même que, quelque part, j’en arrive même à comprendre et apprécier la suppression des LKM d’OpenBSD il y a 10 ans déjà...
Denis Bodor
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...
Programmer en Rust, c’est bien. Mais programmer, toujours en Rust, des générateurs de code Rust, exécutés tout juste au moment de la compilation, c’est mieux ! Voilà ce que permettent les macros, avec toujours cette efficacité redoutable à laquelle nous a habitués ce langage.
Continuons cette série sur les codes fantastiques avec les classes vides de C++
La gestion des artefacts est importante pour garantir la cohérence et la traçabilité des composants logiciels au sein d'un projet. Dans cet article, nous vous présenterons deux plateformes populaires de gestion d’artefacts : JFrog Artifactory et Nexus. Nous aborderons leurs concepts clés, l'installation et la mise en œuvre, ainsi que l'intégration avec les pipelines de CI/CD. Enfin, nous discuterons des avantages de l'utilisation de ces plateformes dans un environnement DevOps.