Firwen a écrit 562 commentaires

Mais c'est assez anormal que passer par eux soit obligatoire pour pouvoir accéder au site d'une banque française.

Déja le fait que tu as un CDN externe qui peut injecter du code JS arbitraire sur le site de ta banque où tu as ton interface de login est une honte en soit.

Est-ce étonnant venant de la pire des banques. Je ne comprends pas qu'elle tienne encore debout.

De manière assez intéressante, un peu prêt toutes les banques Françaises sont qualifiées comme "la pire des banques" suivant à qui tu t’adresses :D

A chaque nouvelle version de Firefox, je découvre de nouveaux services privateurs intégrés, de la télémétrie, des pubs pour des services de la mofo…

Il n'y a rien de "privateur" dans la télémétrie, surtout si elle est anonymisée proprement.

Il y arrive un moment où il faudra peut-être réalisé que Mozilla n'est pas un dieu et n'est pas omniscient.

Si on veut qu'ils continue à développer (gratuitement) un produits adapté à leurs utilisateurs, il faut au moins qu'ils connaissent ce que leur utilisateurs font de leur produit.

J'ai personnellement aucun problème avec une télémétrie anonyme quand c'est dans les mains d'une fondation comme Mozilla.

Si J'apprécie et j'applaudis la démarche, car les entertainements systems ont je pense un grand besoin d'être pen test.

Fait attention dans ta démarche, car le TSA n'est pas connu pour son grand sens de l'humour et plusieurs personnes qui ont fait ça se sont retrouvé sur la no-fly-liste des USA.

https://www.reddit.com/r/netsec/comments/5jdjeu/hacking_inflight_entertainment_systems/

Ceci dit, je pense que plus de personnes devrait faire ça. J'ai déja vu un bon nombre de ses systèmes en error mode qui relachaient des informations internes ( MAC address, IP, RAM, kernel version, etc ) tout en rebootant en boucle.

Où as-tu vu que MinIO n'était pas fait pour la prod ?

Petite expérience: Pour avoir tester MiniIO pendant quelques mois, je le déconseillerais.

En mono noeud, l'expérience est satisfaisante. En multi noeud (cluster de dix noeuds), on a eu à faire à des crashs, des problèmes de réplications, et une incapacité à supporter une forte charge ( perf qui dégrade assez rapidement ).

L'évaludation était en début d'année dernière (2018) et sur machines virtualisées je précise, ça s'est peut être amélioré depuis.

Fait est que nous avons maintenant un cluster Ceph avec le support S3 fourni par RadosGW qui est d'un tout autre niveau en terme de stabilité.

Donc un même paquet (disons une bibliothèque), avec les mêmes options et tout et tout, mais compilé avec un compilateur GNU et un autre Intel (par ex) vont pouvoir vivre leur vie proprement dans l'écosystème nix sans conlits vicieux ? Bonne nouvelle, je vais essayer!

Nix installe chaque package dans son propre prefix isolé de tout le reste du système. Chauqe paquet est compilé dans une sandbox où il n'y a que ses dépendances de visible. Donc avoir plusieurs version de compilateur, où même du même paquet n'est pas un problème.

Oui mais ça dépend de la config Kernel de ton installation.

Comme je n’étais pas root et que bien sûr un tel répertoire était impossible à obtenir, j’avais dû abandonner.
Sais-tu si ça marche de ce côté-là ?

C'est trés fortement déconseillé de ne pas utiliser /nix. Si tu n'as pas les droits roots, tu peux par contre simuler un "/nix" en utilisant un mount bind et les linux namespaces.

Je travaille dans la simulation numérique et j’ai jeté un œil à spack qui permet d’installer des paquets en personnalisant les dépendances par de simples arguments depuis la ligne de commande.

Spack est trés bon mais il ne supporte pas le deploiement de binaires de manière fiable… car justement il n'a pas de prefix absolu comme "/nix". Donc tu dois souvent tout recompiler dés que tu changes de machine.

Que penses-tu de l’utilisation de nix (et de toutes les variations que tu présentes en ce moment : je te remercie) dans ce contexte ?

Tu peux avoir 50 compilateurs en parallèle avec Nix, ce n'est pas un problème. Configurer un nouveau compilateur n'est pas la chose la plus accessible à faire par contre.

Merci pour ce retour d'expérience intéressant. Vous utilisez un système de cache, comme hydra ou cachix, pour éviter les recompilations ?

Oui, mais purement based sur du S3. Les résultats de build sont généré par Jenkins.

Merci pour le journal.

Pour la petite note:

Nous utilisons Nix + overlays comme medium pour déployer toute la stack logiciel de la boite où je travaille.

• Une version de nixpkgs taggué nous fournit tous l'environnement existant.

• Nos softs sont ajoutés comme un seul overlay par dessus.

• C'est suffisament puissant et stable pour deployer une stack d'une centaine de logiciels sur environs 200 machines en production et de manière synchrone.

Ton poste en serait drôle si c'était malheureusement pas si commun.

Je ne compte même plus le nombre de C.V que j'ai vu passé fait par des rois du Bullshit.

• Des experts C++ qui se qualifie 4.5 / 5 en C++ et qui sont perdus dés avec 3 minutes quand tu leur parle de VTable.

• Des indiens auto-proclamé "tech lead" qui sortent du MIT…. enfin sa version indienne, le Mumbai Institute of Technology ( veridicte, j'ai déja vu ça sur CV ).

• Des gens taggé "Senior Programmeurs" qui sont pas foutu d'écrire 4 tests unitaires.

• Des "experts" qui sont perdus quand tu leur demandes de coder une factorielle dans leur language de prédilection.

• Des "experts" python qui te parlent des dernières features à la mode et qui sont pas foutu d'écrire un setup.py.

L'adage moderne du business "Fake it until you make it" a envahi l'IT en parti à cause de ses salaires élevés dans certains domaines et ça c'est bien dommage. On est passé de la recrue typique "geek (trop) timide en manque de confiance" à "Bullshitteur en costard qui vient de lire un bouquin et qui se veut déjà manager".

Avant de chercher toutes les excuses du monde, on pourrait d'abord s'intéresser à ce que l'on peut faire nous.

Quand tu as un problème qui touche tout une industrie. Tu cherches "pourquoi" avant de blâmer des individus.

En tant que développeur je ne suis pas fier que l'industrie à la quelle je fais parti n'arrive pas à éradiquer ce genre de choses

Quand on peut avoir un code qui prouve l'inexistence de certains bug ça vaudrait le coup qu'on arrête de faire les flemmards en se trouvant des excuses.

Tu m'excuseras, mais ça c'est une vision idéaliste ou d'académique ( même si sur ce fond je suis d'accord avec toi ).

Il y a des raisons à la dégeulasse-itude ambiante des softs, et ça n'a rien à voir avec les solutions techniques pour éviter ça. Les solutions techniques, elle existent depuis 3 décades, et rien n'a changé.

Les raisons du bordel et de la tristesse de la situation sont simple:

• Le manque de temps
• Le manque d'argent
• Les méthodes de management débiles omniprésentes où le produit doit être fait pour hier et sur 5% de ton temps de dev qui ne font que empirer les raisons précédentes.

Et Le résultat c'est :

• Que le code en C embarqué de ta voiture a été fait à la va vite. probablement par trois équipes différentes en Inde. Et que ni toi, ni même la NASA n'arriverait à la comprendre ( http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code ).

• Que > 300 personnes ont perdu la vie dans un 737 MAX parce que Boeing a trouvé bonne l'idée de faire une rustine logiciel dégeulasse développé par une team externalisée pour régler les problèmes d'un avion vieux de 30 ans.

• Que la plupart des sites web que tu visites sont des blobs infames en JS fait à la va vite qui shippent 3MB de JS, car ils ont été fait par une team sous dimensionnés de développeurs "full stack" qui ont produit ça à la va vite à grand coup de NPM.

• Que la première action des jeux vidéos que tu achètes de nos jours est de faire une mise à jour de 25GB avant même de se lancer car l'équipe de dev était tellement sous pression qu'elle a a sorti un produit baclé et inachevé pour respecter les deadlines.

Et des exemples du genre, je suis sur que les gens ici peuvent m'en rajouter une 20eme facilement.

Le problème de la sécurité logiciel, c'est un problème avant tout humain et surtout un problème de management.

Tant que la politique ambiante sera "délivre aussi vite que tu peux, le lifetime, l'architecture et la maintenance on s'en fou, il nous faut un MVP", ça restera comme ça et ça n'a rien à voir avec un problème de "flemmard", c'est encore une fois, un problème de management.

C'est un point qui me paraît effectivement très dommage dans le design du C++. Ecrire du code fragile est rendu plis facile qu'écrire du code robuste. On peut comparer à Rust qui opte pour la sécurité par défaut et permet d'ôter certaines protections en les identifiants clairement (unsafe, type dédiés, etc …).

C'est deux approches opposé:

• Rust est safe par défaut, unsafe on demand.
• C++ est unsafe par défaut, mais te donne des primitives safes à la demande du programmeur.

La première approche fait confiance au compilateur, la deuxième approche fait confiance au programmeur.

J'aurai tendance à dire que la première approche (Rust) semble plus logique sur le papier et plus approprié à du développement où la sécurité compte.

Mais à en croire pas mal de retours de blogueurs, l'approche de Rust peut aussi se révéler passablement pénible quand le modèle mémoire ne s'y prette pas ( Graph avec multitude de relations mutuelles ( https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-generator-of-dust3d-from-rust-to-cplusplus/ ) ) ou quand obtenir la performance requise s'associe avec se battre avec la bound checking du compiler ( https://www.reidatcheson.com/hpc/architecture/performance/rust/c++/2019/10/19/measure-cache.html )

Est-ce qu'il ne serait pas utile de créer un service tiers de hash de script JS? Le navigateur irait interroger le service pour vérifier que le JS n'est pas corrompu avant de l'exécuter? Ainsi une compromission du serveur seul serait inoffensive et détectée rapidement.

Dans le modèle Web, le code exécuté par le client est fetché dynamiquement depuis un serveur dans tous les cas et à chaque connection. Tu remplacerais simplement un serveur à compromettre par un autre serveur à compromettre. La finalité serait la même.

Il est trés difficile (impossible) de distribué et de forcer la vérification d'une signature dans un navigateur Web sans passer par une extension de navigateur.

L'E2E encryption pour une utilisation en navigateur web a principalement deux utilisations :

• Eviter les fuites de données en cas de compromision de la DB du serveur.
• Eviter les attacks par Eye dropping dans les environnements qui peuvent se permettre d'ouvrir TLS ( Certains états, ou certains VPN d'entreprise ).

Je n'ai pas vraiment pratiqué de langages fonctionnels purs avant elm et je ne maîtrisais pas bien la syntaxe d'haskel.

Question: Quel temps selon toi prendrait-il à un développeur Junior ( un petit nouveau dans une team, sans expérience en dev fonctionnel ) pour apprendre Elm from scratch et être productif.

Tu peux ramener ma question à la suivante: Si les technos, disons non-commune, comme Elm, Reason ( ou autre compiler de language "safe" vers JS ) semble très attractives sur le papier. Est-ce risqué de les utiliser au coeur d'une infrastructure alors que les développeurs formés à cette techno ne cours pas les rues ?

Certaines news récentes semble faire valoir que oui (https://news.ycombinator.com/item?id=21204761). Mais je serai intéressé par d'autres son de cloches.

Quelqu'un sait d'où vient cette réputation de consommation mémoire de java?

Tout programme utilisant un Garbage Collector utilise en moyenne de 3X à 10X la mémoire d'un programme ayant une gestion manuelle ( C, C++, Rust) ou ARC (Swift, Python).

C'est un fait qui a été longuement étudié. Si il est possible de réduire cette surconsommation, mais ça se fait au détriment des performances.

Dans le cas des Apps Java clients, l'effet est encore pire due au modèle objet très verbeux utilisé par Swing et autre ToolKit GUI qui a tendance à créer un grand nombre de petits objets en mémoire.

+1

Si j'apprécie le nombre de fonctionnalités de ces éditeurs. Ils sont souvent aussi réactif et consommateur de mémoire, et long à charger que Eclipse à ses pires heures de honte.

Car c'est Vendredi, Je dirai que Electron a réussi à associer la consommation mémoire infame des Apps Java, la réactivité horribles des GUI Web, et le truffage de bug de la programmation événementiel mono-threadé à la Visual Basic. C'est assez respectable comme combo, c'était dur à faire.

Alors tu vas m'expliquer comme Oracle va savoir que toi, utilisateur final, tu utilises zfs sur ton NAS et avec quelles lois ils pourraient t'attaquer.

Ce que tu fais toi sur ton NAS tout le monde s'en fout, incluant Oracle :)

Par contre, dans pour des négociations de licenses qui peuvent valoir plusieurs centaines de millions d'euros entre large entreprises, tout leverage est bon à prendre.

Au passage, Oracle a une réputation de requin en ce qui concerne ses licenses,sa propriété intellectuelle et l'aspect légal….

Du reste si Oracle devenait tout méchant ce serait ubuntu et les éventuels devs/projet qui le proposent qui seraient impactés. Pas toi l'utilisateur final.

Ca je suis pas si sur. Aux grandes heures des menaces à coup de brevert par SCO et Microsoft, c'étaient les utilisateurs finaux ( professionels ) qui étaient visés, pas les développeurs.

Tu pourrais aisément imaginer une stratégie similaire par Oracle pour promouvoire "unbreakable Linux" face à Red Hat. Ça serait immensément stupide de mon point de vue, et contre productif… mais pas impossible.

Non, ça m'aurait enlever toute possibilité de troller.

De Plus ça t'aurait également enlever la possibilité de répondre un commentaire de façon à moitié aigri par un commentaire complémentaire. Tout ceci aurait été largement dommageable.

[second degré je précise]

Mes excuses pour cette réponse un peu prompt de bon matin.

La licence est la CDDL, est libre. Oracle n'a pas de levier pour t'emmerder avec.

La CDDL a une clause de non-agression concernant les brevets ?

Si ce n'est pas le cas, Oracle a peut-être une shit tonne de levier pour t'emmerder avec :

https://www.google.com/search?tbm=pts&q=ZFS%20oracle&*&cad=h

Les développeurs du noyaux sont des gens extrêmement bons techniquement, mais ils n'envisagent pas ce qu'il font comme faisant parti d'un système d'exploitation complet.

Et c'est trés bien comme ça, car c'est ça qui apporte de la diversité et une évolutivité permanente.

Si le développement kernel était fait "top-bottom", avec une vision d'ensemble consistante et des tools key in hands, tu aurais des features legacy de partout, impossible à enlever car utilisé en dependence à tous les niveaux.

Si j'avais envie de troller ( mais c'est pas Vendreid !), je dirai comme le Kernel Windows en fait.

Vu les sommes qu'ils dépensent pour racheter un maximum d'IPv4 publiques, ça doit venir d'ailleurs.

Est-ce que c'est étonnant ?

En tant que provider il y a deux scenario :

• Je fournis un réseau interne / services internes et je peux rester sur plage privée IPV4, les problèmes viennent quand on commence à interconnecté.

• Je fournis un service externe.. Et là le V4 devient obligatoire, car 80% de la planète n'a pas de connectivité IPV6 en endpoint ( telephone, wifi publique, maison ) car la majorité des providers s'en battent les steaks.

Sauf que a) personne ne demande

Yep, Cf ce que je disais avant : Tout le monde s'en fout. Encore une fois, ça n'a rien d'une contrainte technique.

Et pourtant IPv6 ne prend toujours pas - à part sur de nouveaux besoin en bordure de réseau comme avec les smartphones.

Et même pas, prends la connectivié smartphone en France. Un bon paquet de provider n'a jamais donné une seul IPv6 publique sur son réseau.

Si tu veux connaitre ma solution pour un déploiement IPV6 global: Que l'Union Européenne foute PV à chaque fournisseur d'accés qui connecte un device à Internet sans une IPv6 publique. Je te parie qu'en moins de 2 ans tous tes problèmes seront magiquement résolus.

Ça je sais, la question à se poser est pourquoi ? Pourquoi le réseau avec le plus d'endpoints public au monde n'utilise que très très peu IPv6.

Honnêtement ? Comme tout chez Amazon: le pognon.

Ils n'ont que très peu d’intérêt commercial à le faire tant qu'il n'y a pas une forte demande.

Le fait que les autres l'ont fait montre que c'est faisable. Même mon petit Cloud pro-vider Suisse du coin me donne un support IPv6 actuellement.

Chez les installation de particuliers libristes peut-être. Mais en domotique "pro" j'ai vu du Crestron, du KNX, du ZWave et du ZigBee chez les particuliers. Partfois de l'AMX.

Yep, mais de mon expérience ça tend à converger vers une solution IP + MQTT or CoAP.

• ZigBee offre des performances insuffisantes pour certaines utilisations, et nécessaite des gates maison.
• Les autres sont des protocols proprio qui reste des iles à part.

Oui coté d'un particulier sachant on peut faire de l'IPv6. Mais honnêtement à part par curiosité intellectuelle, ça n'apporte pas grand chose.

Ben tu viens justement de pointer le problème: Tant qu'il y a de la musique, tout le monde dance. Tant qu'il y a des IPv4 encore disponible, personne n'en a rien à foutre sauf quelques avant gardiste.
Et quand le prix des plages v4 va monter exponentiellement, tout le monde va paniquer et tourner en rond.

IPv6 pouvait rester par terre plusieurs jours - j'ai jamais eu une plainte. (Une remarque une fois d'un admin réseau pointilleux après 48h)

La tu pointes un autre problème. Un bon nombre de sys admins n'est pas formé à IPv6 et surtout pas intéressé "tant que ça marche".