Gouverné par des illettrés de l’informatique
Alors que le service des impôts devrait libérer son code source, cette libération de code devrait également être étendue aux autres services administratifs.
Mais c’est sans compter le Sénat, dont certains membres manifestent encore leur incompétence sur les sujets débattus (incompétence qui va pourtant se répercuter sur 65 millions de personnes).
En effet, selon un sénateur :
Transmettre le code source d’un logiciel permet (...) d’accéder aux informations qui régissent ce logiciel, il n’y a plus besoin de le pirater !
Et aussi :
le projet de loi Lemaire permet aux administrations de refuser la diffusion de certains documents administratifs (dont les codes sources) dès lors que leur divulgation porterait atteinte “à la sécurité des systèmes d'information des administrations”. Selon le député Luc Belot, […] il s’agit de protéger la sécurité informatique des administrations.
(source)
Ils n’ont encore rien compris (ou personne leur a expliqué, mais s’ils avaient demandé, on n’en serait pas là).
Ce raisonnement est complètement crétin : c’est pas parce qu’un algo est caché qu’il est sécurisé.
Si une application est mal foutue, ce n’est pas en cacher le code source qui la rendre plus sécurisée. Ça donne l’illusion de sécurité, mais ce n’est justement qu’une illusion.
Prenons un exemple : quand vous avez une porte protégée par un digicode, le clavier du digicode n’est ni protégé par un verrou ni gardé par un policier. Tout le monde y a accès et tout le monde peut essayer de deviner le code. La sécurité du digicode ne réside pas dans le fait que le clavier du digicode soit accessible ou non. La sécurité réside dans le fait que le code secret soit bien secret. C’est tout.
Dans le code de la cryptographie c’est pareil : le logiciel, le formulaire, le code source n’ont pas besoin d’être secrets, si les clés de chiffrements (les mots de passes, si vous préférez) sont suffisamment sécurisées.
En pratique, ces clés de chiffrement sont très longues et très compliquées. Elles sont générées de façon très complexe, en utilisant des variables aléatoires, impossibles à reproduire même en utilisant le même programme dans les mêmes conditions. La sécurité (et la difficulté d’un bon système de chiffrement) réside là : dans l’unicité du mot de passe grâce au caractère l’aléatoire qu’on injecte dans les clés, puis dans le fait que ces clés soit bien secrètes.
La totalité des grands systèmes de chiffrements utilisés partout, que ce soit RSA, AES, et leur implémentations comme TLS (utilisé sur les sites « https » comme celui de votre banque) ou PGP/GPG et bien d’autres, sont en fait open-source et souvent également libres. Ça ne les a jamais empêchés d’être suffisamment forts pour être utilisés à grande échelle (et de continuer à donner beaucoup de fil à retordre à la NSA).
Si vous voulez retenir quelque chose, retenez ça : en sécurité informatique ce n’est pas l’algorithme qu’il faut cacher. Ce sont les clés (mots de passe) qu’il faut cacher.
De la même façon, cacher le code d’un programme utilisé par les administrations ne rendra pas le système moins vulnérable. Au contraire : s’il y a des failles de sécurité dans un programme lisible par des millions de personnes, alors des millions de cerveaux seront plus à même de les déceler que les 4 ou 5 stagiaires qui font les programmes.
ÉDIT : pour répondre à certaines questions dans les commentaires et pour éviter de dévier.
On parle ici de codes sources financés par l’argent public. Il n’est pas admissible que ceux qui payent pour ça n’y aient pas accès. L’État Français ce sont les citoyens, pas une poignée d’élus.
À ce titre, la question (selon moi) à débattre en général n’est pas si on doit libérer le code source, mais plutôt comment s’y prendre.
Le rôle du sénateur c’est justement de dire si oui ou non il veut rendre au peuple ce qui lui revient de droit. Il n’est pas là pour causer technique comme il le fait.
Pour la seconde question, comment s‘y prendre, c’est ensuite le rôle d’experts et d’ingénieurs en informatique de faire le travail, et d’y parvenir.