Moonz a écrit 3542 commentaires

Comme toi j'ai super-peur du gouvernement, alors je préfère utiliser un outil de mafieux

Le FBI est tout à fait d’accord avec toi : il faut vraiment avoir mauvaise conscience pour utiliser des outils de criminels comme la cryptographie.

que le monde linux arrete de se branler avec 20 frameworks UI

Mais de quoi parles-tu ? Tu as deux gros frameworks, Qt et Gtk. Et encore, Qt c’est plus « multiplateforme » que « monde Linux ». Le reste est quantité négligeable — et si tu veux compter les quantités négligeables, les autres OS ont autant voire plus de frameworks UI secondaires à la con utilisés par deux projets (d’autant plus qu’énormément des frameworks secondaires sont multiplateformes). Et tu n’as pas à tout supporter. Tu as juste à en choisir un.

Ça me fait penser à ceux qui ressortent sans cesse cette image pour dire « le son sous Linux c’est le bordel », en passant sous silence que les 3/4 des trucs cités là dedans sont des libs/serveurs de sons portables qui existent ailleurs, et que ailleurs aussi tu as généralement plusieurs API pour accéder au son (sous Windows par exemple tu as à minima DirectAudio et l’API legacy des MFC).

qui sont un enfer a deployer

Ha oui apt-get install libqt4 c’est vraiment un enfer de complexité de déploiement.

Ça reste néanmoins une « super idée », personnellement je m’en sers autant que possible (je m’en suis servi par exemple pour protéger l’accès à l’espace d’administration d’un site SPIP).

Tu m’intéresses. Comment tu fais en PHP pour accéder au certificat et au résultat de la validation ? La dernière fois que j’ai regardé, yavait strictement rien un tant soi peu normalisé pour ça, fallait le faire à la main à coups de fascgi_param TLS_CLIENT_CERT $ssl_client_cert avec nginx.

s'il y a beaucoup plus de bits d'entropie que le premier, il n'est pas forcément plus difficile à casser

Ben si, de par la définition d’un bit : la quantité d’information nécessaire pour diviser le nombre de possibilités par deux. Autrement dit, si un schéma a n bits d’entropie, par définition ça signifie qu’il faut tester environ possibilités pour le deviner (plus précisément, il faut tester possibilités pour avoir 100% de chance de le deviner, possibilités pour avoir 50% de chances de le deviner, possibilités pour avoir 25% de chance de le deviner…)

4 mots tirés d’un dictionnaire de 3000 mots, c’est 3000⁴=81 téra-possibilités (téra=10¹²). C’est bien plus (environ un million de fois plus) que les 2**16 * 2 * 2 * 2**3 * 2**4 * 2**3 = 2**28 = 268 méga-possibilités (10⁶) offertes par le premier.

Le problème de ce XKCD c’est qu’il ne présente pas l’alternative qui est une chaîne générée aléatoirement (au lieu de partir d’un mot de base). En se limitant à [a-zA-Z0-9], pour obtenir les 46 bits d’information équivalents, il suffit de 8 caractères. 7 si tu inclus les caractères spéciaux. Perso j’ai pas tellement plus de difficultés à retenir (sur le long terme) 8 caractères plutôt que 4 mots. Et c’est plus court à taper.

Le fantasme c’est surtout de croire que le seul scénario d’attaque envisageable c’est la NSA, et prétendre que si on est pas une cible de la NSA on a pas besoin de sécurité.

Pour moi le scénario n°1 en sécurité, en terme d’impact, c’est mitiger les « oups ». « Oups, après remplacement notre ancien serveur de backup a été revendu/recyclé/refilé sans que les données aient été effacées ». « Oups la règle qui fermait SSH sur le serveur de prod a sauté, et on y a pas mis de fail2ban ». « Oups le stagiaire de la DSI a ouvert un mail vérolé… sur la session admin ».

Quitte à jouer à « même ce langage était peu connu et éprouvé à une époque », on peut évoquer… javascript, longtemps considéré comme un jouet pour faire des trucs genre « Entrez votre nom » « Bonjour "nom" » sur un site perso, et son utilisation côté serveur non seulement impossible mais impensable.

Le mainstream de demain c’est le jouet d’aujourd’hui, même si tout jouet d’aujourd’hui ne sera pas un mainstream demain. Le jeu c’est justement d’avoir le flair pour trouver lequel ;)

La sortie de btrfs send, c’est une liste d’opérations génériques (créer fichier, supprimer fichier, changer permissions, changer contenu). Tu peux donc le restaurer sur n’importe quel système de fichiers btrfs. Dans l’absolu tu pourrais même écrire un outil pour le restaurer sur une partition ext4/NTFS/whatever, mais à ma connaissance personne ne s’est fatigué à le faire.

Tu fais un snapshot en read only de la partition que tu veux sauvegarder (par exemple /home) :

btrfs subvolume snapshot -r /home /home/.snapshots/$(date +"%Y%m%dT%H%M%S")

Tu peux ensuite en faire ce que tu veux, par exemple l’envoyer en SSH sur un serveur distant :

btrfs send /home/.snapshots/$date | gzip | ssh backups@srv-backup "cat > $date.gz"

Tu peux même faire du backup incrémental :

btrfs send -p /home/.snapshots/$previous /home/.snapshots/$date | gzip | ssh backups@srv-backup "cat > $previous-to-$date.gz"

Pour restaurer, c’est un poil plus technique, mais rien d’insurmontable :

cd /home
mkdir .snapshots
cd .snapshots
ssh backups@srv-backup "cat $lastfull.gz $lastfull-to-${inc1}.gz ${inc1}-to-${inc2}.gz" | zcat | btrfs receive .

# A partir de là on a récupéré le dernier snapshot en mode lecture seule.
# On peut faire un gros copier bourrin cp -a /home/.snapshots/${inc2}/{*,.*} /home,
# ou alors on peut faire ça plus finement et ordonner à btrfs d’utiliser
# le dernier snapshot pour /home :

# Faire une copie du snapshot à restaurer en mode lecture-écriture
# (les snapshots récupéres par btrfs receive sont toujours en read-only
btrfs subvolume snapshot ${inc2} last-rw

# On récupère l’id de last-rw
id=$(btrfs subvolume list /home | awk '/\/last-rw$/{print $2}')

# On change le snapshot utilisé par /home, et on remonte
btrfs subvolume set-default $id /home
cd /; umount /home; mount /home

bower est marqué en pré-requis dans ce journal c'est donc un nième outil à installer.

Comme il pourrait être en prérequis d’un projet en PHP. Encore une fois, rien à voir avec la plateforme.

mais va assurer sa propre mise à jour de manière autonome…

Pas nécessairement : seulement si les devs prennent la peine de fournir une version pré-empaquetée. Exactement comme en node donc…

Non, je ne vois toujours pas de rapport entre le nombre d'utilisateurs et les risques de sécurité

J’ai parlé de « millions d’utilisateur » pour une chose : indiquer que c’est quelque chose de testé, y compris en production et à large échelle.

Les récents événements ont montré que même les librairies les plus utilisées ne sont pas exemptes de bugs/failles depuis des années

Ça tombe bien, personne n’a prétendu ça.

Maintenant, faisons simple. Tu prends 200 développeurs de tous niveaux. Aux cent premiers, tu leur fait coder un CMS où ils doivent faire toutes leurs requêtes SQL à la main. Au cent autres, tu leur fait coder un CMS avec obligation d’utiliser un ORM. À ton avis, quel groupe aura statistiquement le plus d’injections SQL ? Petit indice : le groupe 2 en aura 0. Ça veut pas dire que ce sont des meilleurs codeurs, et qu’ils n’introduiront aucun bug ni aucune faille. Mais au moins il ne tomberont pas dans ce piège bien précis. Ajoute à cette image un système de template qui échappe les variables par défaut (en opposition à coder à coups de <?php echo $row["user_comment"] ?>), un système de routage qui évite les pièges genre <?php include $_GET['module']."/".$_GET['page']; ?>, et tu te trouveras certes avec 150.000 dépendances, mais un code vachement plus sûr (et non, je n’ai pas dit à 100% sûr).

Je te rejoins sur un truc : ce qui fait la sécurité, c’est la qualité du code. Et la qualité du code, elle passe par des bonnes pratiques, qui incluent :

• Factorisation et réutilisation du code: utilisation de librairies externes éprouvées tant que possible.
• Automatisation maximale (tests, génération de code, gestions des asset). Le « bower » dont tu te plains.

Alors oui, dans la qualité du code il n’y a pas que ça (loin de là), mais ce dont tu te plains (150.000 dépendances, outillage lourd) sont deux aspects très important de la qualité du code. D’où le fait que je réagisse assez violemment à ta remarque « ah, de mon temps, on avait pas à s’encombrer de tout ça, pas de dépendances, on faisait nos requêtes SQL avec amour » (oui, je caricature ;)). Ce bon vieux temps, c’est aussi un bon vieux temps où on voyait passer dans les CVE des dizaines de SQL injection par semaine sur une base de code totale (beaucoup !) moins large. Ce qui a endigué l’épidémie de SQL injection (et je suis optimiste. Disons, vaguement contenu, vu qu’il y a encore beaucoup de projets dans la nature en mode « YOLO les ORM c’est pour les noobs »), c’est pas un coup de baguette magique qui a rendu les devs plus intelligent, c’est l’exemple de Rails et les émules qu’il a fait dans le monde PHP.

rails : qui se vantait d'une protection native des sql injections et s'en est mangé une monstrueuse il y a 2 ans…

C’est un excellent exemple que tu nous sors là. Déjà, ce n’est pas une injection SQL à proprement parler (tu ne peux pas injecter de commande SQL arbitraire). Je te refais la faille en PHP :

Le formulaire :

Nom: <input name="user[name]"><br>
Adresse email: <input name="user[email]">
<input type="submit"/>

Gestion du formulaire :

$user = User::findOne($_SESSION["userid"]);
foreach($_POST["user"] as $attr => $val) {
    $user->set($attr, $val); // ici $attr et $val sont correctement échappés : pas d’injection SQL
}
$user->validate();
$user->save();

La faille ? Simple, l’utilisateur ayant le contrôle des entrées, il peut très bien envoyer en données POST user[is_admin] = 1.

Pourquoi c’est un exemple intéressant ? Parce qu’on a là des développeurs expérimentés, qui savent ce qu’est qu’une injection SQL, qui sont tombés le panneau. Je vais te faire une confession : j’ai un jour, comme beaucoup, succombé au syndrome NIH. J’ai fait un rails-like dans mon langage favori (Objective-C. On a tous nos perversions inavouables). Devine quoi ? Quand la faille pour rails a été révélée, j’étais bien évidemment tombé dans le même panneau. En quoi cette remarque est pertinente sur ce qui nous intéresse ? Après tout, tu vas me dire : le truc fait à la main a la faille, le framework connu a la faille, 1 partout balle au centre.

Sauf que cette histoire a deux ans. Presque tout le monde l’a oubliée. Contrairement aux SQL injections qui sont martelées à la tête de tous les développeurs (ce qui n’empêche pas certains de continuer à en introduire régulièrement, parce que les ORM c’est trop usine à gaz…), le détail de cette faille n’est connu presque de personne.

Un dev qui partira sur Rails ne sera pas affecté. L’erreur a été corrigée. Lesson learned, comme disent les anglais. Par contre, un wanabee « moi j’aime pas les dépendances, je vais tout refaire à la main », je te fiche mon billet qu’il a plus (bien plus !) d’une chance sur deux de retomber dans ce panneau.

Les devs de framework ne sont pas des dieux qui codent mieux que toi, mais ils ont généralement fait les erreurs que tu vas faire avant que tu ne les aies faites. Et les ont corrigées avant que tu les fasses. Et celles qu’ils n’ont pas encore faites mais qu’ils vont faire, ben tu vas les faire aussi. Profite de leur expérience.

Tu te rends compte que pour exposer ce service REST, je dois me manger git/node/bower et pour chacun d'eux peut-être des dépendances supplémentaires qu'il va falloir que je gère sur le long terme

Tout ça n’a rien à voir avec PHP vs node. Tu peux très bien faire un .tar d’une appli node, tout comme tu peux déployer une appli PHP avec git+composer (et pour info, bower a encore moins à voir avec la choucroute, c’est pour le frontend, et c’est aussi utilisé dans des projets faits en PHP). Faudra m’expliquer la différence fondamentale entre https://github.com/symfony/symfony/blob/master/composer.json et https://github.com/expressjs/express/blob/master/package.json pour appeler l’un usine à gaz et pas l’autre.

Ce dont tu te plains c’est jusque que les devs d’applications node s’embêtent plus rarement que les devs d’application PHP à fournir une archive prépackagée. Alors je peux comprendre que ce soit légèrement irritant pour certains (perso j’ai du mal à voir en quoi git clone && npm install est tellement plus pénible que tar xzf, mais admettons…), mais de là à en faire un point bloquant, ça me dépasse…

Au passage, je ne vois pas le rapport entre réinventer la roue et les trous de sécurité.

Tu vois sincèrement pas en quoi un projet qui utilise un ORM connu et largement testé comme Doctrine aura beaucoup moins de chances d’avoir des SQL injections qu’un projet qui décide de faire toutes ses requêtes SQL à la main parce que « je veux pas embarquer 150.000 dépendances » ?

De trous de sécurité, il y en a partout même sur une bibliothèque un peu utilisée.

Je n’ai jamais prétendu que l’utilisation de librairie externes garantissait l’absence de failles.

Ça doit être ça ma grossière erreur : j’ai vu traîner (j’arrive pas à retrouver où) « Source : revenus fiscaux de 1996 à 2011 » donc j’en ai déduis que c’était non corrigé de l’inflation et avant redistribution.

Par contre si on va sur la source primaire http://www.insee.fr/fr/ffc/ipweb/ip1464/ip1464.pdf on voit que c’est bien revenus fiscaux et sociaux rétropolées, donc corrigés de l’inflation et après redistribution.

Mea culpa donc.

sans les 15.000 dépendances utilisées et un gestionnaire de paquets propre à chaque couche

Tu veux dire, le temps où chacun réinventait la roue de son côté, de préférence carrée en apportant son lot de trous de sécurité (XSS, SQL injections, local/remote file inclusions) et ses correctifs douteux (magic quotes) ?

Après si c’est ton trip tu peux très bien faire du node sans npm et 0 dépendances en réécrivant tout toi-même avec amour, la technologie de base n’a pas grand chose à voir avec ça. Dans le fond j’ai du mal à voir en quoi express est plus usine à gaz que symfony.

Et surtout, depuis 30 ans 100% des gens se sont enrichis, zut alors

Ça n’a pas l’air corrigé de l’inflation. Et à la louche, l’inflation entre 1996 et 2011, c’est 25%

rate = [_/100+1 for _ in [2.0,1.2,0.7,0.5,1.7,1.7,1.9,2.1,2.1,1.8,1.6,1.5,2.8,0.1,1.5]]
inflation = 1
for r in rate: inflation *= r
print inflation
# => 1.2584748858666641

(données : http://www.insee.fr/en/themes/series-longues.asp?indicateur=inflation)

Ce qui donne pour conclusion que tout le monde s’est appauvri. Mon intuition me dit le contraire, mais je n’ai pas le temps de creuser pour voir si c’est mon intuition qui est mauvaise ou si j’ai tout simplement fait une erreur grossière.

Autre problème du graphique, c’est qu’il prend en compte les revenus avant redistribution. Après redistribution, ce serait plus intéressant.

Voici les outils de coreutils :

[ base32 base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes

Quel est la demi-douzaine qui permettent de créer un fichier vide là dedans ? Je vois dd if=/dev/zero of=file count=0, echo -n >> file et truncate -s +0 file. Les trois sont casse-gueule dans le sens où si tu te plantes dans les arguments (> au lieu de >>, oublier count=0, 0 au lieu de +0) et que le fichier existe déjà, ben paf le fichier.

Aucun moyen de savoir lequel est le repo upstream (c'est un des trucs pour lequel je comprends pas l'engouement pour github d'ailleurs!).

Tu n’as pas quasiment pas d’upstream et de forks, si tu excepte le premier résultat qui s’est fait pas mal forker (et tu ne vois aucun des forks dans la première page de résultats). C’est une trentaine de projets différents qui ont pris le même nom.

Pour trouver l’upstream sous github c’est simple : prend https://github.com/pitkley/paperless par exemple, tu as "forked from" sous le nom qui est un lien vers l’upstream, en l’occurrence https://github.com/danielquinn/paperless.

Dit-moi que GitLab CE fait tout ce que fait GitHub, et on en reparle.

Depuis quand un logiciel doit avoir exactement les mêmes fonctionnalités pour être un équivalent viable ? Office 2016 n’est pas une alternative viable à Office 97 par manque de trombone rigolo ?

ai-je dit le contraire?

Oui :

Certains aiment, OK, mais de la à parler de LL…

Ça veut pas dire « on peut pas parler de LL en ce qui concerne gitlab » ?

mais de la à parler de LL

C’est pas toi qui pestait contre les idéologues qui invoquaient « l’esprit du libre » à tout bout de champ pour des trucs qui n’avaient rien à voir avec la choucroute ? Parce que là tu fais exactement la même chose.

Gitlab CE est libre, point. Tu peux l’utiliser sans restriction, le modifier, le redistribuer, et redistribuer tes modifications. Ça satisfait aux critères de l’OSI, de la FSF et des DFSG.

Comme tu l’as dit toi-même dans un autre contexte, un logiciel est libre ou ne l’est pas, et il l’est s’il satisfait à la définition d’un logiciel libre, un point c’est tout. Gitlab CE est libre. Que les méthodes de Gitlab inc te déplaisent n’y change absolument rien.

Moi et d'autres amis dans leurs boites respectives on utilise github en équipe avec process de review, merge request, CI… et on est très heureux.
et?

Et ils le font avec du logiciel libre (oui, tout ça est dans Gitlab CE) contrairement à ceux qui font ça sous Github.

Justement non, je fais gaffe à ce que j’installe, du coup je ne me retrouve pas avec des services inconnus qui écoutent sur des ports dont je n’ai pas besoin. Les ports ouverts sont ceux dont j’ai besoin, les autres sont fermés pour la bonne et simple raison que personne n’écoute derrière, pas par un firewall dont je ne vois pas l’utilité.

mais le firewall j'ai rien compris, alors j'ai ouvert tous les ports sur ma CoincoinBOX

J’aimerais qu’on m’explique un jour les raisons derrière ce fétichisme de « il faut fermer tous les ports même s’il y a rien qui écoute derrière ».

Sur mon VPS perso j’ai 0 ports fermés et j’ai du mal à voir où est le problème.

Paperwork est l'outil idéal pour les flemmards

Je vais donc faire mon enfoiré d’utilisateur flemmard qui pose des questions avant de lire la doc :)

• J’ai déjà un gros paquet de documents .djvu, .pdf, .jpeg scannés. Je peux les importer facilement ? (je veux dire sans les reprendre un par un). Si possible en donnant une liste de correspondances "tous les docs de ce dossier auront ce tag" (la FAQ répond à la première question, pas la seconde)
• C’est backup-friendly, dans le sens ou tout (images, métadonnées type tag, OCR…) est contenu dans un seul dossier bien précis, ou c’est plutôt dispatché aux quatre coins de mon $HOME ? (de ce que je vois dans la FAQ, ya un index ailleurs que dans ~/paper: si j’omet de le sauvegarder, il est recréé lorsque je restaurerai une sauvegarde ?)

Merci à vous deux pour vos réponses :)

On préfère historiquement le XPath car il est beaucoup plus puissant. Cependant dans les cas simples, c'est moche, et c'est plus difficile d'accès.

Pourquoi du coup ne pas avoir mis CSS par défaut et une fonction XPath quand on a besoin de cette puissance plutôt que l’inverse ?

De fait, une classe APIBrowser a été rajoutée, ainsi que des filtres permettant de parser le JSON de façon similaire aux filtres CSS ou XPath.

Justement, comment ça marche les filtres CSS ?

Je suis en train de regarder par quoi remplacer mes scripts de scrapping qui traînent à gauche et à droite, en en réécrivant avec scrapy/weboob.browser. Et je dois dire que autant je préfère de loin le design général de weboob.browser, autant xpath me donne de l’urticaire. Par exemple, comment remplacer les sélecteurs xpath par des sélecteurs css dans l’exemple de la doc ?

class ListPage(LoggedPage, HTMLPage):
    @method
    class get_accounts(ListElement):
        item_xpath = '//ul[@id="list"]/li'

        class item(ItemElement):
            klass = Account()

            obj_id = Attr('id')
            obj_label = CleanText('./td[@class="name"]')
            obj_balance = CleanDecimal('./td[@class="balance"]')

(pourquoi xpath pue objectivement la merde pour le scraping ? parce que le sélecteur pour balance par exemple ne fonctionnera pas sur <td class="closed-account balance numeric">. En xpath pour sélectionner une classe c’est [@class and contains(concat(' ', normalize-space(@class), ' '), ' balance ')])

M’enfin toujours est-il que j’arrive pas à trouver quelque chose qui se rapproche de la simplicité de la mini lib que je m’étais faite (qui a par contre l’inconvénient d’être mal testée et bugguée à mort), je trouve ça un peu décevant :(

C'est une nouvelle frontière explorée depuis 30 ans par Perl et soigneusement ignorée par ailleurs

De très très loin, ça ressemble pourtant très fort à la métaprogrammation de F#, et aux macros de Rust, Nim et Scala, non ?

Oui : http://www.regular-expressions.info/possessive.html

Pour faire court, c’est pour interdire au moteur d’expression régulière de faire du backtracking sur un choix précis. Ici, c’est le choix est : "a?" matche-t-il un caractère ou 0 ?

/^a?ab/ arrivera a matcher "ab", mais /^a?+ab/ n’y arrivera pas, parce que dans le second cas "a?" a pris la décision de consommer le premier "a", et il ne reviendra pas sur cette décision ("+"), même quand cette décision implique un échec de la reconnaissance globale.