Re-bonjour (j'en profite),
Merci pour les conseils précédents. J'ai encore quelques petits
problèmes avec emacs, ou plus précisèment avec Gnus. J'ai configuré ce
dernier pour utiliser imaps, tout fonctionne bien, sauf que
régulièrement emacs 'freeze'.
Dans le meilleur des cas, je tue openssl
et je peux recharger le groupe ou rafraîchir le buffer *Group*. Il
arrive cependant qu'emacs 'freeze' lors du chargement des groupe de
news normaux nntp (tels que celui-ci).
Enfin, en l'utilisant sur un portable qui est régulièrement
ensommeillé donc deconnecté du réseau, je suis souvent obligé de tuer
tout le monde pour repartir sur des bases saines. J'avais auparavant
une config à base de fetchmail qui fonctionnait bien (ou plutôt mieux)
mais avait l'inconvénient d'être localisée à une machine pas toujours
accessible en ssh (j'interviens régulièrement dans des entreprises où
les règles sont sévères et stupides: http/https et point-barre).
Bon, enfin voila, j'ai retourné le manuel de Gnus mais avec peu de
succès.
Ak, ok donc pour appeler les choses par leur nom il y a le proxy qui filtre et / ou sert de mandataire (éventuellement avec un cache pour ne pas redemander plusieurs fois la même ressource) l'http, et le firewall qui filtre et / ou route des ports et des paquets ip.
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça serait une sorte d'attaque man-in-the-middle si c'était vraiment le proxy qui envoyait la requette, comprennait le résultat, et te le transmettait). En https, le proxy établit la connection, et te laisse faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du HTTPS).
dans ce thread. J'ai déjà utilisé à travers un proxy filtrant sans soucis ^_^.
-- Matthieu
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
Ak, ok donc pour appeler les choses par leur nom il y a le proxy qui
filtre et / ou sert de mandataire (éventuellement avec un cache pour ne
pas redemander plusieurs fois la même ressource) l'http, et le firewall
qui filtre et / ou route des ports et des paquets ip.
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça
serait une sorte d'attaque man-in-the-middle si c'était vraiment le
proxy qui envoyait la requette, comprennait le résultat, et te le
transmettait). En https, le proxy établit la connection, et te laisse
faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du
HTTPS).
Ak, ok donc pour appeler les choses par leur nom il y a le proxy qui filtre et / ou sert de mandataire (éventuellement avec un cache pour ne pas redemander plusieurs fois la même ressource) l'http, et le firewall qui filtre et / ou route des ports et des paquets ip.
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça serait une sorte d'attaque man-in-the-middle si c'était vraiment le proxy qui envoyait la requette, comprennait le résultat, et te le transmettait). En https, le proxy établit la connection, et te laisse faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du HTTPS).
dans ce thread. J'ai déjà utilisé à travers un proxy filtrant sans soucis ^_^.
-- Matthieu
Insitu
Matthieu Moy writes:
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça serait une sorte d'attaque man-in-the-middle si c'était vraiment le proxy qui envoyait la requette, comprennait le résultat, et te le transmettait). En https, le proxy établit la connection, et te laisse faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du HTTPS).
dans ce thread. J'ai déjà utilisé à travers un proxy filtrant sans soucis ^_^.
OK. C'est assez logique en y reflechissant, puisque c'est la connexion TCP qui encrypte les paquets, non ? Bon enfin bref, merci pour les infos, je ne serais plus perdu la prochaine fois sans pouvoir me connecter à mon screen :)
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça
serait une sorte d'attaque man-in-the-middle si c'était vraiment le
proxy qui envoyait la requette, comprennait le résultat, et te le
transmettait). En https, le proxy établit la connection, et te laisse
faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du
HTTPS).
dans ce thread. J'ai déjà utilisé à travers un proxy filtrant sans
soucis ^_^.
OK. C'est assez logique en y reflechissant, puisque c'est la connexion
TCP qui encrypte les paquets, non ? Bon enfin bref, merci pour les
infos, je ne serais plus perdu la prochaine fois sans pouvoir me
connecter à mon screen :)
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça serait une sorte d'attaque man-in-the-middle si c'était vraiment le proxy qui envoyait la requette, comprennait le résultat, et te le transmettait). En https, le proxy établit la connection, et te laisse faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du HTTPS).
dans ce thread. J'ai déjà utilisé à travers un proxy filtrant sans soucis ^_^.
OK. C'est assez logique en y reflechissant, puisque c'est la connexion TCP qui encrypte les paquets, non ? Bon enfin bref, merci pour les infos, je ne serais plus perdu la prochaine fois sans pouvoir me connecter à mon screen :)
insitu.
Eric Masson
Matthieu Moy writes:
'Lut,
Bref, si vous croyez à la pérénité de ce truc, bah pas moi.
Je n'en sais strictement rien, par contre les fonctionnalités sur lesquelles l'équipe semble bosser sont intéressantes.
-- Bref, j'en ai lu des conneries dans fufe, j'en ai même écrit, mais là, on flirte avec le ruban bleu. -+- RM in : <http://www.le-gnu.net> - Ca mérite le GNUban bleu -+-
Bref, si vous croyez à la pérénité de ce truc, bah pas moi.
Je n'en sais strictement rien, par contre les fonctionnalités sur
lesquelles l'équipe semble bosser sont intéressantes.
--
Bref, j'en ai lu des conneries dans fufe, j'en ai même écrit, mais là,
on flirte avec le ruban bleu.
-+- RM in : <http://www.le-gnu.net> - Ca mérite le GNUban bleu -+-
Bref, si vous croyez à la pérénité de ce truc, bah pas moi.
Je n'en sais strictement rien, par contre les fonctionnalités sur lesquelles l'équipe semble bosser sont intéressantes.
-- Bref, j'en ai lu des conneries dans fufe, j'en ai même écrit, mais là, on flirte avec le ruban bleu. -+- RM in : <http://www.le-gnu.net> - Ca mérite le GNUban bleu -+-
Sébastien Kirche
Le 17 juillet 2007 à 11:28, Insitu a dit :
Mais il y a des clients paranoïaques (sans raison d'ailleurs, c'est pas la DGSE): dans le cas que j'ai en tête, non seulement on ne pouvait utiliser que du http/https au travers d'un proxy/cache, mais en plus on ne pouvait pas télécharger ce qu'on voulait et parfois le proxy analysait le contenu des .jar :)
C'est le cas de mon employeur actuel : on a une cochonnerie de proxy nommé astaro qui interdit certains sites en se basant sur des catégories (sexe, militaria, religion) et peut-être des mots-clés sauf que je ne sais pas comment est fait la classification car des sites de dev informatique se font interdire sur des critères très bizarres.
Ainsi http://www.crasseux.com/ qui propose un emacs cvs win32 est interdite pour cause de « Warez / Hacking / Illegal Software »... ?
Le même proxy empêche le chargement de certains fichiers et pour des formats comme zip, jar, gzip... soit je peux télécharger directement soit je suis obligé d'attendre qu'il fasse le téléchargement pour moi et qu'il en scanne le contenu contre les virus. Mais le chargement n'est pas transparent et je dois utiliser une page web spéciale. Du coup ça me casse le fonctionnement des installations de packages pour eclipse par exemple, et si je n'avais pas trouvé ntlmaps je ne pourrais pas installer d'egg python ou de gem ruby...
J'en connais qui utilisent ajaxterm, mais je n'ai personellement jamais essayé.
Ça a l'air intéressant ce truc, je vais regarder de plus près mais malheureusement les ports 8080 ou 8022 utilisés par ajaxterm ne passent pas ici :( -- Sébastien Kirche
Le 17 juillet 2007 à 11:28, Insitu a dit :
Mais il y a des clients paranoïaques (sans raison d'ailleurs, c'est
pas la DGSE): dans le cas que j'ai en tête, non seulement on ne
pouvait utiliser que du http/https au travers d'un proxy/cache, mais
en plus on ne pouvait pas télécharger ce qu'on voulait et parfois le
proxy analysait le contenu des .jar :)
C'est le cas de mon employeur actuel : on a une cochonnerie de proxy
nommé astaro qui interdit certains sites en se basant sur des catégories
(sexe, militaria, religion) et peut-être des mots-clés sauf que je ne
sais pas comment est fait la classification car des sites de dev
informatique se font interdire sur des critères très bizarres.
Ainsi http://www.crasseux.com/ qui propose un emacs cvs win32 est
interdite pour cause de « Warez / Hacking / Illegal Software »... ?
Le même proxy empêche le chargement de certains fichiers et pour des
formats comme zip, jar, gzip... soit je peux télécharger directement
soit je suis obligé d'attendre qu'il fasse le téléchargement pour moi et
qu'il en scanne le contenu contre les virus. Mais le chargement n'est
pas transparent et je dois utiliser une page web spéciale. Du coup ça me
casse le fonctionnement des installations de packages pour eclipse par
exemple, et si je n'avais pas trouvé ntlmaps je ne pourrais pas
installer d'egg python ou de gem ruby...
J'en connais qui utilisent ajaxterm, mais je n'ai personellement
jamais essayé.
Ça a l'air intéressant ce truc, je vais regarder de plus près mais
malheureusement les ports 8080 ou 8022 utilisés par ajaxterm ne passent
pas ici :(
--
Sébastien Kirche
Mais il y a des clients paranoïaques (sans raison d'ailleurs, c'est pas la DGSE): dans le cas que j'ai en tête, non seulement on ne pouvait utiliser que du http/https au travers d'un proxy/cache, mais en plus on ne pouvait pas télécharger ce qu'on voulait et parfois le proxy analysait le contenu des .jar :)
C'est le cas de mon employeur actuel : on a une cochonnerie de proxy nommé astaro qui interdit certains sites en se basant sur des catégories (sexe, militaria, religion) et peut-être des mots-clés sauf que je ne sais pas comment est fait la classification car des sites de dev informatique se font interdire sur des critères très bizarres.
Ainsi http://www.crasseux.com/ qui propose un emacs cvs win32 est interdite pour cause de « Warez / Hacking / Illegal Software »... ?
Le même proxy empêche le chargement de certains fichiers et pour des formats comme zip, jar, gzip... soit je peux télécharger directement soit je suis obligé d'attendre qu'il fasse le téléchargement pour moi et qu'il en scanne le contenu contre les virus. Mais le chargement n'est pas transparent et je dois utiliser une page web spéciale. Du coup ça me casse le fonctionnement des installations de packages pour eclipse par exemple, et si je n'avais pas trouvé ntlmaps je ne pourrais pas installer d'egg python ou de gem ruby...
J'en connais qui utilisent ajaxterm, mais je n'ai personellement jamais essayé.
Ça a l'air intéressant ce truc, je vais regarder de plus près mais malheureusement les ports 8080 ou 8022 utilisés par ajaxterm ne passent pas ici :( -- Sébastien Kirche
Sébastien Kirche
Le 17 juillet 2007 à 11:20, Matthieu Moy vraute :
Dans l'annonce initiale de la création de SXEmacs [1], le type justifiait le fait qu'il forkait XEmacs plutôt que d'y contribuer directement par ceci :
,---- > We don't wish to eventually become absorbed into the XEmacs (or > GNU/Emacs) code base, and we have no desire for the opposite to > happen. > > I'm a leader, not a follower, the SXEmacs Project is the same. I > sincerely hope you can keep up with (even surpass) us. `----
Que je traduirait en Français par un truc du genre « J'ai fait SXEmacs parce que là, au moins, c'est moi le chef ».
Ah oui, quand même. Avec ce que relates plus haut de xtla j'ai l'impression que le monsieur a un ego assez développé, disons.
Il veut devenir RMS à la place de RMS ?
Bref, si vous croyez à la pérénité de ce truc, bah pas moi.
J'aime assez les affirmations péremptoires du style « c'est comme ça parce qu'on l'a décidé et ça ne saurait être autrement » qu'on peut lire ça et là sur la page d'accueil.
Dommage et déception :( -- Sébastien Kirche
Le 17 juillet 2007 à 11:20, Matthieu Moy vraute :
Dans l'annonce initiale de la création de SXEmacs [1], le type
justifiait le fait qu'il forkait XEmacs plutôt que d'y contribuer
directement par ceci :
,----
> We don't wish to eventually become absorbed into the XEmacs (or
> GNU/Emacs) code base, and we have no desire for the opposite to
> happen.
>
> I'm a leader, not a follower, the SXEmacs Project is the same. I
> sincerely hope you can keep up with (even surpass) us.
`----
Que je traduirait en Français par un truc du genre « J'ai fait SXEmacs
parce que là, au moins, c'est moi le chef ».
Ah oui, quand même. Avec ce que relates plus haut de xtla
j'ai l'impression que le monsieur a un ego assez développé, disons.
Il veut devenir RMS à la place de RMS ?
Bref, si vous croyez à la pérénité de ce truc, bah pas moi.
J'aime assez les affirmations péremptoires du style « c'est comme ça
parce qu'on l'a décidé et ça ne saurait être autrement » qu'on peut lire
ça et là sur la page d'accueil.
Dans l'annonce initiale de la création de SXEmacs [1], le type justifiait le fait qu'il forkait XEmacs plutôt que d'y contribuer directement par ceci :
,---- > We don't wish to eventually become absorbed into the XEmacs (or > GNU/Emacs) code base, and we have no desire for the opposite to > happen. > > I'm a leader, not a follower, the SXEmacs Project is the same. I > sincerely hope you can keep up with (even surpass) us. `----
Que je traduirait en Français par un truc du genre « J'ai fait SXEmacs parce que là, au moins, c'est moi le chef ».
Ah oui, quand même. Avec ce que relates plus haut de xtla j'ai l'impression que le monsieur a un ego assez développé, disons.
Il veut devenir RMS à la place de RMS ?
Bref, si vous croyez à la pérénité de ce truc, bah pas moi.
J'aime assez les affirmations péremptoires du style « c'est comme ça parce qu'on l'a décidé et ça ne saurait être autrement » qu'on peut lire ça et là sur la page d'accueil.
Dommage et déception :( -- Sébastien Kirche
Erwan David
Matthieu Moy écrivait :
Sébastien Kirche writes:
Ak, ok donc pour appeler les choses par leur nom il y a le proxy qui filtre et / ou sert de mandataire (éventuellement avec un cache pour ne pas redemander plusieurs fois la même ressource) l'http, et le firewall qui filtre et / ou route des ports et des paquets ip.
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça serait une sorte d'attaque man-in-the-middle si c'était vraiment le proxy qui envoyait la requette, comprennait le résultat, et te le transmettait). En https, le proxy établit la connection, et te laisse faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du HTTPS).
Les proxys qui font vraiment proxy avec inspection du contenu en HTTPS, ça existe... Il suffit juste qu'ils génèrent un certificat à la volée pour le site demandé, signé par une autorité connue du browser, par exemple l'autorité interne à la boite où c'est installé.
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
Ak, ok donc pour appeler les choses par leur nom il y a le proxy qui
filtre et / ou sert de mandataire (éventuellement avec un cache pour ne
pas redemander plusieurs fois la même ressource) l'http, et le firewall
qui filtre et / ou route des ports et des paquets ip.
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça
serait une sorte d'attaque man-in-the-middle si c'était vraiment le
proxy qui envoyait la requette, comprennait le résultat, et te le
transmettait). En https, le proxy établit la connection, et te laisse
faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du
HTTPS).
Les proxys qui font vraiment proxy avec inspection du contenu en HTTPS,
ça existe... Il suffit juste qu'ils génèrent un certificat à la volée
pour le site demandé, signé par une autorité connue du browser, par
exemple l'autorité interne à la boite où c'est installé.
Ak, ok donc pour appeler les choses par leur nom il y a le proxy qui filtre et / ou sert de mandataire (éventuellement avec un cache pour ne pas redemander plusieurs fois la même ressource) l'http, et le firewall qui filtre et / ou route des ports et des paquets ip.
Oui, mais pour du HTTP_S_, le proxy ne fait pas vraiment proxy (ça serait une sorte d'attaque man-in-the-middle si c'était vraiment le proxy qui envoyait la requette, comprennait le résultat, et te le transmettait). En https, le proxy établit la connection, et te laisse faire le boulot (d'où la facilité à tunneliser n'importe quoi dans du HTTPS).
Les proxys qui font vraiment proxy avec inspection du contenu en HTTPS, ça existe... Il suffit juste qu'ils génèrent un certificat à la volée pour le site demandé, signé par une autorité connue du browser, par exemple l'autorité interne à la boite où c'est installé.
