> Rien à voir avec des crashes. On parle de fonctionnalités ici. Les
> crashes se sont des bugs rien à voir avec un upgrade majeur. Une
> correction de bug c'est un upgrade mineur.
Bah à lire ça, j'espère que tu n'es pas mainteneur d'un soft que
j'utilise. Bon, alors on va faire un petit cours de fiabilité des
logiciels ...
Quand tu fais une upgrade majeure, tu changes du code. Il y a un truc
qui dit qu'un bon développeur, après avoir testé un minimum son
logiciel, laisse environ 5 bugs par 1000 lignes de code. Si tu changes
un million de lignes de code, il faut donc t'attendre à avoir environ
5000 nouveaux bugs, et d'un autre côté, les changements que tu as fait
(souvent des réécritures completes de certains morceaux) t'ont éliminé
un grand nombre de bugs. Bref, entre la version majeure N et la
version N+1, les bugs ne sont pas les mêmes.
Dans tous les cas, sauf utilisation de méthodes formelles, ou petit
bout de code relativement trivial, il y aura des bugs. Il y a
des milliers de bugs dans Windows, des milliers de bugs dans
Debian, ... le truc étant que les milliers de bugs qui restent après
le test, ce sont ceux qui se voient le moins, sinon, on les aurait
corrigé.
Maintenant, tu développes une application par dessus ces milliers de
bugs. Si tu as vraiment de la chance, tu ne tombera sur aucun de ces
bugs, mais peut-être que tu n'auras pas cette chance sur la version
N+1. Si t'as un peu moins de chance, tu tombes sur un bug, et tu
trouves un moyen de le contourner, et là non plus, tu ne sais pas si
ce contournement sera encore valable dans la version suivante. Et si
tu n'as vraiment pas de chance, le bon fonctionnement de ton
application peut dépendre d'un bug, et là, si le bug est corrigé,
c'est le drame (j'avais entendu dire que Windows émulait parfois des
bugs des versions précédantes pour que des applications continuent à
fonctionner).
Si tu n'as pas encore entendu parler d'une application sous Linux qui
cesse de fonctionner à cause d'une upgrade du noyau, de la libc, ou
autre composant du système, je te suggère 1) de te renseigner un peu
2) d'arrêter de donner des leçons.
Allez, quelques exemples :
Combien d'applications développées il y a quelques années ne compilent
même plus sur un GCC récent ?
Combien de fois une décision technique dans le noyau a cassé
cdrecord ?
Alors bien sur, quand les logiciels sont dans la distribution, on
corrige les incompatibilités et la version stable suivante est
cohérente (c'est précisément un des gros avantages du libre), mais il
faut se faire à l'idée que sous la plupart des distributions, si tu
achètes un logiciel externe pour la version N, tu n'as aucune garantie
qu'il continue à marcher après une upgrade du système.
- CVS (vieux, compliqué, pas puissant, ...)
- tla/baz : beaucoup trop compliqués par rapport à ce qu'ils font.
Parmis les stars du moment, il y a bzr (Bazaar-NG) et hg (Mercurial), qui sont tous deux très puissants, extensibles, mais quand même faciles d'utilisation (d'ailleurs, en passant : les équipes des deux sont en train de se rapprocher, il y a peu de chance que ça aboutisse à une fusion, mais il y aura sans doute des ponts entre les deux prochainement. Il y a déjà un plugin expérimental pour accéder à une archive hg depuis bzr).
Dans le genre simple et puissant, il y a Darcs. Le gros point noir de Darcs est qu'il ne passe pas très bien à l'échelle, donc il n'est pas tellement question de l'utiliser sur des très gros projets, et ça a peu de chance de changer.
> Je pense que la communauté, dans toute sa diversité, permet déjà de tester un nombre important de scénario.
Bah, moi, je connais personne qui s'ammuse à tester le passage d'une stable à l'autre. Je connais pleins de gens (dont moi) qui utilisent unstable et font des bug-reports, mais qui n'upgradent que de unstable vers unstable.
Si tu connais des gens qui testent la migration stable vers stable N+1, n'hésites pas à le faire savoir.
Sauf erreur de ma part, c'est 5 ans après la sortie de la version N+1 (histoire que le mec qui a acheté Windows la veille de la sortie de la version suivante ai droit à ses 5 ans de support).
Afficher une image avec rotation, transposée, ou mirroir, un élève de terminale arriverait à le faire sans que ça ne coûte quoi que ce soit. Tu changes les indices de ta boucle, et voilà.
Faire tourner une image décompressée, même avec une relativement haute résolution, y'a pas besoin d'être un géni pour trouver l'algorithme non plus, et se rendre compte que c'est quasi-instantané sur les machines d'aujourd'hui.
Par contre, si je te donne une image jpeg, et que je te demande de la faire tourner de 90 degrés, l'algorithme naïf « décompresser, appliquer l'algo ci-dessus, recompresser » (convert faisait ça a une époque, je ne sais pas si c'est encore le cas) est doublement mauvais. Premièrement, l'algo va passer tout son temps dans la compression et décompression (sur des images à quelques millions de pixels, ça prend vite quelques secondes), et ensuite, la compression étant avec perte, on va perdre en qualité. Par exemple, tu prends une image fortement compressée en jpeg, si tu la fais tourner sans un algo spécifique, soit tu va reperdre énormément en qualité, soit tu auras une image qui prendra plus de place sur le disque.
Pour le jpeg, le problème est partiellement résolu, puisqu'il y a des outils comme jpegtran qui font de la rotation sans perte sur du jpeg, mais la rotation n'est réélement sans perte que si ton image a une dimension, de mémoire, multiple de 8 pixels en horizontal et en vertical (pas étonnant puisque le jpeg travaille sur des blocs de 8x8). Bref, le problème de la rotation du jpeg est effectivement un problème ...
Par exemple, sur mon appareil numérique, je peux faire une « rotation ». En fait, l'appareil se garde bien de faire la rotation lui-même, il se contente d'ajouter l'information sur la rotation dans les données EXIF, et il les utilise pour l'affichage sur l'écran LCD. Ensuite, c'est Digikam qui fait la rotation au moment de récupérer les photos. Mais tout ça, ça passe par EXIF, qui est une extension pas aussi standard qu'elle pourrait l'être. Intégrer ça au format d'image, c'est relativement évident, mais ça n'en est pas moins une très bonne idée.
Si j'ai bien compris, ce n'est pas de ça qu'il s'agit. Ça serait plutôt : autoriser MSIE à accéder au site, et bloquer les firefox.
En local, je ne sais plus comment ça se fait en pratique, mais le noyau peut retrouver quel est l'executable à l'origine d'une connection assez facilement, donc no problem. Par contre, à distance, on a juste les paquets TCP et il faut faire avec, donc, c'est là qu'il faut rajouter une couche, et c'est là qu'il y a forcément un maillon de la chaine de confiance chez le client, qui dit « Ouais, j'ai vérifié, c'est bien un MSIE, laisses-le passer ».
Au passage, si c'était Microsoft qui avait fait ce genre de trucs, et qui l'avait appelé Palladium ou NGSCB, on aurait eu beaucoup moins d'éloge sur ce site ...
Si tu as un firewall entre toi et la machine cible, tu peux toujours essayer de faire un ssh, ça ne marchera pas, il sera bloqué par le firewall. Ce qu'il te faut pour passer à travers le firewall via le proxy, c'est un truc qui se connecte au proxy, et qui lui demande dans le langage des proxys de se connecter à ta machine.
Là, l'astuce, c'est qu'il faut demander au proxy d'établir une connection HTTPS, et en HTTPS, le proxy n'a aucun contrôle sur le contenu (sinon, ça serait une attaque man-in-the-middle), donc, tu peux bien faire passer du ssh à la place du HTTP chiffré, le proxy n'y voit que du feu. Une fois la connection établie, donc, au lieu d'envoyer les paquets directement a la machine vers laquelle tu te connecte, tu les envoies au proxy, et tu recoit de lui.
Corkscrew n'est pas un client ssh, c'est juste un tout petit programme qui fait la bidouille décrite ci-dessus, et tu configures ton OpenSSH pour utiliser corkscrew pour établir la connection. C'est en plus, pas à la place de.
Attention quand même avec cette solution : une partie de la chaine de confiance se trouve chez le client. Si l'utilisateur a le contrôle de la machine cliente, il peut contourner les protections.
C'est juste de passer à travers le proxy de ton côté, et c'est effectivement un hack relativement trivial. Mais de l'autre côté, oui, c'est un ssh qui tourne sur le port 443.
Là, on parle de sécurité. Le programme A, ça peut très bien être un virus ou n'importe quoi que tu ne controles pas.
> D'ailleurs ton programme A peut directement se connecter sur ta machine distante sans AjaxTerm
Ben, là, il est question de contourner les politiques de sécurité, les VPN, toussa, donc, non, le programme A, il ne peut pas se connecter directement.
(hint: google, firewall, proxy, et revient en parler un peu après si tu veux).
> Par ailleurs, AjaxTerm n'a strictement rien à voir avec un VPN : là on parle de
> HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies
> clavier. De là à dire que ça correspond à un VPN du style SSH ...
... il n'y a qu'un pas !
Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm (genre "wget http://mon-site.com/mon-troyen; ./mon-troyen"). Le petit démon B en question peut être un sshd à peine modifié, pour recevoir ses ordres dans stdin et envoyer les données par stdout. Ton programme A se comporte alors comme un client ssh, et B comme le serveur ssh, et tu peux implémenter tout ce que tu faisais avec ssh à travers ton AjaxTerm (avec des performances lamentables, mais bon), y compris le forward de port.
Bref, tu peux très bien implémenter un VPN over AjaxTerm.
Par contre, si la machine avec AjaxTerm est compromise, à priori, ça ne lui donne aucun moyen de compromettre le client.
> Par ailleurs, AjaxTerm n'a strictement rien à voir avec un VPN : là on parle de
> HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies
> clavier. De là à dire que ça correspond à un VPN du style SSH ...
... il n'y a qu'un pas !
Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm (genre "wget http://mon-site.com/mon-troyen; ./mon-troyen"). Le petit démon B en question peut être un sshd à peine modifié, pour recevoir ses ordres dans stdin et envoyer les données par stdout. Ton programme A se comporte alors comme un client ssh, et B comme le serveur ssh, et tu peux implémenter tout ce que tu faisais avec ssh à travers ton AjaxTerm (avec des performances lamentables, mais bon), y compris le forward de port.
Bref, tu peux très bien implémenter un VPN over AjaxTerm.
Par contre, si la machine avec AjaxTerm est compromise, à priori, ça ne lui donne aucun moyen de compromettre le client.
Moi, j'ai bien reçu un mail, que si je le renvoyais à 10 de mes contacts, Bill Gates m'envoyais un chèque de 100 USD, alors si c'est possible de faire ça, pourquoi pas dans l'autre sens, hein !
Sauf erreur de ma part, ils ont commencé à ouvrir des @hotmail. pour faire plus d'adresses possible, parce que les gens en avaient marre de devoir rajouter des _345346 à la fin de leur nom pour avoir une adresse valide (ils doivent toujours le faire, mais un peu moins ...).
$ host -t mx hotmail.fr
hotmail.fr mail is handled by 10 pamx1.hotmail.com.
Au passage, si on reprends les écrits fondateurs, on peut y lire
J'ai été voir mes mails du dimanche matin et j'ai lu planet.gnome debout dans la file du boulanger.
A moins que ça ne soit une typo et qu'il fallait y lire debout dans la fille du boulanger, je crois que les fantasmes de certains linuxfriens s'effondrent, là !
> Relis bien mon poste : certaines personne _ne peuvent pas_ accepter l'argent
Euh, moi, je relis bien ton poste, et je vois : « ne peuvent pas ou ne veulent pas ». Et si tu relis bien le mien, de poste, tu verras que je ne te vise pas personnellement. Bien sûr que si tu ne peux pas toucher l'argent, bah, tu vas pas le toucher ;-).
> je ne vois pas ou est le mal de laisser l'argent a Google
> (meme si ce n'est pas ce que je fais), ils font deja assez avec le programme SoC a mon avis;
Je trouve aussi que le programme SoC est une très bonne initiative, et on ne peut que remercier Google pour ça. Mais il ne faut pas non plus se leurer, ils le font parce qu'ils y ont un intérêt, et l'un des intérêts est de travailler leur image de marque en criant haut et fort qu'ils donnent de l'argent (l'autre, à mon avis, étant d'entretenir des bonnes relations avec les étudiants qu'ils comptent tenter de recruter). Alors si ils se font de la pub en donnant des sous, et que de l'autre côté, les gens les refusent, ils ont un peu le beurre et l'argent du beurre !
Tu constates que le .doc n'y est même pas mentionné (y'en a que pour l'HTML et OpenDocument, c'est scandaleux !). Tu télécharges donc le PDF pointé en haut « volet interopérabilité technique » ( https://www.ateliers.adele.gouv.fr/ministeres/domaines_d_exp(...) ) pour comprendre.
Pour exprimer ton mécontentement, tu cliques sur l'onglet « discussion », puis sur « éditer », et le tour est joué.
[^] # Re: ah merde alors
Posté par Matthieu Moy (site web personnel) . En réponse au journal Debian ne supportera plus la Woody à la fin du mois. Évalué à 2.
> crashes se sont des bugs rien à voir avec un upgrade majeur. Une
> correction de bug c'est un upgrade mineur.
Bah à lire ça, j'espère que tu n'es pas mainteneur d'un soft que
j'utilise. Bon, alors on va faire un petit cours de fiabilité des
logiciels ...
Quand tu fais une upgrade majeure, tu changes du code. Il y a un truc
qui dit qu'un bon développeur, après avoir testé un minimum son
logiciel, laisse environ 5 bugs par 1000 lignes de code. Si tu changes
un million de lignes de code, il faut donc t'attendre à avoir environ
5000 nouveaux bugs, et d'un autre côté, les changements que tu as fait
(souvent des réécritures completes de certains morceaux) t'ont éliminé
un grand nombre de bugs. Bref, entre la version majeure N et la
version N+1, les bugs ne sont pas les mêmes.
Dans tous les cas, sauf utilisation de méthodes formelles, ou petit
bout de code relativement trivial, il y aura des bugs. Il y a
des milliers de bugs dans Windows, des milliers de bugs dans
Debian, ... le truc étant que les milliers de bugs qui restent après
le test, ce sont ceux qui se voient le moins, sinon, on les aurait
corrigé.
Maintenant, tu développes une application par dessus ces milliers de
bugs. Si tu as vraiment de la chance, tu ne tombera sur aucun de ces
bugs, mais peut-être que tu n'auras pas cette chance sur la version
N+1. Si t'as un peu moins de chance, tu tombes sur un bug, et tu
trouves un moyen de le contourner, et là non plus, tu ne sais pas si
ce contournement sera encore valable dans la version suivante. Et si
tu n'as vraiment pas de chance, le bon fonctionnement de ton
application peut dépendre d'un bug, et là, si le bug est corrigé,
c'est le drame (j'avais entendu dire que Windows émulait parfois des
bugs des versions précédantes pour que des applications continuent à
fonctionner).
Si tu n'as pas encore entendu parler d'une application sous Linux qui
cesse de fonctionner à cause d'une upgrade du noyau, de la libc, ou
autre composant du système, je te suggère 1) de te renseigner un peu
2) d'arrêter de donner des leçons.
Allez, quelques exemples :
Combien d'applications développées il y a quelques années ne compilent
même plus sur un GCC récent ?
Combien de fois une décision technique dans le noyau a cassé
cdrecord ?
Alors bien sur, quand les logiciels sont dans la distribution, on
corrige les incompatibilités et la version stable suivante est
cohérente (c'est précisément un des gros avantages du libre), mais il
faut se faire à l'idée que sous la plupart des distributions, si tu
achètes un logiciel externe pour la version N, tu n'as aucune garantie
qu'il continue à marcher après une upgrade du système.
# Conseils
Posté par Matthieu Moy (site web personnel) . En réponse au journal Quel gestionnaire de révisions pour un "débutant". Évalué à 3.
- CVS (vieux, compliqué, pas puissant, ...)
- tla/baz : beaucoup trop compliqués par rapport à ce qu'ils font.
Parmis les stars du moment, il y a bzr (Bazaar-NG) et hg (Mercurial), qui sont tous deux très puissants, extensibles, mais quand même faciles d'utilisation (d'ailleurs, en passant : les équipes des deux sont en train de se rapprocher, il y a peu de chance que ça aboutisse à une fusion, mais il y aura sans doute des ponts entre les deux prochainement. Il y a déjà un plugin expérimental pour accéder à une archive hg depuis bzr).
Dans le genre simple et puissant, il y a Darcs. Le gros point noir de Darcs est qu'il ne passe pas très bien à l'échelle, donc il n'est pas tellement question de l'utiliser sur des très gros projets, et ça a peu de chance de changer.
[^] # Re: ah merde alors
Posté par Matthieu Moy (site web personnel) . En réponse au journal Debian ne supportera plus la Woody à la fin du mois. Évalué à 2.
Bah, moi, je connais personne qui s'ammuse à tester le passage d'une stable à l'autre. Je connais pleins de gens (dont moi) qui utilisent unstable et font des bug-reports, mais qui n'upgradent que de unstable vers unstable.
Si tu connais des gens qui testent la migration stable vers stable N+1, n'hésites pas à le faire savoir.
[^] # Re: ah merde alors
Posté par Matthieu Moy (site web personnel) . En réponse au journal Debian ne supportera plus la Woody à la fin du mois. Évalué à 2.
Là dessus, même Debian est loin derrière.
[^] # Re: Cool...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Dapper jour 1. Évalué à 3.
[^] # Re: Ils sont trop forts, on peut pas lutter ...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Microsoft cherche à remplacer le JPEG. Évalué à 3.
Afficher une image avec rotation, transposée, ou mirroir, un élève de terminale arriverait à le faire sans que ça ne coûte quoi que ce soit. Tu changes les indices de ta boucle, et voilà.
Faire tourner une image décompressée, même avec une relativement haute résolution, y'a pas besoin d'être un géni pour trouver l'algorithme non plus, et se rendre compte que c'est quasi-instantané sur les machines d'aujourd'hui.
Par contre, si je te donne une image jpeg, et que je te demande de la faire tourner de 90 degrés, l'algorithme naïf « décompresser, appliquer l'algo ci-dessus, recompresser » (convert faisait ça a une époque, je ne sais pas si c'est encore le cas) est doublement mauvais. Premièrement, l'algo va passer tout son temps dans la compression et décompression (sur des images à quelques millions de pixels, ça prend vite quelques secondes), et ensuite, la compression étant avec perte, on va perdre en qualité. Par exemple, tu prends une image fortement compressée en jpeg, si tu la fais tourner sans un algo spécifique, soit tu va reperdre énormément en qualité, soit tu auras une image qui prendra plus de place sur le disque.
Pour le jpeg, le problème est partiellement résolu, puisqu'il y a des outils comme jpegtran qui font de la rotation sans perte sur du jpeg, mais la rotation n'est réélement sans perte que si ton image a une dimension, de mémoire, multiple de 8 pixels en horizontal et en vertical (pas étonnant puisque le jpeg travaille sur des blocs de 8x8). Bref, le problème de la rotation du jpeg est effectivement un problème ...
Par exemple, sur mon appareil numérique, je peux faire une « rotation ». En fait, l'appareil se garde bien de faire la rotation lui-même, il se contente d'ajouter l'information sur la rotation dans les données EXIF, et il les utilise pour l'affichage sur l'écran LCD. Ensuite, c'est Digikam qui fait la rotation au moment de récupérer les photos. Mais tout ça, ça passe par EXIF, qui est une extension pas aussi standard qu'elle pourrait l'être. Intégrer ça au format d'image, c'est relativement évident, mais ça n'en est pas moins une très bonne idée.
[^] # Re: Mais comment ca marche ???
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche NuFW 2.0, nouvelle version majeure du pare-feu authentifiant. Évalué à 1.
En local, je ne sais plus comment ça se fait en pratique, mais le noyau peut retrouver quel est l'executable à l'origine d'une connection assez facilement, donc no problem. Par contre, à distance, on a juste les paquets TCP et il faut faire avec, donc, c'est là qu'il faut rajouter une couche, et c'est là qu'il y a forcément un maillon de la chaine de confiance chez le client, qui dit « Ouais, j'ai vérifié, c'est bien un MSIE, laisses-le passer ».
Au passage, si c'était Microsoft qui avait fait ce genre de trucs, et qui l'avait appelé Palladium ou NGSCB, on aurait eu beaucoup moins d'éloge sur ce site ...
[^] # Re: J'ai pas tout pige...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Un émulateur de terminal en AJAX.... Évalué à 4.
Là, l'astuce, c'est qu'il faut demander au proxy d'établir une connection HTTPS, et en HTTPS, le proxy n'a aucun contrôle sur le contenu (sinon, ça serait une attaque man-in-the-middle), donc, tu peux bien faire passer du ssh à la place du HTTP chiffré, le proxy n'y voit que du feu. Une fois la connection établie, donc, au lieu d'envoyer les paquets directement a la machine vers laquelle tu te connecte, tu les envoies au proxy, et tu recoit de lui.
Corkscrew n'est pas un client ssh, c'est juste un tout petit programme qui fait la bidouille décrite ci-dessus, et tu configures ton OpenSSH pour utiliser corkscrew pour établir la connection. C'est en plus, pas à la place de.
[^] # Re: Mais comment ca marche ???
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche NuFW 2.0, nouvelle version majeure du pare-feu authentifiant. Évalué à 3.
[^] # Re: Format d'image supportant les DRM ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal Microsoft cherche à remplacer le JPEG. Évalué à 5.
> des carrés noirs aux emplacements de ces images?
C'était déjà le cas des captures d'écran de MS Encarta 98, donc, oui, c'est très envisageable, et ça a déjà été fait.
[^] # Re: J'ai pas tout pige...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Un émulateur de terminal en AJAX.... Évalué à 2.
[^] # Re: "secure"
Posté par Matthieu Moy (site web personnel) . En réponse au journal Un émulateur de terminal en AJAX.... Évalué à 1.
Là, on parle de sécurité. Le programme A, ça peut très bien être un virus ou n'importe quoi que tu ne controles pas.
> D'ailleurs ton programme A peut directement se connecter sur ta machine distante sans AjaxTerm
Ben, là, il est question de contourner les politiques de sécurité, les VPN, toussa, donc, non, le programme A, il ne peut pas se connecter directement.
(hint: google, firewall, proxy, et revient en parler un peu après si tu veux).
[^] # Re: question
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Summer of Code, enfin les sélections. Évalué à 0.
Tu peux faire s/tu/le mec/ si tu préfères ;-)
[^] # Re: J'ai pas tout pige...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Un émulateur de terminal en AJAX.... Évalué à 2.
C'est bien plus efficace pour faire du ssh-over-https avec proxy.
Mais c'est probablement très limite par rapport à la charte d'utilisation des moyens informatiques de ta boite.
[^] # Re: "secure"
Posté par Matthieu Moy (site web personnel) . En réponse au journal Un émulateur de terminal en AJAX.... Évalué à -3.
> HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies
> clavier. De là à dire que ça correspond à un VPN du style SSH ...
... il n'y a qu'un pas !
Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm (genre "wget http://mon-site.com/mon-troyen; ./mon-troyen"). Le petit démon B en question peut être un sshd à peine modifié, pour recevoir ses ordres dans stdin et envoyer les données par stdout. Ton programme A se comporte alors comme un client ssh, et B comme le serveur ssh, et tu peux implémenter tout ce que tu faisais avec ssh à travers ton AjaxTerm (avec des performances lamentables, mais bon), y compris le forward de port.
Bref, tu peux très bien implémenter un VPN over AjaxTerm.
Par contre, si la machine avec AjaxTerm est compromise, à priori, ça ne lui donne aucun moyen de compromettre le client.
[^] # Re: "secure"
Posté par Matthieu Moy (site web personnel) . En réponse au journal Un émulateur de terminal en AJAX.... Évalué à 2.
> HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies
> clavier. De là à dire que ça correspond à un VPN du style SSH ...
... il n'y a qu'un pas !
Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm (genre "wget http://mon-site.com/mon-troyen; ./mon-troyen"). Le petit démon B en question peut être un sshd à peine modifié, pour recevoir ses ordres dans stdin et envoyer les données par stdout. Ton programme A se comporte alors comme un client ssh, et B comme le serveur ssh, et tu peux implémenter tout ce que tu faisais avec ssh à travers ton AjaxTerm (avec des performances lamentables, mais bon), y compris le forward de port.
Bref, tu peux très bien implémenter un VPN over AjaxTerm.
Par contre, si la machine avec AjaxTerm est compromise, à priori, ça ne lui donne aucun moyen de compromettre le client.
# C'est possible !
Posté par Matthieu Moy (site web personnel) . En réponse au journal Taxe sur les courriels et SMS. Évalué à 8.
---> [ ]
[^] # Re: vraiment
Posté par Matthieu Moy (site web personnel) . En réponse au journal Publicite pour hotmail/msn cachée?. Évalué à 3.
$ host -t mx hotmail.fr
hotmail.fr mail is handled by 10 pamx1.hotmail.com.
[^] # Re: Ce n'est pas exprès
Posté par Matthieu Moy (site web personnel) . En réponse au journal Publicite pour hotmail/msn cachée?. Évalué à 5.
J'ai été voir mes mails du dimanche matin et j'ai lu planet.gnome debout dans la file du boulanger.
A moins que ça ne soit une typo et qu'il fallait y lire debout dans la fille du boulanger, je crois que les fantasmes de certains linuxfriens s'effondrent, là !
[^] # Re: question
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Summer of Code, enfin les sélections. Évalué à 1.
Euh, moi, je relis bien ton poste, et je vois : « ne peuvent pas ou ne veulent pas ». Et si tu relis bien le mien, de poste, tu verras que je ne te vise pas personnellement. Bien sûr que si tu ne peux pas toucher l'argent, bah, tu vas pas le toucher ;-).
> je ne vois pas ou est le mal de laisser l'argent a Google
> (meme si ce n'est pas ce que je fais), ils font deja assez avec le programme SoC a mon avis;
Je trouve aussi que le programme SoC est une très bonne initiative, et on ne peut que remercier Google pour ça. Mais il ne faut pas non plus se leurer, ils le font parce qu'ils y ont un intérêt, et l'un des intérêts est de travailler leur image de marque en criant haut et fort qu'ils donnent de l'argent (l'autre, à mon avis, étant d'entretenir des bonnes relations avec les étudiants qu'ils comptent tenter de recruter). Alors si ils se font de la pub en donnant des sous, et que de l'autre côté, les gens les refusent, ils ont un peu le beurre et l'argent du beurre !
> (ii) Google nous pousse a accepter l'argent.
Ça, au moins, c'est fair-play !!
[^] # Re: question
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Summer of Code, enfin les sélections. Évalué à 1.
Autant accepter les 500$ et les donner à la FSF ou autre si tu ne les veux pas personnellement.
[^] # Re: question
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Summer of Code, enfin les sélections. Évalué à 2.
man ploum
[^] # Re: il faut faire quoi ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Référentiel Général d'Interopérabilité: Nouvel appel à contributions. Évalué à 5.
Mettons que tu veuille imposer le .doc dans l'administration. Tu vas sur la page d'accueil ( http://www.adele.gouv.fr/wiki/index.php/Accueil ), tu cliques sur « Format de document » ( http://www.adele.gouv.fr/wiki/index.php/Formats_de_documents ), et tu regardes quelles sont les règles proposées.
Tu constates que le .doc n'y est même pas mentionné (y'en a que pour l'HTML et OpenDocument, c'est scandaleux !). Tu télécharges donc le PDF pointé en haut « volet interopérabilité technique » ( https://www.ateliers.adele.gouv.fr/ministeres/domaines_d_exp(...) ) pour comprendre.
Pour exprimer ton mécontentement, tu cliques sur l'onglet « discussion », puis sur « éditer », et le tour est joué.
[^] # Re: dans le cadre de : on aurait pu y penser
Posté par Matthieu Moy (site web personnel) . En réponse au sondage Mon logiciel de voix sur IP préféré. Évalué à 2.
[^] # Re: dommageable ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Référentiel Général d'Interopérabilité: Nouvel appel à contributions. Évalué à 5.
L'appel à commentaires débute le 1er avril 2006 et se termine le 30 Août 2006.