benja a écrit 1211 commentaires

impardonnable la violation de leurs droit à la vie privée

Mouarf… Avec une prise de position si tranchée, c'est effectivement mieux que tu passes par un intermédiaire pour "éduquer" ces gens… :D

Sérieusement cette loi sur les cookies est vraiment un WTF intégral. Cela rend la navigation privée très très pénible. Ce qui est un comble car la personne la plus à même de protéger sa vie privée, c'est précisément elle-même… et on fait tout pour l'en dissuader :D L'autre effet pervers, c'est que les bad guys utilisent des stratégies plus sophistiquées (sans dépendre des cookies) pour suivre les gens, ce qui enfonce un deuxième clou dans le cercueil de la navigation privée.

Je passe certaines aberrations techniques pour conclure la liste des effets pervers: amha entreprendre des procédure administratives à tout va, va avoir pour conséquences: 1) le découragement de certains acteurs, i.e. les gens que tu vas emm*der 2) le recrutement toujours plus important de ce personnel administratif (certains peuvent y voir un avantage… no comment) 3) une diminution des fraudes et autres acteurs malveillants le risque que les dits acteurs honnêtes mais découragés vont se tourner soit vers une carrière de fonctionnaire à la CNIL, soit vers le piratage sans fois ni lois (ce qui est probablement intellectuellement plus stimulant), mais cesseront clairement d'investir de l'énergie à combattre des moulins à vents. Je ne pense pas que la valeurs des avantages dépasse celles des inconvénients.

Au choix:

1. si par "sans soucis" tu entends sans devoir entrer de password, que ce soit le mot de passe de ta clef ou le mot de passe de ton utilisateur remote, c'est que tu utilise probablement le mauvais nom d'utilisateur. Vérifie que ton "Libvirt URI" soit "qemu+ssh://[USER]@[HOST]/system" avec le même [USER] que dans ton test.

2. SSH ne trouve pas ssh-askpass, ce qui peut-être un bug dans guix ou pas. Cependant tu peux lui indiquer le chemin en exportant la variable SSH_ASKPASS=/chemin/vers/ssh-askpass avant le lancer virt-manager. Consulte la documentation de guix pour savoir comment retrouver le path de l'exécutable dans le paquet que tu as installé. Sur une distrib traditionnelle il devrait se trouver dans /usr/libexec/openssh/XXX-ssh-askpass. Alors dans guix, ca va être un peu plus dur à trouver, mais bon vu que c'est ton choix de distrib tu es sensé pouvoir te démerder… au pire fais un env SSH_ASKPASS=`find /gnustore -name \*askpass\* -executable -type f | head -1` virt-manager ;-)

3. Vu que tu souhaites t'authentifier par clef, le password qu'il te demande est sensé être celui de ta clef privée. Il suffit de la charger dans ton agent ssh pour ne plus devoir la déchiffrer au moment où virt-manager utilise ssh. "ssh-add maclef" devrait faire l'affaire…

4. Virt-manager se torche comme un pochtron, enlève la ligne contenant "show_errmsg = False" de /usr/share/virt-manager/virtManager/lib/connectauth.py et tu auras un message plus explicite (%modulo le path dans le gnustore…).

5. En fait non, je n'ai pas d'autre idée clef en main… Je ne sais pas comment guix gère les binaires de types "libexec". Pour un binaire classique, c'est facile il est dans ton profile, et un simple which binaire te donne le path complet. Pour un libexec, à priori guix doit patcher cela à la compilation (tout comme les !shebang etc). Donc à mon avis, tu (ou virt-manager) utilise(s) le mauvais paquet "client ssh", ou bien c'est un bug dans guix. Tu auras plus d'info en contactant les gens de guix directement! Feel free de backfeeder ici lorsque tu auras ta solution…

je n'ai pas encore vu les generateurs/iterateurs. est ce que cest la commande yield?

Oui c'est exactement ça dont je parle, il y a un tuto ici https://realpython.com/introduction-to-python-generators/#example-1-reading-large-files

Dans ton cas, tu ne vas pas construire ta grande liste de petites liste en une fois, mais simplement tes petites listes au fur et à mesure que tu lis chaque ligne. Parfois cela impliquera de refaire un calcul (pour recommencer au début du fichier f, faire f.seek(0,SEEK_SET) cf. documentation), mais c'est un compromis nécessaire quand tu travailles avec de grosses données. Voir aussi la notion de fold/reduce pour le big-data, les algos pour calculer des moyennes cumulées, etc.

pr le swap, tu parles bien d'un reglage de l'os?

Oui cela permet d'augmenter virtuellement la mémoire disponible pour un programme au prix de très mauvaises performances, voir de problèmes de stabilité pour les autres programmes, à éviter donc. C'est défini par la taille de ta partition d'échange ou de fichier swap supplémentaires (comme sur windows). Dans ton cas, tu peux voir ton fichier comme un swap, c'est-à-dire de la mémoire stockée sur disque et chargée à la demande, pas besoin de le charger deux fois en "mémoire" donc.

je n'ai pas vu de doc sur le calcul de la memoire necessaire

Il ne s'agit pas de faire un calcul précis mais juste une approximation, bien que comme tu as l'air d'en être au courant avec beaucoup de recherche sur les types de datastructures utilisée par python il doit être possible d'être assez précis. Genre comptons au pif 10 octets par entiers, 16 octets d'overhead de la liste par valeur d'entier (2 pointeurs ?), 100 pour par liste en elle même (entête, stats, ref gc, etc. ??). et que dans ton fichier original tu utilise en moyenne 3 octets par valeurs, ca te fais 800*1M/3*26+100*2 octets, fin bref grosso-modo un facteur*10 en python… Bien sûr à cela tu vas devoir ajouter la mémoire utilisée pour faire ton traitement et tes résultas intermédiare, sauf si c'est négligeable (exemple: pour calculer la moyenne il te faut juste stocker une somme et un compte).

Si ces données sont structurées, pourquoi ne pas importer tout cela dans un serveur sql qui saura correctement gérer la mémoire et travailler avec des fichiers d'échanges le cas nécessaire ?

Sinon pour répondre à tes questions, non python n'alloue pas des buffeurs énormes pour faire des I/O. Étant donné qu'il n'y a que deux fichiers (entrée et sortie), il est très peu probable que ceci soit la source de tes problèmes. Il est probable que la mémoire soit utilisée par tes listes justement, surtout si tu utilises beaucoup de listes intermédiaires. En ce qui concerne le ramasse-miette, python utilise également ce concept tout comme java, sauf qu'il se base sur le comptage de référence, là où java analyse le graphe des valeurs accessibles. Hormis cette différence d'implémentation, ceux-ci ont la même fonction. Il faut bien faire attention de ne pas garder de références sur les résultats intermédiaires plus longtemps que nécessaire, afin de permette la libération de la mémoire utilisée par ceux-ci.

Suggestions: utiliser les générateurs/itérateurs, activer plus de swap, calculer un l'ordre de grandeur de la mémoire nécessaire et vérifier la faisabilité, éviter de lire tout le fichier d'un coup (faire du ligne-à-ligne ou utiliser mmap).

Il n'y a pas besoin d'utiliser ce dépot qui ne contient en fin de compte que la libaio et une version obsolete d'oracle xe (on parle de +de 14 ans qd meme :p). Cette librairie est depuis bien longtemps disponible dans les dépots debian/ubuntu officiels.

Un simple apt install libaio1 fera l'affaire avant de lancer l'installateur officiel d'oracle d'une version plus récente. À priori tu dois pouvoir le télécharger après un simple enregistrement. Il te faudra aussi probablement installer le paquet build-essential afin que le relink fonctionne. Si je me souviens bien (ca date la dernière fois que j'ai fais celà…), il y a un ou deux binaires qui n'ont pas le même path dans red-hat que dans debian, un symlink pourra résoudre le problème facilement si tel est toujours le cas. Après plusieurs essais/erreurs tu devrais y arriver.

Ce qui est déterminant pour pouvoir dire qu'un disque/clef un un problème, ce sont les messade de type erreure I/O.

[ 7218.332054] print_req_error: I/O error, dev sdb, sector 741029880

mais c'est probablement causé par le fait que le bus usb se déconnecte/reconnect (voir mon message au dessus).

Avant de jetter quoi que ce soit à la poubelle (une enclosure + un hdd dans ce cas présent ?), vérifier que le problème ne soit pas du à un mauvais cable, mauvais connecteur, voir changer de port usb2/usb3, changer de carte mère (=> pas assez de voltage sur le port, certains dd exigent un peu plus que le 700mA). Rien n'indique que le problème est lié à la "clef", c'est une possibilité mais pas la seule…

[ 7221.660299] usb 2-4: new SuperSpeed Gen 1 USB device number 22 using xhci_hcd
[ 7221.684386] usb 2-4: New USB device found, idVendor=2109, idProduct=0711, bcdDevice= 1.44
[ 7221.684391] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7221.684394] usb 2-4: Product: VLI Product String
[ 7221.684397] usb 2-4: Manufacturer: VLI manufacture String
[ 7221.684399] usb 2-4: SerialNumber: 000000123AE7
...
[ 7283.144174] usb 2-4: USB disconnect, device number 22

De plus, ext4 n'aime pas vraiment que l'on fasse un DD sur un disque dont une des partition est déjà montée… ce qui peut expliquer certaines erreures :D

Donc tu te reposes sur le fait que tous tes clients sont 1) correctement configués et 2) non-buggés. C’est assez osé à mon sens comme pré-requis.

Ben oui malheureusement il n'est pas possible de faire autrement, c'est ce que j'essaye de dire depuis le début: il est impossible de se prémunir d'un MITM si le client ne vérifie pas le certificat. Mais pas la peine de paniquer, c'est ce que font les client sérieux depuis plus 15 ans…

Deusio je n'ai jamais dit qu'on ne pouvait pas forcer un canal sécurisé côté serveur, mais ça n'a rien à voir avec STARTTLS ou pas. voir ci dessous

L’argument du « je ne contrôle pas ce qui se passe en dehors de chez moi alors ça sert à rien que je me casse le cul à faire attention chez moi »

Ca s'appelle un reality check. mettre une porte blindé sur une cabane en bois, je ne trouve pas cela très productif :)

C'est d'autant plus amusant de venir me reprocher cela alors que tu souhaites vouloir ignorer le problème de la configuration du client :D

Je pense que s'assurer que le client en bien configuré ou a le bon comportement est plus nécessaire: pour continuer mon analogie, vérifier le certificat équivaudrait à monter des murs en brique sur sa cabane.

Justement le STARTTLS stripping dispense l’attaquant de devoir monter un vrai MITM. Rendre le STARTLS stripping impossible complique la tâche de l’attaquant qui n’a dès lors plus le choix, il doit faire un vrai MITM.

Ca ne sert à rien de répéter cet argument pour le rendre vrai. Il suffit d'empêcher le relais pour les users non authentifiés et forcer l'authentification sur un canal sécurisé (comme je l'avais indiqué dans mon premier commentaire déjà). Point.

Voir http://www.postfix.org/SASL_README.html#server_sasl_enable

To offer SASL authentication only after a TLS-encrypted session has been established specify this:

/etc/postfix/main.cf:
    smtpd_tls_auth_only = yes

nitpick: s/il faut vérifier la CA/il faut vérifier le certificat/

Désolé, je reposte pour compléter un peu.

Sans vérification du certificat […] seul le TLS explicite est vulnérable au STARTTLS stripping.

Ceci est absurde comme argument, le starttls stripping n'apporte rien si l'attaquant est déjà en position d'impersonniser le serveur.

Au lieu de dire que "TLS imlicite est mieux" (c'est faux), il faut dire "il faut vérifier la CA" et imposer le chiffrement côté client. Notons aussi que certains clients n'ont pas d'option STARTLS ou TLS/SSL, simplement SSL qui veut dire n'importe lequel du moment que c'est chiffré, ce qui est un comportement raisonnable et sécurisé.

En TLS explicite, l’attaquant peut forcer les deux parties à communiquer en clair simplement

C'est pour ca que j'ai appuyé sur le fait que le client doit être aussi correctement configuré, tant sur le choix de l'option tls que sur la vérification de CA. Donc non, pas possible de forcer le downgrade (ou alors il y a un bug dans le client), c'est orthogonal à STARTTLS vs TLS… (nb: certaines version de TLS sont aussi succeptible à des "downgrades"-attack). Si j'ai coché "starttls" dans la config de mon client, qu'on appelle ça explicite ou implicite*, il n'est pas sensé basculer en plain-text.

TLS stripping se transforme en déni de service

Si tu as un MITM, ce sera sans doute là la cause de ton déni de service. TLS ou startls ne sont pas plus immunisés l'un que l'autre. À nouveau, le TLS stripping n'est pas possible si le client est correctement configuré/implémenté.

OpenPGP ne protège que le corps du message, pas toutes les métadonnées associées.

toutafé, il ne protège pas l'envelloppe. de ce point de vue là, tls leak "juste" l'addresse ip, ce qui peut donner pas mal d'info aussi…

Que penses-tu de mon argument de ne pas avoir de certitude quant à la suite du chemin ? N'as tu pas peur de te reposer sur un faux-sentiment de sécurité ?

*: ceci est une boutade, pas la peine de me dire que j'ai rien compris à la rfc :p

As-tu pu utiliser un débuggeur pas-à-pas ?

Sinon tout à fait d'accord avec toi, j'ai faillit le mentionner mais amha c'est plus l'exception qui confirme la règle de ce qu'on peux trouver en mainstream… Notons qu'en java tu t'affranchis dès le départ une partie de la gestion de mémoire aussi. J'ai récemment développé un prototype en scala avec un DSL en groovy et j'ai trouvé celà très facile à faire et satisfaisant quant au résultat. Facile et modérément complexe :) Mais je n'ai jamais utilisé de debuggeur java, c'est aspect là m'échappe.

Hormis les considérations entre MTA évoquées plus haut*, ta question portait initialement sur la communication entre MUA et MTA/MDA. Que je sache, il n'y a aucune différence entre TLS et STARTLS en ce qui concerne la possibilité d'un MITM (et vouloir s'en prémunir me semble vain, voir de nouveau*) et il te faudra configurer correctement les 2 côtés, c'est-à dire imposer (START)TLS et contrôler le certificat côté client (=> éviter de se reposer sur une CA externe pour les plus paranos).

Le plus important reste que ton MTA/MDA n'accepte que le mails destinés à lui où émis par un utilisateur duement "authentifié". Dans ce cas, (START)TLS permet simplement de savoir que tu parles à ton serveur, je n'y vois pas d'autre avantage. Techniquement on peut s'authentifier en "clair" de manière sécure, juste que sans certificat tu ne sais pas à qui tu parles… Ce qui n'est pas spécialement un problème, voir *.

*: personnellement il me semble absurde d'exiger que la communication entre ton MTA et le next-hop soit chiffrée sans avoir aucune garantie sur la suite du parcours… utiliser pgp pour la confidentialité/intégralité!

Autant prendre la version de groovy au lieu de la version 2.3.2 qui est sortie en 2016 tout de même. À priori elle s'installe toujours sur 20.04/focal (d'après une inspection manuelle et sommaire des dépendances). Cf. https://packages.ubuntu.com/search?keywords=amule pour trouver les fichiers deb…
L'autre option c'est d'upgrader vers groovy qui est vraiment juste au coin de la rue…

Il est probable que la non utilisation du 8bit soit le facteur déterminant (quelque chose me dit que c'est plus facile à implémenter au niveau HW que du 9 ou 10 voir 12…) surtout que le 8 est sensé être plus que suffisant ~= 24bpp en rgb, pas sûr que la télé du gars ou que ta source puisse faire mieux. Il me semble aussi qu'un constructeur n'a pas le droit d'annoncer le support hvec s'il ne supporte pas le profile le plus basique, donc essaye en h265/8b en désactivant toutes les extensions p-ê ?

Effectivement pour un même codec il y a différents réglages ou profiles possibles, notamment la profondeur des couleurs en nombre de bits (le 10 de "main 10") fait varier la taille de certaines matrices et donc cela exige des codes (ou des circuits dans le cas d'une accélération matérielle) différents. Le mieux je suppose c'est d'utiliser un profile le plus basique ou ancien possible pour s'assurer d'une compatibilité maximale. https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles

On pourrait même dire que l'existence même de ce journal prouve bien que ce n'est pas trivial d'embarquer un langage dans un autre :D Ceci dit, cela n'a rien de spécifique à python/c… Au même titre que l'écriture d'un interpréteur ad-hoc ou de faire de la génération de code, cela rend le débuggage plus complexe.

Il y a embarquer et embarquer… Ici, l'embarcation ne va pas beaucoup plus loin qu'un simple system("python -c 'print(\"hello world!\))'");. Là où ça commence à devenir compliqué c'est lorsqu'il faut échanger des valeurs entre le monde python et le monde C avec des difficultés de gestion de la mémoire, conversion de types, contrôle de l'environnement (recherche des bibliothèques, contexte d'exécution), etc. De plus, l'auteur a choisi de s'interfacer avec la bibliothèque C de python qui (par définition) n'offre aucune facilité pour le C++. Là où une bibliothèque spécifiquement conçue pour le C++ (telle que Boost.Python ?) offrirait très certainement plus d'automatisme ou de facilités.
Bref, je m'abstiendrais de tirer quelconques conclusions sur cet exemple si simple.

PS: Le commentaire ci-dessous m'a intrigué: pourquoi interrompre le traitement si l'appel à Py_SetProgramName est optionnel ?

    if (program == NULL) {
        fprintf(stderr, "Fatal error: cannot decode argv[0]\n");
        exit(1);
    }
    Py_SetProgramName(program);  /* optional but recommended */

En quoi supprimer certaines informations (nom de l'outil, nom du calque et du fichier -> bonjour la prise de tête quand tu travailles sur plusieurs calques en même temps) et réduire l'aire de toutes les surfaces de contrôle améliorent l'ergonomie (au pif, tu l'as divisée par 2, cela demande 2x plus de précision/temps de la part de l'utilisateur) ?

Quand au slider moins pratique, t'es tu fais ton opinion en ayant lu l'explication (illustrée!) dans cette nouvelle ? Ou simplement suite à de longues années de pratique subitement remisent en cause par la nouvelle version ? :P

J'ai récemment appris l'existence de cette "feature" car elle est indispensable pour pouvoir booter un sparc. L'openboot firmware ne pourrait démarrer que sur la partition qui commence au secteur zéro, partie qui contient aussi la table de partition (a.k.a. "sun disklabel") et, a fortiori, le bootblock. Ne me demandez pas comment grub s'en sort pour s'insérer dans ce bazard, ça marche juste.

Bravo à ton équipe et à toi pour cet excellent boulot. Encore quelques pistes:

• pourquoi inclure du code généré dans le tree? traditionnellement on fait une sorte de "make dist" qui va générer tous le fichiers nécessaires à la distribution d'un tarball source.

• si le code conflictuel est uniquement issu des fichiers générés, ne les générez plus… :) ou bien uniquement dans des branches dédiées.

• n'est-il vraiment pas possible de fusionner le tout après une certaine réorganisation ? Ce qui est dans /example devient example/gtk2, /src/ -> /src/gtk2, ce qui est commun ou qui peut facilmenent le devenir (mode de compilation et/ou #define) va dans /src/common. Le coeur de génération a déjà l'air d'être commun ce qui est une très bonne chose. J'imagine que le gros du travail sera de fusionner les fichiers cmake/meson. Il suffirait à mon sens de générer une (sous-)librairies par version de gtk, rien d'impossible AMHA.

• si vraiment vous souhaitez garder des branches, avoir une telle séparation au niveau des noms des répertoires et fichiers simplifiera grandement les différents merges. Par exemple: vous développez src/cfwrapper dans sa propre branche que vous fusionnez régulièrement dans les branches gtk2,3 (et 4)…. Mais encore une fois, celà me semble une approche compliquée.

• git-filter-branch/filer-repo peut aider à faire ce genre de réorganisation en gardant l'historique.

Autant essayer de tout avoir dans une seule branche. Les modifications au code commun n'auront pas à être fusionnées (cherry-pickées), le code séparé est considéré "optionel" (i.e. ./configure --enable-gtk5), et est soit entouré de #defines et/ou dans des fichiers ou dossiers séparés. Les branches te servent uniquement au release management: grosso modo des branches de feature, une de dévelopement dans laquelle les précédentes sont fusionnées, et une ou plusieurs branches de versions stabilisées. À mon avis c'est le moins prise de tête (imagine d'avoir une branche dev pour gtk3, pour gtk4, et puis par feature, etc. ça va vite être ingérable tant pour toi que pour git…).

Cela pourrait être un problème de session/cookies, cf. http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cookie_domain pour nginx. Si tu réécris l'en-tête host, assures-toi de réécrire l'attribut domain du set-cookie de la réponse, si présent. Bon je dis ça c'est juste une autre piste… La question est de savoir si cela fonctionne déjà en mode reverse proxy simple, c.-à-d. sans réécrire le Host mais en bidouillant le /etc/hosts du client et/ou du proxy.

Pour info une idée similaire est implémentée dans le make de FreeBSD, sous le doux nom de meta mode. Note qu'il utilise une interface spécifique à FreeBSD à la place de ptrace, probablement pour des questions de performance (?). Peut-être pourrais-tu t'en inspirer pour porter ton smk sur FreeBSD ou inversement utiliser tes compétences pour porter bmake+meta mode sur Linux/ptrace ?

https://www.freebsd.org/cgi/man.cgi?query=make

Cela concerne aussi (surtout, à vrai dire) les communications professionnelles. Je me demande comment ce genre de pratique peuvent encore être justifiées avec le règlement sur les données personnelles (GDPR). Il s'agit bel et bien d'un traitement automatique de données, y compris (forcément) de données personnelles appartenant tant à l'employé, ou à un tiers avec lequel cet employé communique. Et pour lequel aucune autorisation n'a été accordée…