Un système de vote électronique est intrinsèquement plus complexe que le système traditionnel. La complexité étant le pire ennemi de la sécurité, même si en théorie il est possible de développer un système de vote électronique infalsifiable, cela n'arrivera sans doute jamais car il y aura toujours bien une faille quelque part que ça soit dans le design ou l'implémentation.
Le système traditionnel n'est pas infalsifiable mais le falsifier de manière à pouvoir influencer significativement un vote semble nécessiter passablement plus de ressources que dans le cas d'un vote électronique. De plus, vérifier un vote classique semble plus aisé que vérifier un vote électronique, surtout quand on n'y comprend rien (comme c'est le cas de la vaste majorité des votants).
Une organisation qui envisagerait la manipulation des votes en passant par un « hackage » de machines à voter va sans doute passer un peu plus que 3 jours sur le problème. Cette initiative est intéressante mais je doute qu'elle permette de trouver des trucs plus intéressants que ce qu'un collège d'experts digne de ce nom a déjà trouvé et cela ne permettra certainement pas de déclarer le système « sûr ».
La garantie de temps de contournement se heurte au même problème que celle du temps de rétablissement. Je peux t'expliquer comment réinstaller le système pour contourner le problème (OK, c'est un peu extrême mais pas forcément la solution de contournement la plus lente à déterminer et mettre en place) et répondre à tes questions en moins de 60 minutes (ou au moins te tenir au courant de l'avancement des recherches toutes les 60 minutes) mais je peux pas garantir combien de temps ça va te prendre pour réinstaller (mais si t'as prévu le coup, ça devrait aller vite).
Bon, en pratique dans mon expérience, le temps de contournement est souvent bien en dessous de 60 minutes.
> Et au passage, puisqu'on parlait de Debian, y a-t-il quelqu'un qui
> propose au moins un temps de réponse garanti sur de la Debian, en France ?
Je serais aussi intéressé de connaître la réponse. Ça m'étonnerait un peu qu'on trouve des société qui offrent des contrats génériques de ce type (comme le font Red Hat, Novell,...) mais on peut sans doute trouver des intégrateurs/consultants qui fournisse ce genre de support/maintenance pour les trucs qu'ils installent (y compris l'OS qui est potentiellement du Debian).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
> * S'il faut attendre d'une entreprise qui vient d'atteindre 300 personnes
> autant que d'une entreprise de 5000 employés ?
Red Hat, c'est environ 3000. Novell, d'après Wikipedia, c'est environ 4000. Certes il reste un facteur 10 et je suis incapable de commenter pertinemment sur les proportions des contributions de chacun mais il serait quand même intéressant d'arrêter de donner n'importe quoi comme chiffres.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
>> Qui fait du support pour quelque système d'exploitation que ce soit avec
>> des temps de rétablissement garantis ?
>
> RedHat sur RHEL
Je sais pas pour les autres mais on fait pas ça, non. Je travaille au support RHEL chez Red Hat et on a bien des SLA sur le temps de réponse mais pas sur le temps de résolution, ce qui serait passablement idiot à partir du moment où on ne contrôle pas entièrement l'environnement.
La distro peut inclure des patches qui ne sont pas upstream, être en retard sur certaines choses,... Si tu arrives à reproduire le problème en utilisant la version de développement upstream, tu peux ouvrir le bug en upstream mais sinon, mieux vaut passer par la distribution et le mainteneur fera le nécessaire pour remonter vers upstream si nécessaire.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Il y a trop de moyens permettant de corrompre le tas pour les énumérer tous. Essai de voir ce qui se passe quand tu lances ton application dans valgrind ou avec electric fence. S'il y a effectivement un problème à ce niveau, Valgrind devrait pouvoir le détecter de manière précise. Sinon tu peux aussi essayer de jouer avec MALLOC_CHECK_.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ça bloque parce que ça fait un malloc() dans asprintf() pour tenter de gérer un assert() qui a raté mais évidemment ça bloque puisqu'on est déjà dans malloc() et qu'on a choppé le [fm]utex.
Je suspecte deux bugs :
- dans ton code qui a peté le heap bien avant ce malloc() ;
- dans malloc() parce qu'il ne devrait pas se réappeler sans tenir compte du futex qu'il a déjà.
Je crois que mon pic de Ballmer est à 8 bières.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ben on voit clairement qu'il y a un deadlock quelque part dans malloc() et si l'application n'a qu'un thread ça ressemble quand même fort à un problème dans malloc() lui même. Pour voir plus loin, un backtrace complet serait effectivement utile.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
> (Pour la petite histoire, ils ont pu tracer le problème en bricolant leur suite de
> benchmark pour recompiler chaque révision du git, rebooter sur le noyau et
> relancer le test, je trouve ça magnifique dans le genre « je suis obstiné mais
> flemmard, je vais écrire quelques centaines de lignes de code histoire que ma
> machine bosse sans moi »).
Et quelques unes que j'ai du boulot :
/*
* Initially, we populate the island with all the rifraff peers
* that happen to be lying around. Those with seriously
* defective clocks are immediately booted off the island. Then,
* the falsetickers are culled and put to sea. The truechimers
* remaining are subject to repeated rounds where the most
* unpopular at each round is kicked off. When the population
* has dwindled to sys_minclock, the survivors split a million
* bucks and collectively crank the chimes.
*/
-- ntp-4.2.2p1/ntpd/ntp_proto.c:clock_select()
%
select(0, NULL, NULL, NULL, &tv); // ought to loop until done
-- top.c
%
ret = setsockopt(sockfd, TC_IPPROTO, SO_SET_REPLACE, repl,
sizeof(*repl) + repl->size);
if (ret < 0) {
errno = ret;
-- iptables/libiptc/libiptc.c:TC_COMMIT()
%
<XXX> kernel: Badness in __writeback_single_inode -- does that telle something to anyone ?
<YYY> XXX, it means __writeback_single_inode was coded by samuel l. jackson
%
if (pn->inode==inode) {
/* Some warning should be appropriate here
as we got multiple processes for one i-node */
return;
}
-- netstat.c
%
#define PRG_HASHIT(x) ((x) % PRG_HASH_SIZE)
-- netstat.c
%
* XXX is trying to understand how coreutils' get_date() works
* XXX feels pathetic
%
J'en ai aussi sur TDWTF.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Quand je parle de stocker tout l'état à chaque instruction je pense effectivement plutôt à stocker les différences entre les états entre deux instructions. Une peu à la façon dont les vidéo sont compressées : on a une image de base et l'image suivante, c'est la même avec un delta (c'est sans doute super simplifié, j'y connais rien en encodage vidéo).
C'est juste qu'au final ça revient au même qu'à stocker tout l'état à chaque instruction, la manière dont c'est « compressé » ne sont que des « détails » d'optimisation.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Sinon, les présentations de la salle « Agora » ont été diffusées en presque direct sur internet. J'ose espérer qu'elles ont été enregistrées mais si c'est le cas je ne sais pas quand elles seront mises à disposition.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# s/RedHat/Red Hat Enterprise Linux/g
Posté par Krunch (site web personnel) . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à 1.
Vous pouvez aussi gagner du karma en dénonçant le fait que ce PDF a été généré avec des outils propriétaires.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ce n'est pas le problème !
Posté par Krunch (site web personnel) . En réponse au journal Concours de hackage de machines à vote électronique. Évalué à 3.
Le système traditionnel n'est pas infalsifiable mais le falsifier de manière à pouvoir influencer significativement un vote semble nécessiter passablement plus de ressources que dans le cas d'un vote électronique. De plus, vérifier un vote classique semble plus aisé que vérifier un vote électronique, surtout quand on n'y comprend rien (comme c'est le cas de la vaste majorité des votants).
http://en.wikipedia.org/wiki/K-I-S-S
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 1900€
Posté par Krunch (site web personnel) . En réponse au journal Concours de hackage de machines à vote électronique. Évalué à 3.
Voir aussi http://www.schneier.com/crypto-gram-9812.html#contests
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Quel avantage d'utiliser une ubuntu serveur ?
Posté par Krunch (site web personnel) . En réponse à la dépêche Canonical pousse son offre serveur : entretien avec Nicolas Barcet. Évalué à 3.
Bon, en pratique dans mon expérience, le temps de contournement est souvent bien en dessous de 60 minutes.
> Et au passage, puisqu'on parlait de Debian, y a-t-il quelqu'un qui
> propose au moins un temps de réponse garanti sur de la Debian, en France ?
Je serais aussi intéressé de connaître la réponse. Ça m'étonnerait un peu qu'on trouve des société qui offrent des contrats génériques de ce type (comme le font Red Hat, Novell,...) mais on peut sans doute trouver des intégrateurs/consultants qui fournisse ce genre de support/maintenance pour les trucs qu'ils installent (y compris l'OS qui est potentiellement du Debian).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Question simple, simple question
Posté par Krunch (site web personnel) . En réponse à la dépêche Canonical pousse son offre serveur : entretien avec Nicolas Barcet. Évalué à 5.
> autant que d'une entreprise de 5000 employés ?
Red Hat, c'est environ 3000. Novell, d'après Wikipedia, c'est environ 4000. Certes il reste un facteur 10 et je suis incapable de commenter pertinemment sur les proportions des contributions de chacun mais il serait quand même intéressant d'arrêter de donner n'importe quoi comme chiffres.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Quel avantage d'utiliser une ubuntu serveur ?
Posté par Krunch (site web personnel) . En réponse à la dépêche Canonical pousse son offre serveur : entretien avec Nicolas Barcet. Évalué à 4.
>> des temps de rétablissement garantis ?
>
> RedHat sur RHEL
Je sais pas pour les autres mais on fait pas ça, non. Je travaille au support RHEL chez Red Hat et on a bien des SLA sur le temps de réponse mais pas sur le temps de résolution, ce qui serait passablement idiot à partir du moment où on ne contrôle pas entièrement l'environnement.
https://www.redhat.com/licenses/Enterprise_Agr_France.pdf
Tableau 2.2 sur la page 20, ou bien en plus user friendly : http://www.redhat.com/support/policy/sla/production/
On parle de « response time », pas de temps de rétablissement ou résolution.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Quel avantage d'utiliser une ubuntu serveur ?
Posté par Krunch (site web personnel) . En réponse à la dépêche Canonical pousse son offre serveur : entretien avec Nicolas Barcet. Évalué à 0.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# texte complet ?
Posté par Krunch (site web personnel) . En réponse à la dépêche Canonical pousse son offre serveur : entretien avec Nicolas Barcet. Évalué à 1.
Je n'ai trouvé le texte complet nulle part. Quelqu'un sait où trouver une transcription de cet entretien ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dans l'ordre
Posté par Krunch (site web personnel) . En réponse au message Bug report: où donc ?. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mtrace, ltrace, stracej
Posté par Krunch (site web personnel) . En réponse au message lowlevellock. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mtrace, ltrace, stracej
Posté par Krunch (site web personnel) . En réponse au message lowlevellock. Évalué à 2.
Je suspecte deux bugs :
- dans ton code qui a peté le heap bien avant ce malloc() ;
- dans malloc() parce qu'il ne devrait pas se réappeler sans tenir compte du futex qu'il a déjà.
Je crois que mon pic de Ballmer est à 8 bières.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mtrace, ltrace, strace
Posté par Krunch (site web personnel) . En réponse au message lowlevellock. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# mtrace, ltrace, strace
Posté par Krunch (site web personnel) . En réponse au message lowlevellock. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: plus de précisions seraient pas mal
Posté par Krunch (site web personnel) . En réponse au message Gawk / pb de mémoire ?. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# s/RedHat/Red Hat/
Posté par Krunch (site web personnel) . En réponse à la dépêche Sortie de la version bêta de Fedora 12. Évalué à 2.
Et en fait, si on se réfère à la distribution, c'est Red Hat Enterprise Linux.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Fedora 11 était toujours en beta, non ?
Posté par Krunch (site web personnel) . En réponse à la dépêche Sortie de la version bêta de Fedora 12. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: A propos du 2.6.32
Posté par Krunch (site web personnel) . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 3.
> benchmark pour recompiler chaque révision du git, rebooter sur le noyau et
> relancer le test, je trouve ça magnifique dans le genre « je suis obstiné mais
> flemmard, je vais écrire quelques centaines de lignes de code histoire que ma
> machine bosse sans moi »).
Cette technique est décrite dans la documentation Linux depuis au moins 1996 : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Microcodes
Posté par Krunch (site web personnel) . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Alors moi j'ai des fortunes.
Posté par Krunch (site web personnel) . En réponse au journal ha le php et ses élites. Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Petit joueur....j
Posté par Krunch (site web personnel) . En réponse au journal ha le php et ses élites. Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Alors moi j'ai des fortunes.
Posté par Krunch (site web personnel) . En réponse au journal ha le php et ses élites. Évalué à 3.
Et quelques unes que j'ai du boulot :
/*
* Initially, we populate the island with all the rifraff peers
* that happen to be lying around. Those with seriously
* defective clocks are immediately booted off the island. Then,
* the falsetickers are culled and put to sea. The truechimers
* remaining are subject to repeated rounds where the most
* unpopular at each round is kicked off. When the population
* has dwindled to sys_minclock, the survivors split a million
* bucks and collectively crank the chimes.
*/
-- ntp-4.2.2p1/ntpd/ntp_proto.c:clock_select()
%
select(0, NULL, NULL, NULL, &tv); // ought to loop until done
-- top.c
%
ret = setsockopt(sockfd, TC_IPPROTO, SO_SET_REPLACE, repl,
sizeof(*repl) + repl->size);
if (ret < 0) {
errno = ret;
-- iptables/libiptc/libiptc.c:TC_COMMIT()
%
<XXX> kernel: Badness in __writeback_single_inode -- does that telle something to anyone ?
<YYY> XXX, it means __writeback_single_inode was coded by samuel l. jackson
%
if (pn->inode==inode) {
/* Some warning should be appropriate here
as we got multiple processes for one i-node */
return;
}
-- netstat.c
%
#define PRG_HASHIT(x) ((x) % PRG_HASH_SIZE)
-- netstat.c
%
* XXX is trying to understand how coreutils' get_date() works
* XXX feels pathetic
%
J'en ai aussi sur TDWTF.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ton dédié mutualisé?
Posté par Krunch (site web personnel) . En réponse au journal Hébergement mutualisé, petit état des lieux. Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: À rebours?
Posté par Krunch (site web personnel) . En réponse à la dépêche GDB 7.0 et le déverminage concurrentiel à rebours. Évalué à 3.
C'est juste qu'au final ça revient au même qu'à stocker tout l'état à chaque instruction, la manière dont c'est « compressé » ne sont que des « détails » d'optimisation.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et il y aurait des vidéos ?
Posté par Krunch (site web personnel) . En réponse au journal mes présentations: à l'OSDC, et jeudi prochain. Évalué à 4.
Ouch. PHAIL.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et il y aurait des vidéos ?
Posté par Krunch (site web personnel) . En réponse au journal mes présentations: à l'OSDC, et jeudi prochain. Évalué à 2.
Sinon, les présentations de la salle « Agora » ont été diffusées en presque direct sur internet. J'ose espérer qu'elles ont été enregistrées mais si c'est le cas je ne sais pas quand elles seront mises à disposition.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.