Re: Protéger un script
Je ne pensais déclencher tant de réactions avec mon mail :-) Le logiciel libre est bien entendu un concept intéressant, je suis le premier utilisateur ET contributeur à l'occasion dans le cadre de mon travail. Autant l'objectif des sources libres est très attrayant, aujourd'hui le modèle économique du logiciel libre ne permet pas d'envisager tous les développements avec un retour sur investissement garanti. 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 suis pas d'accord pour dire que la création d'une source n'a pas de coût direct. Comment peut-on dire cela? Ma société développe un logiciel qui cumule aujourd'hui 25 années hommes de développement, je te laisse faire le calcul du coût. Bien entendu pour financer le développement nous vendons ce produit. Effectivement le coût de reproduction est nul. C'est bien pourquoi rendre un logiciel libre c'est prendre le risque que quelqu'un reprenne le développement à son compte. 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. Le risque c'est qu'une société investisse des millions d'euros (c'est le coût d'un gros logiciel) et qu'une autre société vende du conseil sans avoir besoin de rentabiliser l'investissement. Qui va investir si cela se passe comme ça? 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. Le lien qu'il a envoyé discutait de l'impact sur la sécurité de l'obscurcissement du système ce qui me semble est hors sujet, c'est pour cela que j'ai réagi. 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. Tu fais un raccourci. Tu peux très bien fournir au client les sources et un moyen de protéger son script lorsqu'il l'installe. C'est très courant, j'ai travaillé sur plusieurs systèmes qui fonctionnent comme cela avec une clé à brancher. (Peu m'importe la fiabilité de la protection). 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. Cette vision est simpliste et ne prend pas en compte les milliards d'euros qui sont investis dans les entreprises tous les ans pour développer des logiciels. Perso si je développe un générateur de gallerie web de photos sur ton mon temps libre j'ai tout intérêt à le diffuser. Si une société d'aviation développe un protocole réseau pour ses besoins, elle a tout intérêt à le rendre libre, cela ne va pas directement profiter à ses concurrents. Idem pour les labos de recherche. Mais maintenant si une entreprise qui construit des voitures développe pour des millions d'euros un logiciel qui permet d'analyser les bruits parasites dans une voiture elle espèrera rentabiliser son investissement en vendant des voitures moins bruyantes que ses concurrents. Si elle rend son logiciels libre, tous ses concurrents vont utiliser le logiciel sans avoir à amortir le coût de l'investissement. C'est l'entreprise qui a investi qui va le moins vendre puisque ses voitures seront plus chères. Je ne défends pas le monde de la concurrence et toutes ses dérives. Je fais un constat et j'en déduis que le modèle économique du logiciel libre ne permet pas il me semble aujourd'hui d'envisager de gros investissements. J'ai beaucoup de respect pour les développeurs du monde libre et on ne peut que les remercier de leurs contributions. Cependant je pense qu'on trouvera facilement un passionné de photo ou de 3D pour développer des applications sur leur temps libre parce que justement cela les passionne. Moi le premier j'ai passé des mois à développer un logiciel de gestion de course à pied parce que cela m'amusait. Trouver un développeur qui sur son temps libre va s'amuser à produire un logiciel pour effectuer des calculs de câblage dans une machine à laver je pense que cela sera plus dur. Ceux-là il faudra les payer et il faudra
Re: Protéger un script
houlà, ça c'est un modèle qui date du moyen âge (pgm s/s ZX-81 peut-être) le modèle actuel est que le client paye le dev, puis que ledit dev est en Gal reversé en tant que contribution à la communauté; ce qui permet, C'est ton avis perso et non argumenté ;-) Je connais des sociétés pour qui ce modèle fonctionne bien, Oracle, IBM, Microsoft, BEA, ... Et je connais aussi beaucoup de clients, EDF, SNCF, Administrations, fabricants de voitures et d'avions qui fonctionnent avec ce modèle. c'est faux: depuis que le monde est monde, dès qu'un type a voulu se garder quelque chose sans partager, il-y-en a toujours eu un autre, en Gal plus brillant, qui regardait par-dessus son épaule et libérait le savoir (fausse monnaie, reverse engineering, cracking des protections, contournement logiciel des dongles hardware, ...) Ca ne regarde que toi de considérer qu'un faux monnayeur ou un pirate est quelqu'un de plus brillant qu'un inventeur ;-) vi, un simple exemple: le client n'a qu'un binaire, le dev meurt, le client se retrouve dans la merde (ça fait aussi partie d'un service au client de qualité que de prévoir ce genre de situation.) Les entreprises se prémunissent contre ces désagréments, vous connaissez mal les contrats qui unissent les éditeurs de logiciel et leurs client. En général les éditeurs s'engagent à rendre les sources libres si le logiciel meurt. Mickaël -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
Vera Mickael a écrit : Je ne pensais déclencher tant de réactions avec mon mail :-) Le logiciel libre est bien entendu un concept intéressant, je suis le premier utilisateur ET contributeur à l'occasion dans le cadre de mon travail. Autant l'objectif des sources libres est très attrayant, aujourd'hui le modèle économique du logiciel libre ne permet pas d'envisager tous les développements avec un retour sur investissement garanti. Hum, explique ça à RedHat, ça va bien les faire rire ! 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 suis pas d'accord pour dire que la création d'une source n'a pas de coût direct. Comment peut-on dire cela? Ma société développe un logiciel qui cumule aujourd'hui 25 années hommes de développement, je te laisse faire le calcul du coût. Bien entendu pour financer le développement nous vendons ce produit. Effectivement le coût de reproduction est nul. C'est bien pourquoi rendre un logiciel libre c'est prendre le risque que quelqu'un reprenne le développement à son compte. 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. Le risque c'est qu'une société investisse des millions d'euros (c'est le coût d'un gros logiciel) et qu'une autre société vende du conseil sans avoir besoin de rentabiliser l'investissement. Qui va investir si cela se passe comme ça? Il y a de très grosses sociétés qui investissent dans le développement de logiciels libre, et des états également. Tu devrais peut-être te documenter un peu sur le sujet... 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. Le lien qu'il a envoyé discutait de l'impact sur la sécurité de l'obscurcissement du système ce qui me semble est hors sujet, c'est pour cela que j'ai réagi. 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. Tu fais un raccourci. Tu peux très bien fournir au client les sources et un moyen de protéger son script lorsqu'il l'installe. C'est très courant, j'ai travaillé sur plusieurs systèmes qui fonctionnent comme cela avec une clé à brancher. (Peu m'importe la fiabilité de la protection). 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. Cette vision est simpliste et ne prend pas en compte les milliards d'euros qui sont investis dans les entreprises tous les ans pour développer des logiciels. Perso si je développe un générateur de gallerie web de photos sur ton mon temps libre j'ai tout intérêt à le diffuser. Si une société d'aviation développe un protocole réseau pour ses besoins, elle a tout intérêt à le rendre libre, cela ne va pas directement profiter à ses concurrents. Idem pour les labos de recherche. Mais maintenant si une entreprise qui construit des voitures développe pour des millions d'euros un logiciel qui permet d'analyser les bruits parasites dans une voiture elle espèrera rentabiliser son investissement en vendant des voitures moins bruyantes que ses concurrents. Si elle rend son logiciels libre, tous ses concurrents vont utiliser le logiciel sans avoir à amortir le coût de l'investissement. C'est l'entreprise qui a investi qui va le moins vendre puisque ses voitures seront plus chères. Je ne défends pas le monde de la concurrence et toutes ses dérives. Je fais un constat et j'en déduis que le modèle économique du logiciel libre ne permet pas il me semble aujourd'hui d'envisager de gros investissements. Là tu est mûr pour utiliser Winchose ou MacOS. C'est Novell, RedHat, IBM et bien d'autres qui doivent soudain être pris d'une angoisse terrible : ils viennent de découvrir que leur modèle économique n'est pas viable, et ne permet pas de gros investissements... Zut alors. ;-) J'ai beaucoup de respect pour les développeurs du monde libre et on ne peut que
Re: Protéger un script
Autant l'objectif des sources libres est très attrayant, aujourd'hui le modèle économique du logiciel libre ne permet pas d'envisager tous les développements avec un retour sur investissement garanti. Hum, explique ça à RedHat, ça va bien les faire rire ! 1 - je pense que TOUS les développements ne sont possibles sur le mode du libre. Je ne dis pas qu'il n'existe pas des développements possible sur le modèle du libre. Tu ne démontres rien avec cet exemple. 2 - Merci pour cet exemple, il va exactement dans le sens de ce que j'avance. En comparaison du volume des softs qu'il inclue dans sa distribution, Red-Hat n'a pratiquement rien développé. Donc Red-Hat n'a rien investi mais il tire des bénéfices du travail de bénévoles qui eux ne toucheront rien du tout. Ceci dit le travail fourni par Red-Hat est tout à fait intéressant et louable. Ma société est aussi partenaire de Red-Hat je ne vais pas cracher dans la soupe :-) Si Red-Hat avait dû financer le développement de l'ensemble de sa distribution il n'aurait pas les moyens de rembourser cet investissement. Il y a de très grosses sociétés qui investissent dans le développement de logiciels libre, et des états également. Tu devrais peut-être te documenter un peu sur le sujet... Je ne dis pas le contraire de ce que tu dis. Tu ne fais pas avancer le débat. Je n'oppose pas libre et marché des éditeurs, je pense qu'il y a des domaines plus adaptés à l'un ou à l'autre. Pour ton information, notre produit est aussi financé par les administrations. Les administrations ne financent pas uniquement les logiciels libres. Et les administrations développent parfois elles aussi des logiciels non libres. D'ailleurs certaines administrations sont réticentes aux logiciles libres et tu auras du mal à leur faire remplacer leur Oracle/IBM/Sun par du Postgres/Jboss/Linux. Je ne défends pas le monde de la concurrence et toutes ses dérives. Je fais un constat et j'en déduis que le modèle économique du logiciel libre ne permet pas il me semble aujourd'hui d'envisager de gros investissements. Là tu est mûr pour utiliser Winchose ou MacOS. C'est Novell, RedHat, IBM et bien d'autres qui doivent soudain être pris d'une angoisse terrible : ils viennent de découvrir que leur modèle économique n'est pas viable, et ne permet pas de gros investissements... Zut alors. ;-) Désolé mais je ne te suis pas, on ne se comprend pas ? Il me semblait qu'IBM était avant tout un éditeur qui vend: - du système - de la base de données - des serveurs d'application - de nombreux autres outils ... Même si IBM a financé de l'open source (eclipse) peut-être avec de très mauvaises intentions, comme par exemple mettre des bâtons dans les roues à son grand concurrent Sun (Eclipse / Sun). IBM reste un éditeur qui vend du logiciel non libre. Quand IBM éditeur de logiciels se sera écroulé, on pourra éventuellement reprendre l'exemple d'IBM pour tenter d'affirmer que le modèle économique des éditeurs de logiciels n'est plus viable. Aujourd'hui je pense qu'IBM se porte relativement bien. Je te rejoins sur un point, je trouve dommage que une fois qu'un logiciel a été développé il ne puisse pas être librement utilisé. Idem pour les disques. C'est du gâchis de ne pas pouvoir écouter une musique parce que l'on n'a pas les moyens de se payer des centaines de disques. Tu as des doutes au sujet du logiciel libre, mais du piratage non... Vive la liberté temps qu'elle me profite exclusivement... Encore une fois je ne te comprends pas ? Tu comprends ce que tu as envie de comprendre. Je ne défends pas le piratage et je ne vois pas ce qui peut te le faire penser. J'affirme juste que peu de gens ont les moyens aujourd'hui de se payer de centaines de disques et que du coup il sont privés de les écouter alors que ces disques existent. Je fais le rapprochement avec les logiciels non libres. Ce que je ne vois pas aujourd'hui dans notre monde actuel, c'est comment financer les développement puis les rendre libres. Heureusement d'autres ont trouvé la solution. Mais ce n'est pas toi qui m'en auras convaincu. Mickaël -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
Le 27 octobre 2009 17:33, Basile STARYNKEVITCH bas...@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 -- 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 -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
Kevin Hinault a écrit : Le 27 octobre 2009 17:33, Basile STARYNKEVITCH bas...@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 Merci à vous deux, ce n'est pas dans un but purement égoiste, 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 ;-) C'est vraiment un cas exceptionnel! -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
Kevin Hinault wrote:
Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
bas...@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
Oui, mais la protection fournie est illusoire. Un shell ça organise
surtout des tas d'appels systèmes, qu'on peut tracer par des outils
comme strace ou ltrace.
Moi je voudrais comprendre quand même ce que Merwin croit cacher dans ce
script. Mon intuition, c'est qu'il se fait de grosses illusions sur la
pseudo-sécurité d'une telle approche.
Rendre le code source d'un shell script illisible par un utilisateur ne
suffit pas à cacher ce que fait ce script.
J'insiste pour Merwin: s'il ne prend pas d'autres précautions, sa
protection ne sert à rien. Il faudrait donc qu'il explique un peu plus
ce qu'il cherche à cacher.
Merwin explique vaguement:
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 ;-)
La protection contre ce genre de piratage est de nature légale (un
copyright, une licence, un contrat) ou sociale, pas technique. Et je ne
crois pas trop qu'un concurrent prenne la peine de voir ce script.
En plus, le fait que Merwin envisage de cacher juste un script me fait
méchamment penser qu'il ne maîtrise pas toutes les subtilités de la
sécurité d'un système (autrement il n'aurait pas formulé sa question
telle qu'il l'a initialement fait). Donc sa concurrence n'a pas intérêt
à copier la mauvaise solution de Merwin, mais à faire mieux donc autrement.
Si on veut restreindre l'accès par SSH il est préférable d'utiliser un
shell restreint pour ça. http://en.wikipedia.org/wiki/Restricted_shell
mais c'est difficile à configurer correctement.
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
Librement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
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. 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? Je rappelle que les premières questions à se poser quand on veut mettre en place de la sécurité sont: - qui est susceptible de m'attaquer - quelle est la valeur de ce que je protège - quelles moyens suis-je prêt à mettre en oeuvre 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. Mickaël -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
Mode vendredi ON. Le 28 octobre 2009 12:18, Vera Mickael vera.mick...@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 -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
Kevin Hinault a écrit : Mode vendredi ON. Le 28 octobre 2009 12:18, Vera Mickael vera.mick...@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 J'interviens pour expliquer le pourquoi du comment, je loue des shells à des utilisateurs, ils ont donc accès des ressources sur la machine, en plus de ça je mets à leurs disposition des scripts bash fais par mes soins permettant pour eux l'automatisation de certaines taches, comme l'insatallation, la compilation automatique d'un logiciel X. Je ne souhaite pas que d'autres concurrents utilisent mes scripts pour fournir le même service à leurs utilisateurs. Si c'est contre le logiciel je m'en excuse et je suis bien entendu prêt à changer ma façon de faire, Cordialement -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
Le 14545ième jour après Epoch, Vera Mickael écrivait: 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 ? Il est trivial pourtant: cacher un shell est relativement illusoire, car il sera toujours possible de voir quelles sont les commandes que ce shell lance (strace), et éventuellement en déduire ensuite les grandes lignes de ce que ça fait. 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. 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é. Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas? Pourtant c'est la même chose. Sécuriser des choses en les cachant est un mauvais moyen en général. On ne protège pas ssh en le faisant écouter sur un autre port. On ne fait qu'éventuellement augmenter le temps que va mettre l'attaquant à trouver le bon port. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
Kevin Hinault a écrit : Mode vendredi ON. et même Vendredi matin Le 28 octobre 2009 12:18, Vera Mickael vera.mick...@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. houlà, ça c'est un modèle qui date du moyen âge (pgm s/s ZX-81 peut-être) le modèle actuel est que le client paye le dev, puis que ledit dev est en Gal reversé en tant que contribution à la communauté; ce qui permet, entre autres avantages, débugging/amélioration/etc par la communauté (la programmation, c'est comme le fric, la bagnole et le reste: il-y-en a toujours un qui en a plus que toi...) 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 plussois 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. c'est ausi en Gal un juste retour des choses: on prend à la communauté, et on lui rend par la mise à disposition d'un travail (correctement exécuté, s'entend.) S'il désire vendre sa création, rien ne l'en empêche. S'il désire le protéger, les licences existent. et il-y-en a pour tous les goûts des licenses; . Si n'importe qui désire vendre du logiciel libre, il le peut. C'est malhonnête mais possible. heureusement, les diverses associations libres veillent de plus en plus au grain, et l'on sent pointer une reconnaissance certaine des licenses type GPL un peu partout en europe. 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. wai, c'est exactement comme de dire qu'un d'jeun va regretter les photos d'une fête arrosée mises en ligne: y'a que les vieux cons pour penser que c'est le reflet de toute sa vie et surtout _juger_ une personne là-dessus. 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. c'est faux: depuis que le monde est monde, dès qu'un type a voulu se garder quelque chose sans partager, il-y-en a toujours eu un autre, en Gal plus brillant, qui regardait par-dessus son épaule et libérait le savoir (fausse monnaie, reverse engineering, cracking des protections, contournement logiciel des dongles hardware, ...) c'est juste une question de temps et de compétence (cf, par exemple, la dissection du fonctionnement intime de skype, en son temps, par des spécialistes de la sécurité) 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. la CIA n'a pas les services idoines: ce sont le FBI et la NSA qui font ce type de boulot. et la plupart du temps, les réseaux militaires très sensibles US sont carrément totalement déconnectés de l'Internet (et passent par leurs propres fibres/cuivres.) 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
Re: Protéger un script
François TOURDE a écrit : ... 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é. Sans oublier non plus le fait que le soft colle *exactement* aux besoins/désirs du client! -- Other than that, Mrs. Lincoln, how did you like the play? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
On Wed, Oct 28, 2009 at 12:18:41PM +0100, Vera Mickael wrote: Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas? Bah, on cherche à protéger le code source (ou le script, j'ai pas très bien compris) contre la copie. Il vient de me venir une idée d'ailleurs: faire tourner le script derrière une fifo, et donner aux utilisateurs une autre commande qui écrit dans la fifo. On peut alors garder le script totalement invisible pour l'utilisateur. Ça pose par contre d'autres problèmes (comment le script sait-il que l'utilisateur a le droit d'executer le script, comment sait-il s'il se fait passer pour un autre utilisateur...) Y. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Re: Protéger un script
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.
Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs From et Reply-To:
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
