Discussion :

[Malick]

Chers membres du club,

J'ai le plaisir de vous présenter cet article de Gerard J. Holzmann traduit en français par watchinofoye :

Le Pouvoir des Dix
Règles pour développer du code critique sécurisé

Les règles suivantes peuvent présenter des avantages, surtout si leur faible nombre signifie que les développeurs les respecteront effectivement. Chaque règle est suivie d’une brève justification de son utilisation.

Bonne lecture

Retrouvez Les meilleurs cours et tutoriels pour apprendre la programmation.

[cryptonyx]

Tous ces conseils sont intéressants, sauf peut-être, à un degré moindre, le dernier : les messages d'avertissement sont parfois éloignés des considérations de sécurité et chercher à les faire "disparaître" tous peut s'avérer difficile dans certains environnements (et constitue donc une perte de temps inutile).

L'auteur passe néanmoins sous silence d'autres problématiques :
- l'utilisation de la récursivité, qui est à manier avec précaution (ou avec une allocation de pile adaptée) sous peine de plantage intempestif
- le traitement systématique des erreurs
- la protection des éléments secrets dans le code (mots de passe, clés, paramètres d'initialisation divers, etc.) et le nettoyage des conteneurs de ces éléments dans les environnements partagés ou réutilisables
- le choix des algorithmes cryptographiques (quand il y en a)
- le choix des composants tiers (bibliothèques)
- et sans doute d'autres, au cas par cas

[gangsoleil]

Bonjour,

Tout est discutable, et les règles citées ici le sont autant que le reste. Ce ne sont pas forcément les premières à mettre en avant.

1. Récursivité
À condition de ne pas considérer la programmation fonctionnelle, c'est vrai. Mais il ne faut pas oublier que la programmation fonctionnelle est vérifiable, avec récursivité.

2. Boucles avec une limite supérieure fixe
Soit je suis bête (ce qui n'est pas exclu), soit je ne comprends pas comment faire avec une liste chaînée (ce n'est qu'un exemple). Si j'ai une liste chaînée, c'est justement que je ne connais pas le nombre d'éléments, donc à quoi est-ce que ça sert d'ajouter un compteur arbitraire au nombre d'éléments de ma liste ?
Si je connais le nombre d'éléments max, je peux utiliser d'autres structures que la liste chaînée.
Si je ne connais pas le nombre d'éléments max, la valeur arbitraire sera probablement débile, et donc absolument inutile. Et elle va à l'encontre de la règle 1 qui est, en gros, de faire du code simple et lisible.

3. pas d'allocation dynamique de mémoire après initialisation
Ben si, mais il faut savoir ce que l'on fait.
Si je ne peux pas utiliser l'allocation dynamique après l'init, à quoi ça sert d'utiliser une allocation dynamique ???
Le principe de l'allocation dynamique, c'est que je ne connais pas à l'avance la taille dont j'ai besoin. Donc je l'alloue au moment où j'en ai besoin, et je la réalloue lorsque nécessaire (si si, c'est l'intérêt principal). Si je connais la taille à la compilation, ou à l'initialisation, j'utilise une allocation statique.
Ah, et bien sûr j'utilise des outils de profiling pour m'assurer que je n'ai pas de fuites ni d'écrasements ni autres bugs.
Et enfin, utiliser un tableau n'empêche aucunement d'accéder à une case non allouée (qui n'a jamais déclaré un tableau de N éléments (accessibles de tab[0] à tab[N-1]) puis a accédé à tab[N] ?)

4. Fonctions trop longues
Non. Du moins pas dans un gros programme. Ceux sur lesquels je travaille ont environ 1 million de lignes de code (c'est peut-être trop, mais c'est un autre débat). Si je respecte les 60 lignes par fonctions, ça me fait un peu plus de 16 600 fonctions, ce qui est beaucoup trop.
Je veux bien limiter la taille des fonctions, mais aussi leur nombre, ça ne sert à rien de couper une fonction juste pour qu'elle "ne soit pas trop longue" (déjà vu).
Ce qui est vrai, c'est qu'une fonction devrait être minimale, et ne concerner que ce qu'elle doit faire, et ne pas chercher à faire le travail de la fonction d'en face.

[el_slapper]

C'est marrant, les règles 1, 2, et 3 reviennent à écrire en COBOL. Qui interdit ce que l'article proscrit. La règle 9 presque, les pointeurs en cobol, c'est une horreur que personne n'utilise (ou presque).

[cryptonyx]

Un article sur la gestion de projet de développement : https://medium.com/better-programmin...t-1b1657b4d04d

En résumé :
1. Estimates Are Always Wrong
2. The Bigger the Project, the Less Accurate Your Estimate Will Be
3. Focus and Concentration Are Our Most Valuable — and Scarcest — Commodities
4. Hofstadter’s Law Is the Truth (“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”)
5. You Can’t Speed Up Software Development, You Can Only Limit How Much You Slow It Down
6. You Can Only Run in the Red for Very, Very Brief Periods
7. Brain Time Is More Important Than Butt Time
8. Hardware Is Cheaper Than Developer Time — Way Cheaper
9. You Can’t Measure Software Developer Productivity
10. If You Haven’t Read “PeopleWare”, Then You Aren’t Really a Software Development Manager
11. Quality Is a Perception — Not a Bug Count

[cryptonyx]

...

Bonjour,

3. pas d'allocation dynamique de mémoire après initialisation


L'auteur doit venir de la sûreté de fonctionnement (aéronautique, transports au similaire) et dans de type de logiciel "critique", l'allocation dynamique n'est pas la bienvenue. On alloue les variables statiquement (on fait du C à la sauce ADA). Ça explique aussi les boucles finies (pas de while(true) ou d'autres astuces de ce genre).

c.

[air-dex]

En quoi les Xxx::with_capacity() de Rust sont-ils compatibles ou incompatibles avec ces règles, notamment les règles n°3 et n°2 (plus pour les boucles que pour les malloc, certes) ? Ces méthodes là ont pour but d'éviter autant que faire se peut les réallocations au delà d'une limite fixe passée à la méthode. Du coup j'ai toujours trouvé sécurisé et optimisé dans mes codes Rust d'initialiser des collections avec des trucs du genre Xxx::with_capacity(limite_superieure_prevue). Est-ce une bonne pratique, surtout à la vue de ces règles ?