Une équipe américaine vient de tester les machines à voter de trois fabricants.
Les résultats sont sans appels : des failles extrêmement sérieuses permettant de modifier les votes sans aucun problème!
Certaines de ces failles pouvaient être effectuées avec juste une clé usb partitionnée correctement pour lancer l'autorun de windows, et a partir de la lancer un trojan.
D'autres montrent que la database utilisée comporte des failles corrigées , mais que les patchs n'ont pas été appliqués !
Ps il faudra qu'on m'explique quel est l'utilité d'une bd sql pour une élection.
Un fichier plain text me semble bien plus intelligent et plus rapide a parser (et plus simple et plus facilement securisable).
Bref des trucs codés avec des pieds vendus a prix d'or, et étant contreproductif.
L'avènement de l'IT, et surtout des entreprises (parasites) s'accompagne de tas de choses bénéfiques...
L'article, en anglais.
http://arstechnica.com/news.ars/post/20070729-california-vot(...)
Journal Les machines a voter, définitivement pas sur.
30
juil.
2007
# .
Posté par snt . Évalué à 4.
>Un fichier plain text me semble bien plus intelligent et plus rapide a parser (et plus simple et plus facilement securisable).
Si il faut qu'on t'explique l'avantage d'une base de données sur un fichier texte lorsque que l'on souhaite stocker des données de manière sure et fiable, alors tu es peut etre pas le mieux placé pour te moquer des solutions mises en oeuvre ;-)
[^] # Re: .
Posté par nats . Évalué à 6.
Pour ce qui est de la sûreté de ces machines, on savait déjà... Maintenant c'est officiel...
Mais je pense qu'il en faudra plus pour faire reculer les fanatiques technocrates...
[^] # Re: .
Posté par snt . Évalué à 2.
Et donc il n'y a aucun risque d'avoir une corruption de données ? Avec un sgbd, tu as normalement des mécanismes sophistiqués pour éviter de n'écrire que la moitié de ton integer par exemple..
Bref, ça fait des années que des types bossent pour constuire un systeme robuste et sécurisé, alors qu'en fait il suffisait d'utiliser un fichier texte !
Pour les failles inutiles, il suffit de ne pas choisir un SGBD qui manque de maturité ( comme le SGBD, c'est un concept un peu plus vieux que le web 2.0, on en trouve quand meme quelques-uns ).
Et puis si on veut vraiment aller à l'economie de moyen et tout reinventer en se passant de l'experience accumulée depuis des décénies, on peut aussi de passer d'OS sur la machine et tout coder directement en ASM. Ca sera léger, rapide et surement blindé dès qu'on sortira du chemin nominal d'execution.
[^] # Re: .
Posté par nats . Évalué à 5.
Sur ce genre de machine... OUI à ta dernière proposition qui me paraît la plus saine...
Ou du moins un OS minimaliste et retouché pour l'occasion...
Et encore moins un truc proprio commercial.
Pas besoin de Flash pour une interface bidon...
Franchement c'est de l'embarqué là quand meme... Et puis les gens ils appuient pas 50 fois la seconde sur la touche...
[^] # Re: .
Posté par briaeros007 . Évalué à 3.
Un sgbd a pas franchement la meme utilité qu'un fichier texte.
Ca a des systemes d'indes, de recherche, d'intégrité (comme tu le fait remarquer) de reprise a chaud ou a froid etc...
Mais toute ces fonctionnalités ont une complexité et un coup.
Un bête fichier texte, ou n bêtes fichiers textes, avec un chattr +a et un support du fs en 'sync' offre une bien meilleur protection qu'un gros bousin de bd sql lors qu'il s'agit juste de foutre des données, fortement semblable, a la queulele.
Sans compter que la redondance permet de récupérer en cas de corruption, (on peut utiliser aussi un systeme de crc/hash), et avec le support en sync et en chattr+a, cela permet une reprise a froid tout a fait correcte.
Pour les failles inutiles, il suffit de ne pas choisir un SGBD qui manque de maturité ( comme le SGBD, c'est un concept un peu plus vieux que le web 2.0, on en trouve quand meme quelques-uns ).
Tu me dis qu'un code de plusieurs centaines de milliers de lignes de code introduit autant de faille qu'un code d'une centaine de lignes ?
Balèze la.
Et puis si on veut vraiment aller à l'economie de moyen et tout reinventer en se passant de l'experience accumulée depuis des décénies, on peut aussi de passer d'OS sur la machine et tout coder directement en ASM. Ca sera léger, rapide et surement blindé dès qu'on sortira du chemin nominal d'execution.
Sauf qu'un sgbd ne fait pas franchement QUE de l'intégrité.
Pour faire que de l'intégrité on a des trucs bien plus mieux : raid, voir zfs en raidz2 et ditto block.
(Zfs a des écritures atomiques, mais chut j'ai rien dis hein).
[^] # Re: .
Posté par Éric (site web personnel) . Évalué à 6.
Bref, un fichier de texte ouvert en écriture avec un flush et un FS journalisé, *ici* ça offrira autant ou presque que ce que peut proposer un SGBD évolué.
En effet, recoder tout soit même est très rarement "mieux", mais là quand il s'agit juste de faire un compteur fixe sans concurrence d'accès et sans contraintes de performances ... utiliser une couche SQL je vois mal ce que ça peut apporter de positif.
[^] # Re: .
Posté par Alex . Évalué à -1.
Mouais
Eventuellement le fs peut te garantir une écriture, mais rarement l'atomicité de gros blocs de data (sachant qu'en plus ton programme ne les écrit pas obligatoirement en une fois). De plus utiliusé une db qui a été testé et éprouvé de nombreuses fois me parait plus sur que de réinventer et réimplémenter les règles ACID ( http://en.wikipedia.org/wiki/ACID ). De plus une db n'est pas obligatoirement quelque chose de très lourd (et pas obligatoirement du sql dailleurs), te garantie l'intégrité de tes données, même après un crash de la machine, et te permet de les récuperer/trier/analyser aisément.
[^] # Re: .
Posté par briaeros007 . Évalué à 3.
Zfs ...
En plus : 'gros blocs de data' ... Tu fous quoi dans ton vote, toutes les news de linuxfr a chaque vote ?
De plus une db n'est pas obligatoirement quelque chose de très lourd (et pas obligatoirement du sql dailleurs), te garantie l'intégrité de tes données, même après un crash de la machine, et te permet de les récuperer/trier/analyser aisément.
Enfin la on parlait de sql serveur ...
De plus utiliusé une db qui a été testé et éprouvé de nombreuses fois me parait plus sur que de réinventer et réimplémenter les règles ACID ( http://en.wikipedia.org/wiki/ACID ).
Zfs + checksum interne a zfs ...
[^] # Re: .
Posté par Alex . Évalué à 1.
Ben ca j'aimerai bien le savoir, mais on en sait rien justement
Enfin la on parlait de sql serveur ...
Oui en effet ...mea culpa
Zfs + checksum interne a zfs ...
Ben justement là on est au niveau du fs, pas de l'applicatif, zfs te garanti qu'une écriture de l'appli se passe correctement, si l'appli effectue ses écritures en plusieurs fois le fs n'en sait rien. La db te garantie que tout se qui est fait entre le début et la fin d'une transaction sera bien conforme a ACID
[^] # Re: .
Posté par briaeros007 . Évalué à 1.
Ensuite si le programme fait appel a la bd de facon idiote en plusieurs fois, la bd non plus va pas retrouver ses petits : si les codeurs codent comme des porcs c'est normal que ca merdouille a la fin.
La db te garantie que tout se qui est fait entre le début et la fin d'une transaction sera bien conforme a ACID
Zfs aussi, ca tombe bien.
[^] # Re: .
Posté par Alex . Évalué à 1.
[^] # Re: .
Posté par briaeros007 . Évalué à 3.
et je suis meme pas sur que tu ne peux pas faire des transaction 'compliquées'.
Mais bon, je rapelle qu'initialement on était sur ... UN SIMPLE VOTE ELECTRONIQUE!
Pas un truc avec plein de transaction, trigger et autre.
Donc tout l'argument 'ouais avec un sgbd on peut faire plein de transaction' , qui meme si il est vrai, ne s'applique pas !
Tu part quand meme d'une hypothèse ultra forte 'et si il veut rajouter plein de données'. Et quand je te pose la question tu répond,
Ben ca j'aimerai bien le savoir, mais on en sait rien justement
Je sais pas donc supposons que pour le vote électronique il fait des transaction de 1 Go ?
Je suis le seul que ca choque ?
[^] # Re: .
Posté par Éric (site web personnel) . Évalué à 4.
Certes, reste à voir l'utilité de "gros blocs de data" dans le cadre d'un vote. Inscrire un octet à chaque vote dans le fichier au nom du candidat choisit ça garde une atomicité très simple à garantir. Tu n'auras jamais de démi octet écrit donc l'écriture ton bloc de data sera atomique.
# Ca la fout bien...
Posté par nats . Évalué à 10.
Ca c'est quand même le Must Have !
[^] # Re: Ca la fout bien...
Posté par briaeros007 . Évalué à 2.
# fichier texte
Posté par vincent LECOQ (site web personnel) . Évalué à -3.
>Un fichier plain text me semble bien plus intelligent et plus rapide a parser (et plus simple et plus facilement securisable).
Super, plusieurs millions d'electeurs qui votent parfois en meme temps, comment tu assures que l'écriture dans le fichier texte va etre atomique ?
[^] # Re: fichier texte
Posté par allcolor (site web personnel) . Évalué à 10.
[^] # Re: fichier texte
Posté par nats . Évalué à 3.
[^] # Re: fichier texte
Posté par snt . Évalué à 2.
Tu implementes ton propre systeme de transaction pour ne pas perdre ce qui avait été comptablisé jusque là ou tu te contentes de planter ? Si tu écris ton propre truc, je prefére utiliser un soft qui a fait ses preuves dans ce genre de condition. Et si tu contentes de planter, je t'embauche pas :-p
[^] # Re: fichier texte
Posté par nats . Évalué à 2.
Ou même qu'il y a un problème dans la jonction électrique au niveau de la carte mère...
...
Et si jamais au moment du vote une bombe atomique explose à 4000km que des particule et autres perturbations viennent troubler la transaction SQL, est-ce que l'on a prévu un sytème de sauvegarde des votes...
Non mais sérieusement on peut trés bien avoir des sytèmes basiques de sureté sans déployer un SQL... Ca fait un peu lourd...
[^] # Re: fichier texte
Posté par Uriel Corfa . Évalué à 8.
Ultime comme invention, je vous dis !
[^] # Re: fichier texte
Posté par Éric (site web personnel) . Évalué à 3.
> compteur ?
La même chose que s'il y a une erreur de disque pendant que ton SGBD transactionnel bosse ?
- c'est une erreur non détectée par le logiciel, ça merdera sur le fichier texte mais aussi sur ton SGBD
- c'est une erreur renvoyée par l'OS mais le système continue de tourner : le SGBD comme la fonction d'écriture vont te répondre que l'écriture n'a pas eu lieu, à toi d'en faire ce que tu veux
- le système crashe, au redémarrage tu peux récupérer le journal d'écriture (celui du FS dans le cas du fichier texte, et en plus celui du SGBD dans ton cas), et là dans les deux cas l'écriture du journal peut être incomplète et on perd le dernier vote, soit elle est complète et on peut la récupérer.
Reste le cas où on écrit une demi ligne dans le fichier texte avant le crash, mais il existe des solutions très simples pour palier le problème (genre un fichier par candidat, à chaque vote on écrit un octet dedans : aucun risque de demi écriture ou d'écriture incohérente, et cette dernière solution est vachement plus sécurisée pour ce cas d'utilisation que tout ce que tu pourras faire avec ton moteur transactionnel).
Bref, dans les deux cas on peut perdre le dernier vote, dans les deux cas on ne peut perdre que le dernier vote (sous réserve de faire un flush entre chaque écriture).
[^] # Re: fichier texte
Posté par BAud (site web personnel) . Évalué à 5.
[^] # Re: fichier texte
Posté par vincent LECOQ (site web personnel) . Évalué à 0.
Ou alors il y a un vrai moyen d'exporter les données (d'ou le port USB certainement), et si possible dans un format pratique a importer dans la base complete ?
[^] # Re: fichier texte
Posté par nats . Évalué à 2.
[^] # Re: fichier texte
Posté par Axone . Évalué à 5.
Ensuite les résultats sont communiqués par téléphone à la préfecture dans la soirée. Les PV doivent être transmis physiquement un peu plus tard.
[^] # Re: fichier texte
Posté par abgech . Évalué à 5.
Monter un sémaphore n'a rien de vraiment bien sorcier !
[^] # Re: fichier texte
Posté par kolter (site web personnel, Mastodon) . Évalué à 1.
man flock
M.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.