.flac
, toutes mes photographies (.nef
), toutes les données
relatives à un incident de sécurité, mes ebooks, mes fichiers on-the-go, etc. Bref tout, je pourrais
en parler pendant des heures, mais je me limiterai à en parler dans un futur post.
Je viens de pousser sur github un projet nommé SSTIC-Annex. C’est la compilation de tous les articles, slides, videos de SSTIC dans un seul repository git-annex.
Plutôt qu’un long discours, un exemple d’utilisation :
1 2 3 4 5 6 7 8 |
|
Pour tous ceux qui sont constamment en déplacement, jetez un oeil à git-annex, cela changera votre manière de travailler.
]]>Combien de temps allons-nous devoir continuer à utiliser cette boue ? Debian nous force à l’utiliser à cause du choix de licence des développeurs d’OpenSSL.
Pourtant, le constat est simple : La sécurité de GnuTLS n’est pas au niveau d’OpenSSL (niveau qui n’est pourtant pas élevé, mais faut bien avouer que le protocole SSL est complexe).
Maintenant, quelles sont les options ?
Pousser chaque développeur d’application à faire une exception OpenSSL
Individuellement, recompiler ses paquets avec le support d’OpenSSL
Demander aux développeurs d’OpenSSL de changer pour une licence autorisant le linkage avec une application GPL.
Seule la première option semble possible, mais demanderait un gros travail à fournir. Qui monte un which-software-is-still-not-openssl-compliant.org pour faire pression sur tous les logiciels important n’ayant pas une exception de licence ?
Update quelque temps après Heartbleed : CVE-2014-0160 ne change rien à mon propos. Je ne dis pas qu’OpenSSL est le projet parfait avec une sécurité incroyable. Il faut juste se rendre compte qu’il y beaucoup plus d’audits effectués sur OpenSSL que GnuTLS et que si Debian utilise GnuTLS, c’est uniquement pour des raisons politiques et non techniques.
]]>Les plus :
Uniformisation du mode de développement : Lorsqu’un projet est sur GH, sauf exception comme torvalds/linux, la soumission d’un patch est naturelle via une pull-request, il n’y a plus besoin de trouver l’URL du repository des sources, écrire son patch, s’inscrire à la liste des développeurs pour poster son patch et attendre.
C’est un avantage indéniable.
Dans cette uniformisation, on a également structuré les développeurs : ils ont enfin repris goût à écrire des README, ils disposent d’un bug-tracker qui n’a rien à envier aux logiciels “professionnels” et un wiki est à disposition si besoin. En gros, il n’y a plus l’excuse du “ah oué il faut que je monte un bugzilla dès que j’aurai acheté plus de crédit CPU à ma VM”.
Les projets sur GH sont devenus participatifs et non plus en lecture seule comme avant.
La création d’un nouveau projet est l’histoire de 2 minutes chrono.
Les moins :
GH, malgré lui, a tué l’ecosystème de git. À part Joey Hess qui continue de développer des outils (géniaux) autour de git, tout le monde a abandonné l’idée d’écrire des logiciels facilitant la vie des utilisateurs.
Par exemple, parlons de l’hébergement de projets, y a quoi ? Gitlab (et ses vulns triviales) ? Gitblit ? Gitorious (qui a son propre exploit dans Metasploit ?
Gitolite ou gitosis (abandonné par Debian) sont incomplets : déjà, la création de repository est soit dépendante d’un administrateur disponible, soit nécessite de donner trop de privilèges aux utilisateurs. Ensuite le transport SSH est pas pratique en déploiement d’entreprise :
impossible d’utiliser des OTP (notez que pour ce point, on peut aussi utiliser des clefs signées sur une machine de confiance avec une durée de validité minime.)
ssh ne supporte pas vraiment de traverser les proxy (même si c’est possible via corkskrew)
GH est une boîte comme les autres. Elle doit suivre les loisWpressions politiques lorsqu’elle recoit des DMCA Takedowns abusifs. Elle doit également subir les lois liberticides US.
Question naïve mais… Est-ce que GH fait des backups ?
]]>For its part, Getty set up a single network connecting the 11 Olympic venues. Mainardis estimates that Getty lay down some 22 kilometers of ethernet cable so that most of its 37 photographers could be directly wired in.
…
The second a photographer fires the shutter on a camera, the resulting image—a high quality JPEG, not an uncompressed RAW file—is transported by ethernet to Getty’s central editing office in about 1.5 seconds. There, a team of three editors processes the photo. The first selects the best image and crops it for composition; the second editor color corrects; and the third adds metadata. The whole editing process is done in 30-40 seconds. Once the last editor is done, the image is blasted to the world. It takes about 90 seconds for the images to travel over redundant 100 Mbit/s dedicated lines to Getty’s data servers in the the United States.
…
Photos delivered to clients at an average clip of three minutes or less.
Combien de temps vais-je devoir mettre ?
AAAAAAAAAAAAAAAAAARG. Y a pas des services où on leur envoit un CD et il le pousse quelque part ?
]]>Résilient au cambriolage/incendie/copine hystérique détruisant tout. Donc je ne peux pas me reposer uniquement sur mon NAS. Par contre, je peux accéder à une Dedibox que je maîtrise.
Incrémental pour la vie : Ce qui discrédite immédiatement duplicity. Ce dernier n’appréciant pas d’avoir des chaînes incrémentales à rallonge.
PRISM-proof (si cela veut dire quelque chose…) donc chiffrement obligatoire des données et des méta-données. Ici, c’est bup qui sort de la course, j’ai bien lu qu’il y avait des hacks implémentant le chiffrement, mais si c’est aussi simple, pourquoi ce n’est pas mainstream ? On parle de sauvegarde là, pas d’un logiciel de création de GIF animés.
Donc en fait, la seule solution utilisable pour de vrai reste tarsnap qui reste une solution chère ($0.30 / GB.month) mais bigremment efficace.
La seule alternative qui voit le bout de son nez, c’est l’utilisation de bup couplé à Tahoe-Lafs (via FUSE). Mais pour que ça soit utilisable, il me faudrait un petit cercle d’amis de confiance prêt à tenter l’expérience ? Qui veut essayer ?
]]>Nan. Finalement, l’appareil avec un disque de 64 Go de musique est une meilleure idée. Mais à part l’iPod, je ne vois pas beaucoup de concurrent…
]]>Ce qui signifie qu’on peut mettre plein de symboles à la con : style ✈ pour le dossier contenant tous les messages de déplacement, ou Pile of poo pour les spams…
]]>The Event Log service uses memory-mapped files, and it runs as one of the services under the Services.exe process as Eventlog.dll. When files are loaded in this way, the entire file is loaded into the computer’s memory. All of the current versions of Windows have an architectural limitation with regard to memory-mapped files: no process can have more than 1 GB of memory-mapped files in total. This limitation means that all of the services that run under the Services.exe process must share the 1-GB pool.
Because of these limitations [..] we have verified that the practical limit is approximately 300 megabytes (MBs) on most 32-bit servers running Windows Server 2003 that is, 300 MBs for all of the event logs combined
Et vous savez ce qu’est le pire ? C’est que Windows est censé être la solution pour les entreprises, les déploiements massifs, le paradis des sysadmins. Mouarf.
Ca me donne envie de pleurer parfois.
]]>Lors de mon exode de Google, j’étais passé sur une Kimsufi de chez OVH et pas sur l’équivalent de chez Dedibox uniquement parce que le disque était bien plus important chez OVH.
Mais ça me plaisait pas terrible : la console d’administration d’OVH vraiment pas terrible (en plus du fait que j’ai réussi à payer la facture de quelqu’un d’autre sans toucher à quoi que ce soit… J’ai donc pû profiter du “super” service client d’OVH si réputé, ben cela n’a pas été la joie).
Alors je scrutais le compte twitter d’Arnaud Bermingham car ils sortent de temps des “ventes privées”.
Là, je suis tombé sur un HP DL120G7 avec :
Le tout pour 19.99 EUR/mois HT. Donc j’ai dit banco! Longue vie à pouic !
Au tour de la configuration maintenant, que choisir ?
Au début, j’étais parti pour cloisonner chaque service dans un vserver, je me disais que depuis le temps, ça a avait dû faire vachement de progrès en stabilité puisque certaines entités l’utilisent intensivement… Ou pas. Dès les premiers tests, c’est parti en cacahuète avec la découverte d’un bug et d’un leak donc je suis resté sur ma lançée et essayer LXC, le truc mainstream depuis plusieurs années. Pas mieux, le noyau plante immédiatement après quelques bind-mount sans aucune trace de logs. Ok… J’ai abandonné et et installer tout ça comme d’habitude en me reposant sur l’isolation offerte par chroot+grsecurity.
Puis… rien pendant 2 mois. Le temps que je me motive à vraiment tout migrer. Le plus chiant a été la migration de Gmail et sa fonctionnalité d’archivage.
Pour ceux qui ne connaissent pas le fonctionnement des archives Gmail, plutôt que de supprimer les mails, vous les archivez : en gros, ça fait passer votre mail de votre INBOX dans un dossier appelé “All mails”. Comme son nom l’indique, ce dossier contient ‘’vraiment tous’‘ les mails : un mail dans le dossier “Notifications” est également présent dans “All mails”.
Ce mode de fonctionnement marche bien dans le monde Google, mais en IMAP, c’est un peu chiant. Donc il a fallu jouer avec les filtres pour déplacer tous les ancien mails d’INBOX archivés dans “All mails” et des les déplacer dans des dossiers “Archives.$YEAR”.
Exemple de filtre utilisé pour faire le dossier Archives.2006 :
-{label:Forums label:Social Updates label:sstic label:Notifications \
label:Promotions label:Inscriptions label:LeMonde} \
before:2007/01/01 after:2006/01/01
Ainsi, à la fin, il n’y a plus qu’à dupliquer toute l’arborescence IMAP entre mon serveur et gmail en ignorant “All mails”.
J’avais comme souvenir que tous les serveurs Jabber existant étaient des grosses bouses énormes (Java, Erlang, etc.) et pas du tout dans un esprit de simplicité. Mais il existe aujourd’hui prosody, un serveur écrit en LUA minimaliste mais vu mon usage, c’est largement suffisant !
Vous pouvez à nouveau m’ajouter dans votre roaster, mon JID est
nico@chdir.org
, si en plus vous avez le module OTR activé, ça me va
tout autant.
Pour le calendrier, je suis parti sur Radicale, un serveur simplissime CalDAV et CardDAV que j’accède à l’aide de Mozilla Lightning et de mon client Mac.
]]>Un email est envoyé à l’adresse email de l’identifiant avec un URL unique à cliquer. Cet URL comporte 21 caractères générés au hasard. … Les 2 fonctions random sur 3 que nous avons utilisé dans ce code ne générait pas une vraie chaîne au hasard.
C’est fail. Faut-il lire “fonctions random” comme “fonctions de hashage” où en
fait, token = hash(ip_addr) + hash(username) + hash(timestamp)
?
Là où c’est encore plus fail, c’est que bitcoin-central n’utilisait pas du chiffrement de disque (luks). Ok, c’est chiant que les serveurs ne soient pas capable de démarrer tout seul (car il faut donner la passphrase au boot) mais vu l’argent en jeux, ça aurait valu le coup…
]]>