Quand le bureau KDE et toutes ses applications seront portés sur Windows
(on s'en rapproche pour ceux qui suivent, les applications deviennent de
plus en plus stables), celui-ci envahira Windows car, contrairement à
Linux qui possède des dizaines de bureaux, il sera l'unique alternative
au bureau Windows : KDE apporterait un souffle nouveau à Windows, en
tous cas plus que le bureau de Seven.
Du coup, l'utilisateur lambda (qui est l'utilisateur très largement
majoritaire) ne verra plus la différence entre un Windows et un linux
(ou un OpenSolaris ou un BSD) qui tournera derrière et au bout du
compte, il préférera naturellement se tourner vers l'OS qui lui coûte le
moins cher.
Yves Lambert, dans le message <4b43a55b$0$30393$, a écrit :
Le bon contenu.
Qui peut aussi bien être généré ailleurs.
Et le suid c'est magique.
Pour toi qui n'y comprends rien, peut-être.
yl
In article <hhvmti$25su$, (Michel Talon) writes:
Certes il n'a aucune raison d'y être, mais croire que sa présence ou son absence modifient en quoi que ce soit la sécurité est de la démence.
Le bon compilateur pour la bonne archi avec les headers des bibliothèques, ça simplifie beaucoup le travail quand meme. Que ce soit poour installer un port ou une porte.
-- http://mikeread.tripod.com/archive.htm
In article <hhvmti$25su$1@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr (Michel Talon) writes:
Certes il n'a aucune raison d'y être, mais croire que sa présence ou son
absence modifient en quoi que ce soit la sécurité est de la démence.
Le bon compilateur pour la bonne archi avec les headers des
bibliothèques, ça simplifie beaucoup le travail quand meme.
Que ce soit poour installer un port ou une porte.
Certes il n'a aucune raison d'y être, mais croire que sa présence ou son absence modifient en quoi que ce soit la sécurité est de la démence.
Le bon compilateur pour la bonne archi avec les headers des bibliothèques, ça simplifie beaucoup le travail quand meme. Que ce soit poour installer un port ou une porte.
-- http://mikeread.tripod.com/archive.htm
Nicolas George
Michel Talon, dans le message <hhvmti$25su$, a écrit :
En particulier s'il est physiquement accessible, ce n'est même pas la peine de se poser la question de sa sécurité logicielle.
Ce n'est pas vrai : passer root sur une machine en fonctionnement est autrement plus utile que de passer root sur une machine en la rebootant.
Et il est possible de blinder même une machine sur laquelle un utilisateur hostile a accès physique : tous les filesystems chiffrés avec une clef donnée par l'administrateur au boot, câble réseau permettant uniquement de faire passer un VPN.
Michel Talon, dans le message <hhvmti$25su$1@asmodee.lpthe.jussieu.fr>,
a écrit :
En particulier s'il est physiquement accessible, ce n'est même pas la
peine de se poser la question de sa sécurité logicielle.
Ce n'est pas vrai : passer root sur une machine en fonctionnement est
autrement plus utile que de passer root sur une machine en la rebootant.
Et il est possible de blinder même une machine sur laquelle un utilisateur
hostile a accès physique : tous les filesystems chiffrés avec une clef
donnée par l'administrateur au boot, câble réseau permettant uniquement de
faire passer un VPN.
Michel Talon, dans le message <hhvmti$25su$, a écrit :
En particulier s'il est physiquement accessible, ce n'est même pas la peine de se poser la question de sa sécurité logicielle.
Ce n'est pas vrai : passer root sur une machine en fonctionnement est autrement plus utile que de passer root sur une machine en la rebootant.
Et il est possible de blinder même une machine sur laquelle un utilisateur hostile a accès physique : tous les filesystems chiffrés avec une clef donnée par l'administrateur au boot, câble réseau permettant uniquement de faire passer un VPN.
Ben oui. Sauf que les messages ne sont pas forcément perdus mais retardés si ton démon défaille et ne bugue pas assez pour ne pas renvoyer un code d'erreur
-- http://mikeread.tripod.com/archive.htm
In article <slrnhk5uh8.mka.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
Ben oui. Sauf que les messages ne sont pas forcément perdus
mais retardés si ton démon défaille et ne bugue pas assez pour
ne pas renvoyer un code d'erreur
Ben oui. Sauf que les messages ne sont pas forcément perdus mais retardés si ton démon défaille et ne bugue pas assez pour ne pas renvoyer un code d'erreur
-- http://mikeread.tripod.com/archive.htm
yl
In article , Stephane TOUGARD writes:
Yves Lambert a perdu son temps a nous dire:
Tiu n'es absolument pas obligé d'en accepter tant à la fois. Tu les traite 1 par 1 et le spammeur attend. Le temps total de traitement est le meme.
Toi, t'as jamais gere un serveur MX. Tu sais, un MX, c'est pas fait QUE de spam et d'anti-spam. Dans la vraie vie, il y a aussi des vrais emails et des vrais gens qui recoivent ces vrais emails.
Et qui se font greylister pendant 4h ou poubelliser par une règle obscure de procmail sans etre averti. C'est pas pire.
-- http://mikeread.tripod.com/archive.htm
In article <5heb17-rf52.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Yves Lambert a perdu son temps a nous dire:
Tiu n'es absolument pas obligé d'en accepter tant à la fois. Tu les
traite 1 par 1 et le spammeur attend. Le temps total de traitement est
le meme.
Toi, t'as jamais gere un serveur MX. Tu sais, un MX, c'est pas fait QUE
de spam et d'anti-spam. Dans la vraie vie, il y a aussi des vrais emails
et des vrais gens qui recoivent ces vrais emails.
Et qui se font greylister pendant 4h ou poubelliser par une règle
obscure de procmail sans etre averti. C'est pas pire.
Tiu n'es absolument pas obligé d'en accepter tant à la fois. Tu les traite 1 par 1 et le spammeur attend. Le temps total de traitement est le meme.
Toi, t'as jamais gere un serveur MX. Tu sais, un MX, c'est pas fait QUE de spam et d'anti-spam. Dans la vraie vie, il y a aussi des vrais emails et des vrais gens qui recoivent ces vrais emails.
Et qui se font greylister pendant 4h ou poubelliser par une règle obscure de procmail sans etre averti. C'est pas pire.
-- http://mikeread.tripod.com/archive.htm
yl
In article , Stephane TOUGARD writes:
Nicolas George a perdu son temps a nous dire:
Si smtpd accepte tous les emails, les mets dans un spool, puis tu traites l'anti-spam avec un nombre connu de process, tu vas mettre du delai dans le traitement, mais ton service sera toujours debout.
Et tu vas émettre un nombre incalculable de bounces et te retrouver dans toutes les blacklists du monde en moins de deux jours.
Et pourquoi veux-tu que j'emette des bounces ? Un anti-spam n'est pas la pour emettre des bounces mais pour attriber un spam rate a un email que l'utilisateur final peut filtrer a son bon besoin.
Tu connais beaucoup de lusers qui ont besoin de security patch, de warez et de vi4gr4 ?
-- http://mikeread.tripod.com/archive.htm
In article <88eb17-rf52.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:
Nicolas George a perdu son temps a nous dire:
Si smtpd accepte tous les emails, les mets dans un spool, puis tu
traites l'anti-spam avec un nombre connu de process, tu vas mettre du
delai dans le traitement, mais ton service sera toujours debout.
Et tu vas émettre un nombre incalculable de bounces et te retrouver dans
toutes les blacklists du monde en moins de deux jours.
Et pourquoi veux-tu que j'emette des bounces ? Un anti-spam n'est pas la
pour emettre des bounces mais pour attriber un spam rate a un email que
l'utilisateur final peut filtrer a son bon besoin.
Tu connais beaucoup de lusers qui ont besoin de security patch, de warez
et de vi4gr4 ?
Si smtpd accepte tous les emails, les mets dans un spool, puis tu traites l'anti-spam avec un nombre connu de process, tu vas mettre du delai dans le traitement, mais ton service sera toujours debout.
Et tu vas émettre un nombre incalculable de bounces et te retrouver dans toutes les blacklists du monde en moins de deux jours.
Et pourquoi veux-tu que j'emette des bounces ? Un anti-spam n'est pas la pour emettre des bounces mais pour attriber un spam rate a un email que l'utilisateur final peut filtrer a son bon besoin.
Tu connais beaucoup de lusers qui ont besoin de security patch, de warez et de vi4gr4 ?
-- http://mikeread.tripod.com/archive.htm
yl
In article , JKB writes:
C'est possible mais tu ne répond pas à la question : pourquoi c'est mal de filtrer les messages avec un spamd et donner la réponse 400 après le .
Tu m'excuseras, mais pour répondre à une question, il faut l'avoir comprise. Ceci étant dit, je ne vois pas pourquoi renvoyer un 4xx après le '.'. Personnellement, j'envoie un 5xx à la fin de la transaction, c'est plus radical.
Le 4xx est plus mutin. Je voulais dire 500, ceci dit.
personnellement je n'y vois que des avantages. Tu m'as expliqué comment le faire sur postfix, puis comment s'en passer) ma question est «pourquoi s'en passer ?»; c'est efficace, élégant et ça permet de respecter à la lettre les RFC concernant le mail, alors que les spams passent au travers du greylisting, par exemple et que les RBL génèrent trop de faux positifs.
Le greylisting, ça se configure aux petits oignons avec le score SA et les RBL sans jamais mettre en liste noire (sauf des trucs triviaux comme des incohérences SPF).
La dernière fois que j'ai parlé de SPF dans fcm, personne ne connaissait. Bon c'était il y a deux ans. Par contre le greylisting était considéré comme la panacée et ne demandait aucun settings. ORDB fait aussi partie des trucs triviaux, non ? Le discours que j'ai lu était jamais nde liste noire, mais alors jamais, il peut toujours y avoir un correspondant légitime qui envoie son mail directement depuis sa machine sur IP dynamique ou depuis une machine connue pour etre un relais ouvert, n'est-ce pas.
-- http://mikeread.tripod.com/archive.htm
In article <slrnhk5uq0.mka.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
C'est possible mais tu ne répond pas à la question : pourquoi c'est mal
de filtrer les messages avec un spamd et donner la réponse 400 après le
.
Tu m'excuseras, mais pour répondre à une question, il faut l'avoir
comprise. Ceci étant dit, je ne vois pas pourquoi renvoyer un 4xx
après le '.'. Personnellement, j'envoie un 5xx à la fin de la
transaction, c'est plus radical.
Le 4xx est plus mutin. Je voulais dire 500, ceci dit.
personnellement je n'y vois que des avantages. Tu m'as expliqué comment
le faire sur postfix, puis comment s'en passer) ma question est «pourquoi
s'en passer ?»; c'est efficace, élégant et ça permet de respecter à la
lettre les RFC concernant le mail, alors que les spams passent au
travers du greylisting, par exemple et que les RBL génèrent trop de
faux positifs.
Le greylisting, ça se configure aux petits oignons avec le score SA
et les RBL sans jamais mettre en liste noire (sauf des trucs
triviaux comme des incohérences SPF).
La dernière fois que j'ai parlé de SPF dans fcm, personne ne
connaissait. Bon c'était il y a deux ans. Par contre le greylisting
était considéré comme la panacée et ne demandait aucun settings.
ORDB fait aussi partie des trucs triviaux, non ? Le discours que j'ai lu
était jamais nde liste noire, mais alors jamais, il peut toujours y
avoir un correspondant légitime qui envoie son mail directement depuis
sa machine sur IP dynamique ou depuis une machine connue pour etre un
relais ouvert, n'est-ce pas.
C'est possible mais tu ne répond pas à la question : pourquoi c'est mal de filtrer les messages avec un spamd et donner la réponse 400 après le .
Tu m'excuseras, mais pour répondre à une question, il faut l'avoir comprise. Ceci étant dit, je ne vois pas pourquoi renvoyer un 4xx après le '.'. Personnellement, j'envoie un 5xx à la fin de la transaction, c'est plus radical.
Le 4xx est plus mutin. Je voulais dire 500, ceci dit.
personnellement je n'y vois que des avantages. Tu m'as expliqué comment le faire sur postfix, puis comment s'en passer) ma question est «pourquoi s'en passer ?»; c'est efficace, élégant et ça permet de respecter à la lettre les RFC concernant le mail, alors que les spams passent au travers du greylisting, par exemple et que les RBL génèrent trop de faux positifs.
Le greylisting, ça se configure aux petits oignons avec le score SA et les RBL sans jamais mettre en liste noire (sauf des trucs triviaux comme des incohérences SPF).
La dernière fois que j'ai parlé de SPF dans fcm, personne ne connaissait. Bon c'était il y a deux ans. Par contre le greylisting était considéré comme la panacée et ne demandait aucun settings. ORDB fait aussi partie des trucs triviaux, non ? Le discours que j'ai lu était jamais nde liste noire, mais alors jamais, il peut toujours y avoir un correspondant légitime qui envoie son mail directement depuis sa machine sur IP dynamique ou depuis une machine connue pour etre un relais ouvert, n'est-ce pas.
-- http://mikeread.tripod.com/archive.htm
JKB
Le 05-01-2010, ? propos de Re: KDE tuera Windows, Yves Lambert ?crivait dans fr.comp.os.linux.debats :
Ben oui. Sauf que les messages ne sont pas forcément perdus mais retardés si ton démon défaille et ne bugue pas assez pour ne pas renvoyer un code d'erreur
Lorsque le daemon part aux choux, il ne répond plus rien. Je n'ai jamais vu SA bloqué autrement.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 05-01-2010, ? propos de
Re: KDE tuera Windows,
Yves Lambert ?crivait dans fr.comp.os.linux.debats :
In article <slrnhk5uh8.mka.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
Ben oui. Sauf que les messages ne sont pas forcément perdus
mais retardés si ton démon défaille et ne bugue pas assez pour
ne pas renvoyer un code d'erreur
Lorsque le daemon part aux choux, il ne répond plus rien. Je n'ai
jamais vu SA bloqué autrement.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Ben oui. Sauf que les messages ne sont pas forcément perdus mais retardés si ton démon défaille et ne bugue pas assez pour ne pas renvoyer un code d'erreur
Lorsque le daemon part aux choux, il ne répond plus rien. Je n'ai jamais vu SA bloqué autrement.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Stéphane CARPENTIER
Yves Lambert wrote:
Physiquement accessible ne signifie pas accès au bouton power ou au reset
Ben si, sauf si le bouton power n'existe pas.
mais à une console.
Ben non, ça c'est un accès réseau.
Un accès physique, c'est quand tu peux le toucher avec tes doigts. Utiliser un tournevis pour démonter le disque dur ou mettre une clé USB dessus par exemple.
Yves Lambert wrote:
Physiquement accessible ne signifie pas accès au bouton power ou
au reset
Ben si, sauf si le bouton power n'existe pas.
mais à une console.
Ben non, ça c'est un accès réseau.
Un accès physique, c'est quand tu peux le toucher avec tes doigts.
Utiliser un tournevis pour démonter le disque dur ou mettre une clé USB
dessus par exemple.
Physiquement accessible ne signifie pas accès au bouton power ou au reset
Ben si, sauf si le bouton power n'existe pas.
mais à une console.
Ben non, ça c'est un accès réseau.
Un accès physique, c'est quand tu peux le toucher avec tes doigts. Utiliser un tournevis pour démonter le disque dur ou mettre une clé USB dessus par exemple.
yl
In article <hi096m$244l$, Nicolas George <nicolas$ writes:
Yves Lambert, dans le message <4b43a226$0$10100$, a écrit :
En exploitant une faille de HAL ou d'une autre bibliothèque privilégiée.
HAL n'est pas une bibliothèque.
Ou d'une bibliothèque.
« Ou d'une _autre_ bibliothèque », tu as dit.
J'ai donc rectifiée.
Et pour ta gouverne, une bibliothèque ne peut pas avoir de problèmes de sécurité vis-à-vis du programme qui l'utilise.
Oui unix est un système sur, il n('y a jamais eu de faille de sécurité il est inutile de les corriger si on en trouve une puisqu'il est impossible de les exploiter et qu'elles n'existent pas.
HAL m'a énervé : session X à distance, l'appel à HAL arrete la machine sur laquelle il y a la session au lieu de la machine sur laquelle on est et bien évidemment molly guard ne bloque pas le processus.
Ce n'est pas parce que tu as deux mains gauches que tu as le droit de raconter n'importe quoi.
Une session X avec LXDE sur une machine en session XDMCP, le menu pour fermer la session propose "arreter" le copain clique arreter et ça provoque un shutdown sur la machine où était la session. Je n'invente rien. C'est peut-etre corrigé mais ça m'a fait ça en mai dernier. J'étais sur l'autre machine (celle ou il avait la session) et elle s'est mise à faire son shutdown. Le copainn m'avait demandé "je clique sur arreter" et comme un con, je lui avais dit "oui, oui.
OK j'ai deux mains gauche mais je n'invente rien. -- http://mikeread.tripod.com/archive.htm
In article <hi096m$244l$1@nef.ens.fr>,
Nicolas George <nicolas$george@salle-s.org> writes:
Yves Lambert, dans le message <4b43a226$0$10100$426a74cc@news.free.fr>,
a écrit :
En exploitant une faille de HAL ou d'une autre bibliothèque privilégiée.
HAL n'est pas une bibliothèque.
Ou d'une bibliothèque.
« Ou d'une _autre_ bibliothèque », tu as dit.
J'ai donc rectifiée.
Et pour ta gouverne, une bibliothèque ne peut pas avoir de problèmes de
sécurité vis-à-vis du programme qui l'utilise.
Oui unix est un système sur, il n('y a jamais eu de faille de sécurité
il est inutile de les corriger si on en trouve une puisqu'il est
impossible de les exploiter et qu'elles n'existent pas.
HAL m'a énervé : session X à distance, l'appel à HAL arrete la machine sur
laquelle il y a la session au lieu de la machine sur laquelle on est et bien
évidemment molly guard ne bloque pas le processus.
Ce n'est pas parce que tu as deux mains gauches que tu as le droit de
raconter n'importe quoi.
Une session X avec LXDE sur une machine en session XDMCP, le menu pour
fermer la session propose "arreter" le copain clique arreter et ça provoque
un shutdown sur la machine où était la session. Je n'invente rien. C'est
peut-etre corrigé mais ça m'a fait ça en mai dernier. J'étais sur l'autre
machine (celle ou il avait la session) et elle s'est mise à faire son shutdown. Le copainn m'avait demandé
"je clique sur arreter" et comme un con, je lui avais dit "oui, oui.
OK j'ai deux mains gauche mais je n'invente rien.
--
http://mikeread.tripod.com/archive.htm
In article <hi096m$244l$, Nicolas George <nicolas$ writes:
Yves Lambert, dans le message <4b43a226$0$10100$, a écrit :
En exploitant une faille de HAL ou d'une autre bibliothèque privilégiée.
HAL n'est pas une bibliothèque.
Ou d'une bibliothèque.
« Ou d'une _autre_ bibliothèque », tu as dit.
J'ai donc rectifiée.
Et pour ta gouverne, une bibliothèque ne peut pas avoir de problèmes de sécurité vis-à-vis du programme qui l'utilise.
Oui unix est un système sur, il n('y a jamais eu de faille de sécurité il est inutile de les corriger si on en trouve une puisqu'il est impossible de les exploiter et qu'elles n'existent pas.
HAL m'a énervé : session X à distance, l'appel à HAL arrete la machine sur laquelle il y a la session au lieu de la machine sur laquelle on est et bien évidemment molly guard ne bloque pas le processus.
Ce n'est pas parce que tu as deux mains gauches que tu as le droit de raconter n'importe quoi.
Une session X avec LXDE sur une machine en session XDMCP, le menu pour fermer la session propose "arreter" le copain clique arreter et ça provoque un shutdown sur la machine où était la session. Je n'invente rien. C'est peut-etre corrigé mais ça m'a fait ça en mai dernier. J'étais sur l'autre machine (celle ou il avait la session) et elle s'est mise à faire son shutdown. Le copainn m'avait demandé "je clique sur arreter" et comme un con, je lui avais dit "oui, oui.
OK j'ai deux mains gauche mais je n'invente rien. -- http://mikeread.tripod.com/archive.htm
