El 26 de agosto de 2010 08:56, Diego Leonardo Revechini < [email protected]> escribió:
> El 26/08/2010 04:42, Alejandro Vargas escribió: > > El día 26 de agosto de 2010 01:38, Diego Leonardo Revechini >> <[email protected]> escribió: >> >>> Si bien muchos ojos pueden mejorar lo que nadie ve, la realidad es que >>> muchos mas ojos pueden darse cuenta de >>> por donde atacar primero. >>> >> Es muy cierto lo que decís. Habría que agregar entonces que el banco >> tiene que comportarse correctamente y cuando se descubra un error >> debería corregirlo en cosa de minutos u horas como en el software >> libre, en lugar de buscar encarcelar al que descubrió el error. >> >> Casi siempre que se publica un error en algún software, lo hace gente >> que quiere que se corrija y si no se hace es porque las empresas se >> empecinan en cosiderar la reparación de errores de software como un >> gasto y no como una inversión. >> >> Desgraciadamente para los que manejan la batuta de muchas empresas, la > informatica > sigue siendo un gasto... > > Un banco es una entidad sensible. Si bien estoy >>> deacuerdo de que deberian usar >>> software visible, tambien entiendo que abrir de un dia para otro el >>> software >>> de un banco para que todo el mundo >>> lo "vea" es francamente un disparate. >>> >> Bueno, en realidad deberían haber usado desde el principio software >> que estuviera a la vista. Y si no lo hay deberían haberlo desarrollado >> a la vista, creando algún proyecto libre donde paso a paso durante el >> desarrollo la gente haya ido viendo y corrigiendo los errores. >> >> La conclusión que podríamos sacar es una que ya conocemos bien: que es >> un gran error invertir en software cerrado, y ese error se paga >> durante mucho tiempo porque después te quedás enganchado a él y te >> sale mucho más caro solucionarlo. >> >> De nuevo, quienes manejan la batuta, se mandan soberanas macanas que > despues > son insalvables en el tiempo. > > Y me baso en que cualquier software, >>> posee bugs, y por tanto es sensible a ser >>> explotado. >>> >> Eso es una falacia muy utilizada para justificar los errores del >> software comercial. Se puede hacer software sin errores. Por ejemplo, >> ahora mismo podría escribirte un programa que suma los parámetros que >> le pasés y lo hace sin un sólo error. Lo que sí es cierto es que al >> aumentar la cantidad de líneas de código, aumenta la probabilidad de >> errores. Pero una probabilidad no es una certeza. Y por otro lado esa >> probabilidad disminuye muchísimo cuando el desarrollo es abierto como >> en el software libre porque los errores se encuentran y corrigen >> constantemente. >> >> >> Mira, el ejemplo mas claro que puedo darte es Firefox y Microsoft > Internet Explorer. > Ambos nacieron del mismo proyecto. La concepcion es la misma, y los > problemas > (bugs) a la larga en muchos casos los mismos. Mientras IE se la pasa > arreglando bugs > Firefox ha, gracias a una mejor inteligencia colectiva, mejorado aspectos y > no caido > en los mismos bugs que su "hermano". Sin embargo, sigue teniendo (no > tantos) como > IE y seguira teniendo porque habra alguno que tarde o temprano se de cuenta > de > como hacer para reventar algun aspecto que no fue tenido en cuenta. Vos me > diste el > ejemplo de que podes hacerme un programa sin errores. Pero para hacerlo > deberas > PENSAR en todas las posibilidades que el usuario PODRIA no respetar. En tu > mismo > ejemplo, me decis de sumar dos parametros ¿de que manera? ¿numericos? > ¿concatenados? > Si son numericos, entonces deberas limitar al usuario que no te ponga > letras y simbolos > (siempre hay algun guacho), porque el programa fallara. Tambien limitar la > cantidad a sumar > no valla a ser que puedas colapsar la memoria del programa traspasando al > SO (siempre > hay algun otro guacho), y entonces el programa crece y crece, y uno nunca > esta cubierto > porque nunca piensa las infinitas posibilidades que hay para reventar el > programa. > Y el tener el codigo fuente, a veces inclusive te da la posibilidad de > "crear" nuevos metodos... > En cuanto a la velocidad de resolucion de errores, si, quizas como decis, > lo abierto es > mas rapido de arreglar, y mas rapido de encontrar errores antes que > sucedan. En lo > cerrado es a prueba y error hasta que salta el problema, es como ir > caminando a ciegas y > de golpe te encontras con un pozo. De la otra manera, es la misma calle > pero encontras > los pozos y te evitas el porrazo. > > E inclusive las maneras mas locas salen de cosas de lo mas >>> elementales (recuerdo, no hace mucho como >>> usando campos de un formulario web, inyectaban codigo SQL dentro de bases >>> de >>> datos) y para eso no es necesario >>> que se vea el codigo >>> >> Es un error muy común. Hace unos meses en un software vergonzosamente >> caro que compró mi empresa, los vendedores decían que no se podían >> usar apóstrofes en los nombres. Yo me di cuenta instantáneamente de >> cuál era el error: faltaba escapar o limpiar las secuencias SQL, así >> que les escribí un mail avisándoles, diplomáticamente, que era un >> error grave y peligroso (permite justamente la inyección de SQL) y que >> deberían solucionarlo. Y adiviná qué? >> >> Si hubiera sido software libre me lo habrían agradecido y habrían >> solucionado el problema. Pero esta gente se limitó a contestarme >> descaradamente que no era un error suyo sino de Oracle. Ahí sí les >> contesté como se merecían, explicándoles como si fueran unos inútiles >> que no supieran lo que es una inyección de SQL (porque obviamente no >> lo sabían), cuáles son sus causas y cuáles los peligros, y que no se >> trata para nada de un problema de la base de datos sino del programa >> que la usa. >> >> Obviamente el problema sigue ahí, porque si querés que te arreglen un >> problema en un programa carísimo, también te sale carísimo. >> Obviamente, por caro que sea el sistema no venía con el código fuente, >> así que no puedo hacer nada para arreglarlo. >> >> Por si hay alguien que no tenga caro el peligro de una inyección de >> SQL en un programa, acá tienen: http://xkcd.com/327/ >> >> >> Cierto, muy cierto. Yo tengo experiencias parecidas que van desde el > cifrado (medio > insulso, pero cifrado al fin) de tablas de datos, hasta el "flaco, te pago > para que > desarrolles tu producto y utilices un motor SQL neutro" y la respuesta es > "no se puede" > y yo estoy SEGURISIMO que estos cabezas usan SQL basico al estilo M$ porque > tengo un servidor andando y no hay un fucking tigger ni nada por el estilo. > Pero son > programadores de hace 40 años que se casaron con un lenguaje y que de pedo > usan SQL, asi que imaginate... > > :). Imaginate un hacker con algo de idea, con semejante >>> informacion. En 30 segundos fundio al >>> banco. >>> >> Tremendo... >> >> Si verdad :) > > Pero más miedo me da un sistema que tiene esos agujeros y nadie pueda >> examinarlo y mucho menos corregirlo. >> >> Uuuu, el concepto de "che, yo puedo hacerlo mejor, sos un SQT" lo tengo > incorporado > hace años. Donde valla veo cosas que estan mal hechas y que con tan solo > algo de > cesudes, se puede hacer mucho mejor. Desgraciadamente soy un "genio" > desperdiciado :) > y hablo de cualquier cosa, no simplemente de software. > > Saludos Alejandro. > > > -- > Diego Leonardo Revechini > Soporte Tecnico Independiente > blog: www.olafitoweb.com.ar > > > Bueno, efectivamente se bifurca el debate, y creo que es necesario que se discuta en esta lista el tipo de informacion y algunas posturas basicas con respecto al software. NO digo que definamos un discurso contra el imperio, satanas y la bruja de blancanieves, o que pidamos que se acaben todas las guerras para volver a contestar un mail... Pero estaria interesante que se especifique si la lista es de Soft libre o de soft en General. SI es Soft libre, entonces no tenemos que dar respuestas ni tratar ideas que vayan contra el software libre, como en este caso particular donde se pide consejo para enjalular codigo y no permitir que las personas que lo crearon tengan acceso a el (encima esto es ilegal.... la ley de propiedad intelectual es muy clara al respecto, el dueño de la propiedad es el creador. Puede que el creador no tenga derechos de uso comercial por haberlos "cedido", pero sigue siendo el dueño. PRivarlo del derecho de llevarse el codigo a su casa es delito estimados....) Nada en contra de que la lista trate sobre soft en general, pero en ese caso que se renombre a SugMen, (software user group) y dejen la denominacion LUG para que otro grupo s forme y maneje temas solo de soft libre. Sino es como ser sede de greenpeace y aconsejar a una empresa minera sobre cual es la mejor manera de armar un proyecto de megamineria, aprovechadno lo que sabemos del tema. Es incongruente por dode se lo mire.
