IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le Pouvoir des Dix - Règles pour développer du code critique sécurisé,
écrit par Gerard J. Holzmann, traduit par watchinofoye

Le , par Malick

61PARTAGES

11  0 
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.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 30/12/2020 à 14:09
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.
6  0 
Avatar de cryptonyx
Membre actif https://www.developpez.com
Le 29/12/2020 à 14:18
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
1  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 30/12/2020 à 14:49
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).
1  0 
Avatar de cryptonyx
Membre actif https://www.developpez.com
Le 30/12/2020 à 16:21
Citation Envoyé par gangsoleil Voir le message
...
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.
1  0 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 24/02/2021 à 20:03
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 ?
0  0 
Avatar de cryptonyx
Membre actif https://www.developpez.com
Le 30/12/2020 à 16:16
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
0  1