Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source
de mon script, mais qu'ils puissent l'éxécuter.
Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source
de mon script, mais qu'ils puissent l'éxécuter.
Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source
de mon script, mais qu'ils puissent l'éxécuter.
Merwin wrote:
Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la sou rce de
mon script, mais qu'ils puissent l'éxécuter.
Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par des
humains.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englo be
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisat eur. La
philosophie du logiciel libre, c'est bien de le montrer à qui veut!
Et si ce script contient des mots de passe ou autre il y a aura des malin s
qui arriveront à le lire.
Merwin wrote:
Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la sou rce de
mon script, mais qu'ils puissent l'éxécuter.
Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par des
humains.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englo be
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisat eur. La
philosophie du logiciel libre, c'est bien de le montrer à qui veut!
Et si ce script contient des mots de passe ou autre il y a aura des malin s
qui arriveront à le lire.
Merwin wrote:
Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la sou rce de
mon script, mais qu'ils puissent l'éxécuter.
Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par des
humains.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englo be
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisat eur. La
philosophie du logiciel libre, c'est bien de le montrer à qui veut!
Et si ce script contient des mots de passe ou autre il y a aura des malin s
qui arriveront à le lire.
Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
a écrit :Merwin wrote:Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
mon script, mais qu'ils puissent l'éxécuter.
Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par des
humains.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisateur. La
philosophie du logiciel libre, c'est bien de le montrer à qui veut!
Et si ce script contient des mots de passe ou autre il y a aura des malins
qui arriveront à le lire.
Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
Libre de fournir des binaires sans les sources à côté.
Cependant c'est possible et Gangan avait fait un billet sur ce sujet
il y a quelque mois :
http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell
Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
<basile@starynkevitch.net> a écrit :
Merwin wrote:
Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
mon script, mais qu'ils puissent l'éxécuter.
Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par des
humains.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisateur. La
philosophie du logiciel libre, c'est bien de le montrer à qui veut!
Et si ce script contient des mots de passe ou autre il y a aura des malins
qui arriveront à le lire.
Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
Libre de fournir des binaires sans les sources à côté.
Cependant c'est possible et Gangan avait fait un billet sur ce sujet
il y a quelque mois :
http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell
Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
a écrit :Merwin wrote:Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
mon script, mais qu'ils puissent l'éxécuter.
Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par des
humains.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisateur. La
philosophie du logiciel libre, c'est bien de le montrer à qui veut!
Et si ce script contient des mots de passe ou autre il y a aura des malins
qui arriveront à le lire.
Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
Libre de fournir des binaires sans les sources à côté.
Cependant c'est possible et Gangan avait fait un billet sur ce sujet
il y a quelque mois :
http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell
Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
a écrit :Merwin wrote:Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
mon script, mais qu'ils puissent l'éxécuter.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Et si ce script contient des mots de passe ou autre il y a aura des malins
qui arriveront à le lire.
Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
Libre de fournir des binaires sans les sources à côté.
Cependant c'est possible et Gangan avait fait un billet sur ce sujet
il y a quelque mois :
http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell
Merci à vous deux, ce n'est pas dans un but purement égoïste, mais si j'offre un service à mes clients qui ont un accès SSH sur la machine, je ne souhaite pas que ce script se retrouve par inadvertance chez un concurrent ;-)
Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
<basile@starynkevitch.net> a écrit :
Merwin wrote:
Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
mon script, mais qu'ils puissent l'éxécuter.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Et si ce script contient des mots de passe ou autre il y a aura des malins
qui arriveront à le lire.
Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
Libre de fournir des binaires sans les sources à côté.
Cependant c'est possible et Gangan avait fait un billet sur ce sujet
il y a quelque mois :
http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell
Merci à vous deux, ce n'est pas dans un but purement égoïste, mais si j'offre un service à mes clients qui ont un accès SSH sur la machine, je ne souhaite pas que ce script se retrouve par inadvertance chez un concurrent ;-)
Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
a écrit :Merwin wrote:Bonjour à tous,
J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
d'éxecuter un script bash, mais pas de le dire ?
L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
mon script, mais qu'ils puissent l'éxécuter.
Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
l'appel au shell. On pourrait aussi dans certains cas et avec certains
shells, s'amuser avec les permissions.
Et si ce script contient des mots de passe ou autre il y a aura des malins
qui arriveront à le lire.
Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
Libre de fournir des binaires sans les sources à côté.
Cependant c'est possible et Gangan avait fait un billet sur ce sujet
il y a quelque mois :
http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell
Merci à vous deux, ce n'est pas dans un but purement égoïste, mais si j'offre un service à mes clients qui ont un accès SSH sur la machine, je ne souhaite pas que ce script se retrouve par inadvertance chez un concurrent ;-)
> De manière plus générale, le fantasme de la sécurité par l'obscurité
reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre
à ses clients, c'est qu'il est un bon commercial, pas forcément un bon
technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
> De manière plus générale, le fantasme de la sécurité par l'obscurité
reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre
à ses clients, c'est qu'il est un bon commercial, pas forcément un bon
technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
> De manière plus générale, le fantasme de la sécurité par l'obscurité
reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre
à ses clients, c'est qu'il est un bon commercial, pas forcément un bon
technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
De manière plus générale, le fantasme de la sécurité par l'obs curité reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients, c'est qu'il est un bon commercial, pas forc ément un bon technicien. http://en.wikipedia.org/wiki/Security_through_ob scurity
Je ne vois pas le rapport entre le besoin initial et les divagations de B asile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à un client. Il est légitime qu'un client ne souhaite pas qu' un travail qu'il a financé profite aussi à ses concurrents.
L'obscurcissement des sources est une solution à moindre coût qui peu t apporter satisfaction. Je ne juge pas par contre de la qualité de la so lution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas?
Protéger un script qui a demandé une semaine de développement contr e un prestataire qui pourrait venir intervenir sur la machine ne nécessit e pas un degré de protection élevé contrairement à un système mil itaire qui est susceptible de se faire attaquer par une centaine de spéci alistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupér er la source au bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante dans pas mal de cas.
De manière plus générale, le fantasme de la sécurité par l'obs curité reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients, c'est qu'il est un bon commercial, pas forc ément un bon technicien. http://en.wikipedia.org/wiki/Security_through_ob scurity
Je ne vois pas le rapport entre le besoin initial et les divagations de B asile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à un client. Il est légitime qu'un client ne souhaite pas qu' un travail qu'il a financé profite aussi à ses concurrents.
L'obscurcissement des sources est une solution à moindre coût qui peu t apporter satisfaction. Je ne juge pas par contre de la qualité de la so lution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas?
Protéger un script qui a demandé une semaine de développement contr e un prestataire qui pourrait venir intervenir sur la machine ne nécessit e pas un degré de protection élevé contrairement à un système mil itaire qui est susceptible de se faire attaquer par une centaine de spéci alistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupér er la source au bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante dans pas mal de cas.
De manière plus générale, le fantasme de la sécurité par l'obs curité reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients, c'est qu'il est un bon commercial, pas forc ément un bon technicien. http://en.wikipedia.org/wiki/Security_through_ob scurity
Je ne vois pas le rapport entre le besoin initial et les divagations de B asile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à un client. Il est légitime qu'un client ne souhaite pas qu' un travail qu'il a financé profite aussi à ses concurrents.
L'obscurcissement des sources est une solution à moindre coût qui peu t apporter satisfaction. Je ne juge pas par contre de la qualité de la so lution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas?
Protéger un script qui a demandé une semaine de développement contr e un prestataire qui pourrait venir intervenir sur la machine ne nécessit e pas un degré de protection élevé contrairement à un système mil itaire qui est susceptible de se faire attaquer par une centaine de spéci alistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupér er la source au bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante dans pas mal de cas.
Mode vendredi ON.
Le 28 octobre 2009 12:18, Vera Mickael a écrit :De manière plus générale, le fantasme de la sécurité par l'obscurité reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients, c'est qu'il est un bon commercial, pas forcément un bon technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il a financé profite aussi à ses concurrents.
Je ne suis pas d'accord avec cette affirmation qui est exactement
celles que les éditeurs de logiciels privateurs avancent pour
justifier la privation de liberté.
La création d'une source n'a pas de cout direct, c'est plutôt un
investissement : celui du temps passé à la création du logiciel. Et
contrairement à ce que notre société nous dicte, le temps ce n'est pas
de l'argent. Dans le monde du logiciel libre, le développeur fait le
plus souvent don de son temps à la communauté en désirant juste que
l'on garde la paternité de son travail. L'investissement est le pari
que le client reviendra vers lui.
Je ne dit pas que logiciel libre doit être gratuit mais que son cout
de reproduction est nul et donc qu'il sort de l'économie de la rareté
imposé par notre monde physique pour entrer dans l'économie de
l'abondance.
S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
protéger, les licences existent.
Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
malhonnête mais possible.
C'est tout autant malhonnête de vendre des milliers de clones (sans
cout de fabrications) de ce qui a été créé une seule fois. La solution
économique au logiciel libre n'est donc pas dans le logiciel mais dans
la valeur ajouté par le créateur : le support, le service rendu.L'obscurcissement des sources est une solution à moindre coût qui peut apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas?
Basile parlait de sécurité non pas au sens sécurité anti-intrusion
mais au sens d'empêcher quelqu'un de voir comment fonctionne le
script. Il parle de sentiment de sécurité du développeur.Protéger un script qui a demandé une semaine de développement contre un prestataire qui pourrait venir intervenir sur la machine ne nécessite pas un degré de protection élevé contrairement à un système militaire qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante dans pas mal de cas.
Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
où le client n'est plus le client et qu'il veut faire évoluer son
système, il sera juste bloqué parce que lui et personne ne pourra
améliorer le script qu'il a pourtant acheté et qui donc lui
appartient. Le logiciel libre va a l'encontre de cette idée de prise
en otage des clients.
Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
le logiciel libre et c'est aussi un grand manque de respect envers les
développeurs dans le monde du logiciel libre. C'est prendre
égoïstement Debian parce que c'est gratuit en se moquant du temps
qu'ils ont passés et pourquoi ils l'ont fait.
Mode Vendredi Off
--
Kévin
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
http://identi.ca/khi - http://twitter.com/kh_i - http://system-linux.eu
Nick IRC : khi sur irc.mozilla.org - irc.debian.org - irc.freenode.net
Mode vendredi ON.
Le 28 octobre 2009 12:18, Vera Mickael <vera.mickael@free.fr> a écrit :
De manière plus générale, le fantasme de la sécurité par l'obscurité reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients, c'est qu'il est un bon commercial, pas forcément un bon technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il a financé profite aussi à ses concurrents.
Je ne suis pas d'accord avec cette affirmation qui est exactement
celles que les éditeurs de logiciels privateurs avancent pour
justifier la privation de liberté.
La création d'une source n'a pas de cout direct, c'est plutôt un
investissement : celui du temps passé à la création du logiciel. Et
contrairement à ce que notre société nous dicte, le temps ce n'est pas
de l'argent. Dans le monde du logiciel libre, le développeur fait le
plus souvent don de son temps à la communauté en désirant juste que
l'on garde la paternité de son travail. L'investissement est le pari
que le client reviendra vers lui.
Je ne dit pas que logiciel libre doit être gratuit mais que son cout
de reproduction est nul et donc qu'il sort de l'économie de la rareté
imposé par notre monde physique pour entrer dans l'économie de
l'abondance.
S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
protéger, les licences existent.
Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
malhonnête mais possible.
C'est tout autant malhonnête de vendre des milliers de clones (sans
cout de fabrications) de ce qui a été créé une seule fois. La solution
économique au logiciel libre n'est donc pas dans le logiciel mais dans
la valeur ajouté par le créateur : le support, le service rendu.
L'obscurcissement des sources est une solution à moindre coût qui peut apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas?
Basile parlait de sécurité non pas au sens sécurité anti-intrusion
mais au sens d'empêcher quelqu'un de voir comment fonctionne le
script. Il parle de sentiment de sécurité du développeur.
Protéger un script qui a demandé une semaine de développement contre un prestataire qui pourrait venir intervenir sur la machine ne nécessite pas un degré de protection élevé contrairement à un système militaire qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante dans pas mal de cas.
Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
où le client n'est plus le client et qu'il veut faire évoluer son
système, il sera juste bloqué parce que lui et personne ne pourra
améliorer le script qu'il a pourtant acheté et qui donc lui
appartient. Le logiciel libre va a l'encontre de cette idée de prise
en otage des clients.
Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
le logiciel libre et c'est aussi un grand manque de respect envers les
développeurs dans le monde du logiciel libre. C'est prendre
égoïstement Debian parce que c'est gratuit en se moquant du temps
qu'ils ont passés et pourquoi ils l'ont fait.
Mode Vendredi Off
--
Kévin
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
http://identi.ca/khi - http://twitter.com/kh_i - http://system-linux.eu
Nick IRC : khi sur irc.mozilla.org - irc.debian.org - irc.freenode.net
Mode vendredi ON.
Le 28 octobre 2009 12:18, Vera Mickael a écrit :De manière plus générale, le fantasme de la sécurité par l'obscurité reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients, c'est qu'il est un bon commercial, pas forcément un bon technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il a financé profite aussi à ses concurrents.
Je ne suis pas d'accord avec cette affirmation qui est exactement
celles que les éditeurs de logiciels privateurs avancent pour
justifier la privation de liberté.
La création d'une source n'a pas de cout direct, c'est plutôt un
investissement : celui du temps passé à la création du logiciel. Et
contrairement à ce que notre société nous dicte, le temps ce n'est pas
de l'argent. Dans le monde du logiciel libre, le développeur fait le
plus souvent don de son temps à la communauté en désirant juste que
l'on garde la paternité de son travail. L'investissement est le pari
que le client reviendra vers lui.
Je ne dit pas que logiciel libre doit être gratuit mais que son cout
de reproduction est nul et donc qu'il sort de l'économie de la rareté
imposé par notre monde physique pour entrer dans l'économie de
l'abondance.
S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
protéger, les licences existent.
Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
malhonnête mais possible.
C'est tout autant malhonnête de vendre des milliers de clones (sans
cout de fabrications) de ce qui a été créé une seule fois. La solution
économique au logiciel libre n'est donc pas dans le logiciel mais dans
la valeur ajouté par le créateur : le support, le service rendu.L'obscurcissement des sources est une solution à moindre coût qui peut apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas?
Basile parlait de sécurité non pas au sens sécurité anti-intrusion
mais au sens d'empêcher quelqu'un de voir comment fonctionne le
script. Il parle de sentiment de sécurité du développeur.Protéger un script qui a demandé une semaine de développement contre un prestataire qui pourrait venir intervenir sur la machine ne nécessite pas un degré de protection élevé contrairement à un système militaire qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante dans pas mal de cas.
Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
où le client n'est plus le client et qu'il veut faire évoluer son
système, il sera juste bloqué parce que lui et personne ne pourra
améliorer le script qu'il a pourtant acheté et qui donc lui
appartient. Le logiciel libre va a l'encontre de cette idée de prise
en otage des clients.
Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
le logiciel libre et c'est aussi un grand manque de respect envers les
développeurs dans le monde du logiciel libre. C'est prendre
égoïstement Debian parce que c'est gratuit en se moquant du temps
qu'ils ont passés et pourquoi ils l'ont fait.
Mode Vendredi Off
--
Kévin
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
http://identi.ca/khi - http://twitter.com/kh_i - http://system-linux.eu
Nick IRC : khi sur irc.mozilla.org - irc.debian.org - irc.freenode.net
De manière plus générale, le fantasme de la sécurit é par l'obscurité
reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le
vendre à ses clients, c'est qu'il est un bon commercial, pas
forcément un bon
technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations
de Basile ?
L'objet de la question initiale est de protéger la source d'un trava il
facturé à un client. Il est légitime qu'un client ne souha ite pas
qu'un travail qu'il a financé profite aussi à ses concurrents.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise Ã
protéger un système des attaques? Je ne vois pas?
De manière plus générale, le fantasme de la sécurit é par l'obscurité
reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le
vendre à ses clients, c'est qu'il est un bon commercial, pas
forcément un bon
technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations
de Basile ?
L'objet de la question initiale est de protéger la source d'un trava il
facturé à un client. Il est légitime qu'un client ne souha ite pas
qu'un travail qu'il a financé profite aussi à ses concurrents.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise Ã
protéger un système des attaques? Je ne vois pas?
De manière plus générale, le fantasme de la sécurit é par l'obscurité
reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le
vendre à ses clients, c'est qu'il est un bon commercial, pas
forcément un bon
technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations
de Basile ?
L'objet de la question initiale est de protéger la source d'un trava il
facturé à un client. Il est légitime qu'un client ne souha ite pas
qu'un travail qu'il a financé profite aussi à ses concurrents.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise Ã
protéger un système des attaques? Je ne vois pas?
Mais il est pourtant possible que le client paye pour un logiciel, sans
que ce logiciel soit forcément privateur. C'est exactement ce que j'ai
pû faire durant ces 2 dernières années. Le logiciel est libre,
accessible, et pourtant en grande partie financé par un client.
Dans son esprit (le client), il a payé pour le logiciel, mais surtout
pour l'expérience acquise, la possibilité d'avoir un support pointu, et
la pérennité du logiciel comparé à la pérennité de la société qui l'a
développé.
Mais il est pourtant possible que le client paye pour un logiciel, sans
que ce logiciel soit forcément privateur. C'est exactement ce que j'ai
pû faire durant ces 2 dernières années. Le logiciel est libre,
accessible, et pourtant en grande partie financé par un client.
Dans son esprit (le client), il a payé pour le logiciel, mais surtout
pour l'expérience acquise, la possibilité d'avoir un support pointu, et
la pérennité du logiciel comparé à la pérennité de la société qui l'a
développé.
Mais il est pourtant possible que le client paye pour un logiciel, sans
que ce logiciel soit forcément privateur. C'est exactement ce que j'ai
pû faire durant ces 2 dernières années. Le logiciel est libre,
accessible, et pourtant en grande partie financé par un client.
Dans son esprit (le client), il a payé pour le logiciel, mais surtout
pour l'expérience acquise, la possibilité d'avoir un support pointu, et
la pérennité du logiciel comparé à la pérennité de la société qui l'a
développé.
Mode vendredi ON.
Le 28 octobre 2009 12:18, Vera Mickael a écrit :De manière plus générale, le fantasme de la sécurité par l'obscurité reste un
fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients,
c'est qu'il est un bon commercial, pas forcément un bon technicien.
http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à
un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il
a financé profite aussi à ses concurrents.
Je ne suis pas d'accord avec cette affirmation qui est exactement
celles que les éditeurs de logiciels privateurs avancent pour
justifier la privation de liberté.
La création d'une source n'a pas de cout direct, c'est plutôt un
investissement : celui du temps passé à la création du logiciel. Et
contrairement à ce que notre société nous dicte, le temps ce n'est pas
de l'argent. Dans le monde du logiciel libre, le développeur fait le
plus souvent don de son temps à la communauté en désirant juste que
l'on garde la paternité de son travail. L'investissement est le pari
que le client reviendra vers lui.
Je ne dit pas que logiciel libre doit être gratuit mais que son cout
de reproduction est nul et donc qu'il sort de l'économie de la rareté
imposé par notre monde physique pour entrer dans l'économie de
l'abondance.
S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
protéger, les licences existent.
Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
malhonnête mais possible.
C'est tout autant malhonnête de vendre des milliers de clones (sans
cout de fabrications) de ce qui a été créé une seule fois. La solution
économique au logiciel libre n'est donc pas dans le logiciel mais dans
la valeur ajouté par le créateur : le support, le service rendu.
L'obscurcissement des sources est une solution à moindre coût qui peut
apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger
un système des attaques? Je ne vois pas?
Basile parlait de sécurité non pas au sens sécurité anti-intrusion
mais au sens d'empêcher quelqu'un de voir comment fonctionne le
script. Il parle de sentiment de sécurité du développeur.Protéger un script qui a demandé une semaine de développement contre
un prestataire qui pourrait venir intervenir sur la machine ne nécessite
pas un degré de protection élevé contrairement à un système militaire
qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au
bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante
dans pas mal de cas.
Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
où le client n'est plus le client et qu'il veut faire évoluer son
système, il sera juste bloqué parce que lui et personne ne pourra
améliorer le script qu'il a pourtant acheté et qui donc lui
appartient. Le logiciel libre va a l'encontre de cette idée de prise
en otage des clients.
Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
le logiciel libre et c'est aussi un grand manque de respect envers les
développeurs dans le monde du logiciel libre. C'est prendre
égoïstement Debian parce que c'est gratuit en se moquant du temps
qu'ils ont passés et pourquoi ils l'ont fait.
Mode Vendredi Off
Mode vendredi ON.
Le 28 octobre 2009 12:18, Vera Mickael <vera.mickael@free.fr> a écrit :
De manière plus générale, le fantasme de la sécurité par l'obscurité reste un
fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients,
c'est qu'il est un bon commercial, pas forcément un bon technicien.
http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à
un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il
a financé profite aussi à ses concurrents.
Je ne suis pas d'accord avec cette affirmation qui est exactement
celles que les éditeurs de logiciels privateurs avancent pour
justifier la privation de liberté.
La création d'une source n'a pas de cout direct, c'est plutôt un
investissement : celui du temps passé à la création du logiciel. Et
contrairement à ce que notre société nous dicte, le temps ce n'est pas
de l'argent. Dans le monde du logiciel libre, le développeur fait le
plus souvent don de son temps à la communauté en désirant juste que
l'on garde la paternité de son travail. L'investissement est le pari
que le client reviendra vers lui.
Je ne dit pas que logiciel libre doit être gratuit mais que son cout
de reproduction est nul et donc qu'il sort de l'économie de la rareté
imposé par notre monde physique pour entrer dans l'économie de
l'abondance.
S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
protéger, les licences existent.
Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
malhonnête mais possible.
C'est tout autant malhonnête de vendre des milliers de clones (sans
cout de fabrications) de ce qui a été créé une seule fois. La solution
économique au logiciel libre n'est donc pas dans le logiciel mais dans
la valeur ajouté par le créateur : le support, le service rendu.
L'obscurcissement des sources est une solution à moindre coût qui peut
apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger
un système des attaques? Je ne vois pas?
Basile parlait de sécurité non pas au sens sécurité anti-intrusion
mais au sens d'empêcher quelqu'un de voir comment fonctionne le
script. Il parle de sentiment de sécurité du développeur.
Protéger un script qui a demandé une semaine de développement contre
un prestataire qui pourrait venir intervenir sur la machine ne nécessite
pas un degré de protection élevé contrairement à un système militaire
qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au
bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante
dans pas mal de cas.
Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
où le client n'est plus le client et qu'il veut faire évoluer son
système, il sera juste bloqué parce que lui et personne ne pourra
améliorer le script qu'il a pourtant acheté et qui donc lui
appartient. Le logiciel libre va a l'encontre de cette idée de prise
en otage des clients.
Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
le logiciel libre et c'est aussi un grand manque de respect envers les
développeurs dans le monde du logiciel libre. C'est prendre
égoïstement Debian parce que c'est gratuit en se moquant du temps
qu'ils ont passés et pourquoi ils l'ont fait.
Mode Vendredi Off
Mode vendredi ON.
Le 28 octobre 2009 12:18, Vera Mickael a écrit :De manière plus générale, le fantasme de la sécurité par l'obscurité reste un
fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients,
c'est qu'il est un bon commercial, pas forcément un bon technicien.
http://en.wikipedia.org/wiki/Security_through_obscurity
Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
L'objet de la question initiale est de protéger la source d'un travail facturé à
un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il
a financé profite aussi à ses concurrents.
Je ne suis pas d'accord avec cette affirmation qui est exactement
celles que les éditeurs de logiciels privateurs avancent pour
justifier la privation de liberté.
La création d'une source n'a pas de cout direct, c'est plutôt un
investissement : celui du temps passé à la création du logiciel. Et
contrairement à ce que notre société nous dicte, le temps ce n'est pas
de l'argent. Dans le monde du logiciel libre, le développeur fait le
plus souvent don de son temps à la communauté en désirant juste que
l'on garde la paternité de son travail. L'investissement est le pari
que le client reviendra vers lui.
Je ne dit pas que logiciel libre doit être gratuit mais que son cout
de reproduction est nul et donc qu'il sort de l'économie de la rareté
imposé par notre monde physique pour entrer dans l'économie de
l'abondance.
S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
protéger, les licences existent.
Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
malhonnête mais possible.
C'est tout autant malhonnête de vendre des milliers de clones (sans
cout de fabrications) de ce qui a été créé une seule fois. La solution
économique au logiciel libre n'est donc pas dans le logiciel mais dans
la valeur ajouté par le créateur : le support, le service rendu.
L'obscurcissement des sources est une solution à moindre coût qui peut
apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.
Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger
un système des attaques? Je ne vois pas?
Basile parlait de sécurité non pas au sens sécurité anti-intrusion
mais au sens d'empêcher quelqu'un de voir comment fonctionne le
script. Il parle de sentiment de sécurité du développeur.Protéger un script qui a demandé une semaine de développement contre
un prestataire qui pourrait venir intervenir sur la machine ne nécessite
pas un degré de protection élevé contrairement à un système militaire
qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.
Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au
bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante
dans pas mal de cas.
Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
où le client n'est plus le client et qu'il veut faire évoluer son
système, il sera juste bloqué parce que lui et personne ne pourra
améliorer le script qu'il a pourtant acheté et qui donc lui
appartient. Le logiciel libre va a l'encontre de cette idée de prise
en otage des clients.
Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
le logiciel libre et c'est aussi un grand manque de respect envers les
développeurs dans le monde du logiciel libre. C'est prendre
égoïstement Debian parce que c'est gratuit en se moquant du temps
qu'ils ont passés et pourquoi ils l'ont fait.
Mode Vendredi Off