peck a écrit 565 commentaires

Marrant, toutes les réponses que je vois sont des "interfaces" à iptables (sauf une).
A croire que personne n'a utilisé zonealarm

Mais il ne permet pas de réagir à un paquet qui vient de passer. Problème, une fois que le paquet syn est perdu, c'est foutu pour la connexion.

> A ma connaissance ça n'existe pas sous Linux. Un patch kernel pourrait apporter ce genre de fonctionnalités, mais de manière plus compliquée étant donnée la multiplicité d'interfaces et le fait que le noyau n'en connaisse rien. Il faudrait
> a) modifier iptables pour que, lorsqu'il rencontre un paquet sans règle de gestion, un appel à un helper en userland (à la /sbin/hotplug) soit fait.
> b) que ce helper pose la question à l'utilisateur (détecter si un serveur X est lancé, lequel est actif, y afficher une fenêtre en utilisant la variable DISPLAY, etc - la partie la moins facile à mon avis, et la plus "bidouille affreuse")
> c) que ce helper mette à jour les règles iptables
> d) qu'il rende la main au noyau pour laisser passer, ou non, le paquet.

> Avec la difficulté supplémentaire de "suspendre" le paquet sans le rejeter, ni le dropper, en attendant la réponse.

Il existe un module iptables qui fait presque tout ça.
Quand une règle lui spécifie un paquet il le passe en userland et attend qu'un processus prenne la décision.

Il suffit alors de faire une interface graphique qui met en dur les règles de bases et passe le reste à ce module. Ensuite elle fait ce qu'elle veut des paquets restant (nouvelles règles, gestions évoluée de règles, filtre bayésien ...).
Tout est possible au seul inconvénient que ce module n'inclue pas la possibilité de connaitre (et donc de filtrer) le processus qui a envoyé le paquet.

Guarddog est comme firestarter, il permet de donner facilement des règles statiques. Mais pour ce qui est d'un changement dynamique ...
Me trompe-je ?

Ca permet de savoir quel logiciel local tente de se connecter à l'extérieur.
Un pro qui connait le code de tout ce qu'il installe peut le dire, mais le néophyte ?

Ca permet aussi au passage de n'autoriser que certaines personnes à se connecter
chez soi sur un serveur donné.

> En plus FT s'est engagé à déployer l'ADSL sur tout NRA où 100 demandes d'abonnement seraient faites (tous opérateurs confondus).

Marrant, chez nous, ils ont exigé qu'on s'engage à s'abonner à wanadoo.

Ce qu'ils n'osent pas avouer c'est que s'ils sortent les versions trops vite, ils n'auront plus assez de nouveaux noms disponibles.

Une révolution pour ceux qui se donnent la peine de porter les softs sur autre chose que x86.

Dans le ne même thread :

> * Theodore Ts'o (tytso@mit.edu) wrote:
> > You forgot one other thing. We'll also have to strip **ALL**
> > **FONTS** from Debian, since fonts come in binary form, and we don't
> > have anything approaching the "preferred form for modification" for
> > fonts. In particular, the Truetype Bitstream Vera fonts which were so
> > generously donated by Vera was generated not only using propietary
> > source files, but also using propietary non-free programs.
>
> Well, now, I'm not entirely convinced of this. Could a similar argument
> not be used on JPEG's or PNG's? Do we have *some* reasonable way to
> modify these fonts? It's been a long time, but I did hack on some fonts
> a long time ago and while it wasn't the most fun thing I could have
> sworn there was a free program available to do it..

Ah, but I could hack around firmware using a hex editor as well. The
question is whether or not a compressed PCF or truetype font file is
the "preferred form for modification" --- i.e., source. If the
requirement is that "source" is available for all files shipped in
main, I don't see how we can include any of our fonts in the Debian
distribution.

- Ted

P.S. For non-x86 kernels, the kernel includes fonts for console
support. So despite removing the firmware from the kernel, at least
for non-x86 kernels, we will probably need to move the kernel into
non-free as well.

Yay, rah.

Prem's !
Tu peux aussi mettre 'AddDefaultCharset off' dans ton httpd.conf pour qu'apache ne donne pas ce charset.

> En fait il suffit qu'une ou deux entreprises se "sacrifient"

Se sacrifier, est-ce bien une solution ? Disons qu'il faudrait qu'il paient un informaticien et un comptable pour qu'il travaillent ensemble Pendant un certain temps puor qu'ils puissent publier des spécifications précises et utilisables par des programmeurs.
Je ne pense pas qu'une PME puisse se le permettre. Et je ne sais pas si les grosses entreprises s'intéressent vraiment au sujet.

Pourquoi ne pas la resortir après le rentrée pour attirer plus de monde.

Je ne vois pas le rapport !
On peu très bien etre patron d'un pme et avoir un écran en 800x600. D'une pas toute les PME ne sont pas riches au point de se permettre une écran 19 pouces. Et d'autre part tout le monde n'est pas masochiste au point de vouloir du 1600x1200 quite a ne plus voir les pixels.

Et qu'est-ce qui prouve que celui qui a fait ca ne fait pas partie de ceux qui vérifient l'intégrité des codes ?

Et le beurre est sans sel bien sur !