Seguridad de la base de datos de Firebird 2.5.2

[Kiranov]

Buenos dias,

Como soy nuevo en este foro, pues me presento. Mi nombre es Kiranov (Alberto) y soy del estado mexicano de Chihuahua. Empeze en el año de 1996 con Turbo Pascal y Foxpro, aunque me incline mas por el lado de Visual Foxpro durante muchos años. Fue hasta el año pasado cuando decidi retomar el lenguaje pascal de nuevo. Eh estado experimentando con Delphi y con Lazarus, probando la base de datos de firebird. Conoci este sitio pero nunca me habia decidido a publicar o a preguntar nada ya que hago uso de la busqueda primero para ver si alguien no ha preguntando mis dudas primero y habia fungido como usuario pasivo.

Bien, ya despues de esta breve presentacion hablare hacerca de lo que propuse en el titulo. Como es bien sabido, la seguridad de la base de datos de firebird no es muy buena que digamos al igual que la base de datos de foxpro. En muchos desarrollos que hice en foxpro usaba un procedimiento para darle un poco de seguridad a la base de datos y hacer un poco mas dificil (no puedo decir que impedir) el acceso de un usuario a las tablas.

Mi duda es si existe alguna forma de en un evento de la base de datos, hacer que este reciba los parametros de autenticacion y los compare con informacion de alguna tabla y dependiendo el caso permita o no acceso a la base de datos.
Este segmento de codigo es un procedimiento en el Archivo DBC de foxpro, donde hacia la validacion. Lo intento llevar y mejorar en FB.
PROCEDURE dbc_OpenData(cDatabaseName, lExclusive, lNoupdate, lValidate) *Immediately after DBC is opened. LOCAL lcPass lcPass = "PASSword" && Esta es la contraseña IF VARTYPE(gc_P_A_S_S) # "C" OR gc_P_A_S_S # lcPass PUBLIC gc_P_A_S_S gc_P_A_S_S = INPUTBOX("Ingrese contraseña para la base de datos: " ; + UPPER(JUSTFNAME(cDatabaseName)), "Aviso", "") ENDIF RETURN gc_P_A_S_S == lcPass ENDPROCGracias y por mi cuenta seguire investigando, cualquier cosa les comentare por aqui.

Atte,
Kiranov

[[Delphius]]

Empezado por Kiranov

Como es bien sabido, la seguridad de la base de datos de firebird no es muy buena que digamos al igual que la base de datos de foxpro

Si la seguridad de la base de datos fuera tan pésima que la comparas con el anticuado Foxpro entonces ¿Cómo me explicas que un hospital de alta complejidad haya decidido emplear Firebird en lugar de Oracle? ¿Cómo me explicas que el gobierno de Brasil deposite tanto su confianza en Firebird? Por mencionar sólo dos ejemplos.

Te invito a leer el paper Firebird File and Metadata Security que puedes encontrar en el sitio de documentación de Firebird y después vienes ¿OK?

Saludos,

[ecfisa]

Hola Kiranov, bienvenido a Club Delphi.

Creo que hay varios puntos que desconoces sobre la seguridad de Firebird, te recomiendo la lectura de este artículo: Firebird Administración y seguridad.

Saludos.

[[Al González]]

Hola Alberto, tocayo y paisano. Que gusto ver por aquí a otros programadores de mi tierra.

Primero que nada, siéntete bienvenido de participar cada vez que gustes. Recuerda que la fortaleza de un foro está en la participación constante de sus integrantes, y que cada buena pregunta hecha vale tanto como cada buena respuesta.

Te recomiendo sobremanera consultar el documento que te enlazó el compañero ecfisa. En tu caso es recomendable revisar los temas de permisos, roles y la instrucción Grant de Firebird. Encontrarás lo bien que puede manejarse la seguridad con este estupendo motor de bases de datos.

Un saludo y, ya sabes, ante cualquier duda el foro está para ayudar.

[Cañones]

Empezado por Kiranov

Buenos dias,
Mi duda es si existe alguna forma de en un evento de la base de datos, hacer que este reciba los parametros de autenticacion y los compare con informacion de alguna tabla y dependiendo el caso permita o no acceso a la base de datos.
Atte,
Kiranov

Bienvenido, no soy experto en seguridad pero no creo que este sea el procedimiento correcto. Yo defino los usuarios del servidor, le asigno el rol de la DB y listo el pollo.
Saludos.

[Kiranov]

Gracias por sus rapidisimas respuestas y creanme que en verdad lamento haber lastimado algunos sentimientos dado a falta de alguna coma o acento, por este detalle pido mil disculpas. Yo mismo soy fan de Firebird porque conozco las capacidades de esa base de datos. Si embargo, según tengo entendido la seguridad de firebird se basa principalmente en la seguridad del entorno, por ejemplo:

• servidor dedicado donde solo el(los) administrador(es) tengan acceso
• manejar aliases en vez del nombre real de la tabla
• cambiar el puerto por default y no dejarle el 3050
• cambiar el password al SYSDBA y no dejárselo en masterkey
• tener un buen firewall
• definir muy bien el sistema de usuarios y roles
• usar una buena distro de linux en nuestro servidor... etc.

Es lógico que todo esto no es comparable con el sistema que usa VFP ya que este es un sistema Cliente-Servidor y VFP es un sistema compartido (basado en la seguridad del windows y usando shares de la red).


Todo esto es una maravilla, sin embargo, que impediria que un usuario que tiene acceso físico al servidor saque una copia de la base de datos, la copie a otro equipo que tenga firebird y realice una conexion a la base de datos teniendo acceso a la estructura de la base de datos y peor aun, a los datos de los mismo clientes? yo he realizado esta prueba.



Gracias a todos y espero sus comentarios.
@Delphius: Gracias por el consejo de investigar, creeme que el ultimo recurso que utilizo es postear, primero es investigar. segui tu consejo de primero leer y luego volver. Gracias.
@Ecfisa: Gracias por el articulo de Tejero y Espinoza, muy entendible y va al grano. Saludos.
@Al Gonzalez: Gracias por la calurosa bienvenida paisano. Vamos a echarle ganas!


Gracias a todos!
P.D."No me coman todavía, recuerden que soy nuevecito aun!" - Frase celebre de Sid, el peresozo de la era de hielo...

[ecfisa]

Empezado por Kiranov

Todo esto es una maravilla, sin embargo, que impediria que un usuario que tiene acceso físico al servidor saque una copia de la base de datos, la copie a otro equipo que tenga firebird y realice una conexion a la base de datos teniendo acceso a la estructura de la base de datos y peor aun, a los datos de los mismo clientes? yo he realizado esta prueba.

Hola Kiranov.

Estoy de acuerdo con lo que comentas arriba.

Pero, eso no es una falla de seguridad de la base de datos, sino del diseño de la seguridad del sistema:

• Incorrecta situación física del servidor.
• Falta de control sobre el personal que puede acceder al servidor.
• Sistema operativo instalado.
• ...

De estos los más básicos son los dos primeros. Ya que si cualquiera puede entrar y salir sin control a la sala donde reside el equipo servidor, nada impide a un empleado desairado tirarle una jarra de agua dentro, prenderle fuego, etc. .

Y si encima de esto cualquiera puede obtener los privilegios del S.O. para realizar una copia de la base de datos, está claro donde está la falla de seguridad.

Saludos.

[[Delphius]]

Empezado por Kiranov

sin embargo, que impediria que un usuario que tiene acceso físico al servidor saque una copia de la base de datos, la copie a otro equipo que tenga firebird y realice una conexion a la base de datos teniendo acceso a la estructura de la base de datos y peor aun, a los datos de los mismo clientes? yo he realizado esta prueba.

Precisamente si sucede eso es que la seguridad se ha planteado de forma incorrecta Y por ello sugerí la lectura del paper. En dicho documento se aborda algunas cuestiones relacionadas con la seguridad de las base de datos y aclara bien a como es que, y porqué, se ha diseñado Firebird de esa manera. Y da consejos de como encarar el tema.
Como ha dicho ecfisa, si alguien puede meter mano al server algo anda mal y no tiene la culpa de eso ni Firebird ni el SO del servidor... la culpa ya es de quien lo administra y controla.

Para la versión 3.0 se espera que se incorpore, además, la seguridad a nivel de base de datos.

Saludos,

[Combat-F2D]

considero, es mi parecer, que el poder acceder fisicamente a un FDB ó GDB en un momento dado puede tener más ventajas que inconvenientes si por algun motivo el sysdba desaparece o boicotea el sistema; lo digo por experiencia.

resulta más fácil proteger la maquina que el fichero, o eso creo

[belpab]

Empezado por Delphius

Precisamente si sucede eso es que la seguridad se ha planteado de forma incorrecta Y por ello sugerí la lectura del paper. En dicho documento se aborda algunas cuestiones relacionadas con la seguridad de las base de datos y aclara bien a como es que, y porqué, se ha diseñado Firebird de esa manera. Y da consejos de como encarar el tema.
Como ha dicho ecfisa, si alguien puede meter mano al server algo anda mal y no tiene la culpa de eso ni Firebird ni el SO del servidor... la culpa ya es de quien lo administra y controla.

Para la versión 3.0 se espera que se incorpore, además, la seguridad a nivel de base de datos.

Saludos,

Estoy de acuerdo con este comentario, pero también entiendo a nuestro compañero cuando dice que no es seguro, puesto que si por cualquier circunstancia la base de datos sale de tu servidor, los datos están total y absolutamente abiertos y a merced de lo que quieran hacer con ellos y eso hasta cierto punto vulnera la ley de protección de datos. Ademas no solo los datos, también los procedimientos, y tablas que en cierto modo considero que son propiedad intelectual del programador . Al menos en mi opinión.

Pero centrándonos en el tema de la seguridad a nivel de base de datos. ¿ Esta confirmado el tema de que en la versión 3.0 se va a incluir este nivel de seguridad? por que pienso que seria el paso enorme para eliminar el miedo que nos hace a muchos el cuestionarnos usar Firebird. ¿Tenéis alguna información al respecto? por que he estado buscando información de este tema y no he encontrado nada que me diga que así va a ser.

Aprovecho la ocasión para preguntar ( si no es mucho pedir ) si alguien sabe de algún administrador de base de datos tipo IBexpert que me permita trabajar con firebird 3.0.

Gracias de antemano a todos y un cordial saludo.

[[Delphius]]

Empezado por belpab

Estoy de acuerdo con este comentario, pero también entiendo a nuestro compañero cuando dice que no es seguro, puesto que si por cualquier circunstancia la base de datos sale de tu servidor, los datos están total y absolutamente abiertos y a merced de lo que quieran hacer con ellos

Primero está la seguridad física, luego la lógica.
Repito: si alguien, cualquiera no autorizado, puede meter sus manos al servidor es que sus políticas y medidas de seguridad no están bien planteadas. Y no interesa si hay medidas en lo lógico.
Se me hace que falta un poco de cátedra de auditoría por algunos lares. En los estándares justamente se define y se centran muchísimo más en la seguridad física; después de todo en lo lógico queda abierto a que se defina de forma secundaria y en base las posibilidades y las políticas de la empresa/organización y son medidas complementarias a las primeras.

Empezado por belpab

y eso hasta cierto punto vulnera la ley de protección de datos.

Cada país tiene su propia ley de protección de datos. Por otro lado, cuando se trata de datos sensibles justamente hay mecanismos que pueden aportar al tema, y estos son excluyentes a lo que son base de datos. Ese no es el trabajo de un motor. Es decir, que implementar esas medidas de seguridad son ya responsabilidad de quien elabora y lleva a cabo el proyecto. Repito: un motor de base de datos no tiene porqué hacerlo ni implementar otras medidas de seguridad a nivel de datos dentro de sus bases de datos por defecto. Si tu deseas resguardar los datos de forma lógica, emplea y complementa con otras herramientas y tecnologías que están pensadas para eso.
Por ejemplo, si necesitas almacenar información cifrada entonces hazlo vía sistema, no le des más trabajo al motor. Al motor no le interesa que sea cifrada o no el contenido, el regresa lo que le mandes. Tu aplicación es la responsable de coordinar y garantizar de llevar a cabo las medidas de seguridad complementarias.
Ya el motor tiene su cuota de medida de seguridad para garantizar que los datos se mantengan de forma íntegra y puedan recuperarse ante ciertos niveles, y tolerable, de fallos.

Empezado por belpab

Ademas no solo los datos, también los procedimientos, y tablas que en cierto modo considero que son propiedad intelectual del programador . Al menos en mi opinión.

Una cosa son los datos, cuya propiedad intelectual pertenecen al que los genera (léase Empresa, etc) y otra la propiedad intelectual de quien diseña la base de datos. Son dos tipos diferentes de derechos y propiedad intelectual y para cada quien hay cierta regulación; que de nuevo... depende de cada país.
No por leer la metadata de la estructura de la base de datos y los procedimientos implementados se está en una violación de la propiedad del desarrollador/empresa desarrolladora. Es más hasta cierto punto esta información debiera ser pública puesto que al ser los datos de la empresa tiene parte de los derechos de saber cómo es que están estructurados y como procesarlos si en el futuro necesita migrar a otros entornos y/o infraestructura. Negarles esta posibilidad es atar a una empresa a un modelo muy cerrado y totalmente dependiente de quien desarrolla el sistema.

Nuevamente invito a leer el paper

Empezado por belpab

Pero centrándonos en el tema de la seguridad a nivel de base de datos. ¿ Esta confirmado el tema de que en la versión 3.0 se va a incluir este nivel de seguridad? por que pienso que seria el paso enorme para eliminar el miedo que nos hace a muchos el cuestionarnos usar Firebird. ¿Tenéis alguna información al respecto? por que he estado buscando información de este tema y no he encontrado nada que me diga que así va a ser.

Está FirebirdNews, y está su Roadmap. Fíjate que en su ruta, figura el ítem Security enhancements. Éste hace referencia a esas mejoras. Y ya antes habían dado más detalles a través de sus sitios de noticia, y también desde MindTheBird.

Empezado por belpab

Aprovecho la ocasión para preguntar ( si no es mucho pedir ) si alguien sabe de algún administrador de base de datos tipo IBexpert que me permita trabajar con firebird 3.0.

Gracias de antemano a todos y un cordial saludo.

Si aún no sale la versión 3.0 ¿como esperas que exista, hoy en día, un administrador que lo soporte? La pregunta carece de sentido alguno ¿no crees? Cuando salga la FB3 allí se verá, y muy seguramente casi en forma paralela las nuevas versiones de IBExpert con soporte para ésta.
También está FlameRobin, que es la contraparte Open Source de IBExpert... y que incluso es multiplataforma. Seguramente también se ha de esperar que salgan nuevas liberaciones de FlameRobin para la versión 3 de Firebird.

Saludos,

[belpab]

Gracias por la informacion Delphius. Respecto a lo de la seguridad simplemente discrepamos y tenemos diferentes puntos de vista eso es todo. Pero lo bueno Y enriquecedor es que haya diferentes opiniones y formas de ver la vida. Sigo pensando que un control de usuarios a nivel de base de datos es mucho mas util y necesario. Este nivel de seguridad no implica que el cliente tenga o no acceso a sus datos pero le da un nivel extra de seguridad. Insisto, es mi forma de pensar y entiendo perfectamente la tuya, incluso la comparto, yo tambien considero que la seguridad a nivel de hardware en primera instancia y de S.O. En segunda instancia son imprescindibles, pero considero tambien necesario un tercer nivel de seguridad a nivel de Base de datos. De todos mosdos, si como parece, con la version 3 de firebird esto va incluido todos quedamos contentos y me imagino que sera porque lo han visto como una buena mejora

Lo de el administrador de la base de datos reconozco que ha sido una ida de olla perdon a todos por mi ida de olla.

Agradezco tu tiempo empleado en responderme y la prontitud con la que lo has hecho, tal y como ocurre siempre desde este magnifico portal, que se ha convertido en una herramienta casi imprescindible para los que andamos en el mundo de Delphi. Un abrazo a todos.

[[Chris]]

Empezado por Delphius

Si la seguridad de la base de datos fuera tan pésima que la comparas con el anticuado Foxpro entonces ¿Cómo me explicas que un hospital de alta complejidad haya decidido emplear Firebird en lugar de Oracle? ¿Cómo me explicas que el gobierno de Brasil deposite tanto su confianza en Firebird? Por mencionar sólo dos ejemplos.

Te invito a leer el paper Firebird File and Metadata Security que puedes encontrar en el sitio de documentación de Firebird y después vienes ¿OK?

Saludos,

A esto le llamo una antipática y odiosa bienvenida.

En pasadas ocaciones que he mencionado mejoras que quería ver en Firebird con respecto a la seguridad fuí criticado. Acá en este Club hay grandiosas personas. Pero también aveces te encuentras con opiniones molestas y ruidosas. Gente que se cierra en sus ideas, que por haberse aprendido todo el manual deja de ver las posibilidades fuera de ese manual.

@Kiranov muchas de tus incetidumbres de seguridad también las padecen otros motores de DB. Para solventarlas, a cómo te han dicho, lo importante es la seguridad fisica y virtual del servidor en dónde esté la DB.

Firebird tiene otras fallas o faltas de seguridad aún no mencionadas:
* En autenticación nativa de Firebird, el servidor solo utiliza los primeros 8 carácteres de la contraseña. Inclusive la contraseña predeterminada masterkey no es evaluada complemente. Esto no es una característica, es un bug que viene desde Interbase (eso creo). El equipo de Firebird no lo ha reparado por temor a romper la retro compatibilidad.

* Firebird no ofrece un protocolo de transmisión de datos por TLS. Los datos viajan en texto plano y la autenticación se hace por medio de una encriptación básica que deja mucho que desear si la comparas con TLS.

Muchos dicen: "Esperen a FB 3.0 y verán!" pero hasta donde recuerdo esa versión está planeada desde hace 5 años más o menos. No lo digo en mal plan. El equipo de desarrollo de Firebird es pequeño y seguramente tendrán muchas cosas por hacer. Lo que quiero decir es que no te creas el cuento de que Firebird 3.0 está por salir y esa versión resolverá tus incertidumbres de seguridad.

Saludos!

[Casimiro Notevi]

Empezado por Chris

Muchos dicen: "Esperen a FB 3.0 y verán!" pero hasta donde recuerdo esa versión está planeada desde hace 5 años más o menos.

Hombre, hace 5 años (si las cuentas no me fallan) estábamos con la versión 1.5 y después han salido la 2.0, 2.1 y 2.5
Ahora mismo la 3 es la siguiente que toca, no hay otra que se intercale, por lo que puede que este mismo año esté. Incluso ahora mismo puedes descargar la versión de prueba para testearla.

Una duda: ¿qué base de datos usa TLS sin "ayuda externa?

[[Al González]]

Empezado por Chris

Acá en este Club hay grandiosas personas. Pero también aveces te encuentras con opiniones molestas y ruidosas. Gente que se cierra en sus ideas, que por haberse aprendido todo el manual deja de ver las posibilidades fuera de ese manual.

Comparto el comentario que le haces al buen Delphius, Chris. Pues sí, podría decirse que ese es el lado "malo" de una comunidad altamente incluyente, participativa, tolerante y libre de expresarse. Lo peor es cuando por unos cuantos buscapleitos, mucha gente de gran valía opta por alejarse.

No pienses que me refiero a ti, Delphius, aunque harías bien en ser más amable con los compañeros.

Creo que debemos seguirle apostando a la madurez y al crecimiento ético de cada integrante del foro. Sólo así mejora cualquier grupo social.

Un cordial saludo.

Al.

[[Chris]]

Empezado por Casimiro Notevi

Una duda: ¿qué base de datos usa TLS sin "ayuda externa?

Talvez me equivoqué en esa. Me parece que fue por el 2008 cuando se anunció por primera vez el roadmap para FB 3.0.

Un ejemplo de DBs que usan TLS/SSL sin intermediarios son PostgreSQL y MySQL

Saludos!

[Casimiro Notevi]

Está bien, aunque supongo que tampoco es un problema para quien quiera más seguridad, puede usar zebedee, por ejemplo.

Personalmente me gusta que la BD esté lo más libre de carga posible, y el cifrar/descifrar información para enviarla por red no me parece que sea algo que deba hacer la BD, pero bueno, que tampoco lo veo mal, aunque no creo que lo usara aunque dispusiera de esa opción.

El caso es que firebird no lo usa para transmisión de datos, aunque para "autenticarse" sí que usa ssl/tls, al menos eso es lo que entiendo de esto:

Firebird has inherited a low security environment from Interbase. There is no means to encrypt connections and client authentication uses weak password based authentication. SSL/TLS could be used to improve both areas. Four levels of use are proposed, controlled through the configuration file and/or on a per user basis:

1. No SSL/TLS i.e. the current situation

2. SSL/TLS used to authenticate the server to the client and encrypt the subsequent connection.This is the typical https mode of use and makes use of X.509 certificate based authentication. A PKI is required. However, this does not have to be a paid for service and in most cases a local PKI based on OpenSSL should suffice.

3. SSL/TLS is additionally used to authenticate a client to the server. The client certificate must be signed by a Certification Authority recognised by the client.

4. In addition to authenticating the client, the common name component of the client certificate is used as the "username" and no password is required. This provides strong certificate based authentication of the client.

Most, if not all, of the above functionality already exists in external libraries and is used in ways, similar to the above proposal, by projects such as Sendmail, Dovecot, MySQL, Apache, Racoon, etc.

[Combat-F2D]

la mejor proteccion no es utilizar armamento pesado... sino escorderse y pasar desapercibido... me explico: poca proteccion necesito si no me das localizado
claro que es una opinión mia

[pacopenin]

El acceso a la base de datos física es un gran problema para Firebird pero también para otras muchas. A mi me han llegado solicitudes de traspasos de datos desde SQLServer y MySQL por ejemplo y fueron llevados a cabo. Y no hace falta saber la contraseña de administración, basta una copia de la carpeta de datos. Claro que era con el consentimiento expreso del cliente. El primer paso básico es administrar ese acceso físico al archivo/s de datos. He visto aplicaciones que ubicaban la base de datos en carpetas compartidas del servidor.

[[Delphius]]

Empezado por Chris

A esto le llamo una antipática y odiosa bienvenida.

A mi me late que desde cierta discusión en que te la pensaste que con tus puntos finales se acabaría el hilo y te daríamos la razón aún cuando los demás teníamos sobradas evidencias de que por tu propuesta no estaba la solución te la tienes conmigo... va... de hecho, desde que me aparecí por el club tu te la tienes conmigo.

Asi que si hay odiosos aquí, los hay y hubo, antes de que yo llegara.

Empezado por Al González

Comparto el comentario que le haces al buen Delphius, Chris. Pues sí, podría decirse que ese es el lado "malo" de una comunidad altamente incluyente, participativa, tolerante y libre de expresarse. Lo peor es cuando por unos cuantos buscapleitos, mucha gente de gran valía opta por alejarse.

Te voy avisando y poniendo al día que Cris es justamente algunos de los buscapleitos que ha dicho que nos vayamos al carajo quienes ya sabes quien está en el otro lado.

Empezado por Al González

No pienses que me refiero a ti, Delphius, aunque harías bien en ser más amable con los compañeros.

Yo he sido muy amable, le sugerí que leyera y se informase mejor y revise sus palabras. Fíjate en las expresiones de quien inició el hilo:

Como es bien sabido, la seguridad de la base de datos de firebird no es muy buena que digamos

Aquí está expresando con alta superioridad, y exceso de seguridad algo que no es totalmente cierto.

Pero lo chistoso es que previamente se autodenomina alguien no debidamente preparado para aventar tales palabras ya que recientemente apenas la ha estado probando:

Fue hasta el año pasado cuando decidi retomar el lenguaje pascal de nuevo. Eh estado experimentando con Delphi y con Lazarus, probando la base de datos de firebird.

Una total incongruencia. No puede asegurar y aventar un "Como es de público conocimiento" si apenas la ha tocado y no se ha documentado como debe.
Una de las primeras cosas que se hace, o mejor dicho, debiera hacerse es leer la documentación.
Yo mismo admito que no me las se todas, pero al menos tomé la decisión de agarrar esa cosa que descartamos la mayoría: el manual. Y hago un intento para aprender alguito más. Tal es así que como dije antes, hasta incluso me he tomado la "molestia" de traducir buena parte del material, aunque para la versión 1.5 y un tanto quedada en el tiempo, y me he contactado con Ernesto Cullen, una de las personas encargadas del equipo de traducción al español. Hemos hecho el intento de darle movilidad al tema pero por falta de tiempos y cierta desprolijidad mía en la presentación del documento no se ha avanzado. Me ha sugerido que me anime a a subirme a la lista, y trabajar en la forma en como trabajan ellos para llevar el registro de versiones y documentación; tales herramientas me han resultado un obstáculo, me cuesta entenderlas. Ya veré nuevamente más adelante, ya con 2.5/3 desde tecnología Open Source.

Empezado por Al González

Creo que debemos seguirle apostando a la madurez y al crecimiento ético de cada integrante del foro. Sólo así mejora cualquier grupo social.

Un cordial saludo.

Al.

Yo también apostaría a la madurez y la ética, pero algunos me han demostrado y como dije, ya estoy cansado, de que por ese grupito de inmaduros desde hace un buen tiempo, que CD no es lo que se piensa. Y no me voy a cansar de asegurarlo amigo: CD no es un costal de rosas. Mostraré madurez y ética en lo más posible; y así ha sido de mi parte. Pero el cansancio hacia ciertas personas se me acabó y decidí pagarles y devolverles con la misma moneda se nos ha pagado a muchos.
Yo puedo ser muy paciente, y bastante lo he sido.
Por otro lado si encuentro incongruencias en los dichos, he de señalarlos. De otro modo se seguirá propagando ciertas cosas, al punto en que el rumor, los mitos y las malas prensas que se le hacen a Firebird, y hasta convengamos que con el mismísimo Delphi. Si no busquen en el foro, ¿cuántas veces se ha terminando debatiendo el mito de que Firebird no es seguro y que es un juguete? Ya es cansador seguirle con las vueltas ¿no creen?

Me lo digo a mi, y los digos a todos: RTFMS... o para decirlo más fino: Read The Fucking Manual.

Saludos para algunos,