Prender bluetooth

2010-01-18 Por tema Marcos Delgado 
Hola lis...@s.
Estaba usando blueman para conectar mi laptop con mi celular, vía
bluetooth. Todo muy bien hasta que utilicé la opción de apagar el
dispositivo para ahorrar energía.
A partir de ese momento no he podido prender otra vez el bluetooth. En
algunos casos puedo ver con hciconfig que el dispositivo esta apagado
(down) pero con la opción up no se prende. En este momento ni siquiera
aparece, ni se ve con lsusb.
He revisado con google y no he podido reiniciar el dispositivo. Uso
debian SID. Sí alguien me pudiera ayudar, lo agradecería.

Saludos.
Marcos Delgado.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Uso de "backports"

2010-01-18 Por tema Marcos Delgado 
El día 17 de enero de 2010 16:24, Camaleón  escribió:

> En resumen: ¿qué sería lo recomendable para quienes tenemos Lenny?
> ¿esperar a que esté disponible en backports e instalarlo desde ahí,
> instalar directamente desde la página de Mozilla... o alguna otra
> cosa? :-?
>
> Saludos,
>
> --
> Camaleón
>

Mientras, usa Firefox de Mozilla directamente, hasta donde me quede lo
puedes usar sin instalarlo, es decir lo descomprimes en un directorio
y ya. Pero hace mucho que lo use.

Suerte.
Marcos Delgado.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

%Nuevas Reformas a la Ley de ADQUISICIONES

2010-01-18 Por tema Lic. Giovanna Garcia 


Analisis practico y efectivo de las Nuevas... 
 
 
REFORMAS, ADICIONES Y DEROGACIONES a la Ley de Adquisiciones, Arrendamientos y 
Servicios del Sector Publico
 
 
 
Monterrey, N.L.  25 Enero 2010/  M?xico, D.F.  27 Enero 2010/   
Guadalajara, Jal.  29 Enero 2010
 


 
Este oportuno seminario le dara a conocer de manera dinamica y objetiva, los 
efectos que tienen en la Administracion Publica Federal y en los particulares, 
las ULTIMAS REFORMAS, ADICIONES Y DEROGACIONES a diversas disposiciones de la 
Ley de Adquisiciones, Arrendamientos y Servicios del Sector Publico, publicadas 
el pasado 28 de mayo del presente a?o en el Diario Oficial de la Federacion y 
que entraron en vigor a partir del 27 de junio de 2009.
 
 
 
Realice, con la asesoria de un experto en la materia, el analisis practico de 
los puntos criticos de las modificaciones implementadas a esta Ley, como el 
caso del articulo 31 ?Bases de licitacion?, asi como las ofertas subsecuentes 
de descuento y la obligatoriedad de la realizacion de un estudio de mercado 
para ayudar a determinar el precio no aceptable o el precio conveniente.

 
 
 
Logre el manejo optimo de las aplicaciones de la normatividad vigente, 
incluyendo:
 
 
- Que es el sistema electronico de informacion publica gubernamental y como se 
administrara.

 
- Que es la investigacion de mercado y como debe realizarse.

 
- Cuales son los precios que se manejaran con la nueva Ley.

 
- Como seran las nuevas politicas, bases y lineamientos en las dependencias y 
entidades.
 
 

Y mucho mas...
 
 
 

DIRIGIDO a:

Servidores Publicos, Proveedores del Gobierno y toda persona que realice 
contratos con la Administracion Publica Federal y requiera estar actualizado en 
el conocimiento de las oportunidades y amenazas de la correcta aplicacion de la 
Ley de Adquisiciones, Arrendamientos y Servicios del Sector Publico.
 
 
Obtenga mayor informacion llamando al 0133 31 22 45 00 con 10 lineas
 

o respondiendo los siguientes datos:


Empresa / Dependencia:


Nombre:


Puesto:


Tel: (  ) 


Ciudad de Interes:  (   ) Guadalajara (   ) Mexico, D.F. (   ) Monterrey


Seminario: Ley de Adquisiciones, Arrendamientos y Servicios del Sector Publico
 



Reenvie esta valiosa informacion a quien considere puede ser de utilidad, sin 
duda se lo agradecera!
 
 


Se han omitido intencionalmente los acentos para evitar la deformacion del 
texto en algunos equipos
 
 
 
 
 

Si no desea recibir invitaciones en el futuro sobre ningun tema de CLF envie un 
correo con asunto Emglb3.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

E.marketing: difunda sus productos y servicios

2010-01-18 Por tema E.Soluciones 
This is a message in multipart MIME format.  Your mail client should not be 
displaying this. Consider upgrading your mail client to view this message 
correctly.

Re: bonding mas ifenslave RESUELTO

2010-01-18 Por tema Antonio Trujillo Carmona 
El vie, 15-01-2010 a las 23:00 +0100, Antonio Trujillo Carmona escribió:
> Estoy montando un servidor con dos tarjetas de red para virtualización.
> La lógica de los servidores me dice que use ifenslave para tener
> redundancia (seguridad y multipath) en la red, pero para kvm hay que
> poner las tarjetas en modo "bridge", he intentado hacer un "bond0" (con
> las dos tarjetas reales) y unir esta interfaz al br0, pero no se puede.
> ¿Alguna sugerencia? 
> 
Muchas gracias a todos ya esta resuelto, me faltaba definir como
"manual" la interfaz bond0. Es decir levantarla antes en el fichero
interfaces, aunque lo intente primero (ifconfig bond0 up) por ordenes
debí equivocarme en algo.
use la respuesta que me dio Camaleón (fue la primera)




-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bonding mas ifenslave

2010-01-18 Por tema Antonio Trujillo Carmona 
El dom, 17-01-2010 a las 18:37 -0300, deb...@mstaaravin.com.ar escribió:
> 2010/1/17 Antonio Trujillo Carmona :
> > Creo que esta vez te has colao,
> Yo no creo, no tengo dudas, sos un pelotudo
> 
> > no suelo preguntar lo que soy capaz de
> > probar, y mucho menos nada que me pueda dar el manual o los doc del
> > paquete, lo que pasa es que no siempre que buscas algo encuentras la
> > solución, te reto a que me digas en que linea de los doc o man de
> > bridge-util o de ifenslave dice como mezclarlos los dos.
> No lo dice, por la sencilla razón de que son 2 tecnologías de capa 2,
> sabés lo que es eso.?
> Listo, ahora con eso que te acabo de decir sigue sacando conclusiones
> y verás como todo tiene sentido y te darás cuenta porque no se deben
> mezclar br0 con bond0.
Eso ya lo sabia
> 
> > Real mente he buscado y probado varias de las soluciones, pues he
> > montado mas de un "bridge" y de un "bond", (y lo he hecho solito
> > buscandome la vida, sin molestar a nadie por trivialidades), pero al
> > intentar añadir la interfaz bond0  al bridge este me decía que interfaz
> > no valida, cuando pruebe la solución que ha encontrado Camaleón os dire
> > el resultado por si le puede ser útil a alguien, (tampoco se me olvida
> > buscar en el historial de debian antes de preguntar), hasta otra.
> 
> Creo que tu confusión viene de creer que kvm sólo funciona con un bridge (brX)
> o sea, estas poniendo el carro delante del caballo.
> 
Esa si que era una de mis confuciones.

> verás, yo usos virt-install para crear las VMs,, y cuando lo hago el
> parámetro --network acepta algo mas que un simple br0, échale una
> mirada.
> 
> Volviendo al tema bonding, estamos de acuerdo en que queremos usarlo
> porque necesitamos redundancia, más bandwith, etc.
> 
> Pero hay que tener presente que ese concepto es de la placa de red
> hacia afuera, por lo tanto del otro lado debe existir una
> configuración igual.
> 
> Para hacertelo simple a ver si esta analogía sirve.
> 
> Un bridge es para administrar las interfaces desde la/s  placas de red
> hacia dentro del mismo server.
> Un bonding es un concepto similar (en parte) pero desde la/s placas de
> red hacia afuera.
> 
> Se entiende...?
> 
Claro, por eso era lo de usar las dos mezcladas.

> Comprendiendo eso es más fácil tener un panorama de qué es lo que
> necesitamos realmente y te agrego un gráfico.
> http://www.linux-kvm.org/wiki/images/2/24/Bonding_example.png
> 
> Hay mas que explicar pero hasta no entender lo básico no quiero seguir.
> 
> Salutes!!!
Bueno muchas gracias, ya me funciona.




-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: cargar demonio evolution y korganizer en gnome

2010-01-18 Por tema Laura Pamela 
HOla
Camaleón


> Hum... yo lo intentaría primero con el directorio "/usr/share/gnome/
> autostart" que se supone sirve para eso mismo.

Perfecto ya mismo lo intentaré.
NO había visto /usr/share/gnome/autostart:-(


Gracias por tu eficiente respuesta.



-- 
Laura


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Pallets-NEW-LOCP Pallet System

2010-01-18 Por tema Action Engineering, Inc. 
New - Leveling & Off-Contact Pallet - For the ultimate in calibration and 
machine setup - this is one LOC Pallet System that you will be needing. This 
special system incorporates 4 dial indicators mounted on a piece of Honeycomb 
Aluminum. This assembly mounts exactly like a screen into the existing frame 
holder positions. The indicators allow you to very accurately determine exact 
leveling agreement between the screen holders an the pallets. NO SHOP in the 
world should be without this calibration system for their machinery. Works on 
All Manual & Automatics. Turn your press into a perfectly tuned machine. After 
Calibrating your press with the New LOCP-2010 - your registration, setup time, 
and overall printing quality will be greatly enhanced. 
Only available from Action Engineering, Inc. 770/934-1584
www.actionengineering.com
This message was sent by: Action Engineering, Inc., P.O. Box 389, Tucker, GA 
30085

Email Marketing by iContact: http://freetrial.icontact.com

To be removed click here:
http://app.icontact.com/icp/mmail-mprofile.pl?r=27006093&l=18897&s=FA4I&m=349530&c=513589

Forward to a friend: 
http://app.icontact.com/icp/sub/forward?m=349530&s=27006093&c=FA4I&cid=513589

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema Walber Zaldivar Herrera 

consul tores escribió:

El día 18 de enero de 2010 05:26, Walber Zaldivar Herrera
 escribió:

Jajaja, es cierto, el problema es que no puedo YO SOLO confirmar que los mil
y pico de paquetes que utilizo son "seguros". Tengo que delegar un poco de
confianza  :)


Es que no estas solo, habemos muchos ojos, revisando y mejorando el codigo!


Mis motivos podrán ser paranoicos, pero son mis motivos, ciertos o falsos.
No sé si sabes como funcionan las cosas en Cuba, pero todo es posible cuando
se te ocurre hablar de "soberanía e independencia", sobre todo si le vas en
contra a una posición oficialista.

s...@lu2 Walber


Yo, respeto tu opinion como la de cualquier otro, pero tambien
entiendo que, si el gobierno usa windows comprado; pues siempre sera
pirateado debido al bloqueo.

No, no se exactamente como son; pero, por que no se unen todos los
usuarios de Debian mas los usuarios de Linux en general y hacen una
propuesta seria al gobierno? en esta forma, podrian capacitarse y
transferir sus conocimientos a otros, suponiendo que quieren hacerlo!
Para tu informacion, hay varios paises que han cambiado sus SOs a
distribuciones Linux y que mejor que cambiar a Debian auditado por
ustedes mismos! En El Salvador de America, ya se esta dando el cambio.




De eso se trata, pero para hacer una propuesta SERIA, tenemos que poder 
decir:


"Mira, esto es auditable, lo podemos auditar nosotros y lo auditan un 
montón de ojos en el mundo. Aunque se compiló en Remangalatuerca (lugar 
muy lejano) podemos saber que fue lo que pasó cuando lo compilaron"


Para poder decir lo anterior teníamos que enterarnos, como mínimo, de 
donde estaban los logs.


Y cual es el mejor lugar para aprender eso? Las listas Debian.

s...@lu2 Walber

--
>
+-<=<==|

(o_
//\Linux Registered User
V_/_   #480598

Berimbau VCL 
Just another project to provide Delphi components

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema ga 
On Mon, Jan 18, 2010 at 09:49:34AM -0300, Federico Alberto Sayd wrote:
> Felix Perez escribió:
> >El día 17 de enero de 2010 15:49, ga  escribió:
> >>Buenas,
> >>
> >>On Sun, Jan 17, 2010 at 10:29:50AM -0800, Rodrigo Gallardo wrote:
> >>>On Sun, Jan 17, 2010 at 03:25:43PM +0100, ga wrote:
> On Fri, Jan 15, 2010 at 12:49:07PM -0500, Walber Zaldivar Herrera wrote:
> >Hasta que punto es auditable que el .deb que descargamos coincida
> >100% con el código fuente publicado?
> [Un paquete upstream podría añadir un backdor entre versiones]
> 
> Si un desarrollador de Debian ve que hay una versión nueva del programa
> que mantiene, se baja las fuentes, lo empaqueta y lo sube, sin hacer
> nada más, el paquete será un .deb perfectamente válido, pero con una
> bonita puerta trasera.
> >>>(Aquí si me siento personalmente ofendido)
> >>>
> >>>No, la mayoría de los empaquetadores no hacen eso. ¿Alguna vez has
> >>>notado que las nuevas versiones tardan más de 15 minutos en estar
> >>>empaquetadas? ¿Te has preguntado por qué? La respuesta, en muchas
> >>>ocasiones, es precisamente que el mantenedor no va a simplemente
> >>>cambiar el .orig.tar.gz y compilar. Hay que leer el diff, entender (a
> >>>grandes razgos, por lo menos) qué cambió, actualizar los parches
> >>>(algunos de seguridad) que se le aplican al paquete. Sí, hay gente que
> >>>no hace eso, y también es posible que uno meta la pata. Pero, en
> >>>general, ese comentario tuyo es una falta de respeto a la gran mayoría
> >>>de los empaquetadores.
> >>Pues no quería que te sintieras ofendido (ni nadie) por ninguno de mis
> >>comentarios, simplemente es una posibilidad, somos humanos :).
> >>Nos gusta Debian, pero (personalmente) creo que ciertas cosas hay que
> >>analizarlas friamente, sin el corazón en la mano.
> >>
> >>Por cierto, mantengo un pequeño paquete, y no hago eso.
> >>
> >¿No haces "eso" que?
> >¿no revisas?
> >¿no usas diff?
> >¿no entiendes los cambios?
> >Si es así por favor danos el nombre del paquete, para estar alertas
> >cuando haya algún cambio, no vaya a ser cosa que algo "no deseado" se
> >te pase.
> >
> >Saludos.
> >
> >
> Me parece que lo que no se puede lograr de forma preventiva
> (Analizar minuciosamente el código para ver que no se haya
> infiltrado código malicioso) en la comunidad open source se compensa
> con el modelo reactivo de la comunidad.

Totalmente de acuerdo. De hecho, en el manual de seguridad de Debian se
admite honesta y abiertamente lo que comentas (Punto 12.1.8 de la FAQ):
http://www.debian.org/doc/manuals/securing-debian-howto/ch12.en.html

En castellano:
"El equipo de seguridad de Debian no puede analizar posiblemente todos
los paquetes incluidos en Debian en busca de vulnerabilidades potenciales 
porque simplemente, no tienen recursos suficientes para auditar todo el 
código fuente del proyecto. De todas formas Debian se beneficia de la 
auditoría de código hecha por los desarrolladores de los proyectos 
originales y de otros proyectos (...)"

http://svn.debian.org/wsvn/ddp/manuals/trunk/securing-howto/es/faq.sgml

> 
> Un claro ejemplo es el tema del bug SSL que afectó a Debian más o
> menos un año atrás. La difusión fue tal y los esfuerzos de los
> desarrolladores que no se registraron incidentes importantes. Fue
> tanta la publicidad y la cooperación que cualquier atacante
> malicioso dejó de ver el la posible vulnerabilidad como algo
> "explotable".

También pasó algo parecido con el paquete openssh cuando fue "troyanizado".
Las fuentes de Debian no fueron afectadas, y fueron comprobadas por gente
que no eran los mantenedores del paquete (aparte de que se comprobaron
muchas distribuciones:
http://www.cert.org/advisories/CA-2002-24.html

Saludos.

> 
> Viéndolo de ese lado eso es un punto a favor. Además la solución se
> basa en un modelo de muchas personas auditanto el código contra uno
> o dos desarrolladores (a veces sin conocimientos profesionales de
> seguridad) preocupándose por la seguridad de su proyecto o paquete.
> 
> Saludos
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema consul tores 
El día 18 de enero de 2010 05:56, Federico Alberto Sayd
 escribió:

> En realidad el que no dice nada eres tú. Podrías contraargumentar pero no lo
> haces, (o quizás no quieres esforzarte en entender la retórica?) me da para
> poner +1->troll.
>
> Saludos
>>>
>>> Saludos

No Alberto, lo que pretendo decirte es que, solo estas usando frases
hechas; pero sin tu propia opinion, que es la que realmente cuenta; si
ves tu mensaje, te daras cuenta que ahora solo pretendes que me enoje,
pero no dices nada real! Esto se podria llamar una respuesta de nino
malcriado, me refiero a tu mensaje y sin intencion de molestarte.
Tambien podriamos llamarle spam. Asi que mejor la cortamos, gracias.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema consul tores 
El día 18 de enero de 2010 05:26, Walber Zaldivar Herrera
 escribió:
> Jajaja, es cierto, el problema es que no puedo YO SOLO confirmar que los mil
> y pico de paquetes que utilizo son "seguros". Tengo que delegar un poco de
> confianza  :)

Es que no estas solo, habemos muchos ojos, revisando y mejorando el codigo!

> Mis motivos podrán ser paranoicos, pero son mis motivos, ciertos o falsos.
> No sé si sabes como funcionan las cosas en Cuba, pero todo es posible cuando
> se te ocurre hablar de "soberanía e independencia", sobre todo si le vas en
> contra a una posición oficialista.
>
> s...@lu2 Walber

Yo, respeto tu opinion como la de cualquier otro, pero tambien
entiendo que, si el gobierno usa windows comprado; pues siempre sera
pirateado debido al bloqueo.

No, no se exactamente como son; pero, por que no se unen todos los
usuarios de Debian mas los usuarios de Linux en general y hacen una
propuesta seria al gobierno? en esta forma, podrian capacitarse y
transferir sus conocimientos a otros, suponiendo que quieren hacerlo!
Para tu informacion, hay varios paises que han cambiado sus SOs a
distribuciones Linux y que mejor que cambiar a Debian auditado por
ustedes mismos! En El Salvador de America, ya se esta dando el cambio.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema Federico Alberto Sayd 

consul tores escribió:

El día 18 de enero de 2010 04:49, Federico Alberto Sayd
 escribió:
  

Felix Perez escribió:


El día 17 de enero de 2010 15:49, ga  escribió:
  

Buenas,
On Sun, Jan 17, 2010 at 10:29:50AM -0800, Rodrigo Gallardo wrote:


On Sun, Jan 17, 2010 at 03:25:43PM +0100, ga wrote:
  

On Fri, Jan 15, 2010 at 12:49:07PM -0500, Walber Zaldivar Herrera
wrote:


Hasta que punto es auditable que el .deb que descargamos coincida
100% con el código fuente publicado?
  


Al 100%, has leido acerca de LFS (Linux from scrash), esto podes
hacerlo con Debian. Pero, estas capacitado?

  

[Un paquete upstream podría añadir un backdor entre versiones]



Por motivos de aprendizaje, varios traen puertas traseras, para que
leamos y aprendamos a descubrirlas y asi tener un SO seguro. Se dice
de UNIX, que es muy amigable, solo que el escoje a sus amigos! Y segun
se ve, solo escoge a los curiosos y dispuestos a destripar el sistema
in situ! Tambien, se puede ser un usuario de Estable (Lenny), y no
tener dificultades! o como la mayoria, usar windows pirateado! Asi que
mejor a usar windows 7...pirateado!!!

  

Pues no quería que te sintieras ofendido (ni nadie) por ninguno de mis
comentarios, simplemente es una posibilidad, somos humanos :).
Nos gusta Debian, pero (personalmente) creo que ciertas cosas hay que
analizarlas friamente, sin el corazón en la mano.
Por cierto, mantengo un pequeño paquete, y no hago eso.



Esto, suena como a querer darnos atol con el dedo! Lo siento por el localismo.

  

¿No haces "eso" que?
¿no revisas?
¿no usas diff?
¿no entiendes los cambios?
Si es así por favor danos el nombre del paquete, para estar alertas
cuando haya algún cambio, no vaya a ser cosa que algo "no deseado" se
te pase.

Saludos.

  


  

Me parece que lo que no se puede lograr de forma preventiva (Analizar
minuciosamente el código para ver que no se haya infiltrado código
malicioso) en la comunidad open source se compensa con el modelo reactivo de
la comunidad.



Esto, se llama retorica; hablar mucho y no decir nada!
preventiva? quien no puede? Tu quizas, por ahora; pero que tal si
aprendes. No existe ningun "modelo reactivo", esas son palabras sin
significado real.
Si sabes como hacerlo, pues lo haces y si quieres, pues lo compartes.
Muy simple.

  

Un claro ejemplo es el tema del bug SSL que afectó a Debian más o menos un
año atrás. La difusión fue tal y los esfuerzos de los desarrolladores que no
se registraron incidentes importantes. Fue tanta la publicidad y la
cooperación que cualquier atacante malicioso dejó de ver el la posible
vulnerabilidad como algo "explotable".



Mas retorica!

  

Viéndolo de ese lado eso es un punto a favor. Además la solución se basa en
un modelo de muchas personas auditanto el código contra uno o dos
desarrolladores (a veces sin conocimientos profesionales de seguridad)
preocupándose por la seguridad de su proyecto o paquete.



Y seguimos sin decir nada.

  
En realidad el que no dice nada eres tú. Podrías contraargumentar pero 
no lo haces, (o quizás no quieres esforzarte en entender la retórica?) 
me da para poner +1->troll.


Saludos

Saludos




  



--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema consul tores 
El día 18 de enero de 2010 04:49, Federico Alberto Sayd
 escribió:
> Felix Perez escribió:
>> El día 17 de enero de 2010 15:49, ga  escribió:
>>> Buenas,
>>> On Sun, Jan 17, 2010 at 10:29:50AM -0800, Rodrigo Gallardo wrote:
 On Sun, Jan 17, 2010 at 03:25:43PM +0100, ga wrote:
> On Fri, Jan 15, 2010 at 12:49:07PM -0500, Walber Zaldivar Herrera
> wrote:
>> Hasta que punto es auditable que el .deb que descargamos coincida
>> 100% con el código fuente publicado?

Al 100%, has leido acerca de LFS (Linux from scrash), esto podes
hacerlo con Debian. Pero, estas capacitado?

> [Un paquete upstream podría añadir un backdor entre versiones]

Por motivos de aprendizaje, varios traen puertas traseras, para que
leamos y aprendamos a descubrirlas y asi tener un SO seguro. Se dice
de UNIX, que es muy amigable, solo que el escoje a sus amigos! Y segun
se ve, solo escoge a los curiosos y dispuestos a destripar el sistema
in situ! Tambien, se puede ser un usuario de Estable (Lenny), y no
tener dificultades! o como la mayoria, usar windows pirateado! Asi que
mejor a usar windows 7...pirateado!!!

>>> Pues no quería que te sintieras ofendido (ni nadie) por ninguno de mis
>>> comentarios, simplemente es una posibilidad, somos humanos :).
>>> Nos gusta Debian, pero (personalmente) creo que ciertas cosas hay que
>>> analizarlas friamente, sin el corazón en la mano.
>>> Por cierto, mantengo un pequeño paquete, y no hago eso.

Esto, suena como a querer darnos atol con el dedo! Lo siento por el localismo.

>> ¿No haces "eso" que?
>> ¿no revisas?
>> ¿no usas diff?
>> ¿no entiendes los cambios?
>> Si es así por favor danos el nombre del paquete, para estar alertas
>> cuando haya algún cambio, no vaya a ser cosa que algo "no deseado" se
>> te pase.
>>
>> Saludos.
>>

> Me parece que lo que no se puede lograr de forma preventiva (Analizar
> minuciosamente el código para ver que no se haya infiltrado código
> malicioso) en la comunidad open source se compensa con el modelo reactivo de
> la comunidad.

Esto, se llama retorica; hablar mucho y no decir nada!
preventiva? quien no puede? Tu quizas, por ahora; pero que tal si
aprendes. No existe ningun "modelo reactivo", esas son palabras sin
significado real.
Si sabes como hacerlo, pues lo haces y si quieres, pues lo compartes.
Muy simple.

> Un claro ejemplo es el tema del bug SSL que afectó a Debian más o menos un
> año atrás. La difusión fue tal y los esfuerzos de los desarrolladores que no
> se registraron incidentes importantes. Fue tanta la publicidad y la
> cooperación que cualquier atacante malicioso dejó de ver el la posible
> vulnerabilidad como algo "explotable".

Mas retorica!

> Viéndolo de ese lado eso es un punto a favor. Además la solución se basa en
> un modelo de muchas personas auditanto el código contra uno o dos
> desarrolladores (a veces sin conocimientos profesionales de seguridad)
> preocupándose por la seguridad de su proyecto o paquete.

Y seguimos sin decir nada.

> Saludos


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema Walber Zaldivar Herrera 

consul tores escribió:

El día 15 de enero de 2010 11:38, Walber Zaldivar Herrera
 escribió:


Por supuesto que YO confío en Debian ;)


Grandisimo error, deberias confiar en ti mismo; esto es lo que hace
muy seguro a Debian, habemos hojos por todo el Mundo, escudrinando el
codigo en diferentes niveles e Idiomas!



Jajaja, es cierto, el problema es que no puedo YO SOLO confirmar que los 
mil y pico de paquetes que utilizo son "seguros". Tengo que delegar un 
poco de confianza  :)



El escenario de la hiper-paranoia sería

los fuentes del paquete X, con las modificaciones de Debian están publicos

Debian compila y empaqueta, pero en ese proceso alguien conocido como
MaloMalo adiciona una orden "plan de dominación mundial" :) y genera el .deb

El .deb se supone que no tenga la orden "plan de dominación mundial" pero la
tiene porque no está en las fuentes publicadas sino en las que manipuló
MaloMalo en el último instante.

por lo que veo de los logs, MaloMalo no tiene forma de incluir su plan sin
ser detectado por otros. O me equivoco?

s...@lu2

Walber



Yo, veo que has hecho un planteamiento absurdo; si tu no eres el
encargado del Gobierno en asuntos de seguridad Nacional; como podrias
ni siquiera imaginar, que te van a pedir explicaciones!

Cada gobierno tiene sus expertos, quienes hacen las evaluaciones
tecnicas. Que SO ocupa actualmente el Gobierno y su pueblo? Windows?
sabiendo que cada ordenador con Windows manda informacion a Microsoft
y esta es procesada por oficinas como la que metio SELinux en el
nucleo Linux para formar un gobierno unico Mundial!

Deberian de entender, que hace varios anos, cuando pocos tenian
internet, se movia la informacion usando disquetes de 1.4 Mb y se leia
la basta y muy util informacion que hay en cada Debian instalado, esto
garantiza aprendisaje y a su vez, garantiza que a Debian lo
mantendremos limpio; para lo que fue creado.

hasta luego.




Mis motivos podrán ser paranoicos, pero son mis motivos, ciertos o 
falsos. No sé si sabes como funcionan las cosas en Cuba, pero todo es 
posible cuando se te ocurre hablar de "soberanía e independencia", sobre 
todo si le vas en contra a una posición oficialista.


s...@lu2 Walber

--
>
+-<=<==|

(o_
//\Linux Registered User
V_/_   #480598

Berimbau VCL 
Just another project to provide Delphi components

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema Federico Alberto Sayd 

Felix Perez escribió:

El día 17 de enero de 2010 15:49, ga  escribió:
  

Buenas,

On Sun, Jan 17, 2010 at 10:29:50AM -0800, Rodrigo Gallardo wrote:


On Sun, Jan 17, 2010 at 03:25:43PM +0100, ga wrote:
  

On Fri, Jan 15, 2010 at 12:49:07PM -0500, Walber Zaldivar Herrera wrote:


Hasta que punto es auditable que el .deb que descargamos coincida
100% con el código fuente publicado?
  

[Un paquete upstream podría añadir un backdor entre versiones]

Si un desarrollador de Debian ve que hay una versión nueva del programa
que mantiene, se baja las fuentes, lo empaqueta y lo sube, sin hacer
nada más, el paquete será un .deb perfectamente válido, pero con una
bonita puerta trasera.


(Aquí si me siento personalmente ofendido)

No, la mayoría de los empaquetadores no hacen eso. ¿Alguna vez has
notado que las nuevas versiones tardan más de 15 minutos en estar
empaquetadas? ¿Te has preguntado por qué? La respuesta, en muchas
ocasiones, es precisamente que el mantenedor no va a simplemente
cambiar el .orig.tar.gz y compilar. Hay que leer el diff, entender (a
grandes razgos, por lo menos) qué cambió, actualizar los parches
(algunos de seguridad) que se le aplican al paquete. Sí, hay gente que
no hace eso, y también es posible que uno meta la pata. Pero, en
general, ese comentario tuyo es una falta de respeto a la gran mayoría
de los empaquetadores.
  

Pues no quería que te sintieras ofendido (ni nadie) por ninguno de mis
comentarios, simplemente es una posibilidad, somos humanos :).
Nos gusta Debian, pero (personalmente) creo que ciertas cosas hay que
analizarlas friamente, sin el corazón en la mano.

Por cierto, mantengo un pequeño paquete, y no hago eso.



¿No haces "eso" que?
¿no revisas?
¿no usas diff?
¿no entiendes los cambios?
Si es así por favor danos el nombre del paquete, para estar alertas
cuando haya algún cambio, no vaya a ser cosa que algo "no deseado" se
te pase.

Saludos.


  
Me parece que lo que no se puede lograr de forma preventiva (Analizar 
minuciosamente el código para ver que no se haya infiltrado código 
malicioso) en la comunidad open source se compensa con el modelo 
reactivo de la comunidad.


Un claro ejemplo es el tema del bug SSL que afectó a Debian más o menos 
un año atrás. La difusión fue tal y los esfuerzos de los desarrolladores 
que no se registraron incidentes importantes. Fue tanta la publicidad y 
la cooperación que cualquier atacante malicioso dejó de ver el la 
posible vulnerabilidad como algo "explotable".


Viéndolo de ese lado eso es un punto a favor. Además la solución se basa 
en un modelo de muchas personas auditanto el código contra uno o dos 
desarrolladores (a veces sin conocimientos profesionales de seguridad) 
preocupándose por la seguridad de su proyecto o paquete.


Saludos


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] como convencer a la "Seguridad" de que no hay backdoors en los .deb?

2010-01-18 Por tema Federico Alberto Sayd 

Juan Lavieri escribió:

Felix Perez escribió:

El día 17 de enero de 2010 11:25, ga  escribió:

Buenas,


Yo igual replantearía la pregunta (con tu permiso): ¿Hasta qué punto 
son

auditables las fuentes originales que son empaquetadas como .deb?


+1


Digo esto, porque leyendo tu email he recordado, que hace unos años
el cliente de IRC irssi fue "backdoorizado". Hackearon el servidor 
donde

estaban las fuentes, y las modificaron para introducir una puerta
trasera en el código. Según los propios desarrolladores no sabían desde
cuándo podría llevar eso así.
¿Y con un programa que tiene 100mil (por ejemplo cinelerra) líneas 
de código?
¿El que mantuviera el paquete sería capaz de detectar una puerta 
trasera

de 30 líneas? Quizás sí, pero es complicado (o a mi me lo parece al
menos).

debiera poder verificar que cambios entre una y otra versión de 
desarrollo.



Si un desarrollador de Debian ve que hay una versión nueva del programa
que mantiene, se baja las fuentes, lo empaqueta y lo sube, sin hacer
nada más, el paquete será un .deb perfectamente válido, pero con una
bonita puerta trasera.


El empaquetador no solo recibe el código fuente y automáticamente lo
empaqueta y pública, por algo un paquete pasa por experimental, sid,
testing y estable, y no solo se verifica su estabilidad, también
supongo que se audita código y temas relacionados en seguridad.
El sistema de publicación de paquetes de debian es mucho más complejo
de lo que se cree.


En el caso del programa irssi, el paquete deb no contuvo la puerta
trasera:
http://www.derkeiler.com/Mailing-Lists/Securiteam/2002-05/0107.html


Menciona que los binarios y además que las fuentes de debian (supongo
código fuente, no que vengan de debian) no estaban afectados.  Asumo
que funcionó el sistema.


Por otro lado, ha habido varias veces ya, que al hacer un apt-get
update, las firmas md5 no coincidían. Honestamente, ¿cuántos
actualizásteis en esa circunstancia?


Yo no.


En mi opinión, Debian me parece seguro, pero la seguridad (como dicen
por ahí), es solo un estado mental.


Además de ser un estado mental, tu la construyes. Que no podamos tener
una seguridad al 100% es otra cosa.

+1

Además, esa es otra ventaja del software libre, la posibilidad de 
tener las fuentes a mano para auditar.


¿Podrían esas autoridades confiar en el software propietario?  
¿Podrían simplemente hacerle esta misma pregunta al tío Bill y confiar 
a ciegas en su respuesta sin tener acceso al código fuente?
Estas comparaciones no llevan a nada. Todos sabemos que el código de MS 
es cerrado y por lo tanto no auditable. La idea original es replantear 
el tema de la seguridad en Debian.


Puedes comparar algo malo con algo malísimo y lo malo entonces se verá 
como bueno (y ojo que no estoy diciendo que Debian sea  malo, si no, no 
lo usaría) Lo que quiero decir es que este tipo de reflexiones son 
interesantes porque permiten analizar cuál es el grado de seguridad de 
las distros Linux y en caso de ver alguna falencia analizar posibles 
soluciones. O por otra parte determinar si estos posibles problemas de 
seguridad algún día serán técnicamente viables o no.


Estas son solo mis opiniones, algún desarrollador o empaquetador
podría aportar más detalles.

Saludos.


Saludos

Juan Lavieri





--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bonding mas ifenslave

2010-01-18 Por tema deb...@mstaaravin.com.ar 
2010/1/18 Angel L. Mateo :
>        Ah... otra cosa... Si el bonding lo quieres para redundancia, en
> realidad no es necesario si vas a utilizar un bridge. Puedes crear el
> bridge, asocias la eth0 y la eth1 (por separado, sin bonding) al bridge y le
> activas al bridge el spanning tree y ya tienes redundancia. Eso si, tendrás
> que lidiar con el spanning tree.

Lo cual, si es server a server (2x1gb ethernet cable) no representa
ningún inconveniente, se usa asi tal cual.
Pero de haber un switch de por medio, tiene que soportar spannin tree
(by Cisco) tambien compatible con otras marcas pero no me acuerdo el
nombre que le ponen.

Saludos


-- 

"La Voluntad es el unico motor de nuestros logros"

http://www.mstaaravin.com.ar/


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bonding mas ifenslave

2010-01-18 Por tema Angel L. Mateo 

On 15/01/10 23:00, Antonio Trujillo Carmona wrote:

Estoy montando un servidor con dos tarjetas de red para virtualización.
La lógica de los servidores me dice que use ifenslave para tener
redundancia (seguridad y multipath) en la red, pero para kvm hay que
poner las tarjetas en modo "bridge", he intentado hacer un "bond0" (con
las dos tarjetas reales) y unir esta interfaz al br0, pero no se puede.
¿Alguna sugerencia?

	Ah... otra cosa... Si el bonding lo quieres para redundancia, en 
realidad no es necesario si vas a utilizar un bridge. Puedes crear el 
bridge, asocias la eth0 y la eth1 (por separado, sin bonding) al bridge 
y le activas al bridge el spanning tree y ya tienes redundancia. Eso si, 
tendrás que lidiar con el spanning tree.


--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información   _o)
y las Comunicaciones Aplicadas (ATICA)  / \\
http://www.um.es/atica_(___V
Tfo: 868887590
Fax: 86337


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: bonding mas ifenslave

2010-01-18 Por tema Angel L. Mateo 

On 15/01/10 23:00, Antonio Trujillo Carmona wrote:

Estoy montando un servidor con dos tarjetas de red para virtualización.
La lógica de los servidores me dice que use ifenslave para tener
redundancia (seguridad y multipath) en la red, pero para kvm hay que
poner las tarjetas en modo "bridge", he intentado hacer un "bond0" (con
las dos tarjetas reales) y unir esta interfaz al br0, pero no se puede.
¿Alguna sugerencia?

	¿Cómo que no se puede? Es precisamente lo que tengo yo para Xen (no 
KVM, pero es lo mismo). Aquí lo tienes con el bridge y tagging de VLAN 
incluido:


auto bond0
iface bond0 inet static
address XXX.XXX.XXX.XXX
netmask XXX.XXX.XXX.XXX
network XXX.XXX.XXX.XXX
broadcast XXX.XXX.XXX.XXX
gateway XXX.XXX.XXX.XXX
# dns-* options are implemented by the resolvconf package, if 
installed

dns-nameservers XXX.XXX.XXX.XXX
dns-search um.es
slaves eth0 eth3

iface vlan200 inet manual
pre-up /sbin/ifup bond0
vlan-raw-device bond0

iface xen-br200 inet manual
pre-up /sbin/ifup vlan200
bridge_ports vlan200
bridge_fd 0


--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información   _o)
y las Comunicaciones Aplicadas (ATICA)  / \\
http://www.um.es/atica_(___V
Tfo: 868887590
Fax: 86337


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org