Les Elements de Style

Quoi de plus naturel que de commencer un blog par écrire un article sur l’écriture elle même. Sans prétentions, se laissant emporter par cet acte singulier d’aligner des lettres et de créer des mots, l’écriture émerveille par son apparente simplicité et sa puissance. Ecrire sur les choses, écrire sur écrire, écrire simplement une pensée complexe, faire sonner et raisonner son concept, jouer avec les sons, jouer. Définir semble si difficile tant la structure est entrelacée. Utiliser l’écriture sans savoir. Toute personne raisonnable s’y abstiendrait. Et pourtant…

Writing is an act of faith, not a trick of grammar. William Strunk et E.B. White livrent dans The Element of Style leurs pensées sur le travail d’écriture. Le livre est écrit en anglais, mais certaines remarques semblent s’appliquer de manière général. Ecrire est fastidieux, tant les règles à respecter se succèdent; écrire est libérateur, si pour un court instant l’illusion d’avoir compris se fige et métabolise ces mots qui, plus tard, pourront être relus.
Aussi bien, la tendance actuelle à rapporter « les faits et seulement les faits » s’inscrit davantage dans une logique formelle de l’écriture, où la structure et la rigidité du discours est inspiré de la rigueur arithmétique. Se défausser, laisser les chiffres « parler d’eux même », c’est avant tout perdre foi en l’écriture au profit d’un jeu de grammaire. Sujet-verbe-complément mute en variable-operateur-valeur. Les substitutions opèrent et le calcul s’intensifie pour décider qui de ces équations en viendrait à perturber le système. A ce jeu là, la machine aura tôt fait de mettre un peu d’ordre.

Ecrire c’est toucher du doigt le mystère même de la rigueur. C’est emprunter dans l’infini des possible un des chemins qui semble convenir. Est ce le plus court? Probablement pas. Le plus beau? Si seulement. Où va-t-il? Un peu plus loin. Le style est un choix, une géométrie, une topologie. Choisir ses mots, c’est voir ici une vaste étendue plane, monter là-bas une colline, avancer timidement dans une zone inconnue. Les mots sont farceurs après tout. Comment se fait-il que ‘court’ soit court tandis que ‘long’ est court? Alors, est-ce si sérieux? Jouons donc ensemble!

Ce qui est fascinant dans l’écriture, c’est la puissance génératrice du language. Un alphabet fini laisse place à un champ infini de constructions. L’aspect grammatical viendrait supporter et expliquer la fonction logique de chaque mots. Le style accompagne et met en relation. Ecrire, c’est croire en cette idée que la phrase contient une dynamique propre, presque physique, qui agirait sur le sens possible de chaque mots.

Cette symbiose entre rigueur et style apparait aussi sous une forme plus moderne. Ainsi, The Element of Programming Style, s’attache aux règles générales à adopter pour écrire un programme informatique. Le style est présenté comme une structure nécessaire pour être lu et compris par soi même ou un autre. La différence, cependant, reste que ces règles stylistiques sont dictées dans un langage autre que le langage de programmation. La machine est exclue du processus stylistque et ne peut que raisonner fonctionnellement (et non relationnellement) sur son langage.
Quels phénomènes informatiques pourraient traduire et représenter le style propre à un programme? À quand un langage de programmation qui prendrait le concept stylistique au sein même de son système formelle?

« Rust: the Future of Systems Programming » par Josh Triplett à l’Open Source Technology Summit 2019

Logo officle Rust

Voici un résumé complété de quelques notes d’une vidéo de Josh Triplett, ingénieur système chez Intel, sur l’utilisation de Rust dans ce qu’il appelle la programmation système.

Définition du « systems programming »

Josh Triplett définit le « systems programming » (programmation système) par le développement logiciel de composants tels que : BIOS, firmware, bootloaders, kernel, systèmes d’exploitation, équipements embarqués, machines virtuelles et (surprise) navigateurs webs ! De toute évidence ce dernier point ne fait pas l’unanimité. Selon Josh Triplett, la grande complexité des navigateurs web et leurs nombreuses fonctionnalités et interactions justifient leur intégration dans la définition. Ce n’est pas la 1ère fois que les navigateurs webs sont comparés à de véritables systèmes d’exploitation, d’ailleurs c’est sur cette base que Google a créé son système d’exploitation ChromeOS pour ses ordinateurs Chromebooks.

Le systems programming est autrefois passé de l’assembleur au langage C

Les ingénieurs ont longtemps continué à développer les BIOS, firmwares et bootloaders directement en assembleur tandis que pour les autres logiciels on utilisait déjà des langages de programmation avancés. Aujourd’hui, ils sont quasiment intégralement programmés en C et complétés en assembleur.

Que faut-il pour permettre un changement de langage ?

Un basculement d’un langage de programmation à un autre n’est possible qu’à 2 conditions : des fonctionnalités (features) inédites suffisamment intéressantes dans le nouveau langage, et la parité (parity) c’est-à-dire un nouveau langage au moins aussi « capable » ou autrement dit qui permet de faire tout ce que permet l’ancien langage aussi bien, sinon mieux.

Fonctionnalités intéressantes

Il est important que les apports soient non importants afin de compenser l’effort nécessaire pour changer de langage.
Exemples de fonctionnalités intéressantes : sûreté du typage (type safety), des constructions abstraites (high-level constructs), du code plus lisible, …

Parité du C avec l’assembleur

C peut faire à peu près tout ce que fait l’assembleur, n’est pas sensiblement moins rapide dans la plupart des cas, et permet si besoin d’exécuter directement du code assembleur. Sans cela, il n’aura probablement jamais remplacé l’assembleur en tant que principal langage de programmation système !

C is the new assembly

Aujourd’hui, de nombreux développeurs veulent utiliser d’autres langages que le C principalement pour 2 raisons :
– Les difficultés du C (notamment les buffer overflows ou la gestion de la mémoire mais pas seulement)
– Les fonctionnalités offertes par d’autres langages
La gestion automatique de la mémoire est une obligation incontournable pour tout langage de programmation de plus haut niveau que le C pour la programmation système mais ne suffit pas pour être une alternative intéressante.
La facilité d’utilisation et l’efficacité d’un langage vont de pair avec la sécurité : écrire moins de code permet de limiter les risques d’erreur. De la même manière, automatiser des tâches difficiles et promptes à l’erreur (exemple : la gestion de la mémoire) limite l’erreur humaine.

Hors, la parité est jugée difficile à atteindre par Josh pour la programmation système.

Is Rust the new C?

Rust peut être considéré comme une alternative intéressante au C pour la programmation système selon Josh.

Genèse du Rust

Développé par Mozilla, le langage de programmation Rust a été pensé pour être fiable et très performant pour permettre de construire des systèmes complexes comme un navigateur web.
Il faut savoir que Firefox est programmé dans plus d’une dizaine de langages de programmation ce qui rend très complexe certaines tâches de développement ou de maintenance !

Gestion de la mémoire automatique : la façon Rust

Rust gère automatiquement la mémoire, contrairement au langage C. Rust n’utilise pas de garbage collector (processus automatisé qui libère régulièrement la mémoire qui n’est plus référencée, au détriment des performances) comme les langages Python, C#, Go, Java ni de runtime comme le langage Java (on détaille à la suite les inconvénients d’un runtime).

Rust utilise son concept original de propriété (ownership).
Tout objet dans la mémoire a un propriétaire. La propriété d’un objet a toujours un périmètre donné / une durée de vie ou validité (appelé lifetime). Le propriétaire d’un objet peut être typiquement la variable qui « est » ou pointe vers cet objet, qu’il soit dans la pile ou sur le tas (selon le type d’objet). Si on veut manipuler un objet existant, on peut le faire de 2 manières : en l’empruntant ou en le copiant.

L’emprunt

Il existe 2 types d’emprunt (borrowing) : mutable (modifiable) ou partagée (non mutable). Si on emprunte un objet en mutable, on ne peut pas l’emprunter par ailleurs simultanément (ni en mutable ni en partagé). On peut par contre avoir pour un même objet plusieurs emprunts partagés simultanés (comme le nom l’indique).
Chaque emprunt a un lifetime. Ce concept permet de garantir le partage fiable (safe) de la mémoire entre les variables et fonctions d’un programme via les emprunts.

La copie

Si on copie un objet, on est le propriétaire de la copie. On ne manipule plus l’objet original. Par exemple, copier un integer de 32 bits crée un nouvel integer de 32 bits sur la pile. Lorsqu’un objet est détruit, toute la mémoire est libérée (dans la pile et sur le tas suivant le type d’objet), en général sans impact notable sur la performance à l’exécution.

Au contraire en C, la mémoire est gérée manuellement par les développeurs. Un exemple est donné de scénario de problème de gestion de mémoire : dans le cas de l’usage d’une bibliothèque, la documentation peut préciser qu’une fonction renvoie un nouvel objet qu’il faudra libérer après usage, ou renvoie une référence à une partie d’un objet qu’il ne faudra pas libérer avant d’avoir terminer avec l’objet englobant. Une erreur d’un développeur peut alors mener à des bugs pouvant même affecter la sécurité du logiciel, hors l’erreur est humaine ! Au contraire, Rust s’occupe de ces aspects à la place du développeur.

Absence de runtime en Rust

L’absence de runtime est nécessaire en programmation système pour rivaliser avec le C. Un runtime ne permet pas efficacement la programmation système car il implique d’initialiser certains éléments avant l’exécution de tout code et ne permet pas de maitriser complètement tout le code qui est exécuté.

Programmation concurrente fiable

Rust permet plus facilement qu’avec d’autres langages comme le C de faire de la programmation concurrente fiable (« safe »). Il est utilisé par Firefox Quantum notamment pour mettre en forme les pages web via le CSS de manière fragmentée, en traitant en parallèle différentes parties de la page. C’est une tâche très complexe car elle nécessite de tracer exactement les interdépendances entre les différents éléments de la page. L’article Mozilla plus bas témoigne de plusieurs échecs de Mozilla de développer une telle fonctionnalité avec d’autres langages. Il se trouve par que la gestion automatique de la mémoire de Rust permet également de facilement suivre l’interdépendance des processus, threads et objets du langage.

Quelques enquêtes avec des chiffres intéressants sur Rust et les problèmes de gestion de la mémoire :
– Rust est le langage favori des développeurs depuis 3 ans (version 1.0) selon Stack Overflow
70% des bugs affectant la sécurité des produits Microsoft sont liés à la gestion de la mémoire
– 73.9% des bugs de sécurité du composant de firefox appliquant les feuilles CSS aux pages web n’auraient pas pu exister, le composant fut-il écrit en Rust

La parité du Rust vis-à-vis du C

Pour certains types de développement, Rust n’est pas encore aussi capable que le C.
Voici 3 fonctionnalités de C incontournables que Rust permet et qui les rendent interopérables :
– Les fonctions : Rust peut utiliser les fonctions C ou fournir des fonctions que C peut utiliser
– Structures : Rust permet de construire des structures compatibles avec les structures C et peut manipuler les structures C
– Pointeurs : Rust permet de manipuler les pointeurs directement, comme le C

Rust est donc souvent utilisé par-dessus du C pour construire des structures plus complexes (et compatibles avec le code C existant) comme des APIs.

Josh travaille actuellement à la parité du Rust avec le C. Il a travailler à l’intégration de l »union (fonctionnalité du C) à Rust dans le cadre d’un projet de machines virtuelles en Rust. Il a créé et fait partie d’un working group pour la full parity entre Rust et le C, notamment ses plus communes extensions. Il travaille à la réduction de la taille des binaires produits par le compilateur de Rust, l’intégration de l’assembleur dans le Rust de manière plus fiable que le C, la meilleure maitrise des fonctionnalités offertes par les processeurs sous-jacent : vérifier que certaines fonctionnalités sont disponibles lors de la compilation, utiliser des formats nouveaux comme le bfloat16 (utilisé par exemple en machine-learning par Tensorflow sur des processeurs Intel).

Beaucoup d’autres fonctionnalités sont actuellement en cours de développement pour permettre la full parity, et plus encore.

Notes de fin

Première article sur un langage de programmation, le Rust est plutôt en vogue. Mozilla semble avoir frappé fort, espérons qu’ils continuent à contribuer à l’informatique en développant des technologies fiables et sécurisées !
Merci à Victor pour ses éclaircissements sur le concept de propriété du Rust.

certbot : fin de TLS-SNI-O1, mise-à-jour et changement du mode d’authentification

alt text

Le 18 et le 26 janvier 2019, j’ai reçu 2 mails de noreply@letsencrypt.org

Voici le 1er :


De : noreply@letsencrypt.org
Sujet : Action required: Let’s Encrypt certificate renewals

Hello,

Action is required to prevent your Let’s Encrypt certificate renewals from breaking.

Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days.

TLS-SNI-01 validation is reaching end-of-life and will stop working on February 13th, 2019.

You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire.

If you need help updating your ACME client, please open a new topic in the Help category of the Let’s Encrypt community forum:

https://community.letsencrypt.org/c/help

Please answer all of the questions in the topic template so we can help you.

For more information about the TLS-SNI-01 end-of-life please see our API announcement:

https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209

Thank you,
Let’s Encrypt Staff


Suivi du second qui le complète :


De : noreply@letsencrypt.org
Sujet : Action required: Let’s Encrypt certificate renewals

Hello,

Action may be required to prevent your Let’s Encrypt certificate renewals
from breaking.

If you already received a similar e-mail, this one contains updated
information.

Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue
a certificate in the past 60 days. Below is a list of names and IP
addresses validated (max of one per account):

l.q.d.n (1.2.3.4) on 2018-MM-JJ

TLS-SNI-01 validation is reaching end-of-life. It will stop working
temporarily on February 13th, 2019, and permanently on March 13th, 2019.
Any certificates issued before then will continue to work for 90 days
after their issuance date.

You need to update your ACME client to use an alternative validation
method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your
certificate renewals will break and existing certificates will start to
expire.

Our staging environment already has TLS-SNI-01 disabled, so if you’d like
to test whether your system will work after February 13, you can run
against staging: https://letsencrypt.org/docs/staging-environment/

If you’re a Certbot user, you can find more information here:
https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210

Our forum has many threads on this topic. Please search to see if your
question has been answered, then open a new thread if it has not:
https://community.letsencrypt.org/

For more information about the TLS-SNI-01 end-of-life please see our API
announcement:
https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209

Thank you,
Let’s Encrypt Staff


(j’ai remplacé mon nom de domaine par l.q.d.n et mon adresse IP publique correspondante par 1.2.3.4)

Ces mails expliquent que la méthode d’authentification que j’utilisais jusqu’à maintenant pour obtenir ou renouveler des certificats TLS Let’s Encrypt sera bientôt obsolète et que je dois en changer.
J’ai toujours utilisé certbot pour configurer mes certificats TLS obtenus via let’s encrypt. Je fais partie de cette « jeune » génération qui n’a jamais eu besoin de payer pour avoir ses sites personnels en HTTPS 🙂

Comme toujours lorsqu’il faut modifier un système auquel on touche peu (j’avais automatisé le renouvellement de mes certificats par un cron puis par un timer systemd pour m’amuser, je n’avais pas touché à certbot depuis un certain temps) j’ai une certaine appréhension. Bien souvent, il va falloir dépatouyer 3-4 autres problèmes avec de traiter le sujet.

1ère étape : suivre le lien du mail concernant les utilisateurs de certbot. 1ère mauvaise surprise : mon certbot des dépôts stretch debian stable est en 0.10.2-1 (comme on peut le voir sur packages.debian.org tandis que le guide précise que certbot devrait être mis à jour au moins à la version 0.28. En suivant le lien vers le site officel de certbot puis en choisissant nginx puis Debian 9 stretch je vois qu’il faut que j’installe certbot via les dépôts stretch backports de Debian.

Je commence donc par supprimer ma version actuelle :
apt remove certbot
puis j’installe la version backports (le dépôt était déjà configuré ainsi que le plugin nginx (que j’utilise en reverse-proxy donc c’est mon serveur web accessible depuis l’internet) :
apt install -t stretch-backports certbot python-certbot-nginx

Ensuite, puisque j’ai des fichiers de configuration de renouvellement de mes certificats let’s encrypt dans /etc/letsencrypt/renewal il me suffit de lancer la commande :
certbot renew --dry-run
pour vérifier que tout se passe bien. L’option --dry-run permet selon la doc de tester la commande sans sauvegarder de certificat.

Voici un de mes fichiers de fichiers de configuration de renouvellement de mes certificats :

version = 0.28.0
archive_dir = /etc/letsencrypt/archive/l.q.d.n
cert = /etc/letsencrypt/live/l.q.d.n/cert.pem
privkey = /etc/letsencrypt/live/l.q.d.n/privkey.pem
chain = /etc/letsencrypt/live/l.q.d.n/chain.pem
fullchain = /etc/letsencrypt/live/l.q.d.n/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = nginx
account = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
server = https://acme-v02.api.letsencrypt.org/directory

(j’ai remplacé mon nom de domaine par l.q.d.n et mon numéro de compte par des x)

Dans cette nouvelle version de certbot (par rapport à celle que j’avais) le renouvellement des certificats est automatique. Pour ce faire, un cron est ajouté à /etc/cron.d/certbot et un timer systemd (si vous utilisez systemd) à /etc/systemd/system/timers.target.wants/certbot.timer. Le fichier cron indique que le cron n’est pas lancé si systemd est utilisé car le timer a la « priorité ».

Par défaut, le timer va tenter le renouvellement toutes les 12h. C’est un peu abusif à mon goût, les certificats étant valables 90 jours… le renouvellement ne s’effectuera que pour les certificats expirant dans moins de 30 jours. En calculant, le script de renouvellement ne se lancera donc que 1/120 fois !

Je voudrais modifier le timer afin que le renouvellement se fasse au plus dans un délai de 20 jours. C’était ce que je faisais avant avec un timer personnel, malheureusement il a été supprimé lorsque j’ai désinstallé le certbot installé depuis les dépôts stretch stable. Ce sera l’objet d’un autre billet (peut-être) car ce n’est pas si évident que ça en a l’air : les timers sont plus puissants que les cron mais aussi plus complexes.

Note de fin

1er article sur une configuration technique. Je compte en faire d’autre suivant les difficultés que je pense se retrouveront chez beaucoup d’autres. C’est surtout une manière pour moi de conserver une trace au cas où je devrais itérer la manip’ (ce qui arrive de temps en temps).

La cène de l’informatique

L’infocène : n.m., période géologique durant laquelle l’action de l’informatique a de fortes incidences sur l’évolution de la planète et de l’espèce humaine.
L’informeur : n.m., toute personne qui donne forme à l’information.
La cène : n.f., repas du soir au cours duquel Jésus lava les pieds de ses apôtres et institua l’Eucharistie (rien à voir)

L’infocène a déjà commencé. L’informatique a plongé ses racines dans l’espèce humaine. La symbiose s’opère, la planète mute. Membres de cette Infocène, Dylan & BenJ, nous sommes deux informeurs. L’informeur se questionne, écrit et compose avec l’informatique. Notre but est simple : formaliser et partager l’information. Notre moyen : la patience, la volonté, un médium et vous.

Ce blog a pour objectif d’étudier des sujets variés qui nous sont chers : l’informatique et la technologie. Nous voulons préciser et appronfondir notre compréhension et notre perception d’un monde en pleine transormation.
La curiosité nous pousse à rechercher et amasser l’information sous forme d’actualités, de billets de blog, de discussions et de débats, concernant principalement l’innovation, les mathématiques, les sciences ou la technologie. On prendra plaisir à formaliser et condenser ces apprentissages et en y ajoutant note grain de sel.

Les articles seront alternativement

  • des condensés d’actualités formant des dossiers succints et précis, appuyés de sources fiables ;
  • des billets plus courts sur des innovations ou des actualités ;
  • des guides techniques ou des présentations d’applications nous tenant à coeur ; des guides pratiques sur la gestion de la vie numérique ;
  • des recommandations personnelles d’oeuvres littéraires ou artistiques liées à tous ces sujets qui nous attirent ;
  • et plein d’autres heureusités…

Nous espérons également garder une souplesse et une légèreté pour rendre la lecture et la rédaction agréable 🙂

~ Nous donnerons une forme à l’information technique ou abstraite.