Oui, ça permet aux softs qui utilisent v4l (et maintenant v4l2) de recevoir un flux vidéo et non un flux binaire opaque et compréssé.
En l'occurence, ça permet de manipuler la webcam depuis mplayer, ImageMagick, motion, xawtv, gnomemeeting, camE etc.
L'utilisation d'un soft de decompression intermediaire "spécialiserai" énormément la caméra.
s vraiment intéressé de savoir pourquoi il y a des firmwares binaires dans le noyau
J'aimerai plutôt savoir pourquoi c'est autorisé dans certains cas et pas dans d'autres.
Pour le reste, oui, j'ai déjà lu les explications oiseuses de Torvalds sur le "pragmatisme" qui le conduit a accepter des blobs binaires propriéraires dans son kernel ...
On se demande bien pourquoi Linus accepte les hooks pour charger les firmwares binaires pour la majorité des nouveaux chipsets wifi, voir carrément des drivers incluant les binaires sans les sources (comme le driver tg), et refuse le hook pour PWC...
Le problème avec ce genre de failles, c'est qu'elles exigent des compétences importantes pour jauger pleinement de leur gravité (leur utilisabilité dans une attaque "réaliste" vs. l'alarmisme réthorique du papier de Percival).
En l'occurence, Linus Torvald ne semble pas très inquiet quand aux conséquences possible de ladite "faille", au moins sous Linux: http://kerneltrap.org/node/5120(...)
Coté OpenBSD, contrairement à ce qui a été dit plus haut, le HT est supporté si (et seulement si) le bios est un bios SMP. Dans ce cas la solution proposée est bien entendu de désactiver le SMP dans le bios. Même réaction chez NetBSD.
Bref, à part dans une partie de la communauté FreeBSD et les tabloids, pardon, les sites de news ;), personne ne semble vraiment s'affoler...
What the vulnerability does, is with a certain set of pre-conditions, allows an attacker to time how long it takes for the victim process to read memory.
Preconditions: both processes are on the same CPU for the full amount of time of the process, the attacking process gets the first slice of time, and neither is put to sleep, or moved off the CPU. In theory, the attack will work on any two execution cores that share L1 cache memory.
This threat does NOT allow the attacker to read the actual values of memory, just the time it spends.
S'ils disent vrai, cette histoire ressemble plus à un battage médiatique sensationaliste qu'à une grave faille de sécurité.
> et sur la qualité et la propreté du code ? j'ai souvent entendu dire qu'OpenSSH était très très gruiiik ?
J'ai entendu dire ça ... mais toujours par des developpeurs NetBSD. Quand on connait les rapports conflictuels (c'est peut dire !) des communautés Net et Open, on reste très sceptique sur les propos des afficionados d'un système sur l'autre système. Après je ne suis pas qualifié pour juger de sa qualité malheureusement.
OpenSSH est developpé au coeur d'Open (dans le cvs principal + les ajouts de -portable, mais c'est secondaire). Ce qui signifie qu'il bénéficie d'une politique de developpement solide (très éloignée du "oh, un patch qui marche, hop je le commit"), à savoir les exigences imposés aux devs OpenBSD:
- relecture et validation quasiment systèmatique de tout code par un ou plusieurs autres developpeurs avant commit. Ces developpeurs, avec le temps, sont devenus des spécialistes de l'audit sécurité et de la relecture.
- respect de normes de codage ultra strictes (style(9) mais aussi utilisation de fonctions protégées et banissement des fonctions sensibles comme sprintf/strcpy/strcat/... etc.) sous peine de rejet du commit.
- filtrage sérré des contributeur: seuls ceux qui ont faire leurs preuves, par exemple en trouvant et corrigeant pleins de bugs, en produisant du code très propre ..., sont susceptibles d'être acceptés.
- relecture, grep -r, et modification/protection du code chaque fois qu'une nouveau type générique de faille est découvert, ou par séries thématique (eg, problèmes sur les manips de chaines, sur la gestion des signaux, sur le test des codes de retours de snprintf(3), ...), l'arbre des sources étant régulierement nettoyé de ces "oddities" ou de méthodes de programmations dont on découvre qu'elles étaient imprafaites.
- fonctionnement et tests en environnement protégé (eg. /etc/malloc.conf -> AJFG, propolice etc.) pour detecter rapidement les possibles debordements de mémoire.
- évolution très conservatrice et incrémentale (commits par petits patches, refus des ajouts de fonctionalités trop hardies ...).
- design devant permettre un fonctionnement sécurisé (séparation des privilèges pour les daemons, pas d'IPv6 mappé en IPv4, ...).
Donc il est improbable que le code soit sale ; d'autant que le soft tourne sur un paquet de machines (Linux, *BSD, Cisco et autres unix) depuis longtemps déjà ; les problèmes de sécurité remontent vite dans ces conditions, et ils ont été peut nombreux (on peut imaginer qu'OpenSSH est dans la ligne de mire de la plupart des hackers en herbe, vu son utilité stratégique et sa grande diffusion).
Ce qui plaide pour la qualité de ce benchmark, c'est que le classement change très peu d'un test à l'autre.
On obtient la plupart du temps un classement à peut près identique. Donc dans l'ensemble, il y a bien quelque chose de relativement constant qui s'en dégage ...
Par exemple on aura beau dire que l'implem d'un algorithme pur ne ressemble jamais à un programme réel, où les résultats seraient très différents, le fait qu'Ocaml performe très bien sur tout les algos (qui sont très différents les uns des autres) permet quand même de penser qu'Ocaml est un langage très rapide (et l'inverse pour PHP).
Peut être parceque les developpeurs de LL font généralement ça pour le plaisir (et pas pour le rendement, les deadlines etc.) ?
Je pense aussi qu'un grand plaisir est d'utiliser un langage dont l'apprentissage permet aussi de mieux maitriser et comprendre le système sur lequel on l'execute. Ici le C est roi.
Et puis je pense que les devs de LL n'ont pas besoin de se conformer aux lubies des decideux préssés comme en entreprise ; et qu'on ne leur vend pas si facilement du java-c-est-portable et autre c-sharp-c-est-universel à coup de campagnes de marketing sur 01.net ...
'en ai un beau sous windows : eclipse 3 justement.
[...] ok, la version linux est a chier, trop lente
Heu, tu n'aurai pas un autre exemple ?
Quelque chose qui puisse convaincre un utilisateur de linux (je pense la plupart des gens qui lisent linuxfr) ? Parcequ'en l'occurence c'est plutôt un contre exemple pour nous ...
Mais en effet, j'ai repris l'expression approximative du post en amont ("ports ouverts") ; "il y a des services qui écoutent sur le réseau dans l'installation de base" serait plus aproprié. Bref, il y a des services réseau actifs par défaut.
C'est à relativiser, ce slogan ne concerne que les failles distantes (en excluant ssh) dans l'installation par defaut, et sur la branche de développement.
Distantes, bien sûr, c'est ce que dit le "remote" du slogan. Ssh n'est pas exclu vu que la faille dont il est question c'était justement dans openssh. Le fait que ça ne concerne que la branche de dev, j'étais pas au courant ; tu en es sûr ? (ça me semble un peu douteux en fait...).
Mais je n'ai pas trouvé le GUI clair et ergonomique qui permette aux neus-neus, comme moi, de ne pas passer des heures à configurer son firewall avec la peur d'y retoucher ensuite tellement c'était un calvaire.
Pour rester dans le sujet: c'est peut être l'occasion de tester le firewall d'OpenBSD (pf), dont la syntaxe est vraiment très claire (plus qu'iptables, je trouve).
Un exemple de firewall complet qui n'autorise que le web et le ssh en entrée depuis l'exterieur (l'interface externe est ici tun0) et qui autorise et NAT le traffic du lan ; bref un exemple classique d'une passerelle SOHO simple (ce qui interesse généralement les débutants):
# on nat vers l'exterieur nat on tun0 inet from any to any -> (tun0)
# on autorise le ssh et http en entrée ("in") pour tout le monde pass in quick proto tcp from any to any port { ssh, www }
# on autorise en entrée tout ce qui n'arrive pas sur l'interface ext
# (autrement dit tout ce qui vient du lan) pass in quick on ! tun0 all
# on autorise tout en sortie ("out"). "keep state" signifie en gros:
# on autorise aussi les réponses à nos requettes. pass out quick all keep state
# on bloque le reste du traffic entrant block in all
Ça vaut bien toutes les GUI du monde, une telle syntaxe, non ? ;)
> > une politique de sécurité par défaut qui oblige l'administrateur à autoriser explicitement l'ouverture de certains ports pour éviter aux débutants de faire des erreurs et de laisser béantes des failles potentielles de sécurité.
> Et dire que c'est pourtant la base même.
En fait OpenBSD laisse aussi plein de ports ouverts par défault (le propos de la dépèche pourrait laisser penser l'inverse).
Cependant ce n'est pas "la base même" d'une bonne sécurité à mon avis.
Ce qui est important c'est plutôt que ce qui est ouvert est très robuste et controlé: audité, sans cesse ré-audité, adjoint de techniques de mitigation des problèmes potentiels, de protections de la VM (propolice, W^X ...), politiques de developpement et de style ultra strictes, parti pris du minimalisme, tris des developpeurs sur le volet etc. ; la preuve en est le slogan sur le site d'Open : "Only one remote hole in the default install, in more than 8 years!", en dépit desdits ports ouverts.
Bref, et c'est un peu ce qui est propre aux BSD par rapport aux distributions GNU/Linux (même Gentoo), les devs travaillent vraiment à partir de et sur les sources: s'ils ne les écrivent pas toutes eux-mêmes (par exemple quand ils intégrent sendmail ou bind dans leurs cvs) il les relisent, ajoutent quasi systèmatiquement des sécurisations dans le code importé (strlcpy/strlcat, privsep, chrootage ...) etc.
Ce processus ne concerne que le système de base (il y a déjà de quoi faire un serveur web, mail ou un firewall celà dit), pas les ports et packages (qui eux sont souvent maintenus à la façon linuxienne, en patchant suffisament pour que ça marche, et en testant ensuite).
Java n'est pas intrinséquement lent... moins rapide que de l'assembleur je te l'accordre mais java permet d'avoir d'excellents applications rapides, belles et réactives.. les exemples ne manquent pas
Pourquoi ne pas nommer ces exemples ?
Ce serai la meilleure façon de convaincre ceux (visiblement nombreux) qui ne sont pas convaincus de la rapidité de java (et non ne parle pas de légereté).
Par exemple, personnellement, je n'ai jamais trouvé d'applications java rapides (mes dernieres tentatives sont eclipses 3.0 et argouml avec le JRE 1.5 de Sun). D'où un mauvais à priori.
En tout cas j'ai trouvé que le gendarme était notre meilleur soutient dans la seconde partie de l'émission ; face au FUD de Didier Lambert: (de mémoire): "il y a des entreprises capables d'assurer le support sur le logiciel libre pour un cout moindre", "les failles de sécurité sont corrigées plus vite dans le monde du libre", "si toute la gendarmerie nationale est passée à OpenOffice.org, ce n'est pas pas hasard, le LL c'est du sérieux" ....
J'ai souvenir d'avoir passé 10 heures stressantes à debugguer une configuration IPsec dont le seul problème était, finalement, un simple "Authentification" (au lieu d''Authentication") dans la description de la phase 1 d'isakmpd.conf.
C'est pas toujours facile à repérer et ça peut faire du grabuge !
[^] # Re: perte de ses avantages?
Posté par herodiade . En réponse à la dépêche Apple abandonne IBM pour Intel. Évalué à 4.
[^] # Re: idée de sondage
Posté par herodiade . En réponse au sondage OpenBSD. Évalué à 2.
Faut-il en déduire que les usagers sont déjà HS ?
[^] # Re: Possesseur de carte réseau utilisant le module via-rhine (D-Link 530
Posté par herodiade . En réponse à la dépêche Debian 3.1 ; nom de code : Sarge. Évalué à 2.
Y a-t-il quelque part un compendium des petits problemes de ce type (ormi le guide officiel bien sûr) ?
Au fait, les mises à jour sécurité sur Woody maintenues pendant encore longtemps, c'est une légende ? quelqu'un aurait-il une source "officielle" ?
[^] # Re: c'est space
Posté par herodiade . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 2.
En l'occurence, ça permet de manipuler la webcam depuis mplayer, ImageMagick, motion, xawtv, gnomemeeting, camE etc.
L'utilisation d'un soft de decompression intermediaire "spécialiserai" énormément la caméra.
[^] # Re: Hooks sur binaires
Posté par herodiade . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 2.
J'aimerai plutôt savoir pourquoi c'est autorisé dans certains cas et pas dans d'autres.
Pour le reste, oui, j'ai déjà lu les explications oiseuses de Torvalds sur le "pragmatisme" qui le conduit a accepter des blobs binaires propriéraires dans son kernel ...
# Hooks sur binaires
Posté par herodiade . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 5.
# OS ?
Posté par herodiade . En réponse au journal Les nouvelles consoles. Évalué à 4.
[^] # Re: Mouais.....
Posté par herodiade . En réponse à la dépêche Linux à Cuba : İ Viva la penguinista !. Évalué à 2.
# Grave faille ou réthorique de consultant ?
Posté par herodiade . En réponse au journal Faille dans les CPU Intel avec Hyperthreading. Évalué à 2.
En l'occurence, Linus Torvald ne semble pas très inquiet quand aux conséquences possible de ladite "faille", au moins sous Linux: http://kerneltrap.org/node/5120(...)
Coté OpenBSD, contrairement à ce qui a été dit plus haut, le HT est supporté si (et seulement si) le bios est un bios SMP. Dans ce cas la solution proposée est bien entendu de désactiver le SMP dans le bios. Même réaction chez NetBSD.
Bref, à part dans une partie de la communauté FreeBSD et les tabloids, pardon, les sites de news ;), personne ne semble vraiment s'affoler...
Undeadly relativise la gravité de la faille en ces termes (cf. http://undeadly.org/cgi?action=article&sid=20050522032210&m(...) )
S'ils disent vrai, cette histoire ressemble plus à un battage médiatique sensationaliste qu'à une grave faille de sécurité.
[^] # Re: OCaml (difficulté d'apprentissage)
Posté par herodiade . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 4.
Arf, faut que j'en parle à Denis Ritchie ... ;)
[^] # Re: Sortie d'OpenBSD 3.7
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 8.
J'ai entendu dire ça ... mais toujours par des developpeurs NetBSD. Quand on connait les rapports conflictuels (c'est peut dire !) des communautés Net et Open, on reste très sceptique sur les propos des afficionados d'un système sur l'autre système. Après je ne suis pas qualifié pour juger de sa qualité malheureusement.
OpenSSH est developpé au coeur d'Open (dans le cvs principal + les ajouts de -portable, mais c'est secondaire). Ce qui signifie qu'il bénéficie d'une politique de developpement solide (très éloignée du "oh, un patch qui marche, hop je le commit"), à savoir les exigences imposés aux devs OpenBSD:
- relecture et validation quasiment systèmatique de tout code par un ou plusieurs autres developpeurs avant commit. Ces developpeurs, avec le temps, sont devenus des spécialistes de l'audit sécurité et de la relecture.
- respect de normes de codage ultra strictes (style(9) mais aussi utilisation de fonctions protégées et banissement des fonctions sensibles comme sprintf/strcpy/strcat/... etc.) sous peine de rejet du commit.
- filtrage sérré des contributeur: seuls ceux qui ont faire leurs preuves, par exemple en trouvant et corrigeant pleins de bugs, en produisant du code très propre ..., sont susceptibles d'être acceptés.
- relecture, grep -r, et modification/protection du code chaque fois qu'une nouveau type générique de faille est découvert, ou par séries thématique (eg, problèmes sur les manips de chaines, sur la gestion des signaux, sur le test des codes de retours de snprintf(3), ...), l'arbre des sources étant régulierement nettoyé de ces "oddities" ou de méthodes de programmations dont on découvre qu'elles étaient imprafaites.
- fonctionnement et tests en environnement protégé (eg. /etc/malloc.conf -> AJFG, propolice etc.) pour detecter rapidement les possibles debordements de mémoire.
- évolution très conservatrice et incrémentale (commits par petits patches, refus des ajouts de fonctionalités trop hardies ...).
- design devant permettre un fonctionnement sécurisé (séparation des privilèges pour les daemons, pas d'IPv6 mappé en IPv4, ...).
Donc il est improbable que le code soit sale ; d'autant que le soft tourne sur un paquet de machines (Linux, *BSD, Cisco et autres unix) depuis longtemps déjà ; les problèmes de sécurité remontent vite dans ces conditions, et ils ont été peut nombreux (on peut imaginer qu'OpenSSH est dans la ligne de mire de la plupart des hackers en herbe, vu son utilité stratégique et sa grande diffusion).
# constance des résultats, qualité du benchmark
Posté par herodiade . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 5.
On obtient la plupart du temps un classement à peut près identique. Donc dans l'ensemble, il y a bien quelque chose de relativement constant qui s'en dégage ...
Par exemple on aura beau dire que l'implem d'un algorithme pur ne ressemble jamais à un programme réel, où les résultats seraient très différents, le fait qu'Ocaml performe très bien sur tout les algos (qui sont très différents les uns des autres) permet quand même de penser qu'Ocaml est un langage très rapide (et l'inverse pour PHP).
[^] # Re: Dommage ...
Posté par herodiade . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 5.
Je pense aussi qu'un grand plaisir est d'utiliser un langage dont l'apprentissage permet aussi de mieux maitriser et comprendre le système sur lequel on l'execute. Ici le C est roi.
Et puis je pense que les devs de LL n'ont pas besoin de se conformer aux lubies des decideux préssés comme en entreprise ; et qu'on ne leur vend pas si facilement du java-c-est-portable et autre c-sharp-c-est-universel à coup de campagnes de marketing sur 01.net ...
[^] # Re: Nécessité de Java?
Posté par herodiade . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
[^] # Re: Nécessité de Java?
Posté par herodiade . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
[...]
ok, la version linux est a chier, trop lente
Heu, tu n'aurai pas un autre exemple ?
Quelque chose qui puisse convaincre un utilisateur de linux (je pense la plupart des gens qui lisent linuxfr) ? Parcequ'en l'occurence c'est plutôt un contre exemple pour nous ...
[^] # Re: Ports ouverts ou fermés ?
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 2.
Celui qui veut monter un lan avec une passerelle, il doit bien savoir ce qu'est une adresse ip et un lan quand même !
Le béotien complet administrant uniquement son propre poste de travail peut faire, sans chercher à comprendre:
echo "pass out quick all keep state" > /etc/pf.conf
echo "block in all" >> /etc/pf.conf
echo "pf=YES" >> /etc/rc.conf.local
Et il a un firewall sur son poste de travail.
Celà dit, pour une utilisation en workstation, il risque de trouver OpenBSD un peu rugeux sur d'autres aspects ;)
[^] # Re: Sortie d'OpenBSD 3.7
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 2.
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/etc/inetd.conf(...)
ça en fait encore quelques uns quand même (identd, daytime, ...).
Mais en effet, j'ai repris l'expression approximative du post en amont ("ports ouverts") ; "il y a des services qui écoutent sur le réseau dans l'installation de base" serait plus aproprié. Bref, il y a des services réseau actifs par défaut.
C'est à relativiser, ce slogan ne concerne que les failles distantes (en excluant ssh) dans l'installation par defaut, et sur la branche de développement.
Distantes, bien sûr, c'est ce que dit le "remote" du slogan. Ssh n'est pas exclu vu que la faille dont il est question c'était justement dans openssh. Le fait que ça ne concerne que la branche de dev, j'étais pas au courant ; tu en es sûr ? (ça me semble un peu douteux en fait...).
[^] # Re: ca va etre rigolo...
Posté par herodiade . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 6.
Le concours du bloatware est ouvert ;)
[^] # Re: Ports ouverts ou fermés ?
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 6.
Pour rester dans le sujet: c'est peut être l'occasion de tester le firewall d'OpenBSD (pf), dont la syntaxe est vraiment très claire (plus qu'iptables, je trouve).
Un exemple de firewall complet qui n'autorise que le web et le ssh en entrée depuis l'exterieur (l'interface externe est ici tun0) et qui autorise et NAT le traffic du lan ; bref un exemple classique d'une passerelle SOHO simple (ce qui interesse généralement les débutants):
# on nat vers l'exterieur
nat on tun0 inet from any to any -> (tun0)
# on autorise le ssh et http en entrée ("in") pour tout le monde
pass in quick proto tcp from any to any port { ssh, www }
# on autorise en entrée tout ce qui n'arrive pas sur l'interface ext
# (autrement dit tout ce qui vient du lan)
pass in quick on ! tun0 all
# on autorise tout en sortie ("out"). "keep state" signifie en gros:
# on autorise aussi les réponses à nos requettes.
pass out quick all keep state
# on bloque le reste du traffic entrant
block in all
Ça vaut bien toutes les GUI du monde, une telle syntaxe, non ? ;)
[^] # Re: Sortie d'OpenBSD 3.7
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 6.
> Et dire que c'est pourtant la base même.
En fait OpenBSD laisse aussi plein de ports ouverts par défault (le propos de la dépèche pourrait laisser penser l'inverse).
Cependant ce n'est pas "la base même" d'une bonne sécurité à mon avis.
Ce qui est important c'est plutôt que ce qui est ouvert est très robuste et controlé: audité, sans cesse ré-audité, adjoint de techniques de mitigation des problèmes potentiels, de protections de la VM (propolice, W^X ...), politiques de developpement et de style ultra strictes, parti pris du minimalisme, tris des developpeurs sur le volet etc. ; la preuve en est le slogan sur le site d'Open : "Only one remote hole in the default install, in more than 8 years!", en dépit desdits ports ouverts.
Bref, et c'est un peu ce qui est propre aux BSD par rapport aux distributions GNU/Linux (même Gentoo), les devs travaillent vraiment à partir de et sur les sources: s'ils ne les écrivent pas toutes eux-mêmes (par exemple quand ils intégrent sendmail ou bind dans leurs cvs) il les relisent, ajoutent quasi systèmatiquement des sécurisations dans le code importé (strlcpy/strlcat, privsep, chrootage ...) etc.
Ce processus ne concerne que le système de base (il y a déjà de quoi faire un serveur web, mail ou un firewall celà dit), pas les ports et packages (qui eux sont souvent maintenus à la façon linuxienne, en patchant suffisament pour que ça marche, et en testant ensuite).
[^] # Re: Nécessité de Java?
Posté par herodiade . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Pourquoi ne pas nommer ces exemples ?
Ce serai la meilleure façon de convaincre ceux (visiblement nombreux) qui ne sont pas convaincus de la rapidité de java (et non ne parle pas de légereté).
Par exemple, personnellement, je n'ai jamais trouvé d'applications java rapides (mes dernieres tentatives sont eclipses 3.0 et argouml avec le JRE 1.5 de Sun). D'où un mauvais à priori.
[^] # Re: Enregistrement de l'émission
Posté par herodiade . En réponse à la dépêche Une émission de télé en direct sur le libre. Évalué à 2.
Direct8 a cédé ses droits ?
[^] # Re: Quid de GNU Arch?
Posté par herodiade . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 3.
- soit dans l'interpreteur css de mozilla-firefox
- soit dans le code de linuxfr
Parceque le nom du fichier dépasse très largement du cadre chez moi.
[^] # Re: Premiere partie
Posté par herodiade . En réponse à la dépêche Une émission de télé en direct sur le libre. Évalué à 10.
En tout cas j'ai trouvé que le gendarme était notre meilleur soutient dans la seconde partie de l'émission ; face au FUD de Didier Lambert: (de mémoire): "il y a des entreprises capables d'assurer le support sur le logiciel libre pour un cout moindre", "les failles de sécurité sont corrigées plus vite dans le monde du libre", "si toute la gendarmerie nationale est passée à OpenOffice.org, ce n'est pas pas hasard, le LL c'est du sérieux" ....
[^] # Re: s/authentification/authentication/g
Posté par herodiade . En réponse à la dépêche Faille de sécurité dans les protocoles IPSec. Évalué à 4.
J'ai souvenir d'avoir passé 10 heures stressantes à debugguer une configuration IPsec dont le seul problème était, finalement, un simple "Authentification" (au lieu d''Authentication") dans la description de la phase 1 d'isakmpd.conf.
C'est pas toujours facile à repérer et ça peut faire du grabuge !