Historias
Slashboxes
Comentarios
 
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Re:Chungo

    (Puntos:1)
    por runlevel0 (1932) el Domingo, 26 Diciembre de 2004, 00:15h (#411488)
    ( http://www.flickr.com/photos/runlevel0/ | Última bitácora: Jueves, 01 Noviembre de 2007, 11:37h )
    Vetaja: Los desarrolladores de paquetes que no están incluidos en las distros, como algunos paquetes de aplicaciones java (pero para eso ya está Java webstart), algunos antivirus, plugins como el de flash, etc no tendrían que comerse la cabeza con las configuraciones de las diferentes distros.

    Inconveniente: Eso ya lo hacen los sistemas de creacón de binarios automáticamente, como por ejemplo chkinstall que puede crear al vuelo RPMs y DEBs...

    O usar las fuentes directamente, o tgz al viejo estilo...

    En fin, dejemos que actúe el tiempo y la selección natural, tal vez resulte ventajoso para usuarios o desarrolladores o tal ve sólo quede en agua de borrajas. Cómodo es, desde luego y para un usuario
    recién refugiado de Win puede servirle.
    --

    29A the Number of the Beast
    [ Padre ]
  • Viene en las FAQ

    (Puntos:1)
    por Edulix (7155) el Domingo, 26 Diciembre de 2004, 01:06h (#411496)
    ( http://barrapunto.com/ | Última bitácora: Jueves, 09 Febrero de 2006, 19:13h )

    Sé que es costoso =), pero por favor, mirar antes las FAQs [autopackage.org] (penúltima pregunta).

    What about security?

    What about it?

    You mean you're not going to do package signing?

    This is something we're still thinking about. In a decentralised environment like the one we're aiming for, it's obviously rather difficult to provide guarantees the the package hasn't been trojaned/won't blow up your hard disk. As anybody can produce a .package file without permission from us (or anybody else) there is always a risk, no matter how slight, that you will download a package that will attempt to destroy data or root your box. This is a risk that exists with any form of software distribution, even source tarballs.

    So what can be done about? Well, one solution is to have a known trusted authority digitally sign all packages, where they audit the code for trojans. This introduces centralisation however, and worse, if you no longer trust packages which aren't signed, any holdups at the signing authority can cause serious problems.

    Another possibility is a simplistic network of trust. The root server trusts the gnome.org server, and gnome.org trusts gstreamer.net, and gstreamer.net trusts the gst-player package. So you trust gst-player. That might be workable, but it's not something we're currently implementing, and it'd require quite a bit of thought.

    El último párrafo es el más interesante, así que lo transcribo:

    Otra posibilidad es un simplista modelo de confianza en red. El servidor principal confía en el servidor gnome.org, y gnome.org confía en gstreamer.org, que a su vez confía en el paquete gst-player. De esa manera, tú, confías en el gst-player. Podría funcionar, pero no es algo que estemos implementando ahora, y aun requiría pensarlo un poco mejor.

    Tenemos que bueno, si que han pensado en este tema, así por lo pronto no seamos alarmistas - también hay que tener en cuenta que aun no está en su versión 1.0 y que los paquetes que incluyen son de prueba. Eso si, bien les vale cortar el problema por lo sano cuanto antes posible, por la cuenta que les trae. Y sino que se lo digan por ejemplo a la gente de mozilla.org con los malignos xpi.

    Salu2,
          Edulix

    --
    --- "Fracasar es la oportunidad de comenzar de nuevo con más inteligencia." - Groucho Marx
    [ Padre ]