6120 links
  • GuiGui's Show
  • Home
  • Login
  • RSS Feed
  • ATOM Feed
  • Tag cloud
  • Picture wall
  • Daily
Links per page: 20 50 100
◄Older  
page 227 / 306
Newer►
  • AS Rank: AS Ranking - CAIDA : http://as-rank.caida.org
    Intéressant classement. Pour une vue IPv6, il faut regarder dans la liste « dataset » à droite. Données basées sur l'infra CAIDA + celles du projet Route Views + celle du projet RIPEstat + celles de Potaroo.net (les Cidr report sur Nanog).

    Après, un classement en nombre d'IP/AS annoncées/transitées, ça ne fait pas tout, y'a aussi le relationnel, la qualité du support quand quelque chose chie, la qualité des interconnexions (nan parce qu'être un *vrai* tier 1 low cost, en supposant que ça soit vraiment le cas avec des interconnexions médiocres qui saturent de partout, boarf quoi), les gue-guerres commerciales (genre Cogent est 2e en v6 alors qu'on ne peut joindre HE v6 depuis Cogent alors que HE fournit une bonne partie des accès Internet v6 via des tunnels 6in4, ce qui est handicapant pour un opérateur à faible budget qui débute sur Cogent only).

    Via FRnOG.
    December 4, 2015 at 7:38:44 PM UTC - permalink - http://as-rank.caida.org/?mode0=as-ranking&n=50&ranksort=1
  • lxc does not start container when cgmanager is in use · Issue #477 · lxc/lxc · GitHub
    Jessie sans systemd en hôte + wheezy en guest = « Could not find writable mount point for cgroup hierarchy 9 while trying to create cgroup. »

    Solution :
    « According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773421 it was a debian bug, because lxc there was build without cgmanager support. So if you use unstable\testing just install the latest package, on stable use the way mentioned above [ apt-get install cgroupfs-mount ]. »
    December 4, 2015 at 7:09:26 PM UTC - permalink - https://github.com/lxc/lxc/issues/477
  • Mettre à jour ses conteneurs LXC à Debian Jessie
    Il y a deux choses : mettre à jour l'hôte et donc les binaires LXC et mettre à jour le contenu des conteneurs.

    Si tu mets à jour ton hôte sans mettre à jour tes conteneurs, il y a quand même une étape à faire : l'autostart ne fonctionne plus avec le mécanisme de liens symboliques dans /etc/lxc/auto pointant vers les confs dans /var/lib/lxc/<nom_lxc>/config mais avec une option « lxc.start.auto = 1 » dans le config de chaque LXC qui doit être démarré au boot de l'hôte. Il faut donc l'ajouter dans chaque conteneur puis « rm -rf /etc/lxc/auto ».

    Si tu mets à jour les conteneurs sans mettre à jour l'hôte (qui reste donc à Wheezy), t'es obligé de virer systemd du conteneur car soit t'as aucun message d'erreur, soit « Failed to mount tmpfs at /dev/shm: No such file or directory » au lancement du conteneur. Voir http://shaarli.guiguishow.info/?NGJVow . Toutes les méthodes pour contourner ce problème (voir https://blog.iwakd.de/lxc-jessie-under-wheezy, par exemple), monter les cgroups utilisés par systemd hors du conteneur ou utiliser les options « lxc.autodev » et « lxc.kmsg » ne fonctionne pas avec la version de LXC packagée dans Wheezy.

    Une autre piste est d'utiliser wheezy-backports dont la version actuelle (1.0.6-6) de LXC, qui inclus un fix de la version 1.0.7 upstream (voir /usr/share/doc/lxc/changelog.Debian.gz « Adding patch from lxc 1.0.7 to make lxc-debian work with systemd »), permet de lancer des conteneurs Jessie+systemd sans problèmes. Mais, pour ceux et celles qui le faisait avant de mettre à jour, il n'est plus possible de supprimer la capability sys_admin (voir plus bas) car le bout de conf nécessaire « lxc.cgroup.use = @all » n'est pas implémenté. Il y aura le problème du spawn des tty à résoudre, voir plus bas.

    Si tu mets à jour les conteneurs à Jessie sur un hôte Jessie, il y a le mécanisme d'autostart qui change de base (voir plus haut) et si tu veux conserver systemd à l'intérieur des conteneurs, il y a plusieurs choses à changer (voir https://wiki.debian.org/fr/LXC#Incompatibilit.2BAOk-s_avec_systemd que j'ai déjà shaarlié d'ailleurs) :
        * options « lxc.autodev » et « lxc.kmsg »
        * spawn des tty
        * désactiver totalement les services udev et systemd-udevd
        * bonus : désactiver la capability sys_admin

    Pour les options « lxc.autodev » et « lxc.kmsg », c'est simple, elles sont déjà intégrées dans un template dans /usr/share/lxc/config/debian.common.conf. Il suffit d'inclure ce fichier dans la config de chaque conteneur Jessie : « lxc.include = /usr/share/lxc/config/debian.common.conf ». C'est aussi l'occassion de mettre un coup de peigne dans les fichiers de conf de tes conteneurs puisque beaucoup de choses (capabilities supprimées, mount de /proc et /sys, nombre de consoles, limites sur les cgroups,...) ont été factorisées dans ce fichier. Normalement, dans le fichier de conf de chaque conteneur, il doit rester uniquement rootfs, name, arch, points de montage spécifiques (lxc.mount et lxc.mount.entry), config réseau et flag de démarrage au boot de l'hôte. Notons que leur absence ne pas problème sur toutes les infras : j'ai eu le problème sur une infra et pas sur une autre. Les deux en lxc 1.0.6-6+deb8u1 au moment de la migration.

    Pour un spawn correct des tty, j'ai déjà tout noté dans un autre shaarli : http://shaarli.guiguishow.info/?qkFhrQ .

    La désactivation des services udev et systemd-udevd ne semble pas nécessaire (j'ai des LXC de test qui tournent à merveille depuis plusieurs semaines malgrè la non-désactivation de ces services...), elle n'est pas faite par défaut lors de la création d'un nouveau conteneur mais si tu veux la faire quand même : sudo systemctl mask udev.service systemd-udevd.service

    J'avais pour habitude de virer la capability sys_admin de mes conteneurs. L'ennui, c'est que systemd a besoin de monter des trucs, les cgroups, entre autres alors qu'il faut la capability sys_admin pour utiliser mount. Pour résoudre ce problème, il faut (voir https://github.com/debops/ansible-lxc/issues/15) :
        * Autoriser l'usage de toutes les classes de cgroups avec « lxc.cgroup.use = @all » dans /etc/lxc/lxc.conf (qui peut ne pas exister et qu'il faut donc créer) afin d'éviter l'erreur « Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted »

        * Virer la capability sys_admin en ajoutant « lxc.cap.drop = sys_admin » dans la conf' de chaque conteneur.

        * Afin d'éviter l'erreur « Failed to mount tmpfs at /dev/shm: Operation not permitted », il faut monter les fs nécessaires au boot, en dehors du conteneur en mettant tout ce qui suit dans /var/lib/lxc/<nom_conteneur>/fstab (auquel on fait référence dans la conf de chaque conteneur avec « lxc.mount = /var/lib/lxc/<nom_conteneur>/fstab » qui est config auto dans les conteneurs fraîchement créés) :
    « lxc.mount.entry = tmpfs dev/shm tmpfs rw,nosuid,nodev,create=dir 0 0
    lxc.mount.entry = tmpfs run tmpfs rw,nosuid,nodev,mode=755,create=dir 0 0
    lxc.mount.entry = tmpfs run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k,create=dir 0 0
    lxc.mount.entry = debugfs sys/kernel/debug debugfs rw,relatime 0 0
    lxc.mount.entry = mqueue dev/mqueue mqueue rw,relatime,create=dir 0 0
    lxc.mount.entry = hugetlbfs dev/hugepages hugetlbfs rw,relatime,create=dir 0 0 »

    Comme les items 2 et 3 doivent être ajoutés à la conf' de chaque LXC et que la répétition de bouts de conf', c'est mal, on préférera faire un template dans /etc/lxc/drop_sys_admin_cap.conf par exemple et l'inclure dans chaque config de LXC. Son contenu est bêtement la somme des deux derniers tirets.

    Et si tu veux monter un tmpfs ou autre uniquement pour un conteneur, t'auras compris que sa place est dans /var/lib/lxc/<nom_conteneur>/fstab. Pour la syntaxe, voici un exemple de ligne : « tmpfs   media/test      tmpfs   size=100M,rw    0       0 ». Le point de montage est relatif à la racine du conteneur donc il ne faut pas de « / » au début. Donc pas de /media/test, par exemple.

    Si tu ajoutes une nouvelle ligne dans le /etc/fstab du conteneur, elle sera transformée en unit systemd et le prochain reboot se passera mal : mount échouera : « mount: permission denied » donc l'unit échouera : « media-test.mount mount process exited, code=exited status=32 Failed to mount /media/test. Unit media-test.mount entered failed state. » donc le boot se finira dans le shell de maintenance : « [FAILED] Failed to mount /media/test. See 'systemctl status media-test.mount' for details. [DEPEND] Dependency failed for Local File Systems [...] Give root password for maintenance ».


    Notons qu'avec la version de LXC présente dans wheezy-backports et Jessie (v1.0.6-6), seul le spawn des tty et le drop de la cap sys_admin en bonus sont à étudier : le reste fonctionne out-of-box (même si les options ne sont pas définies...). Même pour des conteneurs créés sous wheezy et mis à jour depuis wheezy.


    Synthèse :
        * Si tu màj uniquement l'hôte, t'as uniquement le nouveau mécanisme d'autostart à prendre en compte ;

        * Si tu màj uniquement les conteneurs :
            * Les conteneurs ne booteront plus sauf à utiliser la version de LXC présente dans les backports ;
            * Tu ne peux plus retirer la capability sys_admin si tu le faisais ;
            * Tu devras régler le problème de spawn des tty ;

        * Si tu màj hôte et conteneurs :
            * Tu as le nouveau mécanisme d'autostart à prendre en compte ;
            * Tu devras régler le problème de spawn des tty ;
            * Il y a quelques manipulations supplémentaires à faire pour retirer la capabilitie sys_admin ;
            * Il se peut que t'aies besoin de poser les paramètres « lxc.autodev » et « lxc.kmsg ».
    December 3, 2015 at 8:09:44 PM UTC - permalink - http://shaarli.guiguishow.info/?82j-Ow
  • Systemd-logind dans un LXC : un avant-goût de l'enfer
    À lire par ceux et celles qui vont mettre à jour leur LXC Debian à Jessie ou qui vont créer de nouveaux LXC Debian qui seront donc avec Jessie+systemd par défaut.

    Par défaut,  le comportement documenté de systemd est de lancer un agetty sur tty1 et de traiter tous les autres tty à la demande (genre si tu crtl+alt+f3 pouf, ça spawn un agetty sur tty3 et si tu fais rien bah y'a que tty1 :D). Le nombre max de tty est défini dans /etc/systemd/logind.conf (et plus inittab comme avant) et vaut 6 par défaut.

    Ce mécanisme de spawn automatique repose sur dbus. Heureusement, s'il n'est pas installé ou qu'une erreur est survenue durant son lancement, /lib/systemd/system/getty-static.service prévoit un mécanisme de secours en spawnant le nombre de tty défini dans /etc/systemd/logind.conf quoi qu'il arrive.

    Par défaut, dbus n'est pas installé dans un LXC donc on a bien 6 tty lancés au boot. Or, un LXC n'a que 4 tty (/dev/tty1-4) par défaut. Donc les agetty sur tty5 et tty6 hurlent à la mort toutes les 5 ou 10 secondes dans les logs (auth.log ou journalctl -xn) :
    « déc. 02 14:28:42 test agetty[155]: /dev/tty6: No such file or directory
    déc. 02 14:28:42 test agetty[154]: /dev/tty5: No such file or directory »

    Il est hors de question que je me fasse pourrir mes logs comme ça. Sachant que dbus est obligatoire pour l'autocomplétion et la bonne exécution des commandes systemctl, on l'installe. Si votre LXC est un LXC créé à l'instant, vous pouvez reboot. Si c'est un LXC mis à jour depuis wheezy, ne rebootez pas encore. :)

    En temps normal, /lib/systemd/system/getty@.service est utilisé comme template pour instancier les getty à la demande. Sauf qu'il précise « ConditionPathExists=/dev/tty0 » c'est-à-dire que cette unit doit être exécutée uniquement si /dev/tty0 est présent. C'est le cas par défaut... mais pas dans un LXC. Donc les tty ne seront pas spawnées donc un lxc-console ne donnera pas un prompt de login, juste « Connected to tty 1 ». De quelles tty je parle ? Celles définies dans /etc/systemd/system/getty.target.wants/ (qui sont des liens symboliques vers /lib/systemd/system/getty@.service).

    Pourtant, j'ai dit plus haut que, sur un LXC créé from scratch avec Jessie, ça fonctionnait de base ? Oui, car le template LXC crée une copie de /lib/systemd/system/getty@.service dans /etc/systemd/system/getty@.service dans laquelle « ConditionPathExists=/dev/tty0 » est commentée. Et c'est ce fichier qui est pointé par les units dans /etc/systemd/system/getty.target.wants/, ce qui fait que ça fonctionne.

    Qui crée les fichiers dans /etc/systemd/system/getty.target.wants/ ? systemd-getty-generator (/lib/systemd/system-generators/systemd-getty-generator). Quand ? « systemd will execute those binaries very early at bootup and at configuration reload time -- before the unit files are loaded. » (https://wiki.freedesktop.org/www/Software/systemd/Generators/). Dans un LXC, ni un boot, ni un systemctl daemon-reload  n'exécute le generator... En réalité, c'est le template LXC Debian qui génère les units à la création du LXC :
    « ( cd ${rootfs}/etc/systemd/system/getty.target.wants
            for i in 1 2 3 4 ; do ln -sf ../getty\@.service getty@tty${i}.service; done ) »

    Donc, que faut-il faire sur un ancien LXC mis à jour depuis Wheezy ? Il faut copier /lib/systemd/system/getty@.service dans /etc/systemd/system/getty@.service en *commentant* « ConditionPathExists=/dev/tty0 » puis regénérer les units dans /etc/systemd/system/getty.target.wants/ : cd /etc/systemd/system/getty.target.wants/ && rm getty@tty*.service && for i in `ls /dev/tty[0-9]* | grep -o [[:digit:]]`; do ln -s ../getty@.service getty@tty${i}.service; done . Soit un reboot, soit systemctl daemon-reload && systemctl start getty@tty*.service et vous aurez le bon nombre de tty en attente de votre tentative de connexion.

    Il reste un dernier point à comprendre : pourquoi le spawn automatique ne fonctionne-t-il pas ? C'est une bonne question. Normalement, c'est /lib/systemd/system/autovt@.service qui s'occupe de ça comme l'indique le man logind.conf : « when switched to and are previously unused, "autovt" services are automatically spawned on. These services are instantiated from the template unit autovt@.service for the respective VT TTY name, for example, autovt@tty4.service. By default, autovt@.service is linked to getty@.service. In other words, login prompts are started dynamically as the user switches to unused virtual terminals. ». Par défaut, un tty est réservé et ne sera pas donné à un quelconque sous-sytème. Le numéro de tty est indiqué dans « ReserveVT= » dans /etc/systemd/logind.conf et vaut 6 par défaut. Même en décommentant « ConditionPathExists=/dev/tty0 » dans /lib/systemd/system/getty@.service pour tester, même en changeant le numéro du tty réservé, même en vérifiant que dbus et systemd-logind sont lancés sans erreur (systemctl status), rien à faire : le tty réservé n'a pas de prompt de login et aucun agetty n'est spawné quand on lxc-console sur tty2-4... Visiblement, les devs de LXC ont décidé de feinter avec la méthode présentée précédemment donc je vais faire pareil afin d'avoir une totale harmonisation entre mes LXC existants et mes futurs LXC, pas envie de me prendre la tête une fois de plus sur ce problème.

    Voici les ressources que je n'ai pas encore citées qui m'ont aidé à y voir plus clair :
        * https://wiki.archlinux.org/index.php/Systemd_FAQ#How_do_I_change_the_default_number_of_gettys.3F
        * https://lists.linuxcontainers.org/pipermail/lxc-devel/2013-May/004433.html
        * https://lists.linuxcontainers.org/pipermail/lxc-devel/2013-May/004433.html

    ÉDIT DU 03/12 À 10H10 : Quel intérêt d'avoir autant de tty dans un LXC ? Utile quand votre LXC perd sa connectivité réseau, et que votre connexion SSH avec l'hôte foire quand vous êtes en lxc-console car une nouvelle co SSH et un nouveau lxc-console vous mapperont sur un autre tty (et non, lxc-console -n <nom> -t 1 ne fonctionnera pas « lxc_container: console 1 invalid,busy or all consoles busy ». FIN DE L'ÉDIT.
    December 2, 2015 at 7:03:24 PM UTC - permalink - http://shaarli.guiguishow.info/?qkFhrQ
  • Conferences - Replicant
    Mes notes concernant le talk sur Replicant qui a eu lieu le 17 octobre 2015 à Brest. Les slides et l'enregistrement vidéo ne semblent pas être encore dispos en ligne. ÉDIT DU 05/12/2015 À 18h30 : les slides sont disponibles à l'adresse pointée par ce shaarli, et plus précisément : http://ftp-osl.osuosl.org/pub/replicant/conferences/brest-en-biens-communs-2015/replicant-systeme-exploitation-libre-pour-smartphones.pdf FIN DE L'ÉDIT.

    Je vous recommande vivement de lire ces notes (faute de mieux), on y apprend vraiment beaucoup sur les avancées du libre dans le monde mobile, sur ce qu'est (et n'est pas) Replicant. Très, très intéressant.

    Introduction par Benjamin Bayart :
    [NDLR : il manque environ 5-10 minutes dans mes notes, j'suis arrivé à la bourre...]

    Exemple du lecteur DVD de salon qui ne m'obéit pas : je ne peux pas zapper les pubs et les avertissements anti-piratage. Bizarrement, VLC y arrive. Ce n'est donc pas une difficulté technique mais un choix des fabricants de lecteurs DVD et des vendeurs de culture sur galette.

    Jusque-là, il n'y a pas de grands enjeux. Mais on a le même problème sur les ordiphones Apple/Android : ces systèmes ne sont pas conçus pour rendre service à l'utilisateur. Pour avoir le contrôle, il faut jailbreaker son téléphone... que l'on traduit par casser la prison.

    Les métadonnées (avec qui vous communiquez, quand, à quelle heure, pendant les horaires de taff ou en dehors, quelle durée, quelle fréquence, depuis où (géolocalisation)) sont très importantes et elles disent tout, pas besoin d'avoir le contenu des conversations / messages échangés. Exemple : deux personnes qui ne se parlent jamais et qui se mettent à échanger 15/20 messages par jour, tu sais que Cupidon est passé dans le coin. Facebook avait d'ailleurs fait une étude : deux personnes se rendent à une soirée (elles ont liké la soirée donc tu le sais), le lendemain elles deviennent amies sur FB, la fréquence de leurs échanges augmente jusqu'à un certain point puis leurs échanges s'arrêtent pendant 3 jours, précisément 3 jours... avant de recommencer. Cupidon again et les 3 jours, c'est le week-end que ces personnes ont passé ensemble. Comment le sait-on ? La géolocalisation de leur tél était identique.

    Sur un ordiphone, la géolocalisation par autrui, ce n'est pas le GPS, c'est l'opérateur : pour recevoir un appel, il faut que le réseau de l'opérateur puisse communiquer avec votre téléphone et donc savoir quelles sont les antennes les plus proches de votre téléphone. Pour y échapper, il suffit d'éteindre le téléphone, non ? Hé bah non car dans nos ordiphones modernes, il y a deux processeurs : le processeur qui fait tourner Android ou IOS et l'autre qui pilote toute la partie radio. Et ce dernier processeur se fait piloter par le réseau : configuration et instructions à exécuter comme indication de la modulation radio à utiliser, le signalement que la prochaine antenne ne sera pas sur la même fréquence,...

    Ça va même au-delà avec les fonctionnalités d'effacement du tél à distance. Ça signifie que le réseau est capable de donner l'ordre au processeur radio d'effacer tout le contenu géré habituellement par l'autre processeur. S'il peut effacer, il peut lire/écrire les données... Toutes les données du téléphone.

    Chiffrer son téléphone, c'est cool mais il faut saisir une passphrase... et le contrôleur qui gère le clavier peut l'intercepter et possiblement le transmettre (voir point précédent).

    Rooter son téléphone, c'est avoir le contrôle des applications installées/installables. Avec Cyanogenmod, toute la partie haute du noyau devient libre en plus mais les drivers ne le sont toujours pas. Replicant s'occupe des drivers. Il reste le problème du contrôle de la puce radio/baseband et des microcontrôleurs.

    Le logiciel libre, c'est la pérennité du code au-delà des sociétés commerciales qui coulent.


    Paul Kocialkowski :
    But : libérer toutes les couches : microcontrôleurs qui font des tâches indépendantes, microcodage du processeur,...

    Obsolescence : on met du temps à libérer, ce qui amène certaines personnes à se demander : est-ce que ça a un intérêt ? C'est sûr qu'on ne peut pas suivre le rythme de sortie de tous les ordiphones de toutes les marques.

    Pas toujours possible de remplacer les bouts proprios par du code libre :
        * Problématiques légales : reverse engineering autorisée en EU pour interopérabilité mais pas aux USA, par exemple ;

        * Manque de compétences/temps : le reverse engineering n'empêche pas d'avoir besoin de documentation car on ne peut pas tout deviner avec un binaire or, c'est justement ce qui fait défaut à moins de signer des clauses de confidentialité... ce qui va à l'encontre de l'objectif. Il faut ouvrir la bête, se connecter aux broches, reprogrammer la puce, ce n'est pas permis à tous/toutes ;

        * Contraintes matérielles : puces mémoire en lecture seule, le matos vérifie souvent le logiciel (signatures cryptographiques), risque de rendre le matos inopérant (ce qui représente un coût -> pas permis à toutes les bourses).


    Microcontrôleurs :
        * Audio et capteurs (accéléromètre par exemple) : on a du logiciel libre ;

        * WiFi, Bluetooth, GPS, USB récent : pas de logiciel libre disponible ou très très peu.

        * GPU : privateur mais la situation s'améliore : adreno pour Qualcomm, lima pour Mali, nouveau pour Nvidia ;

        * Caméra : on a des drivers libres mais sans l'accélération matérielle (voir point précédent) donc ça rame à mort ;

        * Modem / processeur de communication / baseband : processeur puissant (l'équivalent du proc' principal de nos ordiphones d'il y a 4/5 ans). Il peut parfois même être en charge du processeur principal (reboot, accès à la mémoire,...). On voit donc que le lien d'autorité est inversé. Backdoor sur les Samsung Galaxy (voir : http://code.paulk.fr/article0018/the-samsung-galaxy-back-door-was-bullshit-really) : le modem a accès à tous les fichiers. :D
            * À l'heure actuelle, on n'a pas de logiciel libre (osmocombb existe mais nécessite un ordinateur à côté et n'est pas abouti). Sans compter que nombre de modems vérifient les signatures...
            * Du coup, plutôt que de lutter contre le modem, on préfère l'isoler matériellement (limiter ce à quoi il a accès (RAM, autres microcontrôleurs,...) voire l'isoler électriquement pour l'éteindre à la demande). Ce n'est pas facile car il n'y a pas de documentation officielle et quand il y en a, on n'a aucune raison d'avoir confiance.


    Processus de boot :
        * Boot ROM : située dans la puce du proc', en lecture seule, on ne pourra pas la remplacer ;
        * Chargeur de démarrage : la boot ROM va souvent vérifier les signatures donc on ne peut pas souvent le remplacer. Coreboot/u-boot prennent en charge quelques plateformes ;
    Note : sur certaines plateformes, on a des boot ROM en deux versions : une qui vérifie et l'autre non. "HS ou GT" dans la référence de la puce


    Les drivers libres liés au noyau ne servent à rien car l'intelligence est déportée dans l'espace utilisateur (firmwares/blob proprios).

    Frameworks : couches d'abstraction qui permettent d'accéder au matériel. Firefox OS, c'est ça mais ils se tapent quand même des morceaux privateurs. Libre dans CyanogenMod/Omni.

    Au niveau des puces, il y a des sociétés commerciales sympas pour en produire, mais rien ne se fait en communautaire. On aura donc un problème de coût (à cause du faible volume d'unités produites) et de confiance envers la société qui produira les puces.

    Actuellement, il n'y a aucun modèle d'ordiphone totalement libre. Chacun doit donc définir la limite qu'il s'autorise. On peut choisir un ordiphone qui rend possible un chargeur de démarrage alternatif ou l'isolation du modem (c'est à dire que, pour commencer le modem ne doit pas être sur la même puce physique que le processeur principal).


    Android libre ou pas ?
        * Android c'est une famille d'OS hétéroclites. Au début, dev par Google avec très peu d'apports communautaires. Google finit par libérer dans Google Android Open Source Project (sauf les couches d'abstraction du matériel, faut pas rêver). Gros fabricants reçoivent ce code et font leur version pour supporter leurs ordiphones. De tout ça, rien n'est libéré.

        * Flicage de Google genre les ordiphones utilisés avec la version communautaire pinguent Google pour dire qu'un nouvel ordiphone vient d'être mis en service avec cette version communautaire.


    Replicant :
        * Petite chronologie :
            * 2008 : Debian GNU/Linux (openmoko) et Android. Libération partielle d'Android (framework principalement et applications de base)
            * 2010 : Naissance de Replicant : version fonctionnelle d'Android pour HTC Dream

        * Être totalement libre, sans utiliser ni recommander du logiciel privateur. Les fonctionnalités essentielles sont prises en charge pour chaque téléphone supportés ;

        * Comment ? Basé sur Google Android Open Source Project et Cyanogenmod pour le support d'ordiphones supplémentaires + on vire les trucs privateurs + f-droid comme logithèque + maintenance/mises à jour de sécurité + remplacer les couches d'abstraction du matériel par du code libre + réécrire des drivers audio/caméra/capteurs ;

        * On délaisse les micrologiciels et les microcontrôleurs types GPU ou baseband/modem car trop complexes, il faut faire les choses de manière incrémentale. Néanmoins, comme dit plus haut, les GPU sont pris en charge par d'autres communautés, par exemple donc on peut très bien imaginer la même chose pour les autres microcontrôleurs ;

        * 12 appareils pris en charge à l'heure actuelle. Pourquoi quasi tous sont des Sansumg Galaxy ?
            * Meilleure chance d'isolation du matériel. Les Nexus supportés sont, en revanche, bien mauvais pour une éventuelle isolation de la baseband...

            * Logiciel assez coopératif, moins de trucs à libérer. Radio Interface Layer implémentée depuis 2011. Sur d'autres ordiphones, on a des problèmes avec, par exemple le format de fichiers pour une caméra qui filme et photographie en même temps. Il est possible de faire passer des infos avec les dev' et Replicant (Paul raconte une très bonne expérience où un tech lui a expliqué, par mail, tout le fonctionnement d'une puce) pour peu qu'on ne s'adresse pas s'adresser aux services communication des sociétés commerciales mais c'est extrêmement rare : de manière générale, il y a très peu de coopération.
         
          Les tablettes n'ont pas de modem/baseband et sont donc plus faciles à prendre en charge.

        * Ce qu'il manque : accélération graphique (y compris encodage vidéo donc il manque la prise de vidéos), WiFi/Bluetooth/GPS (car ça doit être distribué avec le système et comme ce n'est pas libre, Replicant s'interdit de le faire.

        * Replicant c'est :
            * Principalement 1 dev', il y a assez peu de contributions externes (sauf en ce qui concerne la sécurité) ;
            * Exclusivement des dons (pas de subventions) ;

        * Futur de Replicant / comment contribuer :
            * Cyanogen Inc compte Microsoft en investisseur, peut-on avoir confiance ? Faudra-t-il que Replicant prenne son indépendance de Cyanogen ?

            * Aujourd'hui, Replicant se base sur Android 4.2, il faudra mettre à jour ;

            * Il est nécessaire d'écrire des applis libres même simples genre appareil photo et compagnie ;

            * Documentation : la traduire dans plusieurs langues mais aussi documenter/faire un inventaire des ordiphones : est-ce qu'on a une chance d'isoler le modem sur ce modèle, est-il possible d'y installer un chargeur de démarrage alternatif ? Paul a des infos sur des modèles d'ordiphones qu'il n'a pas encore eu le temps de mettre en ligne ;

            * Amélioration de la vie privée : virer tous les bouts de code connus pour avoir des failles de sécurité pas fixées comme le moteur de rendu web d'Android 4.2.


    Niveau matériel :
        * OpenPhoenux fournit du bon matos notamment le futur Neo900 (campagne de financement en cours, voir http://neo900.org/) qui aura sa puce baseband isolée électriquement (on pourra donc l'arrêter intégralement sans retirer la batterie de l'ordiphone).

        * LG Optimus black P970 autorise un chargeur de démarrage libre non signé. Le support par Replicant est en cours.

        * (durant la séance de questions/réponses) Osmocom a bossé sur des modems Mediatek (utilisés par Wiko, par exemple). Les processeurs Nvidia Tegra sont compatibles avec la radio logicielle, ce qui signifie qu'on peut faire tourner une stack GSM logicielle libre (ça existe, cf openbts & co) sur le processeur principal, ce qui constitue une évolution intéressante.


    Questions/réponses [NDLR : je n'ai pas noté toutes les questions et toutes les réponses ] :
        * Discussion sur l'inadéquation des téléphones sécurisés fournis dans les ministères et les usages modernes qu'en attendent les fonctionnaires de ces ministères : la première version n'avait pas le support des SMS, la version actuelle n'a pas Twitter donc ça ne répond pas aux besoins. Hervé Morin a déclaré qu'il faut 10 minutes pour l'allumer et que ça marche une fois sur deux. Benjamin Bayart souligne que Replicant, axé sur le respect des utilisateurs et de leur vie privée, constitue une alternative pour cet usage-là. Pas pire que Thales & co ;

        * Des ordiphones modulaires existent mais ils sont encore à l'état de projets de recherche bien qu'ils constituent une piste intéressante dans l'idée mais pas (encore ?) dans la réalité.

        * Le durcissement du matériel n'intéresse-t-il pas des entreprises qui pourraient contribuer au projet (dev', financement,...) ? Car il y a le Blackphone, certes, mais tous les bouts de crypto sont privateurs ce qui va à l'encontre du principe de Kerckhoffs.
    December 1, 2015 at 10:22:55 PM UTC - permalink - http://redmine.replicant.us/projects/replicant/wiki/Conferences
  • Blog Stéphane Bortzmeyer: DNS, bien commun (à Brest « Temps des Communs »)
    Quelques notes prises durant le talk :

    Internet vu par le gouvernement FR :
        * Lemaire pense qu'il faut signer une charte au ministère pour déployer TLS ;
        * Cazeneuve croit qu'il y a des dirigeants d'Internet et qu'il leur a parlé dans le cadre de la lutte antiterroriste.
    Ça révèle que, pour eux, un truc comme Internet ne peut pas être géré comme un bien commun, ça doit forcément être une grosse hiérarchie bureaucratique.

    Pourtant, il n'y a pas de Président de l'Internet qui pourrait donner des ordres à tous les acteurs. S'il y en avait, on n'aurait plus SSLv3 qui est troué et le support de l'Unicode serait déployé partout.


    Un bien commun, ce n'est pas un groupe de quelques personnes. Les gens partagent beaucoup de choses sans que cela soit des biens communs. Un bien commun, c'est une infrastructure commune, qui ne peut fonctionner seule, pour laquelle des gens, qui sont différents, ne sont pas d'accord sur ce que doit être l'infrastructure, sur les moyens à mettre en oeuvre voire sont même des concurrents mais pour laquelle tout le monde a intérêt à ce qu'elle fonctionne. Voir le livre « Effondrement » de Jared Diamond.

    Exemple technique : il y a des techniques pour empêcher l'usurpation d'adresses IP. Le premier opérateur réseau qui déploie ces techniques devra supporter un coût (humain, en équipement matériel, en licence logicielle,...) mais c'est les concurrents qui profitent de l'effort (puisque celui qui déploie s'interdit d'usurper des adresses mais ne s'offre aucune garantie de ne plus recevoir de paquets usurpés). La direction financière ne sera pas d'accord pour déployer. Autrement dit : si l'opérateur déploie, il supporte les coûts, s'il ne déploie pas, les inconvénients sont supportés par la communauté et il profite des déploiements des autres. Comme souvent en écologie, la somme des intérêts individuels ne fait pas l’intérêt collectif.


    DNS
        * Pourquoi a t-on rajouté ça ? Car les IPs ne sont pas stables (elles dépendent de l'opérateur, du fournisseur de service,...) et les noms sont plus facilement mémorisables pour les humains. En informatique, on peut résoudre tous les problèmes en rajoutant une indirection, ce que fait le DNS.

        * Technologie d'infrastructure : tant que ça marche, on ne s'en rend pas compte. Ce que fait que Ceux qui savent comment ça marche et échange à ce sujet sont en petite communauté.

        * Un nom se compose de plusieurs composants (nombre quasi illimité (127 max de longueur)) : racine, TLD,...

        * Le DNS est arborescent. Avantages : vitesse et délimitation de l'autorité de chaque acteur ; Inconvénient : dépendance (laquadrature.net. nécessite que net. fonctionne pour fonctionner)

        * Le DNS est décentralisé : chaque acteur fait ce qu'il veut chez lui.

        * Qui décide d'enregistrer un nom ? À l'époque du HOSTS.TXT (annuaire centralisé pas flexible, /etc/hosts quoi) géré par le SRI-NIC, il fallait mailer Elizabeth Feinler et hop, on avait le nom désiré. Ça soulève des questions : qui a le pouvoir sur ce fichier ? Qui nomme Elizabeth ? Sur quels critères la nomme-t-on ? Aujourd'hui : c'est plus compliqué.

        * Explications sur le processus de résolution d'un nom qui, on le voit, implique plusieurs acteurs qui doivent gérer les machines, payer les techniciens,...


    Acteurs du DNS :
        * Plusieurs acteurs, plusieurs coopérations entre des sociétés commerciales différentes et concurrentes (ex : Orange / OVH)
        * Registre/registry (AFNIC pour fr/re/tf/pm/wf, Verisign pour com. ,...)
        * Bureaux d'enregistrement/registrar (Gandi,
        * Hébergeurs DNS (OVH, Gandi,...)
        * Gérants de résolveurs DNS (FAI, Google, Cisco (OpenDNS),...). Il n'y a que le ministre qui croit qu'il y'a uniquement Orange/Numericable/Free
        * Un même acteur peut avoir plusieurs rôles (registrar et hébergeur, registre+registra+hébergeur devient courant avec les nouveaux gTLD)

    Qui décide, qui organise la technique derrière ? Pas toujours clair. Mais c'est positif : si une seule organisation pouvait décider de tout, ça serait bad. Exemples :
        * Chaque registre a ses propres règles pour l'enregistrement de noms. Enregistrer un bzh nécessite d'avoir un vague lien avec la Bretagne

        * Pour la racine, c'est le gouvernement US qui décide, caché derrière l'ICANN (livre vert de Clinton en 1997) : pour tout ajout dans la racine, même le changement d'une IP, il faut une autorisation écrite d'un fonctionnaire à Washington.

        * Pour un résolver : le gérant du résolver (pour rediriger vers de la pub et servir ainsi ses intérêts) ou son gouvernement d'appartenance (pour appliquer la censure administrative) ou la justice locale.

        * Fonctionnement technique du DNS : IETF, organisme ouvert à tous et toutes, via les normes techniques qu'il produit, les RFC. Mais l'IETF n'a pas de police pour vérifier l'application des RFC.

    => Il n'y a pas une seule source du pouvoir. Le rêve de beaucoup (exemple : les ayants-droits) qui voudraient un bouton pour censurer un contenu partout en un instant est un rêve vain.


    Passons aux acteurs qui rendent moins efficace le bien commun.

    Les méchants :
        * Hackers russes et chinois ?
        * Pédophiles djihadistes radicalisés ? Exemple : Cazeneuve a déclaré, au FIC : « On est en guerre » pour parler du deface de l'Office national de la chasse et de la faune sauvage :D
        * Industries du divertissement et des jeux d'argents ? ARJEL est l'une des premières censures DNS en France sous prétexte qu'un site web de jeu d'argents ne paie pas sa dîme à l'État
        * NSA et DGSE ?
        * Mythe du lycéen cagoulé dans son garage ?
    Les méchants sont minoritaires, c'est pour cela que le monde tourne

    Les négligents :
        * Ils sont très nombreux mais pas très menaçants individuellement.
        * Ils manquent de temps, de compétences. Exemples : les PC winwin zombis
        * Beaucoup de gens sont largués ou irresponsables genre correction de la faille Kaminsky (empoisonnement de cache DNS) : en 2j, 25% des serveurs vulnérables étaient patchés. En un mois : 50%. En un an : 55%...


    Déploiement d'une nouveauté dans le DNS, l'exemple des IDN (nom de domaine en Unicode donc accents et alphabet non latin) : nécessite peu de changements dans les logiciels qui font tourner l'infrastructure. Changements dans les logiciels côté utilisateur. Norme technique en 2003, noms Unicode autorisés dans la racine en 2009, toujours pas prise en charge par des hébergeurs et des logiciels. Il faut mettre à jour les cerveaux or beaucoup ne remettent pas en cause ce qu'ils ont appris sans compter que la fausse information se propage toujours plus vite que la vraie.


    Passons aux problèmes

    Robustesse : Tremblement de terre en 2010 à Haïti, .ht n'a jamais stoppé grâce à une infrastructure résiliente (des serveurs en dehors de l'île). Les gérants des serveurs extérieurs ont pu spontanément prolonger le service sans joindre les gérants initiaux. Conclusion : la coopération humaine, ça marche.

    La censure via les DNS menteurs : la liste du ministère est secrète donc envoyée à un petit nombre de résolveur donc les autres de l'appliquent pas ; les petits FAI ne sont jamais assignés devant les tribunaux et donc n'appliquent pas les décisions de justice. Conclusion : l'éclatement des formes de décisions limite les formes de censure.

    Qui décide de la racine unique ?
        * Il faut une racine unique sinon un même nom de domaine pourrait pointer sur des contenus différents !
        * C'est les gérants de chaque résolver DNS qui choisissent la racine que leur logiciel va utiliser, c'est un paramètre de la configuration comme un autre
        * Des racines alternatives existent
        * Pourtant, en pratique, tout le monde utilise la racine de l'ICANN/gouvernement US, même la Chine et autres régimes bienveillants car intérêt commun
        * Une racine différente pourrait fonctionner en Corée du Nord qui est refermée sur elle-même mais pas en Chine qui est insérée dans l'économie mondiale (on peut donc s'y rendre physiquement, en sortir,...)


    Donc, s'il n'y a pas de chef, c'est forcément la jungle ? Non, la coopération s'organise : adminsys causent sur IRC, organisations professionnelles comme l'OARC, listes de discussion, forums, twitter (qui est le meilleur logiciel de monitoring :D ). La coopération, ça marche mieux autour d'une bière ou d'une autre activité humaine. L'exemple typique c'est les attaques par déni de service ((D)dos) : il n'y a pas de procédure pour juguler et réparer, ça marche mieux avec des humains.


    Conclusion
        * DNS est un bien commun donc pas de chef, tout le monde est partie prenante et coopère
        * Donc gouvernance compliquée, on pourrait résoudre des problèmes plus rapidement mais elle génère aussi de la robustesse (à la censure, par exemple)


    Questions [ NDLR : Je n'ai très certainement pas noté toutes les questions/réponses ! ] :
        * Expliquer ce qu'est DNSSEC ? [ NDLR : connaissant la réponse, je ne l'ai pas noté mais il s'agit de signer les réponses DNS avec toute la cryptographie asymétrique habituelle dans le but de garantir que la réponse n'est pas modifiée en chemin par un intermédiaire malveillant. ]
     
        * Que penser des nouveaux gTLD comme xyz, coca,... ? Semble être bon pour le business et ça n'affecte pas les autres (principe de l'arborescence du DNS)

        * [ NDLR : Je n'ai raté la question ]. Gestion par anarchie : il ne faut pas voir le monde en binaire. Le Net n'est pas le jardin d'Éden mais n'est pas l'enfer non plus. Si les humains étaient parfaits, il n'y aurait pas besoin d'organiser les communs mais l'humain est imparfait et les communs tentent de gérer ça

    * Qu'est-ce qui justifie la différence de prix entre fr. et bzh. ? Citation du livre de Laurent Chemla, fondateur de Gandi et auteur de « Confessions d'un voleur » dans lequel il dépeint l'arnaque que constitue selon lui la vente de noms de domaine. L'enregistrement d'un nom ne coûte presque rien car il s'agit d'une ressource virtuelle mais il y a quand même des coûts pour faire les backups, assurer la traçabilité d'un nom (même si avec 4,50€ encaissés par l'AFNIC pour l'achat d'un fr. l'AFNIC ne va pas vérifier l'adresse postale ou autre vérification poussée)... Mais il y a des coûts cachés : une résolution d'un nom est gratuite alors qu'il y a 300 machines cachées derrière qu'il faut faire fonctionner et administrer. Qui paye ?

       * Relance de la question précédente. « Mince, je n'ai pas réussi à noyer le poisson ». :D SB n'est pas décideur de la grille tarifaire de l'AFNIC (bzh est techniquement géré par l'AFNIC) et son salaire en dépend.

       * Avenir du tout décentralisé comme NameCoin ou GnuNet ? Techniques intéressantes mais on a d'autres problèmes : conservation de la clé privée, problème de documentation (FAQ de NameCoin incorrecte pour l'enregistrement d'un nom), problème de compétences. Namecoin décollera le jour où y'aura des sortes de notaires pour faire l'intermédiaire.

    * Question IRC : penses-tu qu'une zone DNS soit éditable avec vi ? Emacs

        * Peux-tu nous parler de la vie privée et DNS, des travaux à l'IETF comme la qname minimization ? [ NLDR : étant sensibilisé à la problématique, je n'ai pas noté la réponse à ma propre question :S donc je vous donne un pointeur : https://tools.ietf.org/html/rfc7626 et qname minimization consiste, pour un résolver, à ne pas envoyer le nom complet demandé comme shaarli.guiguishow.info. aux serveurs de la racine, aux serveurs de info.,... quand ils n'ont rien en cache puisqu'ils ces serveurs n'ont pas la réponse (racine connaît juste les serveurs d'info, info. connaît juste les serveurs de guiguishow.info. ]
    December 1, 2015 at 2:12:37 PM UTC - permalink - http://www.bortzmeyer.org/dns-bien-commun.html
  • Postfix 2.10 Release notes [ Pourquoi le code de relay access denied passe de 554 (refus définitif) à 454 (refus temporaire) ? ]
    Monitorer son infra, ce n'est pas juste vérifier qu'une machine / un service est accessible. C'est aussi vérifier automatiquement que la conf' n'est pas trouée par des modifications ultérieures. Exemples : il faut vérifier que le smptd n'est pas un relais ouvert, que le récursif-cache DNS n'est pas ouvert, même chose pour snmpd, ntpd et d'autres...

    Suite au passage à Jessie, Picomon (ordonnanceur de supervision ultra léger et KISS, voir http://shaarli.guiguishow.info/?QdWF1g) nous signale que notre smtpd ne répond plus comme avant au test de relais ouvert. En effet, postfix répond 454 (erreur temporaire, revient livrer ton mail plus tard) au lieu de l'habituel 554 (refus définitif, ce mail ne sera jamais accepté, arrête d'essayer).

    Lisons les release notes :
    « With Postfix versions before 2.10, the mail relay policy and spam
    blocking policy were combined under smtpd_recipient_restrictions,
    resulting in error-prone configuration.

    As of Postfix 2.10, the mail relay policy is preferably implemented
    with smtpd_relay_restrictions, so that a permissive spam blocking
    policy under smtpd_recipient_restrictions will not unexpectedly
    result in a permissive mail relay policy.

    As of Postfix 2.10.0 the smtpd_relay_restrictions parameter built-in
    default settings are:

        smtpd_relay_restrictions =
            permit_mynetworks
            permit_sasl_authenticated
            defer_unauth_destination

    If your site has a complex mail relay policy configured under
    smtpd_recipient_restrictions, this safety net may defer mail that
    Postfix should accept. »

    defer_unauth_destination = 454 ; reject_unauth_destination = 554.

    Ce postfix n'est pas un relais légitime. De plus, ce comportement semble être temporaire afin de faciliter les migrations et je pense que les dev postfix passeront à reject_unauth_destination dans quelques temps. Donc autant le faire dès aujourd'hui.

    Pour ce faire, on ajoute ce qui suit au main.cf :
    « smtpd_relay_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination »
    Et on reload postfix.
    November 30, 2015 at 9:12:49 PM UTC - permalink - ftp://mir1.ovh.net/ftp.postfix.org/postfix-release/official/postfix-2.10.9.RELEASE_NOTES
  • Faire en sorte que puppet agent ne soit pas un démon sous Debian GNU/Linux Jessie
    Le package puppet de Debian, c't'un peu le zouk... Y'a l'initscript et l'unit systemd sans compter le fait que puppet peut rester en démon après un lancement manuel... Autrement dit, c'est le bordel pour avoir un puppet agent qu'on lance uniquement à la demande (oui, on pourrait se poser la question de l'utilisation d'un autre logiciel de gestion de conf' plus approprié comme ansible mais pour l'instant, on veut juste achever notre migration Wheezy (+ dépôt apt puppetlabs) vers Jessie).

        1. Dans /etc/default/puppet, on vérifie que START=no est présent... sauf que, si ce fichier est bien lu dans /etc/init.d/puppet, la variable START ne sert à rien... Il faut donc virer l'initscript à la manière forte :
            * sudo /etc/init.d/puppet stop
            * sudo update-rc.d puppet remove
            * sudo rm /etc/init.d/puppet
            * sudo dpkg-divert --add --no-rename --divert /usr/share/puppet/puppet.initscript /etc/init.d/puppet

        2. On désactive ensuite l'unit systemd : « sudo systemctl stop puppet.service ; sudo systemctl disable puppet.service »

        3. On change aussi l'état interne de puppet : « sudo puppet agent --disable ». Lorsque vous voudrez lancer puppet, faites : « sudo puppet agent --enable && sudo puppet agent --server <server> -t ; sudo puppet agent --disable »

    Normalement, « puppet agent --disable » devrait empêcher puppet de se lancer quel que soit l'origine de l'appel (systemd ou l'initscript) mais ce n'est visiblement pas le cas... La méthode présentée ci-dessus est clairement de l'acharnement thérapeutique mais à moment donné...
    November 30, 2015 at 7:55:17 PM UTC - permalink - http://shaarli.guiguishow.info/?l6JxVg
  • lxc-list.1 - manned.org
    lxc-list a disparu depuis lxc v1.

    Pour remplacer :
        * lxc-ls -f : on voit tous les LXC, leur IPv4, IPv6, état, autostart ou pas
        * lxc-ls --running : montre que les LXC en cours d'exécution. Même raisonnement pour --stopped

    Merci Johndescs‎ (http://jonathan.michalon.eu/blog_index.html)
    November 30, 2015 at 7:21:10 PM UTC - permalink - http://manned.org/lxc-list.1
  • iptables(8) - Linux man page [ module owner ]
    « owner

    This module attempts to match various characteristics of the packet creator, for locally-generated packets. It is only valid in the OUTPUT chain, and even this some packets (such as ICMP ping responses) may have no owner, and hence never match.
    --uid-owner userid
        Matches if the packet was created by a process with the given effective user id.
    --gid-owner groupid
        Matches if the packet was created by a process with the given effective group id.
    --pid-owner processid
        Matches if the packet was created by a process with the given process id.
    --sid-owner sessionid
        Matches if the packet was created by a process in the given session group.
    --cmd-owner name
        Matches if the packet was created by a process with the given command name. (this option is present only if iptables was compiled under a kernel supporting this feature)
    NOTE: pid, sid and command matching are broken on SMP »

    On peut donc filtrer le trafic sortant sur l'uid et le gid du processus qui a créé une socket. Intéressant pour marquer les paquets pour ensuite faire de la QoS avec tc sur les protocoles qui ouvrent des trilliards de connexions sur des ports différents genre torrent, par exemple. L'ennui, c'est que sur un desktop, la plupart du temps, les programmes sont exécutés avec l'uid/gid de l'utilisateur courant, pas avec un utilisateur dédié... Oui, on peut lancer sudo -u <user> <programme> mais il faut que l'user ait un shell et tout donc boarf...
    November 30, 2015 at 6:39:41 PM UTC - permalink - http://linux.die.net/man/8/iptables
  • Systemd : « Failed to get D-Bus connection: Aucun fichier ou dossier de ce type »
    Si l'autocompletion d'une commande systemd (exemple : systemctl status dnssec-triggerd) ou l'exécution d'une commande systemd vous retourne cette erreur alors que vous venez à peine de mettre à jour votre système (de Debian GNU/Linux Wheezy à Jessie, par exemple), il est fort probable que le package « dbus » n'est pas installé... Il faut vérifier avec apt-cache policy dbus, installer au besoin et rebooter (pour que systemd devienne le nouvel init).
    November 30, 2015 at 6:33:31 PM UTC - permalink - http://shaarli.guiguishow.info/?aZk0YQ
  • Stratégie de défense face aux personnes toxiques - Bio-Blog, chroniques de deux consommatrices repenties
    « Ne pas se justifier, c'est donc :

    - simplement répondre à la question posée

    - revenir toujours à la réalité et fuir comme la peste les digressions affectives

    - responsabiliser l'autre pour ne pas être englué dans ses décisions

    - répéter en boucle comme un robot.

    [...]

    "- Ah tu m'appelles enfin!

    - Oui. (réponse à la question)

    - De toute façon, je m'étais dit que si tu ne m'appelais pas avant demain, je n'irais pas à ta fête dimanche!

    - Je ne vois pas le rapport! (erreur, car il y a déjà de l'agressivité dans cette phrase. J'aurais dû répondre : ah!)

    - Si! Le rapport c'est que tu n'en as rien à faire de moi, je peux bien mourir, tu ne le saurais même pas.

    - Mais tu n'es pas morte. (rappel de la réalité)

    - (délire paranoïaque et diarhée verbale) Puisque c'est ça je ne viendrai pas dimanche.

    - C'est dommage, les enfants vont être déçus, mais tu fais comme tu veux, c'est toi qui décide. (responsabilisation : je renvoie la bombe à celui qui l'a lancée. Tu ne veux pas venir? Ce n'est pas mon problème, c'est le tien.)

    - Je vois bien qu'on ne veut pas de moi, c'est pas la peine de m'inviter!

    - Tu es déjà invitée, je t'ai invitée il y a deux mois. Maintenant si tu ne veux pas venir, c'est toi qui le choisit!" (principe de réalité et responsabilisation) »

    Via http://sebsauvage.net/links/?n5W9yQ :(
    November 30, 2015 at 12:50:04 PM UTC - permalink - http://cherryplum.canalblog.com/archives/2006/09/26/2766176.html
  • Espionner les méta-données d'un contact sur Telegram ? Possible et facile - Tech - Numerama
    « Avec un client en lignes de commandes, on peut s’apercevoir facilement que la version Android l’application envoie une notification aux contacts pour dire qu’elle passe en « tâche de fond », c’est-à-dire qu’elle n’est plus l’application utilisée en premier par le système.

    Dès lors, on peut voir à quel moment nos contacts sont connectés et en train de discuter. Mieux encore : avec un poil plus de veille, on peut deviner qui parle à qui. En effet, si deux contacts passent en application ouverte puis en tâche de fond à tour de rôle (sachant que les horaires sont donnés à la seconde près), on peut facilement en déduire qu’ils sont en train de parler et attendent que l’autre réponde pour relancer l’application.

    Et ce n’est pas le pire : « En plus, Telegram ne demande pas aux deux contacts d’accepter de se connecter sur la plateforme », affirme Flisbäck. En conséquence, il vous suffit de connaître le numéro de téléphone de votre cible pour commencer à récupérer les méta-données qui la concernent… et ainsi commencer à surveiller ses heures de connexion, sans que la cible soit avertie. Un problème sérieux pour une application qui revendique la protection des communications de ses utilisateurs. »
    November 30, 2015 at 12:33:23 PM UTC - permalink - http://www.numerama.com/tech/133000-espionner-meta-donnees-dun-contact-telegram-possible-facile.html
  • Ils piratent les pubs parisiennes pour dénoncer les sponsors de la COP21 - Rue89 - L'Obs
    « Le collectif Brandalism – un mot-valise formé à partir de « brand » (marque, en anglais) et de « vandalisme » – revendique la pose, en région parisienne, de 600 affiches détournées.

    L’opération a eu lieu entre vendredi et samedi, pour marquer le coup à la veille de la COP21 et dénoncer « la mainmise des multinationales sur les négociations climatiques ».

    L’initiative est d’autant plus percutante que les entreprises citées font souvent parties des « généreux » mécènes qui ont financé ce grand raout international.

    [...]

    « Roulez plus propre. Du moins en apparence. »
    « Nous avons omis de lever le voile sur nos émissions de CO2 parce que le réchauffement climatique ne fait pas partie de nos thématiques. »

    « Notre philosophie : vous n’avez pas besoin de savoir. » »
    November 30, 2015 at 12:31:25 PM UTC - permalink - http://rue89.nouvelobs.com/2015/11/29/ils-piratent-les-publicites-parisiennes-denoncer-les-sponsors-cop21-262299
  • yubikey-personalization
    ykpersonalize et ykinfo sont packagés dans Debian Jessie mais ne supportent pas les yubikeys 4 (les ID sont hardcodés dans les headers C). Il faut donc compiler notre version de yubikey-personalization \o/

    Si le make check (lancé par le ./build-and-test.sh, c'bien pareil) foire avec ce message :
    « ./.libs/libykpers-1.so: undefined reference to `_ykusb_get_vid_pid'
    ./.libs/libykpers-1.so: undefined reference to `_ykusb_open_device'
    ./.libs/libykpers-1.so: undefined reference to `_ykusb_start'
    ./.libs/libykpers-1.so: undefined reference to `_ykusb_read'
    ./.libs/libykpers-1.so: undefined reference to `_ykusb_close_device'
    ./.libs/libykpers-1.so: undefined reference to `_ykusb_write'
    ./.libs/libykpers-1.so: undefined reference to `_ykusb_stop'
    ./.libs/libykpers-1.so: undefined reference to `_ykusb_strerror'
    collect2: error: ld returned 1 exit status
    Makefile:717: recipe for target 'ykpersonalize' failed
    make[1]: *** [ykpersonalize] Error 1 »

    C'est qu'il faut indiquer à LD où se trouve la libyubikey (installée par le package libyubikey-dev ;) ) : LDFLAGS="-L/usr/lib/x86_64-linux-gnu/" ./configure

    Puis on relance le make check puis sudo make install  puis sudo ldconfig -v pour rafraîchir le cache. ykpersonalize et ykinfo sont désormais utilisables et supportent votre yubikey 4.
    November 29, 2015 at 9:18:02 PM UTC - permalink - https://developers.yubico.com/yubikey-personalization/
  • Des slides Beamer en Markdown – ®om's blog
    « Pour produire des slides propres pour une présentation, j’aime beaucoup Beamer (basé sur LaTeX). Mais la syntaxe est un peu lourde et la configuration est parfois inutilement compliquée (fonts, encodage, compilation multipasse…).

    Est-il possible d’avoir les avantages de Beamer sans ses inconvénients ? La réponse est oui, grâce à pandoc et son Markdown étendu. »

    Je suis du genre à faire mes visuels de présentation à l'arrache car je laisse murir mon message et la manière de l'articuler ce qui fait que j'ai rarement besoin de répéter mon speech : je sais où je veux en venir et comment. Et le stress, ça aide à poursuivre/axer la réflexion. Le support sert uniquement à ne pas me perdre ainsi que l'auditoire. Du coup, se farder des \begin{itemize}, \item et autres \textbf{} à 30 minutes de ton speech : what about no?

    J'ai déjà dit tout le bien que le passage de Impress à Beamer m'a fait (voir http://www.guiguishow.info/2012/06/12/latex-motivations-usage/), maintenant, il est temps de passer au niveau supérieur. :D


    Pour les paramètres à passer à pandoc, les extensions existantes et les balises de formatage, c'est par ici : http://pandoc.org/README.html. Je vous recommande vivement la lecture du bloc « Structuring the slide show »


    Je retiens :
        # = changement de niveau. Donc # = frame/slide, ## = un bloc dans une frame/slide,... Sauf si --slide-level=2 est utilisé dans la ligne de commande pandoc auquel cas # = une interslide qui contient juste le titre de la section, ## une slide/frame ;

        \begin{block|alertblock|exampleblock}{} \end{block|alertblock|exampleblock} = pas d'équivalence mais il est possible d'utiliser cette syntaxe. Simplement, le markdown à l'intérieur ne sera pas interprété donc tout le contenu du bloc doit être du LaTeX : \begin{itemize}, \item, \end{itemize}, par exemple ;

        \itemize \item = - (oui, un tiret). Pour avoir une liste dans une liste, il suffit de tabulation + tiret ;

        \textbf{mon texte en gras} = **mon texte en gras** ;

        \textit{mon texte en italique} = _mon texte en italique_ ;

        \underline{mon texte souligné} = pas d'équivalence ;

        \usepackage{ulem} + \sout{mon texte barré/rayé} = ~~mon texte barré/rayé~~ avec l'extension strikeout ;

        Évidemment, les styles précédent (gras, italique, barré) peuvent se cumuler : ~~_**YOLO**_~~ ;

        \url{mon_lien} = <mon_lien> ;

        \usepackage{eurosym} + \euro = € ;

        \begin{figure}[!h] \centering \includegraphics{images/mon_image.jpg} \caption{Source : ma source} \end{figure} = ![Source : ma source](images/mon_image.jpg) L'image sera centrée automatiquement. Non, des choses comme « [height=6cm, width=2cm] » ne sont pas disponibles. Ce n'est pas le rôle de LaTeX mais celui d'un logiciel de traitement d'images, ceci dit. Attention : si vous utilisez les formats « markdown_strict » ou « markdown_mmd », alors le centrage et la légende ne se font pas automatiquement (je n'ai pas creusé la question de la bonne syntaxe) ;

        % mon commentaire = <!-- mon commentaire --> (oui, la balise commentaire du XHTML). Néanmoins, il est impossible d'introduire un commentaire entre le préambule (titre/auteur/date) du document et la première slide sinon une slide blanche sera insérée automatiquement. Or, c'est ici que j'insère la licence et la ligne de commande pour générer le PDF correspond. Pour éviter ce désagrément, j'utilise un préambule MultiMarkdown :
        « Title:   My title
          Author:  John Doe
          Date:    September 1, 2008
          Comment: This is a sample mmd title block, with
                   a field spanning multiple lines. » (source : http://pandoc.org/README.html) ;

        Comme d'habitude, il faut échapper les caractères qui ont un sens en LaTeX comme « & » ou « # » ou « $ » : \&, \#, \$ ;

        Une table des matières automatique ça n'existe pas sans contrainte avec pandoc (sans éditer le template, j'entends).
            Le premier inconvénient, c'est que la table des matières est insérée juste derrière le slide de titre (celui qu'on projette pour captiver l'auditoire pendant que celui-ci s'installe dans la salle :P ). Or, j'aime bien commencer par une intro où je me présente, j'explique ce que je viens faire ici (quel est mon but ?) et les mots clés de mon sujet avant d'annoncer le plan.
            Le deuxième problème est que, pour avoir une table des matières, il faut forcément que le --slide-level soit à 2. Donc il faut # ma section ## ma slide. Or #ma section produit des interslides dont je ne veux pas.

    Pour activer ou désactiver une extension, il faut + ou - au format d'entrée. Exemple : j'utilise le format d'entrée markdown et je veux l'extension strikeout (pour barrer du texte), alors ma chaîne c'est « markdown+strikeout ». Il faut donc la donner à l'option « -f » de pandoc qui sert à préciser le format d'entrée : pandoc -f markdown+strikeout -st beamer input.md output.pdf.

        Donc pour moi, ça donne : pandoc -f markdown+mmd_title_block+strikeout -st beamer -V theme:Boadilla -V lang:french input.md -o slides.pdf . -V permet de préciser les valeurs de variables internes. Ici : le thème et la langue (pour déterminer où effectuer les éventuelles césures) utilisés. Pour que ça fonctionne, il faut installer les packages texlive texlive-lang-french texlive-latex-extra texlive-base texlive-latex-base cm-super lmodern latex-beamer pandoc.
    ÉDIT DU 29/11/2015 À 11h55 : lang n'attend pas un country code-like comme le dit la doc de pandoc mais french ou francais. Voir /var/lib/texmf/tex/generic/config/language.dat : francais = patois = french. FIN DE L'ÉDIT.
    November 28, 2015 at 10:30:16 PM UTC - permalink - http://blog.rom1v.com/2014/02/des-slides-beamer-en-markdown/
  • SSH with PIV and PKCS11
    FIPS 201 ou plus simplement PIV (Personal Identity Verification) est un standard US pour l'identification et l'authentification des fédéraux et des sous-traitants basé sur une carte à puce (smartcard) et la crypto asymétrique habituelle. Voir https://en.wikipedia.org/wiki/FIPS_201

    Les Yubikeys (Neo, Neo-n, 4, 4-nano) supportent ce standard \o/ ... avec des clés RSA limitées à 2048 bits (mais c'est volontaire, cf http://dx.doi.org/10.6028/NIST.SP.800-78-4 et http://csrc.nist.gov/groups/SNS/piv/news.html - « The final release of FIPS 186-3 Digital Signature Standard, published in June 2009, does not list RSA 4096 as an approved digital signature algorithm and key size for use in the federal government. To comply with FIPS 186-3, SP 800-78-2 accordingly removes RSA 4096 as an algorithm and key size for generating signatures for PIV data objects. »).

    Et si on utilisait cette fonctionnalité des Yubikeys pour s'authentifier via SSH ? :)


    Sur une Yubikey Neo/Neo-n, la première étape sera d'activer l'interface smartcard de la Yubikey. On a déjà vu ça dans un autre shaarli : http://shaarli.guiguishow.info/?VMg7XA (étapes 1 à 4). Cette étape est inutile sur une Yubikey 4 puisque l'interface smartcard/CCID est déjà activée par défaut.

    Pour communiquer avec la Yubikey sous Debian GNU/Linux Jessie, il faut installer le package pcscd.

    Si vous avez une Yubikey 4, il y a une étape supplémentaire : pour détecter les lecteurs de cartes à puce, pcscd se base sur une liste d'ID de fabricants et d'ID de produits. Forcément, la liste packagée dans Debian stable est outdated et votre clé ne sera pas reconnue.

    Il faut modifier le fichier /etc/libccid_Info.plist afin d'y ajouter un item à la fin de la liste des « ifdVendorID » « <string>0x1050</string> » ainsi qu'un item à la fin de la liste des « ifdProductID » « <string>0x0407</string> » ainsi qu'une description sympa à la fin de « ifdFriendlyName » comme « <string>Yubico Yubikey 4</string> ». Il faut ensuite redémarrer pcscd : sudo systemctl restart pcscd.service. Merci à http://forum.yubico.com/viewtopic.php?f=26&t=982&sid=eea0681e9d17e4cdf4ccdb9bc95a56b2&start=10


    Selon la configuration de votre Yubikey 4 (les fonctionnalités que vous avez activées genre OTP, CCID, U2F,...), le ifdProductID change. Pour le retrouver, il faut lancer pcscd en debug : sudo systemctl stop pcscd.service puis sudo pcscd -f -d . Branchez votre Yubikey 4 eeeeeet, parmi la myriade de lignes qui s'affichent : « 00000118 hotplug_libudev.c:296:get_driver() Looking for a driver for VID: 0x1050, PID: 0x0407, path: /dev/bus/usb/001/019 ». 0x0407 est le ifdProductID recherché \o/

    Si vous regardez la sortie debug de pcscd, ne vous préoccupez pas du message :
    « 00000015 ifdhandler.c:130:CreateChannelByNameOrChannel() failed
    00000010 readerfactory.c:1043:RFInitializeReader() Open Port 0x200002 Failed (usb:1050/0407:libudev:1:/dev/bus/usb/001/019)
    00000010 readerfactory.c:335:RFAddReader() Yubico Yubikey 4 init failed. »
    C'est simplement que pcscd seul ne sait pas parler la langue de la Yubikey mais il a bien établi la communication et c'est tout ce qu'on lui demande.


    Maintenant, il faut installer l'outil de manipulation de l'interface PIV fournit par Yubico. Il n'est pas packagé dans Debian Jessie. Dooooooonc :
        * git clone git://github.com/Yubico/yubico-piv-tool

        * cd yubico-piv-tool

        * sudo apt-get install libpcsclite-dev libtool-bin
          Le premier package évite l'erreur « configure: error: cannot find PCSC library ».
          Le deuxième évite l'erreur : « config.status: error: cannot find input file: 'lib/Makefile.in' » qui provient d'erreurs précédentes « AC_LIBTOOL_WIN32_DLL: command not found AC_PROG_LIBTOOL: command not found »

        * ./build-and-test.sh (qui installe quelques dépendances d'où une demande de mot de passe sudo, autoconf, compilation)

        * sudo make install

        * sudo ldconfig -v afin de vider le cache et de prendre en compte la nouvelle lib qui a été ajoutée dans /usr/local/lib (/usr/local/lib est déjà dans le LDPATH, voir /etc/ld.conf.d/libc.conf). Sans ça, au lancement de yubico-piv-tool, vous aurez l'erreur : « yubico-pivtool: error while loading shared libraries: libykpriv.so.1: cannot open shared object file: No such file or directory »

        * yubico-piv-tool -a version devrait vous retourner la version de l'applet PIV de votre Yubikey.


    On peut désormais suivre le tuto pointé par ce shaarli. Notes :
        * On a le choix de l'algorithme, on n'est pas contraint à 9a (qui veut dire RSA 1024) : « 9A, 9C, 9D, 9E: RSA 1024, RSA 2048, or ECC secp256r1 keys (algorithms 6, 7, 11 respectively). ». Voir : https://developers.yubico.com/yubico-piv-tool/YubiKey_PIV_introduction.html

        * On doit changer la clé de management, le code PIN et le code PUK par des éléments persos. Voir : https://developers.yubico.com/yubico-piv-tool/YubiKey_PIV_introduction.html. Pour utiliser la nouvelle clé de management, il faudra la passer en argument de toutes vos futurs commandes yubico-piv-tool avec « -k »

        * Sur la machine à partir de laquelle vous voulez vous authentifier avec votre Yubikey, il faudra installer les packages pscsd comme vu plus haut ainsi que opensc-pkcs11. C'est tout !

        * L'équivalent de -I /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so à mettre dans ssh_config pour se simplifier la vie, c'est « PKCS11Provider=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so »


    Comme on peut le voir, ça peut être plus pratique que d'utiliser l'applet OpenPGP des Yubikeys + virer le fake agent gnupg de MATE + configurer gnugp-agent comme on le faisait ici : http://shaarli.guiguishow.info/?VMg7XA
    November 28, 2015 at 5:29:11 PM UTC - permalink - https://developers.yubico.com/yubico-piv-tool/SSH_with_PIV_and_PKCS11.html
  • YubiKey 4 and YubiKey 4 Nano | U2F, OTP, PIV | Yubico
    Suite à une faille de sécu (http://shaarli.guiguishow.info/?nT1hgQ) dans l'applet OpenPGP de mes yubikeys (neo et neo-n), Yubico, la société qui commercialise les Yubikeys, a mis en place une procédure de remplacement. Comme j'utilise exclusivement cette fonctionnalité (OpenPGP) de mes yubikeys (voir http://shaarli.guiguishow.info/?VMg7XA), j'ai estimé que j'étais légitime et j'ai demandé l'échange contre les nouvelles Yubikeys 4.

    Quoi de neuf avec ces Yubikeys version 4 ? Plus de NFC, support des clés OpenPGP RSA 4096 bits (< 3 ) et Docker. Forcément, votre clé ne sera pas reconnue par les tools Yubico (ykinfo, ykpersonalize) packagés dans Debian stable. ;)

    Niveau OpenPGP, ça juste fonctionne en suivant mon tuto original (http://shaarli.guiguishow.info/?VMg7XA). Néanmoins, la clé est déjà en mode smartcard et il faut utiliser GnuPG v2 pour générer les paires de clés.

    En effet, GnuPG v1 (j'ai testé avec la v1.4.18) voit la yubikey comme une smartcard qui supporte uniquement une taille de clés comprise entre 1024 et 3072 comme l'indique le message :
    « $ gpg2 --card-edit
    [...]
    Key attributes ...: 2048R 2048R 2048R
    [...]

    gpg/card> admin
    Admin commands are allowed

    gpg/card> generate
    Make off-card backup of encryption key? (Y/n) n
    [...]

    Quelle taille de clef désirez-vous pour la clef de signature ? (2048) 4096
    les tailles de clefs RSA doivent être dans l'intervalle 1024-3072

    [...]
    Faut-il modifier le (N)om, le (C)ommentaire, l'(A)dresse électronique
    ou (O)ui/(Q)uitter ? O
    gpg: unknown parameter name in received key data
    gpg: Note that the key does not use the suggested creation date
    gpg: sending command `SCD PKSIGN' to agent failed: ec=6.18
    gpg: échec de la signature : erreur générale
    gpg: make_keysig_packet failed: erreur générale
    Échec de génération de la clef : erreur générale »


    En revanche, GnuPG v2 voit la smartcard avec une taille de clé de 2048 bits par défaut mais va reconfigurer la yubikey pour vous :
    « $ gpg2 --card-edit
    [...]
    gpg/card> admin
    Admin commands are allowed

    gpg/card> generate
    Make off-card backup of encryption key? (Y/n) n
    [...]

    scdaemon[4253]: DBG: asking for PIN '||Please enter the PIN'
    What keysize do you want for the Signature key? (2048) 4096
    The card will now be re-configured to generate a key of 4096 bits
    NOTE: There is no guarantee that the card supports the requested size.
          If the key generation does not succeed, please check the
          documentation of your card to see what sizes are allowed.
    scdaemon[4253]: 3 Admin PIN attempts remaining before card is permanently locked
    scdaemon[4253]: DBG: asking for PIN '|A|Please enter the Admin PIN'
    scdaemon[4253]: size of key 1 changed to 4096 bits
    What keysize do you want for the Encryption key? (2048) 4096
    The card will now be re-configured to generate a key of 4096 bits
    scdaemon[4253]: 3 Admin PIN attempts remaining before card is permanently locked
    scdaemon[4253]: DBG: asking for PIN '|A|Please enter the Admin PIN'
    scdaemon[4253]: size of key 2 changed to 4096 bits
    What keysize do you want for the Authentication key? (2048) 4096
    The card will now be re-configured to generate a key of 4096 bits
    scdaemon[4253]: 3 Admin PIN attempts remaining before card is permanently locked
    scdaemon[4253]: DBG: asking for PIN '|A|Please enter the Admin PIN'
    scdaemon[4253]: size of key 3 changed to 4096 bits
    Please specify how long the key should be valid.
             0 = key does not expire
          <n>  = key expires in n days
          <n>w = key expires in n weeks
          <n>m = key expires in n months
          <n>y = key expires in n years
    Key is valid for? (0) 1y
    Key expires at Sat 26 Nov 2016 03:53:58 PM UTC
    Is this correct? (y/N) y

    GnuPG needs to construct a user ID to identify your key.
    [...]

    scdaemon[4253]: generating new key
    scdaemon[4253]: 3 Admin PIN attempts remaining before card is permanently locked
    scdaemon[4253]: DBG: asking for PIN '|A|Please enter the Admin PIN'
    scdaemon[4253]: please wait while key is being generated ...
    scdaemon[4253]: key generation completed (73 seconds)
    scdaemon[4253]: signatures created so far: 0
    scdaemon[4253]: DBG: asking for PIN '||Please enter the PIN%0A[sigs done: 0]'
    scdaemon[4253]: generating new key
    scdaemon[4253]: please wait while key is being generated ...
    scdaemon[4253]: key generation completed (112 seconds)
    scdaemon[4253]: signatures created so far: 1
    scdaemon[4253]: signatures created so far: 2
    scdaemon[4253]: generating new key
    scdaemon[4253]: please wait while key is being generated ...
    scdaemon[4253]: key generation completed (105 seconds)
    scdaemon[4253]: signatures created so far: 3
    scdaemon[4253]: signatures created so far: 4 »
    November 28, 2015 at 2:23:01 AM UTC - permalink - https://www.yubico.com/products/yubikey-hardware/yubikey4/
  • Qui sommes « nous »? | JCFrogBlog4
    « Fier de la France. C’est le mot d’ordre de la communication gouvernementale pour cette journée d’hommage aux victimes des attentats. Et il faudrait que je mette un drapeau tricolore à ma fenêtre, par solidarité si j’ai bien compris, par patriotisme.

    En ce qui me concerne, je n’ai jamais aimé les drapeaux, ni les chefs et leurs ordres, mais surtout je ne suis pas très fier de mon pays.

    [...]

    Ceci étant dit, je ne décolère pas. Comme pour le 11 janvier, si je suis touché par l’élan émotionnel des foules, je ressens une gêne: la certitude que tout le monde oubliera et reprendra le train train à la machine à café lundi matin.

    [...]

    Mais revenons au « nous ». Celui qui devrait nous rendre fiers, nous faire arborer ensemble nos couleurs, celle d’une Nation unie dans l’épreuve (et en dehors?). Si toute l’année c’était Liberté, Egalité, Fraternité, je pourrais comprendre, mais on est loin du compte.
    Liberté, Egalité, Fraternité

    Un « nous » implique un commun. Or moi ce que j’en vois au quotidien c’est une obsession de destruction du commun, le libéralisme fou règne dans les cerveaux disponibles, le catéchisme libéral est omniprésent dans les grands médias, chaque jour on nous explique que la solidarité c’est bien mignon mais qu’on n’a plus les moyens ma bonne dame. La « gauche » aime l’entreprise et les privatisations, le commun ce n’est pas « moderne » nous explique M Macron.

    Alors elle est où la Fraternité? On vit dans un modèle qui se satisfait de millions de chômeurs depuis des décennies, « inactifs » dont la masse ne fera qu’augmenter mais personne ne veut rien savoir, imaginer un autre système c’est forcément pas sérieux, laisse faire les grands, les experts, les encravatés. Le réalisme c’est de rêver au plein emploi, ce truc qui ne reviendra jamais, mais on fait semblant d’y croire. Et puis promesses d’emplois = suffrages, alors…

    La Liberté? Elle est mise à mal depuis des années dans l’indifférence générale par l’empilement frénétique de lois sécuritaires dont on peut douter tout de même un peu aujourd’hui qu’elles nous protègent mieux. Mais la question démocratique emmerde les français, ça fait pas bouillir la marmite.

    Egalité? Ai-je besoin de développer?

    Non, je ne suis pas spécialement fier de cette France de 2015. Ce pays pourrit gentiment devant sa télé, toujours plus loin de ses idéaux qu’il est si prompt à scander dès que l’émotion le permet. Des valeurs ça ne sert pas qu’aux beaux discours, ça se vit. Ils veulent attaquer « nos valeurs » parait-il, il me semble qu’elles sont déjà bien mal en point et qu’une très grosse partie du problème est là. Je ne sais pas pour les français, dur à estimer, mais la France est de moins en moins fraternelle. »

    Gros +1.

    Via http://korben.info/news/qui-sommes-nous
    November 27, 2015 at 9:48:33 PM UTC - permalink - http://jcfrog.com/blog/qui-sommes-nous/
  • Surveillance internationale : la loi passe le cap du Conseil constitutionnel - Next INpact
    « Le Conseil constitutionnel vient de valider tous les articles de la loi sur la surveillance des communications internationales qui avaient été pointés par les sénateurs LR. [...]

    Ils ont d’abord considéré que les outils ciblant les échanges internationaux relèvent de la police administrative. En conséquence, un tel recueil d’informations « ne peut donc avoir d’autre but que de préserver l’ordre public et de prévenir les infractions ». Sous un autre angle, « il ne peut être mis en œuvre pour constater des infractions à la loi pénale, en rassembler les preuves ou en rechercher les auteurs. »

    [...]


    Il n’y a donc aucune inadéquation particulière, pas plus qu’il n’y a de problème avec d’autres dispositions qui autorisent, toutes, une surveillance décidée par le seul pouvoir exécutif, sans passer par l’intermédiaire de la Commission nationale de contrôle des techniques du renseignement. Pas de contrôle préalable, des durées d’exploitation plus longues, bref un formalisme en retrait, etc. Mais tout va bien : « le législateur a précisément défini les conditions de mise en œuvre de mesures de surveillance des communications électroniques internationales, celles d’exploitation, de conservation et de destruction des renseignements collectés ainsi que celles du contrôle exercé par la commission nationale de contrôle des techniques e renseignement. »

    [...]

    Tous les articles n’ont pas été examinés par le Conseil constitutionnel. Plusieurs sont passés entre ses gouttes laissant ainsi une brèche pour de potentielles QPC. Cela concerne en particulier :

        L854-3 : la protection des avocats, magistrats, parlementaires et journalistes (cependant une disposition similaire avait été validée dans la loi renseignement..)
        L. 854-4 : la traçabilité de l’interception et l’exploitation des communications
        L. 854-6 : l’exploitation des renseignements, leurs transcriptions, etc.
        L. 854-7 : opérations matérielles effectuées par les opérateurs de communications électroniques
        L. 854-8 : exploitation des correspondances interceptées qui renvoient à des numéros d’abonnement ou à des identifiants techniques rattachables au territoire national

    Le Conseil constitutionnel a fait là un contrôle au strict minima. Son analyse des boites noires internationales face à celles prévues par la loi sur le Renseignement en France est particulièrement symptomatique. Si, dans ce dernier cas, il s’est montré très tatillon, il a survolé le dispositif pourtant moins encadré et nettement plus vaste programmé par la loi sur la surveillance internationale.  »
    November 26, 2015 at 11:09:06 PM UTC - permalink - http://www.nextinpact.com/news/97491-surveillance-internationale-loi-passe-cap-conseil-constitutionnel.htm
Links per page: 20 50 100
◄Older  
page 227 / 306
Newer►
Mentions légales identiques à celles de mon blog | CC BY-SA 3.0

Shaarli - The personal, minimalist, super fast, database-free, bookmarking service by the Shaarli community