Re: Bug#307570: please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)
On Wed, May 04, 2005 at 01:23:25AM +0200, Holger Levsen wrote: This might be related to the fact the they're somewhat hidden, at least to ./google sarge releasenotes - http://www.debian.org/releases/testing/releasenotes isn't helpful atm either. Why not? Isn't http://www.debian.org/releases/testing/i386/release-notes/ch-upgrading.en.html#s-upgradingpackages sufficient? It does say that you first net to get aptitude and then use that as the recommended upgrade mechanism. Regards Javier signature.asc Description: Digital signature
Re: Trgico accidente.
On Tue, May 11, 2004 at 11:25:44AM +0200, Roberto Suarez Soto wrote: ¿Se ha pensado en hacer algo en lo que podamos colaborar a distancia? No sé, algo en plan mensaje de condolencia para las familias en nombre de los desarrolladores de Debian españoles, un ramo de flores, o algo así :-m El saber que hay más gente que lamenta la pérdida es algo que se agradece en momentos así. Sí, en nombre de la asociación Debian España (y de forma indirecta de los desarrolladores Debian españoles) quiero enviar una carta a sus familias expresando nuestras condolencias. Idem con el ramo. No tengo las direcciones aún pero la carta pretendo que esté escrita esta noche. La reenviaré traducida a [EMAIL PROTECTED] para que se publique en www.debian.org, en este caso, firmada por el líder del proyecto. Un saludo Javier signature.asc Description: Digital signature
Re: Congreso de valencia
On Mon, May 03, 2004 at 09:14:24PM +0200, Alberto Gonzalez Iniesta wrote: Poz a mi no me invito nadie, asi que yo no estoy entre los que van, y no porque no lo tuviera previsto. Yo tampoco he recibido una invitación directa por parte de la organización (sí he hablado, sin embargo, con Roberto y con Amaya) aunque también dije desde el principio que mi disponibilidad de desplazamiento era limitada. Quitando futuras Debconf-ESes, podriamos montar alguna KDD para Julio entre todos, no? Tipo buscar una casa rural (o similar) para un finde y hacer el friki un rato. ¿Qué tal ver si lo de Guadalajara fructifica para el verano y, sino, organizarla? Javier signature.asc Description: Digital signature
Re: Congreso de valencia
On Thu, Apr 29, 2004 at 11:36:40PM +0200, Guillem Jover wrote: Hola, Dado que no se nos ha comentado nada de la propuesta inicial de movilizar a todos los DDs de habla hispana, e incluso a NMs a estas fechas del congreso, y que hay rumores de que no se nos va a pagar el viaje, yo declino cualquier intencion que haya hecho de asistencia a este. Hasta lo que yo veo no hay ninguna mención de Debian en http://www.lliurex.net/congres/cas/ Ni una sola conferencia de Debian ni de DDs. Sí veo conferencias de los sospechosos habituales (RMS, IBM, HP...) En mi opinión, futuras reuniones de DDs y conferencias en las que se quiera involucrar a Debian será mejor tratarlas (con tiempo) a través de una organización más estable, ofrezco la Asociación Debian España para esto. Un saludo Javi signature.asc Description: Digital signature
Re: Desarrolladores de habla hispana
On Thu, Mar 18, 2004 at 11:18:44PM +0100, Amaya wrote: Quiero consultaros cuál es la mejor forma de confeccionar una lista de desarrolladores de habla hispana, además de una de residentes en España. Pues esta lista, como ya se ha dicho, pero, para tener en cuenta los que no están aquí habría que hacer un ping a todos. La lista [1] va adjunta. Un saludo Javi PS: Falta algunos nicks (de gente que es española pero no está en España) si los sacais del LDAP me los mandais, por favor. [1] Actualizada, espero, y disponible en http://www.debian.org/international/Spanish Desarrolladores de Debian hispanoparlantes. Los siguientes desarrolladores de Debian son hispano parlantes, así que si usted es hispano parlante y desea colaborar con Debian verá que el idioma no tiene por qué ser un impedimento. Estos desarrolladores ayudan frecuentemente a los usuarios de Debian en la lista de correo de usuarios en español, y crean también paquetes de interés para los usuarios. Si desea realizar o ha realizado algún paquete que no está en Debian, o desea convertirse en desarrollador póngase en contacto con ellos (para que le firmen la clave, para que le avalen en el proceso...) utilizando la lista de correo [EMAIL PROTECTED] * De España: + Luis Francisco González + Santiago Vila (sanvila) + Enrique Zanardi (ezanard) + David Martínez Moreno (ender) + Juan Cespedes (cespedes) + Roberto Lumbreras (rover) + Javier Fernández-Sanguino (jfs) + Fernando Sánchez + Eduardo Díaz Comellas (ediaz) + Tinguaro Barreno Delgado (tbarreno) + Jordi Mallach (jordi) + Santiago García Mantinan (manty) + Carlos Prado + Manuel Estrada Sainz (ranty) + Enrique Robledo Anuncio (era) + Jesús M. González-Barahona (jgb) + Jacobo Tarrio (jtarrio) + Hector García (hector) + Sergio Talens-Oliag (sto) + Sergio Rua + Roberto Suárez Soto (turgon) + Ricardo Cárdenes Medina (rcardenes) + Roberto Moreda (moreda) + Jaime Villate + Javier Viñuales Gutiérrez (vigu) + Federico Muñoz + Amaya Rodrigo Sastre (amaya) + José C. García Sogo (jsogo) + Andrés Seco Hernández (andressh) + Esteban Manchado Velázquez (zoso) + Alberto González Iniesta (agi) + Teófilo Ruíz Suárez (teo) + Hugo Espuny (hec) + Pablo S. Torralba (pstorralba) + Jose Rodríguez (boriel) + Juan Manuel García Molina (juanma) + Carlos Prados (cprados) + Guillem Jover (guillem) + Fernando Sánchez (fer) + Luis Arocha (data) + Angel Ramos (seamus) + Jesús Climent (mooch) * De México: + Gunnar Wolf (gwolf) * De Colombia: + Andrés Roldán (aroldan) + Luis Fernando Bustamante (luferbu) + Juan Álvarez (jalvarez) * De Costa Rica: + Marcelo Magallón (mmagallo) * De Uruguay: + Carlos Barros (cbf) + Eduardo Trápani (mapache) * De Argentina: + Nicolas Lichtmaier (nick) signature.asc Description: Digital signature
Re: Desarrolladores de habla hispana
On Wed, Mar 24, 2004 at 01:34:00PM +0100, José Luis Tallón wrote: At 12:28 24/03/2004, you wrote: On Thu, Mar 18, 2004 at 11:18:44PM +0100, Amaya wrote: Quiero consultaros cuál es la mejor forma de confeccionar una lista de desarrolladores de habla hispana, además de una de residentes en España. Pues esta lista, como ya se ha dicho, pero, para tener en cuenta los que no están aquí habría que hacer un ping a todos. La lista [1] va adjunta. Te parecerá bonito... y los NM ?? ;) ( A ver si el bueno de mi AM saca tiempo y me hace algo de caso ) Bueno, Amaya pedía desarrolladores... Ya se que hay gente en NM esperando a serlo :-) Javi signature.asc Description: Digital signature
Re: Cifrar con el algoritmo md5
On Mon, Feb 16, 2004 at 11:08:19PM +0100, Jose M. Gómez Vergara wrote: el md5 no encripta. Entre otras cosas porque no mete nada en una cripta. Ahora bien, si consideramos cifrar como: 1. tr. Transcribir en guarismos, letras o símbolos, de acuerdo con una clave, un mensaje cuyo contenido se quiere ocultar. El algoritmo MD5, aunque sea un algoritmo de hash, sí que cifra (en ese sentido), aunque se llama, en realidad función hash. Generalmente el termino cifrar se reserva a algoritmos de cifra con clave (simétricos o asimétricos). Saludos :-) Javi signature.asc Description: Digital signature
Re: permiso para pequeos cleanups en BTS?
On Thu, Jan 22, 2004 at 01:45:53PM +0100, Adeodato Simó wrote: Lo que pasa es que en esos paseos por el BTS ves que hace falta un tags +woody por aquí o un merge #1 #2 por allá, y entonces viene mi pregunta, porque no sé si puedo hacerlo yo mismo o eso es cosa del maintainer. Puedes hacerlo tú mismo, pero si tienes dudas hablalo antes con el desarrollador. Ayer, por ejemplo, retoqué un par de tags, pero porque estaba segurísimo y eran bugs menores, pero no quisiera seguir haciéndolo sin preguntar si eso es «polite» o según qué DDs prefieren revisar ellos mismos todos sus bugs o qué. A mí no me importa que la gente revise mis bugs (me añada etiquetas, etc..) pero si hace algo que es incorrecto, y tengo que ir después a limpiar pues si me cabrea (más trabajo). Debes asegurarte, sin ningún tipo de duda que lo que haces es correcto y, si tienes dudas, enviar un follow-up al bug diciendo ¿no debería tener este bug el tag X?, no debería cerrarse este bug... mejor que el mail a control@ haciendo los cambios... Mis 2 céntimos de euro. Javi signature.asc Description: Digital signature
Re: Debian-es en la OpenSource World Conference ?
On Thu, Dec 25, 2003 at 03:41:12AM +0100, Eric Van Buggenhaut wrote: Hola, no sé si ya sabeis que la Junta de Andalucía organiza en febrero una Conferencia Mundial del Software Libre en Málaga. Sip. El caso es que buscan 'entidades colaboradoras' cuyos criterios serían: Pues no lo sabía. Participarían con la presentación de 1/2 ponencias. Podrían aportar personalidades que dieran contenido a alguna de las sesiones plenarias. 1-2 se refiere a 1 ó 2 no? Yo estoy gestionando que venga o una persona de la NSA or Russell Coker para hablar de SE linux. Tendrían opción a instalar un stand de 1 módulo. Eso estaría bien, pero para instalar un stand hay que pagar un dinero (por el stand) y tener merchandising (para poner) Dispondrían de 2 invitaciones para la zona VIP, el *bleep*tail de bienvenida y la cena de gala Podría disponerse de una entrevista en la revista de la Conferencia. Su logotipo aparecería como entidad colaboradora en la cartelería de la Conferencia. Creo que debian-es se ajusta bastante bien a este perfil y que nos puede beneficiar como proyecto tener presencia alli (y que queremos ir a la cena de gala!!!). Que os parece ? Me parece muy buena idea si el único requisito es dar una o dos ponencias y Sergio ya se ofrece a dar una. Yo no podría ir (me es complicado ir entre semana por motivos laborales) pero ¿quién más puede ir y le gustaría dar una conferencia y colaborar en la organización de esto? Un saludo Javi
Re: (last) Assurance measures: AMA (coping with the speed of OSS development)
On Sun, Dec 14, 2003 at 11:21:20PM -0600, Graham Wilson wrote: On Sun, Dec 14, 2003 at 11:50:43PM +0100, Magosányi Árpád wrote: I hope that at least some of you were listening. (First I thought there would be some feedback, at least like stop it, this is boring!, or why do you write to a mailing list which does not even exists?.) What was your intent in posting all of these messages? He probably expects some discussion regarding Common Criteria requirements and whether his assesment of Debian compliance is ok or not. I would appreciate such discussion too, btw, but I don't have time to contribute input to it atm. Regards Javi signature.asc Description: Digital signature
Re: Fotos DebConf-es
On Sun, Dec 14, 2003 at 09:13:18PM +0100, Alvaro Lopez Ortega wrote: Content-Description: signed data Hola, Acabo de subir las fotos de estos tres últimos días en la DebConf-es. Están en: http://www.alobbs.com/album/debconf-es Alguna opción de cogerlas _todas_ sin tener que ir por el gallery de php? (para verlas en local y/o tostarlas en Cd junto con otras ...) Saludete Javi signature.asc Description: Digital signature
Re: Infinite http redirect loop from people.d.o
On Wed, Dec 10, 2003 at 01:16:24PM -0700, Jamin W. Collins wrote: Not sure if this is still part of the ongoing recovery or something else, but people.d.o is producing an infinite redirect loop for any personal page request. I sent a note to #222697 (merged with #222717) but it hasn't been added to the BTS yet. In any case, it's a configuration problem: $ grep people /etc/apache/httpd.conf (...) #include /org/people.debian.org/apache.conf Gluck admins need to re-enable people.debian.org in the apache configuration. (I've reviewed it and /org/people.debian.org/apache.conf looks fine to me). Regards Javi
Re: Building a distribution from source?
On Fri, Dec 05, 2003 at 01:45:37PM +1100, Russell Coker wrote: On Fri, 5 Dec 2003 13:18, Steve Kemp [EMAIL PROTECTED] wrote: On Fri, Dec 05, 2003 at 12:10:44PM +1100, Russell Coker wrote: Are you using any extra patches to GCC? Or just a GCC built with the propolice option? Yes I am using slightly modified patches from http://www.immunix.org/. The propolice is something that I shall be evaluating next. I believe that our GCC packages already have propolice patched in but not enabled. Therefore it should be a much easier change to make for it to be included. This is true, debian/patches has a line for propolice (currently commented out) As propolice is not invoked unless a special command-line parameter is passed to GCC it seems like a harmless thing to include. Why aren't GCC packages being built with it? Daniel Jacobowitz says (in #213994) They're large patches, with no testing on most architectures. They touch platform independent code. If it really did do nothing without the option, and we were convinced of that, then maybe they could be applied - I'm not convinced. The bug is tagged upstream so it seems that gcc maintainers will not enable this until upstream adds it into the mainstream source. Regards Javi
Re: debsums for maintainer scripts
(no need to CC: me as I'm subscribe) Why do we have to make each of our users find a solution to generate this from a _local_ mirror (or the system's .deb archive which shoulnd't be trusted in the event of an intrusion) when we could do this ourselves and provide the results? Thats why I want signatures so even after a compromise and reboot from a good medium the debs or md5sum lists from the compromised system can be trusted. You can still have a valid signature but an invalid package (out of date with known security holes) installed, though. It is not that much work and known good databases are really useful in forensic investigation (see below or read Sleuth Kit informer issue #6, http://www.sleuthkit.org/informer/sleuthkit-informer-6.html) Debian can provide such a database completly without any md5sums files in the deb. They are as it is realy useless. No they are not, but it seems you did not understand my example at all. Many vendors [2] provide a full list of valid md5sums for their operating systems which enables investigators to determine if a file belongs to the system or it has been modified. If you want a list of such files, we have it now. If you want We have the information, but it needs to be extracted. Not all users/admins now how to handle our archive, and there are no standard tools to do what I'm askin for (again, see below) Then write such a tool instead of wasting all mirror and users bandwith and diskspace. I'm asking Debian mirrors to handle the file with the whole list of md5sums. Not users. Still, you are saying that users would need to have a _complete_ copy of the archive to generate that list or compare it against a local system. If I want to do a security audit of a compromised system, taken offline, of which I have a hard disk image, md5sums are _not_ useless. If I have a list of known good checksums (provided by the vendor) I can compare them with If the vendor supplies the list you don't need any list in the debs themself. Thanks for prooving our point. You do want that list too, again, you didn't read or understand my example. I'm not proving your point. You argue against people who are basically on your site. A known good list of md5sums is usefull. A md5sums file inside the deb does not provide this. We agree on that. (I guess site - side?) We don't agree in this, I want both: the known good list of md5sums provided in Debian mirrors and the md5sums file inside the debs to use them both for comparisons against the files and against themselves. Do you really want to say that the only way a forensic investigator could have of checking a hard disk image contents is downloading the _full_ Debian archive in order to compare that to the disk? What if the system is Thats how it is now. in package md5sum files, what this is all about, doen't change that a bit. No, it is not. That information can be easily extracted to a single file and provided in the mirror so you can download that file instead of all the packages. stable+security updates, how would you remove the false positives in your above example? You read every single file thats changed and find out if that is an attack. What do you mean read? Do you mean checking the timestamps? Checking the md5 hashes? I'm sorry but I don't see your point. Now, imagine we have this file, and we have the local md5sum database in the image copy of the compromise system. I could check rather easily: 1.- if the vendor provided md5sum files in the database matches the local md5 hashes information for files in the system. That means you throw th local one away and download a known good one. No, it meas I use both to determine if the local database has been tampered or not. The fact that the local database has been tampered means I cannot trust it, but it also highlights a targeted attack (current rootkits do not mess with package information) (...) (1) downloads you a known good copy which mans downloading all debs as it is now. I'm asking for two things here, as I said before, md5sums in the .debs and a Contents-md5sums file in the mirrors which would be downloaded in (1) you wouldn't need to donwload the archive. So my vote goes to adding md5sums to policy. We still don't vote on technical issues, thank god. It was just an expression, obviously. Maybe it's not translatable. Friendly Javi You vote for providing md5sums files seperatly from the debs and not in the debs (and you probably would still agree by just providing a signature for locally stored/generated md5sum file verification). So your on our side. Well, there are not really sides here. But again: - I want md5sums to be stored in the local filesystem, I don't really care if they are inside the debs or not, as long as it's standard procedure and nobody has to hack apt.conf, dpkg or what else to have
Re: debsums for maintainer scripts
On Thu, Dec 04, 2003 at 03:07:52AM +0100, Goswin von Brederlow wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: On Wed, 2003-12-03 at 05:23, Manoj Srivastava wrote: Because it buys little security wise? I can take a rescue disk, a CD with relevant packages on it, boot the suspect server from the rescue disk, and quickly check md5sums. At least, if all packages had md5sums I could. You can just as well just check all the debs. gunzip doesn't take longer, the slowest thing usually is the cdrom. ¿You mean from your CDs? You won't usually have up-to-date CDroms with the security updates (at least I don't). So, if you lack a network connection, you would need to download the archive, make a CD... I was about to say that you needed your own tools, but then I found debsums' --deb-path option. Still, it would be best if you could download a list of valid MD5sums from your favorite Debian mirror (an option not currently available) instead of all the .deb and then manually extract the md5sums from them. That list could be provided on a per-Release basis together with separate lists for security updates and proposed-updates [1] and could be checked automatically by tools like debsums, running of a CD. Regards Javi [1] Similar to our Contents-* files but providing the md5sum within it too. Hmm... I think I'm going to submit a wishlist bug to ftp.debian.org signature.asc Description: Digital signature
Re: debsums for maintainer scripts
[Manoj, I'm going to concentrate on this example, it's probably a corner
case and I'm probably digressing here ... oh well]
On Thu, Dec 04, 2003 at 11:17:46AM -0600, Manoj Srivastava wrote:
Finally, there's one thing md5sums in packages can provide that no
other solution proposed in this thread can: a database of known good
signatures [1].
Uhhh -- if this were indeed important, it is easy to generate
such a list from a known good set of .debs. Why exactly is
publishing such a list usefule, and not mere make work?
Why do we have to make each of our users find a solution to generate this
from a _local_ mirror (or the system's .deb archive which shoulnd't be
trusted in the event of an intrusion) when we could do this ourselves and
provide the results?
It is not that much work and known good databases are really useful in
forensic investigation (see below or read Sleuth Kit informer issue #6,
http://www.sleuthkit.org/informer/sleuthkit-informer-6.html)
Many vendors [2] provide a full list of valid md5sums for their
operating systems which enables investigators to determine if a file
belongs to the system or it has been modified.
If you want a list of such files, we have it now. If you want
We have the information, but it needs to be extracted. Not all users/admins
now how to handle our archive, and there are no standard tools to do what
I'm askin for (again, see below)
to do a security audit, the md5sum is useless. An integrity check
No it's not, see below.
could perhaps use this, and most systems would be better off with
DPkg::Post-Invoke {
debsums --generate=nocheck -sp /var/cache/apt/archives;
};
If I want to do a security audit of a compromised system, taken offline, of
which I have a hard disk image, md5sums are _not_ useless. If I have a list
of known good checksums (provided by the vendor) I can compare them with
the files and see what files might have been changed by an intruder. I can
also use them to detect what packages do files belong to and see if the
packages are known to have security holes (i.e. the 'downgrade' case).
Notice that I'm not necessarily depending on the local md5sums, I'm taking
a file provided by a vendor, in this case, Debian. Let's call it
Contents-xxx.md5sum.gz. This file is available for download from all
Debian mirrors, signed with the Release key and provides these three fields
for every file in a single Release:
filename md5sum package
I don't see any reason why we shouldn't provide this and there are some
situations in which it would be useful (see below). In order to do this
we could either:
1) run a task on the mirrors to generate it (extract the files from the
ars, calculate the md5sum, etc..) when we make a Release
or
2) take the information on the package's md5sums file and put it in a
single file.
Now, with (2), at the same time, you are giving the users a way to
check the filesystem locally, i.e. do integrity checking online. This
has several benefits as already described, but even more in the forensic
situation.
This is very useful in a forensic investigation since it enables a
Bullshit. In a forensic investigation you can't trust on disk
md5sums; and if you need to download the packages to verify the
md5sum, you have a better check for integrity:
# ar p blah.deb data.tar.gz | tar zfd - | grep 'Contents differ'
When did I say that I was trusting disk md5sums? I'm trusting the image
copy of the compromised system, the md5sum binaries of the analysis
computer in which the image is stored, and my list of valid md5sums
(downloaded from Debian as described above). I'm not trusting the local
information on the image copy, but it will be useful to pinpoint attack
methods easily.
Do you really want to say that the only way a forensic investigator could
have of checking a hard disk image contents is downloading the _full_
Debian archive in order to compare that to the disk? What if the system is
stable+security updates, how would you remove the false positives in your
above example?
Now, imagine we have this file, and we have the local md5sum database in
the image copy of the compromise system. I could check rather easily:
1.- if the vendor provided md5sum files in the database matches the local
md5 hashes information for files in the system.
2.- if the local files's md5 hashes match the local md5sum database.
3.- if the local files's md5sum match the vendor-provided database and
which packages (even versions, if the database is made of two releases, say
stable and security updates) it belongs to.
4.- if the packages which files seem to belong to (based on md5sum files)
correspond to packages that _should_ be installed in the system (based on
release files).
Answering (1) can tell me if the local md5 database has been tampered with
or if packages have been modified (they are not the ones provided in the
releases), (2) can tell me if
Re: configuring lilo on package installation
On Sun, Nov 23, 2003 at 06:19:39PM +0100, Tobias Grimm wrote: Hi! I'm working on a nvram-wakeup package for a Debian based VDR distribution (c't vdr). nvram-wakeup needs a special kernel-image, that forces a shutdown on the next reboot. Normally this image is installed to /boot and a new section has to be added to lilo.conf: image = /boot/bzImage.poweroff label = PowerOff It wouldn't be a problem to modify the lilo.conf in the maintainer script, but I'm not sure if this is the way this should be done. Yes it is, it's a policy violation. What's the best way to add a section to the lilo.conf during package installation (and remove it when uninstalling)? If the lilo manager does not provide a script to manage lilo.conf, or does not provide a way to hook things into it (the answer to both question is, I believe, that it doesn't), IMHO you can only add a debconf note telling the admin what he needs to do in order to enable the package. Regards Javi signature.asc Description: Digital signature
Re: debsums for maintainer scripts
On Wed, Dec 03, 2003 at 04:23:33AM -0600, Manoj Srivastava wrote: On Mon, 1 Dec 2003 17:12:36 -0500, christophe barbe [EMAIL PROTECTED] said: I don't see why adding a md5dsum_are_mandatory clause to the debian policy would be difficult (what would be a good reason to not add md5sum to a package?). Because it buys little security wise? Because there are solutions one can put in place today that offer better coverage than in package md5sums? First off, little security is better than no security. Second, it's not only useful for security, it's useful for integrity checking (which is not always related). Third, other solutions (calculating md5sums on install, running tripwire/aide, etc.) might be computational intensive and might need to be ruled out in some (critical) systems. Finally, there's one thing md5sums in packages can provide that no other solution proposed in this thread can: a database of known good signatures [1]. Many vendors [2] provide a full list of valid md5sums for their operating systems which enables investigators to determine if a file belongs to the system or it has been modified. This is very useful in a forensic investigation since it enables a way to determine which files in the system have been modified by comparing them against the vendor-provided list of MD5sums. In many forensic investigation cases, i.e. security-unaware sites, there's no integrity checking being done outside what system tools provide. For example: Tiger provides a module [3] to do this kind of check and some forensic tools (sleuthkit) can use external databases to check for deviations. As for integrity checking, as I said, this can be completely unrelated to security. If I want to retrieve the list of configuration files in the system that have been modified (in order to do a focused backup) md5sums in packages helps a lot, I can also determine if the administrators did not modify a binary in the system (which some might do, in the case of shell scripts, instead of making a copy to /usr/local and replacing that one). An admin that has not foreseen that need, and has to do it without a locally generated integrity database will find it very difficult to accomplish. Let's not get into the discussion of wether tripwire/aide/samhain/integrit are better solutions to do host intrusion detection. They are. But I would love to see an automatic way to analyse a mirror and retrieve _all_ the valid md5sums of binaries in Debian packages for a stable release. The burden imposed on maintainers in adding this is minimum, the burden imposed on administrators in order to do it themselves is higher (install and customize your integrity tool of choice, or modify dpkg to calculate those) and still will not differ from a solution based on packages included md5sums if not planned properly (databases in read-only media, planed updates of the integrity database, checks using trusted binaries in read-only media or in maintenance mode...). Certainly not something your average desktop user will do. So my vote goes to adding md5sums to policy. Friendly Javi [1] Such as those provided by the NIST's National Software Reference Library (www.nsrl.nist.gov) and the Known Goods Database (www.knowngoods.org) Note: Knowgoods is not too up to date. [2] Sun does for Solaris: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsrdb%2F43592zone_32=md5 the database is available at http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl and so does IBM for AIX, take a look for example to how IBM suggests checking the Trusted Computing Base http://publib16.boulder.ibm.com/pseries/en_US/aixbman/security/installing_configuring_tcb_checking [3] check_signatures signature.asc Description: Digital signature
Re: Bits from the RM
On Mon, Dec 01, 2003 at 02:45:09PM +1000, Anthony Towns wrote: Hello world, Hello aj. * LSB 1.3 compatibility mostly achieved (LSB non-compliance issues are now Release Critical; bugs should be filed and addressed by the LSB team, which hangs around the debian-lsb mailing list. Only one compliance issue remains unfixed in sid. LSB 2.0 compliance will be trickier, but will hopefully be being worked on well before the next release.) Just a note (and please bear in mind that I'm a LSB novice): I just noticed that lsbdev has a number of outstanding bugs and is not updated to the latest upstream release (1.3) as described in #188955 and #221287. Even if it's not in testing, and thus not a RC problem per se, could the LSB team please help the maintainer upgrade to a new version? (which would probably fix #194986, #179986, #218081) Thanks Javi signature.asc Description: Digital signature
Re: Asociacin Debian Espaa (era Re: a la debconf-es casi casi fijo)
On Wed, Nov 19, 2003 at 12:32:58AM +0100, Teófilo Ruiz Suárez wrote: He puesto los estatutos, en LaTeX y su PDF, y una copia de los estatutos tipo que propnen en el Ministerio de Interior. http://the-geek.org/~teo/debian/asociacion/ Los miraré con más calma. - Ambito de la Asociación. Estuve hablando con Jesús G. Barahona y con vigu durante las JASL3 en Granada el pasado fin de semana y estuvimos viendo la posibilidad de hacer una asociación europea, que para algo somos de la UE, si es posible creo que sería una opción interesante. No. La asociación debe ser española. - Socios. Dos opciones, o bien hacer distinción entre socios que son desarrolladores oficiales y los que no lo son, o tratar a todos por igual. Atención, una distinción no es inherentemente mala :) Lo que si creo, opinión personal, es que al menos los socios fundadores si deberían ser DD. Yo no creo que sea necesario hacer una distinción. - El tema Junta Directiva. Debe haber una Junta según la Ley. ¿Deben ser todos de Madrid?. ¿Por qué de Madrid? - Cuotas. ¿Cobrar cuotas?. Ummm... tema espinoso. Yo diría que sí. - Patrimonio inicial. ¿Tenemos patrimonio?. No. - Fines. ¿Añadiríais, cambiarias o eliminiaríais alguno?. Añadiría más. Cuando tenga algo te lo envío. - Tasas: http://www.mir.es/otros/tasas/tasas.htm#asoci Eso habrá que pagarlo del bolsillo de algunos cuando se quiera constituir. Se me han ocurrido otras cosas que ya no recuerdo, os toca ;-) Se me ocurre: - Disolución de la Asocicación - Disolución de la Asociación. - Las Asambleas Generales deben poder convocarse por correo electrónico (como medio alternativo), salvo las Extraordinarias que deberá hacerse por escrito. La Disposición Adicional deja que las Extraordinarias se convoquen por correo-e, no se si estoy a favor de eso. - Yo añadiría capacitaciones a la Junta Directiva para poder acordar la delegación de cosas en personal que sea pagado (una persona que lleve las cuentas por ejemplo) - Añadiría la figura de socios amigos para entidades físicas o jurídicas - Incluiría como capacidades de la asociación la de Federación con otras asociaciones extranjeras. - Participar con voz y voto en las Asmableas Generales. - Participar con voz y voto en las Asambleas Generales. - Más obligaciones a los socios (representar correctamente a la asociación por ejemplo) - El límite de presupuesto está en pesetas y debería ser euros. En cualquier caso, diez millones no es mucho. Si me dejas unos días hago un parche al LaTeX con todo esto y os lo envío. Javi signature.asc Description: Digital signature
Re: Asociacin Debian Espaa (era Re: a la debconf-es casi casi fijo)
On Wed, Nov 19, 2003 at 10:25:49AM +0100, Andres Seco Hernandez wrote: Hola Hace relativamente poco tiempo hemos creado una asociación en Guadalajara para las redes inalámbricas, Auriga, y tenemos unos estatutos bastante decentillos, creo, con referencias al uso del correo para los comunicados y convocatorias. No recuerdo que finalmente metieramos que las conversaciones por correo firmadas con gnupg en las que llegaramos a un acuerdo los socios sirvieran como las actas de reuniones, pero creo que es un tema interesante que da comodidad a la (...) Yo no creo que en los Estatutos tenga que poner en detalle todo eso. Simplemente hay que describir en los estatutos que se hará un Reglamento de Regimen Interior (habitualmente lo hace la Junta Directiva y lo aprueba la asamblea general) en el que se incorpora todo esto. Todo lo que complique (en exceso) los Estatutos es mejor evitarlo porque así se aceleran los trámites en el Ministerio (los funcionarios que lo aprueban lo entenderán mejor) Esto no quita que se pongan cosas que se consideren interesantes. Pero el tema operativo no es necesario. Javi signature.asc Description: Digital signature
Re: Asociacin Debian Espaa (era Re: a la debconf-es casi casi fijo)
On Wed, Nov 19, 2003 at 09:22:03AM +0100, Teófilo Ruiz Suárez wrote: Bien, ¿y para los socios fundadores?. Los socios fundadores son los que _fundan_ la asociación. - El tema Junta Directiva. Debe haber una Junta según la Ley. ¿Deben ser todos de Madrid?. ¿Por qué de Madrid? Nu sé, es lo primero que se me vino a la cabeza. Aunque si no tiene que haber reuniones físicas periódicas, no hay porque. ¿Y el domicilio social?. Nada dice que las reuniones tengan que se presenciables. Eso se puede desglosar en el Reglamento de Regimen Interior. Lo que sí tienen que ser es periódicas. Si me dejas unos días hago un parche al LaTeX con todo esto y os lo envío. Sería chachi. Gracias :) Dame un tiempo porque estoy hasta arriba... Javi signature.asc Description: Digital signature
Re: Asociacin Debian Espaa (era Re: a la debconf-es casi casi fijo)
On Wed, Nov 19, 2003 at 01:24:32PM +0100, Andres Seco Hernandez wrote: Tambien es cierto. La pena es que en más de la mitad de asociaciones despues el reglamento de regimen interior no se llega a realizar nunca. Muy cierto. Pero introducir ciertas cosas en los Estatutos significa que luego es más dificil cambiarlas (Asamblea Extraordinaria con 2/3 partes de los socios a favor). Si metes muchas cosas en ellos te arriesgas que, a largo plazo, se vea que una cosa esta mal, se quiera cambiar pero se tengan tantos socios que no se pueda hacer nunca. El RRII es algo más flexible y más operativo, por eso es mejor dejar los Estatutos lo suficientemente genéricos como para que no necesiten cambios y lo suficientemente específicos como para que digan algo. Un saludo Javi
Re: Asociacin Debian Espaa (era Re: a la debconf-es casi casi fijo)
On Wed, Nov 19, 2003 at 10:40:36PM +0100, Teófilo Ruiz Suárez wrote:
He añadido bastantes cosas, aunque habría que mirar bien el tema del
RRI. ¿Quién tiene la facultad de cambiarlo?, ¿solo la asamblea general?.
Adjunto va mi parche, que describe muchas cosas, incluyendo el tema del
RRI. Como puedes ver, lo diseña la Junta Directiva y lo aprueba la Asamblea
General Ordinaria (que tiene la potestad de aprobar las propuestas de la
Junta).
Lo único que me gustaría añadir más es en los fines, creo que quedan algo
cortos. Por cierto, como ahora es Debian GNU/Linux pero en el futuro puede
ser Debian GNU/BSD, Debian GNU/Hurd o vete tú a saber qué, he puesto más
el proyecto Debian (o sus sistemas operativos) que Debian GNU/Linux en
sí.
También introduzco varias figuras distintas de socios, con distintos
derechos y obligaciones. Aparte, he rellenado con más información de otros
estatutos que creo que sería interesante tener. Ojala hubieras utilizado un
estilo que autonumerar los artículos, porque he tenido que cambiarlos
varias veces a mano (después de introducir un artículo aquí y otro
allá)
A ver qué os parece.
Javi
--- estatutos.tex.orig 2003-11-20 00:55:48.0 +0100
+++ estatutos.tex 2003-11-20 01:51:18.0 +0100
@@ -34,29 +34,38 @@
Se constituye en Madrid la entidad denominada
Asociación Debian España al amparo de lo previsto en el artículo 22 de
la Constitución Española, lo establecido en la Ley orgánica 1/2002, de 22 de
-marzo, reguladora del Derecho de Asociación y normas complementarias. El
-régimen de la Asociación se determinará por lo dispuesto en los presentes
-Estatutos, si bien éstos se verán completados por un
-Reglamento de Régimen Interno.
+marzo, reguladora del Derecho de Asociación y normas complementarias.
\arti{Artículo 2º}
La Asociación no tiene ánimo de lucro, y sus fines son:
\begin{itemize}
-\item Promover la utilización del sistema operativo Debian GNU/Linux, y del
software
-libre en general.
-\item Investigar y dar a conocer los avances sobre el proyecto Debian
GNU/Linux, tecnologías
-de la información, programación, y otros aspectos relacionados con el proyecto.
+\item Promover la utilización de los sistemas operativos desarrollados
+dentro del proyecto Debian así como del software libre en general.
+\item Investigar y dar a conocer los avances sobre el proyecto Debian,
+tecnologías de la información, programación, y otros aspectos relacionados
+con el proyecto.
+\item Facilitar la comunicación entre usuarios y desarrolladores de los
+sistemas operativos desarrollados por el proyecto Debian, incluyendo
+el sistema operativo Debian GNU/Linux.
+\item Organizar actividades que puedan resultar de interés para los asociados.
+\item Colaborar con otras asociaciones nacionales o extranjeras que tengan
+fines u objetivos análogos, así como la posibilidad de formar Federaciones
+y Confederaciones de ámbito nacional e internacional.
\end{itemize}
-Para el cumplimiento de los fines establecidos la Asociación establecerá
-cuantas actividades lícitas considere apropiadas.
+Para el cumplimiento de estso finales la Asociación por si misma
+o en unión de cualesquiera otras personas, físicas o jurídicas, públicas
+o privadas, realizará todas aquellas actividades lícitas que contribuyan
+a la consecución de los fines establecidos en estos estatutos.
\arti{Artículo 3º}
-\(TODO\)El domicilio de la Asociación se establece en NowhereLand,
NowhereHouse with
-NoNumber.
+\(TODO\)El domicilio de la Asociación se establece en
+POR DETERMINAR.
\arti{Artículo 4º}
-El ámbito de la Asociación será nacional.
+El ámbito territorial comprende tanto el territorio nacional com o
+internacional, pudiendo firmar los convenicos que consider necesarios
+así como crear, en su caso, las delegaciones que considere oportunas.
\capi{CAPÍTULO II}
\capidesc{Órganos directivos y forma de administración}
@@ -77,6 +86,10 @@
\item Aprobar o rechazar las propuestas de la Junta Directiva en orden a
las actividades de la Asociación.
\item Fijar las cuotas de entrada, ordinarias o extraordinarias.
+\item Resolver la admisión definitiva así como la expulsión de
+ los asociados y colaboradores.
+\item Cualquiera otra que no sea de la competencia exclusiva de la
+Asamblea General Extraordinaria.
\end{enumerate}
\arti{Artículo 8º}
@@ -102,6 +115,16 @@
convocatoria, se hará en un plazo no superior a veinticuatro horas.
\arti{Artículo 11º}
+Las Asambleas Generales, tanto Ordinarias como Extraordinarias,
+quedarán validamente constitutidas en primera convocatoria cuando
+concurran a ella la mayoría de los asociaods con derecho a voto, y
+en segunda convocatoria cualquiera que sea el número de asociados con
+derecho a voto.
+Los acuerdos se tomarán por mayoría simple de votos de asistentes cuando
+se trate de Asamblea Ordinaria y por mayoría de dos tercios cuando se trate
+de Asamblea Extraordinaria.
+
+\arti{Artículo 12º}
Sin perjuicio de las facultades de la
Re: Some observations regardig the progress towards Debian 3.1
On Tue, Nov 18, 2003 at 06:14:29PM +, Colin Watson wrote: [1] As I make it, the following packages in testing depend on a specific version of mozilla in such a way as to cause problems when upgrading mozilla. If you can back up your about two dozen with an expanded list, please do so. rant And that's because the mozilla people do not provide the locale data within the release but force it to be provided in a separate manner. Also, the way locales are managed in Mozilla is really crappy, I wish instead of those xpis (and jars, and javascripts...) they had implemented po's it would be a very different issue. /rant Sorry, for that. Javi signature.asc Description: Digital signature
Re: Incluyendo nuevas imagenes
On Sat, Nov 15, 2003 at 08:48:23AM -0600, Marcelo E. Magallon wrote:
source, ya que al ser .png, me los toma como binarios,
no te los toma, _son_ binarios...
ALguien sabe alguna forma elegante y sencilla de resolver este
pequeño lio ?
$ man uuencode
Efectivamente, yo lo he hecho así en algunos paquetes, básicamente haciendo
algo así (ten en cuenta que todas las operaciones se hacen con ficheros
en doc/) de forma genérica cuando esos png/gif se descargan de páginas web:
update-doc:
cd doc wget (...)
find doc -type f -a \( -name *.gif -o -name *.png \) | \
while read file ; do cat doc/`basename $$file` | uuencode `basename
$$file` doc/`basename $$file`.uu ; done
-rm -f doc/*.{gif,png}
update-doc es un 'target' que hace un wget de un sitio web y uuencodea sus
imágenes, no se ejecuta al construir el paquete, sólo se ejecuta
manualmente.
Luego el target 'fix-doc' llamado desde build arregla esto:
fix-doc:
# We do this in order to prevent dpkg-source from breaking
cd doc/ for i in *.uu; do uudecode $$i; done
Con lo que luego solo tengo que hacer..
dh_installdocs doc/*.html doc/*.{gif,png}
al crear el paquete ('binary' o 'bynary-arch').
Espero que te valga de algo. Esto sirve para poder actualizar los gráficos
más adelante, pero si sólo quieres poner el gráfico una vez, utiliza la
parte de arreglo para uudecodear el fichero.
Asegurate también de añadir el paquete 'sharutils' a las Buil-Depends
(provee uudecode/uuencode)
Un saludo
Javi
Re: radiusd-freeradius history and future
On Thu, Nov 13, 2003 at 12:19:02AM +1100, Paul Hampson wrote: On Wed, Nov 12, 2003 at 02:07:27AM +0100, Javier Fernández-Sanguino Peña wrote: Maybe I'm mistaken, but the rpm spec file seems to use a 'radiusd' user whileas the Debian rules package does not. I would be more confident with the package if it was built this way. At least a security problem in its code (if found) would lead to a remote 'radiusd' compromise (but not 'root') an important difference. I don't know what debian/rules file you're looking at, since the bug report in the DBS relating to this has my patch to fix it, and both the current stable and unstable debian/ filesets do not run as root. You are right. It does adduser freerad shadow on first installation, but not after that (on the advice of Steve Langasek) to allow the local authentication code to work, and to give the admin the freedom to disable this for added security if they're not using the local authentication code. Yes, I missed the 'adduser' calls in postinst. In any case, it would be nice if, instead of 'freerad' a generic 'radiusd' user was used so that it could be shared by different radius packages. Not that one would want to install different Radius servers and share the users file, but just for consistency and to avoid having multiple 'freerad', 'cistronrad', 'livingston' users. It might help if you have a cluster of servers and want ot have uniform usernames between them (even if running different implementations). Just a thought (maybe worthless) Regards Javi
Re: radiusd-freeradius history and future
On Sun, Jan 12, 2003 at 01:21:53PM -0500, Chad Miller wrote: [cc debian-devel] On Sun, Jan 12, 2003 at 05:07:41PM +0100, Toni Mueller wrote: [...] Who withdrew [radiusd-freeradius] or caused it's withdrewal, then? Curious minds want to know, and also, it's a bit misty right now... (...) A few months ago, the Sarge release coordinator swept all gravely-buggy- older-than-3?-months packages from sid, including radiusd-freeradius. Wichert immediately asked for the package to be added back, but someone noted that freeradius, a GPL program, linked against libssl, so it couldn't go back in. What is the current status of this issue? There are yet no radiusd-freeradius (or freeradius) packages either in sid or (even) in ftp://ftp.freeradius.org/pub/radius/. The issue on SSL linking (described in DWN [1]) doesn't look as it is has been fixed and the debian/ directory in the CVS has not seen any change for quite some time (+5 months) Anyone? Regards Javi [1] http://www.debian.org/News/weekly/2003/02/
Re: radiusd-freeradius history and future
On Tue, Nov 11, 2003 at 02:02:49PM -0500, Matt Zimmerman wrote: On Tue, Nov 11, 2003 at 11:52:00AM -0600, Steve Langasek wrote: The packages at http://www.tbble.com/freeradius/ will be sponsored into the archive as soon as I've had a chance to review them (this week). This thing is packed full of strcpy() and strcat(), which is the sort of sloppiness that I don't like to see in a network server. It was a great Which flawfinder flawlessly points out, but this also appears in the current radiusd servers we are shipping. In any case, I'm also worried about these: ./src/main/mainconfig.c:267 [5] (race) chown: [shouldn't fchown() be used instead?] and ./src/modules/rlm_krb5/rlm_krb5.c:201 [3] (tmpfile) tmpnam: Temporary file race condition. [tmpnam should be avoided and tempfile() used instead] blessing to find that we weren't shipping this in woody when the last batch of security problems was discovered. Also, just another question. Is there any reason why it needs to run as root? (as I believe it does in the current Debian package) Would it be unreasonable to ask it to run as a 'radiusd' user? Maybe I'm mistaken, but the rpm spec file seems to use a 'radiusd' user whileas the Debian rules package does not. I would be more confident with the package if it was built this way. At least a security problem in its code (if found) would lead to a remote 'radiusd' compromise (but not 'root') an important difference. However, this is the way that currently the radiusd packages we provide (radiusd-cistron and radiusd-livingston) seem to operate. Is this at all necessary? (after all they use their separate users database) Regards Javi PS: I'm not particularly worried about freeradius, I'm just raising some questions. It seems that our radiusd packages suffer from similar (if not worst) security issues and, furthermore, are not (I believe) that actively maintained upstream.
Re: radiusd-freeradius history and future
On Wed, Nov 12, 2003 at 01:23:02PM +1100, Russell Coker wrote: On Wed, 12 Nov 2003 12:40, Matt Zimmerman wrote: The only reason I can think of for running a RADIUS server as root would be to authenticate against UNIX passwords or such, which is a pretty bad idea anyway. They should all run as non-root. Allowing a RADIUS server to authenticate local users against /etc/shadow is standard and expected functionality IMHO. I consider any RADIUS server which can't authenticate against the local accounts database to be severely broken. Well. IMHO that used to be a standard way of doing this when directories where not available. Now it is quite common to validate against an LDAP, MySQL or whatever server. YMMV. But you are right in that all these implementations assume that checking against the local user database is the default action. This does not necessarily have to require root access. The unix_chkpwd helper program for the pam_unix.so module allows checking a password for an account with the current UID. Giving all local accounts for the RADIUS server the (...) That would need a reimplementation of some (all?) of the servers. Wouldn't it? Old ones (cistron, livingston) call getpwnam()|getspnam() to retrieve the user's encrypted passwords. New ones (freeradius) can alternatively talk with a myriad of authentication services... Regards Javi
