Et le code closed source est finalement plus lu que l'open source car des gens sont payés pour le faire. *
Et la marmotte.... Là ou je bosse, les softs sont troués de partout. C'est du code fermé pourtant... Dans certains cas, j'utilise même une injection SQL (!!!) pour ne pas me faire chier à devoir m'administrer des droits qui me permettraient d'utiliser l'un des softs qu'on à fait normalement. Dans d'autres cas, on à des logs blindés de segfaults (donc, probabilité de pouvoir utiliser une attaque sur les buffer).
Le prestataire qui s'occupe d'administrer les machines physique et virtuelles sur lesquelles on déploie, n'à fais aucune mise à jour depuis... 'tendez je regarde, puisque j'ai les accès root... 15:01:35 up 337 days, 22:58, 2 users, load average: 0,45, 0,36, 0,33. Ah, pas encore un an, mais ça viens. Mais c'est pas comme si l'actu de l'année avait été chaude niveau sécu, hein.
Bien sûr, dans ma boîte, on pourrait corriger nos merdes, mais... le client qui nous demande le dev se mêle de nous faire imposer l'archi logicielle par quelqu'un qui ne connaît pas le dev, pas du tout, alors nous on doit juste pisser du code. Pas motivant, et c'est encore sans compter le reste des contraintes.
Le code de merde et dégueu (et je suis l'auteur d'une partie de ce code) il y en à à la fois dans le code libre, et dans le pas libre. C'est juste que, dans le code libre, on peut le voir... plus facile de faire des injections de code quand on à le source, après tout. Plus facile aussi de boucher les trous quand on s'aperçoit qu'il y en a, et surtout, surtout, plus gratifiant.
Compiler un soft libre, c'est dur? Bah, je vais garder l'exemple de ma boîte: un projet, un dev. Le Makefile est fait en fonction de la config locale du gars en question, chemins codés en dur, binaires qui se cassent la gueule si les fichiers ne sont pas placés ou il faut (et c'est pas des endroits standards). Bien sûr, aucun installateur ou paquet standard.
Il m'a récemment fallu 2 jours pour parvenir à compiler deux programmes, qui ne pèsent pourtant même pas 8200 lignes de code (j'en ai profité pour foutre tout ce bazard dans des dépôt git, au lieu de cp.old, utiliser les git submodules et faire des CMakeLists.txt pour pouvoir tout compiler sans dépendre de la plate-forme sur laquelle on est... mais ce n'est pas ce qui m'a pris le plus de temps!).
Le Monsieur en question, il bosse pour qui, il fait quoi, exactement? Parce que les SSII comme la mienne, je doute qu'il n'y en ait qu'une seule. D'ailleurs, quand j'apprenais, il y à 10 ans, le reverse engineering, les tutos ne portaient jamais sur l'exploitation des failles de logiciels libre, mais systématiquement sur du code fermé.
Soyons sérieux un instant: il n'y à sûrement aucune différence de propreté prouvable entre les codes fermés et les codes libres, et ce n'est pas parce que quelqu'un est payé qu'il fera du bon boulot.
Maintenant, s'il dit que les binaires fermés sont plus simples à installer que les binaires libres, ok, alors parlons des pilotes de périphérique sous windows. Ah, non, pardon, le monsieur compare la compilation des sources d'un projet libre avec l'installation d'un projet fermé... Pas trop facile, de comparé des torchons et des navets, pour dire que le navet est le plus digeste?
PS: ça tombe bien, j'avais justement envie de me défouler. Merci pour le troll :)
# Ahahaha
Posté par freem . En réponse au journal C'est vendredi, c'est trolldi, c'est permis : l'open source n'est pas secure. Évalué à 10.
Et la marmotte.... Là ou je bosse, les softs sont troués de partout. C'est du code fermé pourtant... Dans certains cas, j'utilise même une injection SQL (!!!) pour ne pas me faire chier à devoir m'administrer des droits qui me permettraient d'utiliser l'un des softs qu'on à fait normalement. Dans d'autres cas, on à des logs blindés de segfaults (donc, probabilité de pouvoir utiliser une attaque sur les buffer).
Le prestataire qui s'occupe d'administrer les machines physique et virtuelles sur lesquelles on déploie, n'à fais aucune mise à jour depuis... 'tendez je regarde, puisque j'ai les accès root...
15:01:35 up 337 days, 22:58, 2 users, load average: 0,45, 0,36, 0,33. Ah, pas encore un an, mais ça viens. Mais c'est pas comme si l'actu de l'année avait été chaude niveau sécu, hein.Bien sûr, dans ma boîte, on pourrait corriger nos merdes, mais... le client qui nous demande le dev se mêle de nous faire imposer l'archi logicielle par quelqu'un qui ne connaît pas le dev, pas du tout, alors nous on doit juste pisser du code. Pas motivant, et c'est encore sans compter le reste des contraintes.
Le code de merde et dégueu (et je suis l'auteur d'une partie de ce code) il y en à à la fois dans le code libre, et dans le pas libre. C'est juste que, dans le code libre, on peut le voir... plus facile de faire des injections de code quand on à le source, après tout. Plus facile aussi de boucher les trous quand on s'aperçoit qu'il y en a, et surtout, surtout, plus gratifiant.
Compiler un soft libre, c'est dur? Bah, je vais garder l'exemple de ma boîte: un projet, un dev. Le Makefile est fait en fonction de la config locale du gars en question, chemins codés en dur, binaires qui se cassent la gueule si les fichiers ne sont pas placés ou il faut (et c'est pas des endroits standards). Bien sûr, aucun installateur ou paquet standard.
Il m'a récemment fallu 2 jours pour parvenir à compiler deux programmes, qui ne pèsent pourtant même pas 8200 lignes de code (j'en ai profité pour foutre tout ce bazard dans des dépôt git, au lieu de cp.old, utiliser les git submodules et faire des CMakeLists.txt pour pouvoir tout compiler sans dépendre de la plate-forme sur laquelle on est... mais ce n'est pas ce qui m'a pris le plus de temps!).
Le Monsieur en question, il bosse pour qui, il fait quoi, exactement? Parce que les SSII comme la mienne, je doute qu'il n'y en ait qu'une seule. D'ailleurs, quand j'apprenais, il y à 10 ans, le reverse engineering, les tutos ne portaient jamais sur l'exploitation des failles de logiciels libre, mais systématiquement sur du code fermé.
Soyons sérieux un instant: il n'y à sûrement aucune différence de propreté prouvable entre les codes fermés et les codes libres, et ce n'est pas parce que quelqu'un est payé qu'il fera du bon boulot.
Maintenant, s'il dit que les binaires fermés sont plus simples à installer que les binaires libres, ok, alors parlons des pilotes de périphérique sous windows. Ah, non, pardon, le monsieur compare la compilation des sources d'un projet libre avec l'installation d'un projet fermé... Pas trop facile, de comparé des torchons et des navets, pour dire que le navet est le plus digeste?
PS: ça tombe bien, j'avais justement envie de me défouler. Merci pour le troll :)