ThE FuCkInG sHiT

Acabo de leer en la lista de correo de Nmap que Nessus, el popular scanner de vulneabilidades open-source cierra su codigo aunque de momento se seguirán distribuyendo binarios de forma gratiuta. Lo más interesante son las reflexiones de Fyodor, el responsable de nmap acerca de la participacion de los usuarios en el desarrollo de software libre. Esta en inglés y espero que lo entendais porque no tengo intencion de traducirlo a no ser que os interese muchisimo.

From Fyodor to Nmap Hackers,

In the last Insecure.Org Security Tools survey, you guys proudly voted
Nessus #1. It complements the functionality of Nmap by going further
to detect application-level vulnerabilities. Then in February of this
year, Tenable changed the Nessus license to further restrict the
plugins and require that you fax them a permission request form before
you use Nessus for any consulting engagements. Renaud wrote to this
list on Feb 8
(http://seclists.org/lists/nmap-hackers/2005/Jan-Mar/0001.html),
explaining that their new slogan ("the open-source vulnerability
scanner") was accurate because the engine was still open source.
Today, their slogan has changed to "the network vulnerability
scanner", and you can probably guess what that means. In the
announcement below, Renaud announces that Nessus 3 (due in a couple
weeks) will be binary only and forbid redistribution. They say it
will be free, for now, if you use the delayed plugin feed. They have
also announced that Nessus 3 will be faster and contain various other
improvements. They promise to maintain GPL Nessus 2 for a while, but
I wouldn't count on that lasting long.

I am not taking a position on this move, but I do feel it is worth
noting for the many Nessus users on this list. Tenable argues that
this move is necessary to further improve Nessus and/or make more
money. Perhaps so, but the Nmap Project has no plans to follow suit.
Nmap has been GPL since its creation more than 8 years ago and I am
happy with that license.

When asked why they are making this change, Renaud replied to the
Nessus list today that open source hasn't really worked for Nessus
because "virtually nobody has ever contributed anything to improve the
scanning _engine_ over the last 6 years." This may be the most
important and useful point we can take from this change. Open source
really is a two-way street. The only way we (open source projects)
can seriously compete with projects staffed by dozens or hundreds of
paid full time developers is by having hundreds or thousands of
volunteers each contributing a little bit part time. So if you are a
heavy user of open source software, please think about how you can
help out. Here are some ideas:

o If you are feeling ambitious, write and distribute your own little
program to solve a problem you are having or otherwise makes your
life easier. It doesn't have to be anything big or fancy at first.
Nmap started out as a little 2,000-line utility published in Phrack
magazine. Post your creation to Freshmeat, or to nmap-dev if it
relates to Nmap in some way. Hmm, I think there is a current vacuum
in the open source vulnerability scanner field :).

o Or take a more active coding role for an existing open source
project. In the Nmap world, former Google SoC students are
developing three promising projects: NmapGUI and UMIT are new GUIs
and results viewers for large Nmap scans, and Ncat is a powerful
reinterpretation of the venerable Netcat. Working code for all
three of these is available if you join the Nmap-dev list
(http://cgi.insecure.org/mailman/listinfo/nmap-dev) and I'm sure the
respective authors (Ole Morten Grodaas, Adriano Monteiro, and Chris
Gibson) would appreciate help, feedback, and testing.

o Find a bug in some open source software? Try to reproduce it with
the latest version of the software and do some web searching to see
if it is already known/fixed. If not, report it with full details
about how to reproduce it and the platform and software version of
the software you are running. It is even better if you can submit a
patch which fixes the problem.

o Join the relevant mailing lists for the project and help out new
users. Maybe you can write or translate some documentation, such as a
tutorial for using the product or a HOWTO for using it to solve a
common need.

o The Nmap Project does not accept financial donations, but many other
projects do. If some little project does exactly what you need and
saves you half a day of work or makes it into your regular-usage
arsenal of tools, consider kicking the author back $5 or $10. Not
only will it help defray costs of the project, but it shows the author
that users really appreciate his/her work and thus makes a newer
version more likely. Similarly, if you see an ad on the project
web site that interests you, click on it and spend a couple minutes
checking the product out.

o Spread the word! Commercial software houses pay to spread the word
about their product in magazines, web sites, TV, conferences, etc.
Open source projects such as Nmap can't. So if you find a project
useful, don't hesitate to post a link on your web page and mention it
(including the URL) on mailing list, newsgroup, and web forum posts.

Those are a few ideas, and I'm sure you can think of more based on
your experience, expertise, and available resources. Rather than mope
over the loss of open source Nessus, we can treat this as a call to
action and a reminder not to take valuable open source software such
as Ethereal, DSniff, Ettercap, gcc, emacs, apache, OpenBSD, and Linux
for granted.

Cheers,
Fyodor

PS: Here is the Nessus announcement:

Si a alguien le interesa, el anuncio oficial de Nessus se puede encontrar [Aqui]

Para todos aquellos frikis e informáticos que tienen que programar en C, aqui van unos utiles consejos. Podeis considerarlos como La Guia de Estilo DEFINITIVA.

How to program in C

1. Use lots of global variables.
2. Give them cryptic names such as: X27, a_gcl, or Horace.
3. Put everything in one large .h file.
4. Implement the entire project at once.
5. Use macros and #defines to emulate Pascal.
6. Assume the compiler takes care of all the little details you didn't quite understand.
7. Rewrite standard functions and give them your own obscure names.
8. Use obscure, proprietary, non-portable, compiled library packages so that you never have to move from the platform you love so well.
9. Use very descriptive comments like /* printf("Hello worldn"); */ before each function call.
10. REMEMBER - Carriage returns are for weenies. Tabs are for those who have not reached weenie-dom yet.
11. Include LOTS of inline assembly code.
12. "User Interfaces" are for morons. "Users" have no business interfacing with a professional product like yours.
13. If you are forced to comment your code (in English), then borrow comments from somebody else's code and sprinkle them throughout yours. It's quick, easy, and fun to watch people's expressions as they try to figure it out.
14. Remember to define as many pre-processor symbols as possible in terms of already defined symbols. This is considered 'efficient use of code'.

How to debug a C program

1. If at all possible, don't. Let someone else do it.
2. Change majors.
3. Insert/remove blank lines at random spots, re-compile, and execute.
4. Throw holy water on the terminal.
5. Dial 911 and scream.
6. There is rumor that "printf" is useful, but this is probably unfounded.
7. Port everything to CP/M.
8. If it still doesn't work, re-write it in assembler. This won't fix the bug, but it will make sure no one else finds it and makes you look bad.
9. Since you got it to compile, the problem must be in the Other Guys Code.
10. If it's all your code then the problem MUST be in those unreliable Standard Libraries. See '1'.
11. Claim the bug reports are vicious lies meant to tarnish your sterling reputation as a 'C' programmer (well aren't they ?). After all, those who wrote the reports couldn't even read your code. How could they possibly know if there was a bug or not?
12. If they could read your code, review "How to program in C", above.
13. Claim that there wouldn't be a problem if this stingy Company/School/Wife/etc would spring for a copy of C++.

Leyendo a TopoPardo, me encuentro con un trozo del último libro de David Bravo "Copia este libro". No os perdais la pregunta 8 juasjuas...

Siguiendo la interpretación que hace la industria del artículo 270 del Código Penal, elija cuál es la acción considerada de mayor gravedad:

PREGUNTA 1
a.- Juan fotocopia una página de un libro.
b.- Juan le da un par de puñetazos a su amigo por recomendarle ir a ver la película "Los Ángeles de Charlie".
RESPUESTA: La acción más grave desde un punto de vista penal sería la "a" puesto que la reproducción, incluso parcial, sería un delito con pena de 6 meses a dos años de prisión y multa de 12 a 24 meses. Los puñetazos, si no precisaron una asistencia médica o quirúrgica, serían tan solo una falta en virtud de lo dispuesto en el artículo 617 en relación con el 147 del Código Penal.

PREGUNTA 2
a.- Ocho personas se intercambian copias de su música favorita.
b.- Ocho personas participan en una riña tumultuosa utilizando medios o instrumentos que pueden poner en peligro sus vidas o su integridad física.
RESPUESTA: Es menos grave participar en una pelea que participar en el intercambio de compactos. Participar en una riña tumultuosa tiene una pena de tres meses a un año (art. 154 del Código Penal) y el intercambio tendría una pena de 6 meses a 2 años (art. 270 del Código Penal). Si algún día te ves obligado a elegir entre participar en un intercambio de copias de CDs o participar en una pelea masiva, escoge siempre la segunda opción, que es obviamente menos reprobable.

PREGUNTA 3
a.- Juan copia la última película de su director favorito de un DVD que le presta su secretaria Susana.
b.- Juan, aprovechando su superioridad jerárquica en el trabajo, acosa sexualmente a Susana.
RESPUESTA: El acoso sexual tendría menos pena según el artículo 184.2 CP.

PREGUNTA 4
a.- Pedro y Susana van a un colegio y distribuyen entre los alumnos de preescolar copias de películas educativas de dibujos animados protegidas por copyright y sin autorización de los autores.
b.- Pedro y Susana van a un colegio y distribuyen entre los alumnos de preescolar películas pornográficas protagonizadas y creadas por la pareja.
RESPUESTA: La acción menos grave es la de distribuir material pornográfico a menores según el artículo 186 del C.P. La distribución de copias de material con copyright sería un delito al existir un lucro consistente en el ahorro conseguido por eludir el pago de los originales cuyas copias han sido objeto de distribución.

PREGUNTA 5
a.- Alfonso se descarga una canción de Internet.
b.- Alfonso decide que prefiere el disco original y va a El Corte Inglés a hurtarlo. Una vez allí, y para no dar dos viajes, opta por llevarse toda una discografía. La suma de lo hurtado no supera los 400 euros.
RESPUESTA: La descarga de la canción sería un delito con pena de 6 meses a dos años. El hurto de la discografía en El Corte Inglés ni siquiera sería un delito sino una simple falta (art. 623.1 CP).

PREGUNTA 6
a.- Alfonso se descarga una canción de Internet.
b.- Alfonso va a hurtar a El Corte Inglés y, como se la va la mano, se lleva cincuenta compactos por valor global de 1.000 euros.
RESPUESTA: Seguiría siendo más grave la descarga de Internet. El hurto sería un delito porque supera los 400 euros, pero sería de menor pena que la descarga (artículo 234 C.P.).

PREGUNTA 7
a.- Sergio, en el pleno uso de sus facultades mentales, se descarga una canción de Malena Gracia.
b.- Sergio, en un descuido de Malena Gracia, se lleva su coche devolviéndolo 40 horas después.
RESPUESTA: Sería más grave la descarga. El hurto de uso de vehículo tiene menos pena a tenor del artículo 244.1 del Código Penal.

PREGUNTA 8
a.- Pedro se graba la película El Resplandor del VHS de su amigo.
b.- Pedro, irritado por el doblaje de la película, amenaza de forma leve a Verónica Forqué exigiéndole que no vuelva a hacerlo nunca más. Pedro usó un arma en la amenaza.
RESPUESTA: La copia sería un delito y la amenaza, incluso con un arma, una simple falta (620.1 C.P).

PREGUNTA 9
a.- Ramón, que es un bromista, le copia a su amigo el último disco de Andy y Lucas diciéndole que es el "Kill'em All" de Metallica.
b.- Ramón, que es un bromista, deja una jeringuilla infectada de SIDA en un parque público.
RESPUESTA: La segunda broma sería menos grave a tenor del artículo 630 del Código Penal.

[Extraido de "Copia este libro" de David Bravo]

Leo en DailyCosas "ciertas verdades que un programador que quiera tener la conciencia tranquila debe repasar y asumir como verdades absolutas para poder desarrollar correctamente sus labores."

[Versión Original] [ Traducción ]

This page contains a number of important programming truths that every budding programmer should know about. These truths are self-evident, and need no explanations.

If it compiles, it works.

If it compiles, it's correct.

If it runs, it doesn't have any bugs.

If it doesn't have any immediately obvious bugs, it's perfect.

If a bug doesn't show, it doesn't exist.

If it seems to work, it works.

Doing something right is easy. Avoiding errors only takes a bit of concentration.

The shorter the source code, the faster the program.

It's obvious how to optimize a program.

Prorammers don't make mistakes.

Run-time errors don't occur.

Users don't make mistakes.

I don't make mistakes.

Errors of any kind are rare.

Error handling can be done in version 2.

It's OK to crash on bad input.

It's OK to give incorrect output on bad input.

Portability isn't useful.

All the world's a VAX. Or, these days, an MS-DOS box

The length of the feature list is important.

Speed is good, features are better.

Slowness can be fixed in hardware.

The bigger a program is, the better it is.

Random changes to a program fix bugs.

Testing takes only a short while.

Finding bugs is easy. Fixing bugs is trivial.

Bug-fixes don't need to be tested.

Trivial changes of any kind don't need to be tested.

The first approach, idea, or version is always the best.

A 1% crash rate is actually pretty darn good.

Code is self-evident. Comments aren't needed.

Comments are meant for people other than the original author of the code.

Undocumented features are fun and useful.

It can always be fixed in the next version.

Surprised users are happy users.

Demonstrating for clients is the best debugging method.

[Vía DailyCosas!]

No son frikis, se les puede llamar techies y son personas que tienen un enorme y en ocasiones obsesivo, interés por la tecnología, en particular por los ordenadores. Un ejemplo lo teneis en la foto de la izquierda, correspondiente a Thomas Scovell, que se tatuó una curiosa version del famoso "Hello World".

El tatuaje tiene su historia. Resulta que Scovell participó en un concurso internacional al programa más ilegible escrito en C, el "The International Obfuscated C Code Contest" (http://www.es.ioccc.org/) que lleva celebrandose desde 1984, ganandolo ese mismo año con la siguiente "obra maestra":

Otra iniciativa curiosa es HanoiMania, que contiene implementaciones del famoso algoritmo de las Torres de Hanoi en casi un centenar de lenguajes de programacion diferentes.

[Más info en DailyCosas]