mais d'un coté tu dis que les langages de haut niveau sont trop complexes et n'apportent rien
J'ai écris ca où ? Je n'ai pas généralisé, je parle de Lisaac. En l'occurence je ne vois rien de révolutionnaire en pratique dans ce langage comme a pu l'être la locomotive par rapport à la charette. J'ai pris l'exemple de la sécurité (au sens qualité/bug et au sens protection contre code malveillant), c'est tout.
Choisi ton camps camarade.
Non. Ce n'est pas le but.
Tout ce que je dis est que du point de vue de l'OS
Oué c'est pas faux, mamoi j'ai juste rajouté qu'une machine virtuelle qui a un modèle n'offrant d'accès bas niveau comme une JVM ajoute une couche de sécurité en plus de l'OS.
La façon la plus simple de faire celà est d'aller modifier le bytecode d'une des classe de base.
Tu te rends bien compte que tu triches. Forcement, en java à partir du moment où tu peux écrire dans un fichier tu peux t'amuser à faire écrire à ton programme un Java un bout de code en C ou modifier un fichier de bytecode.
Bref on a tout ce qu'il faut pour envoyer la JVM dans le mur
Si la JVM est bien faite, tu dois pouvoir la configurer pour interdire au programme exécuter d'intéragir avec les .class du code exécuté. J'avoue ne pas être un spécialiste de la sécu des JVM, mais je suppose qu'une JVM configurée pour exécuter du code provenant du net (style une applet) empêche ce genre d'astuce.
En tout cas dans l'environnement .NET proche de celui de Java, l'environnement ne laisse pas les composants faire ce genre de connerie s'il ne sont pas de confiance.
Bref, y'a un modèle "virtuel" intermédiaire avant l'OS qui autorise l'application de tout un ensemple de règles de sécurité plus fines et qui sont toujorus bonnes à prendre avant l'OS.
Je vois bien une applet écrite en C qui tourne dans un navigateur web. A moins de sandboxer le navigateur dans son ensemble (ce qu'est obligé de faire MS avec IE par exemple), par défaut l'applet C pourrait faire toutes les conneries puisque tournant avec les mêmes droit que le navigateur qui héberge le code. A moins de s'amuser à forker sur un compte avec des droits réstreind toussa. Lourd, coûteux et pas forcement adapté.
Pour en revenir à la choucroute initiale, ca ne change rien au problème : Lisaac n'apportera pas grand chose de ce point de vue là.
[^] # Re: C'est trop compliqué !
Posté par TImaniac (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
J'ai écris ca où ? Je n'ai pas généralisé, je parle de Lisaac. En l'occurence je ne vois rien de révolutionnaire en pratique dans ce langage comme a pu l'être la locomotive par rapport à la charette. J'ai pris l'exemple de la sécurité (au sens qualité/bug et au sens protection contre code malveillant), c'est tout.
Choisi ton camps camarade.
Non. Ce n'est pas le but.
Tout ce que je dis est que du point de vue de l'OS
Oué c'est pas faux, mamoi j'ai juste rajouté qu'une machine virtuelle qui a un modèle n'offrant d'accès bas niveau comme une JVM ajoute une couche de sécurité en plus de l'OS.
La façon la plus simple de faire celà est d'aller modifier le bytecode d'une des classe de base.
Tu te rends bien compte que tu triches. Forcement, en java à partir du moment où tu peux écrire dans un fichier tu peux t'amuser à faire écrire à ton programme un Java un bout de code en C ou modifier un fichier de bytecode.
Bref on a tout ce qu'il faut pour envoyer la JVM dans le mur
Si la JVM est bien faite, tu dois pouvoir la configurer pour interdire au programme exécuter d'intéragir avec les .class du code exécuté. J'avoue ne pas être un spécialiste de la sécu des JVM, mais je suppose qu'une JVM configurée pour exécuter du code provenant du net (style une applet) empêche ce genre d'astuce.
En tout cas dans l'environnement .NET proche de celui de Java, l'environnement ne laisse pas les composants faire ce genre de connerie s'il ne sont pas de confiance.
Bref, y'a un modèle "virtuel" intermédiaire avant l'OS qui autorise l'application de tout un ensemple de règles de sécurité plus fines et qui sont toujorus bonnes à prendre avant l'OS.
Je vois bien une applet écrite en C qui tourne dans un navigateur web. A moins de sandboxer le navigateur dans son ensemble (ce qu'est obligé de faire MS avec IE par exemple), par défaut l'applet C pourrait faire toutes les conneries puisque tournant avec les mêmes droit que le navigateur qui héberge le code. A moins de s'amuser à forker sur un compte avec des droits réstreind toussa. Lourd, coûteux et pas forcement adapté.
Pour en revenir à la choucroute initiale, ca ne change rien au problème : Lisaac n'apportera pas grand chose de ce point de vue là.