Pinaraf a écrit 3671 commentaires

La forme est risible… mais y'a quand même du vrai sur les grosses lacunes de MySQL par rapport aux autres grands SGBDR.
Après, c'est quand même cocasse de la part d'un DBA SQL Server. Je me demande s'il s'était mis en nolock pendant la rédaction de l'article… (je vois des DBAs de l'autre côté de la boite, je suis bien content avec mes Pg quand je vois leurs échanges)

C'est loin, mais c'est beau.

La lib litigieuse est tout de même la libc, c'est pas la lib la plus insignifiante à recompiler et forcer. Je trouve le hack sur l'interpréteur plus léger et au final plus fiable.
Par ailleurs, à la compilation il me semble qu'elle inclut toutes les versions, qui sont directement optimisées en assembleur, ce n'est pas du code généré par le compilateur (à vérifier, j'ai plus compilé la libc depuis longtemps)

J'espère qu'il y aura des offres d'emploi sympas sur lolix ou équivalent à ce moment là…

Ça donne une idée de la qualité de l'entreprise.

Si seulement c'était la seule horreur… On peut aussi se planter dans le choix d'algo, ne pas lire les limites de l'algo de hachage utilisée (genre les mots de passe étaient tronqués à 8 caractères, de mémoire…)

Tout ça ne concerne pas PeopleDoc, où les devs ont choisi de ne pas implémenter le hachage eux-même : ils ont délégué à leur framework, du coup au moins c'est audité par des tiers et c'est propre.

Il me semble qu'il est obligatoire, pour tout prestataire hébergeant les fiches de paie, d'avoir une solution d'archivage tamponnée proprement. Dans le cas de PeopleDoc, c'est la Caisse des Dépôts et Consignations. On va dire que si elle disparaît également, les fiches de paie seront pas ma première inquiétude (même si je sauvegarde tout aussi sur mon PC, par principe)

Avec un sel aléatoire aussi… j'ai déjà vu y'a un certain temps une entreprise utiliser une constante… c'était assez rigolo quand on a tenté un brute-force sur la base pour justifier l'évolution.

Heu, non non. C'est pas en passe d'ailleurs, c'est fait le rachat… mais l'entité juridique PeopleDoc France reste là, et promis juré si un collègue américain essaye d'accéder aux données on lui tape dessus. Plus sérieusement, les équipes de développement, de production, de vente… restent séparées. Donc ils auront accès aux données de leurs clients, et nous des nôtres, mais pas d'échanges inutiles.

Alors la chapeau au prestataire, encore ça en 2019… Je parie du coup que les pass ne sont pas chiffrés.

Alors… je bosse pour PeopleDoc, je vais pas tenter de défendre les collègues juristes ou devs, et fort heureusement les mots de passe sont hachés (et pas chiffrés, heureusement).

Et la seule règle que je connaisse (je viens d'aller sur mon compte perso) c'est «au moins 8 caractères, un chiffre, une lettre majuscule et une lettre minuscule».
Du coup, si tu as un contexte précis où les règles sont différentes, je prends, j'adore faire chier les collègues.

~rip()

Cela étant dit, je ne sais pas si ça changerait grand chose et ce sera probablement encore un écran ignoré parmi les nombreuses sollicitations provenant d'un téléphone moyen pour beaucoup de gens (j'espère me tromper bien sûr).

C'est bien le problème, et ce sur quoi semble compter Google vu les captures d'écran.
À partir du moment où tu laisses la possibilité de faire Next Next Next Next, tu n'as pas créé un vrai choix pour l'utilisateur, tu exploites l'absence d'intérêt de l'utilisateur. L'écran de Microsoft n'avait pas ce défaut. Pour rappel:

On ne pouvait passer sans faire un choix. Et ça change tout.

Par contre, a décharge pour Google, la Commission leur donne 90 jours pour faire quelque chose. Dans le temps imparti, je vois pas trop ce qu'ils pouvaient faire de mieux qu'une mise a jour de leur store.

C'est sûr qu'ils pouvaient pas se douter qu'abuser d'une position dominante pour imposer leurs logiciels serait illégal, c'est une première…

La bonne blague. Je traduis l'annonce de Google : «Ces nouveaux écrans seront affichés à l'utilisateur à la première ouverture du Google Play Store après une mise à jour».
Donc… L'utilisateur verra deux écrans, qui permettent certes d'installer d'autres programmes, mais n'importe quel choix autre que Google va nécessiter au moins un clic de plus puisque Google Chrome et Google Search sont déjà installés… Même si Google Chrome est installé, Google devrait demander à l'utilisateur qu'il le revalide.
Et est-ce-que le choix d'un autre navigateur va masquer par défaut l’icône de Chrome de la page d'accueil d'Android pour le confiner à la liste complète des applications ? (Je parle pas trop l'Android ni l'iOS, donc toutes mes excuses si ce n'est pas le bon nom pour ces différentes parties d'interface)
On est très loin de l'écran qu'avait implémenté Microsoft et qui masquait Internet Explorer du bureau, et ne faisait aucune différence entre les différents navigateurs à la sélection.

«Portability - Run SSH through the browser without requiring client software or browser plugins.»

Heu, vraiment ? Comment tu fais passer des outils comme Ansible dans ce cas ?

Je sais c'est has-been, c'est pas web devops tout ça machin… mais vous avez quelque chose contre LDAP ?
On stocke dans l'annuaire les utilisateurs, les clés publiques dans un attribut… et ça roule, avec la possibilité de gérer dans l'annuaire des restrictions d'accès par groupe de machine…

Et sinon ne pas remplir des authorized_keys locaux mais les récupérer dynamiquement depuis le serveur, comme ça y'a plus besoin de client qui maintienne les fichiers locaux ? (À la rigueur avec un cache local si le serveur devient injoignable, mais ça reste sujet à débat)

Du tout, juste pratique. Imposer la même heure à tout le monde, de préférence UTC, et on s'emmerde plus avec les fuseaux horaires et les histoires d'hiver/été. On mange à l'heure adaptée localement, on se couche et se lève selon l'heure du soleil… et c'est bien plus simple. Cf https://linuxfr.org/users/zoot/journaux/hs-etes-vous-pour-rester-a-l-heure-d-ete-ou-a-l-heure-d-hiver#comment-1763004

On est d'accord pour dire que 19H, 7H ou 12H12, c'est une simple convention de communication ?
L'heure est un outil de communication, en aucun cas un diktat à suivre pour le rythme biologique. Si demain je pouvais dire à un Portugais et à un Grec de faire une réunion ensemble à 13H, sans devoir m'inquiéter des conversions, ça serait largement mieux.
Le plus naturel serait de ne parler qu'en heure UTC, et on ne se soucie plus des fuseaux.
Vous direz que ça signifie qu'on ne peut plus se douter qu'un rendez-vous à 12H heure locale du correspondant va perturber son repas du midi… mais c'est négliger l'importance des habitudes locales (on mange très tôt le soir en Allemagne par exemple) qui fait que la convention actuelle ne règle guère de problèmes…

=> Le choix de la France ne doit pas dépendre des autres pays (à noter: la Belgique préfère aussi l'heure d'été permanente)

Ça doit carrément. C'est à ça que sert l'Union Européenne, avoir un truc uni (merde, comme dans «union» ? révélation !).

Hier soir je suis allé dans un restaurant à côté de chez moi. Comme souvent. Et donc, comme souvent, j'ai franchi une «frontière» pour ce faire (c'est-à-dire que je suis passé au dessus d'un pont au milieu d'une ville). Si demain les heures devenaient différentes entre la Belgique et la France, le merdier que ce serait pour tous les commerces frontaliers (qu'ils soient français ou belges), pour les habitants… «Bonjour, je voudrais réserver une table pour 20H», et le client arrive à 21H ? Ou à 19H…

Tu peux avoir une vision centriste (du Centre hein, pas du mouvement politique), voire nationaliste… Mais pour les nordistes, les alsaciens, les alpins, les pacaïstes, les pyrénéens… cette décision dépend bien plus de nos voisins. Je me préoccuperais beaucoup moins que Paris soit à une heure de décalage de Lille que si Comines était à une heure de décalage de Comines (l'une des villes séparées en deux par la frontière de 1713 du traité d'Utrecht qui a établi la Lys comme étant la frontière entre les pays)

2 : je sous-entend quand tu n'ajoutes pas un réseau « parallèle » en ULA

Tiens, je croyais que le minitel n'existait plus :)

Nope, je dirais a peu près 17 seulement, ça pourrait être 2 fois plus simple que prévu, si l'administration était mon métier, mais ce n'est pas le cas (ce qui ne m'empêche pas de vouloir savoir comment ça marche).

Je parlais du cas général, je n'ai pas prétendu que tu avais 30 ans d'éducation en réseau (sinon je crois que tu m'écraserais allègrement) :)

Du fait de l'abondance des IPs, donc, il suffit d'affecter les IPs que l'on souhaite utiliser à une machine spécifique et le tour est joué? Du coup, la différence contrairement à IPv4, c'est qu'il n'a pas besoin d'aller ouvrir le protocole suivant (TCP/UDP/ICMP/Que-sais-je/…) d'où un gain de simplicité dans la pile logicielle?

Voilà. La quantité d'adresses IPs et de réseaux disponibles fait qu'il n'est plus nécessaire de jongler avec des adresses publiques/privées, et donc les routeurs ne font que router les IPs, sans regarder plus loin. Cela simplifie considérablement le travail. Sur un gros réseau, avec un fort trafic, la charge CPU pour le NAT n'est pas négligeable, et cela commence à consommer de la RAM. Et je ne dis pas ça comme un troll : dans des clouds professionnels à beaucoup de brouzouf$ par mois, j'ai déjà eu des connexions réseau qui se coupent entre deux systèmes parce qu'ils n'ont pas envoyé de paquet pendant X minutes et que le routeur a une règle pour supprimer périodiquement de la table de NAT les connexions «inactives» (et quand ça coupe, ça te prévient pas, du coup ton prochain paquet part dans un trou noir et ton appli peut faire la gueule)

De toute façon, je suppose qu'il doit y avoir un équivalent au DHCP qui fonctionne plus ou moins comme ceux que l'on utilise pour IPv4, à l'exception du fait de la quantité d'adresses dispo que l'on ne se prive pas pour assigner plusieurs IPs à une même interface, par exemple une IP publique et une IP locale, qui permette éventuellement de ne lancer les services sensibles que sur l'IP locale?

Tu m'auras pas, je le ferai pas ! :)

Allez, on va faire ça en très court : il y a deux protocoles, SLAAC (StateLess Auto Adress Configuration) et DHCPv6. DHCPv6 a des fonctionnalités en plus par rapport à SLAAC (la RFC 6106 est rarement implémentée pour passer les serveurs DNS en SLAAC hélas, et elle est très peu connue), mais normalement tu peux n'utiliser que SLAAC sur la plupart des réseaux.

Ben justement, ce n'est pas ce que fait sslh, merci bien. J'ai déjà fait ce genre de chose avec de l'openvpn et du https, ça se distingue très bien sans regarder le contenu des paquets. Mais distinguer ssh toto@tutu1 et ssh toto@tutu2 quand tutu1 et tutu2 pointent sur la même IP, c'est pas la même histoire. Ou alors on a trouvé une énorme faille de sécurité dans SSH et personne ne m'a rien dit ?

Combien, 30 ans d'éducation réseau à casser ? Ça va être dur… :)

Prenons Marcel Toto, fier propriétaire du bloc 2000:2001:2002:2000::/56 attribué par son fournisseur d'accès internet RFC.com.
Marcel décide de répartir son réseau en 3 sous-réseaux:
- 2000:2001:2002:2001::/64 pour ses serveurs et services réseau principaux…
- 2000:2001:2002:2002::/64 pour ses ordinateurs de bureau, portables…
- 2000:2001:2002:2066::/64 pour le wifi invité.

Quand son serveur, 2000:2001:2002:2001::73, échange avec son ordinateur de bureau, 2000:2001:2002:2002::42, la communication va se faire sans traduction d'adresse, vu que les adresses sont uniques. L'équipement qui passera les paquets pourrait avoir, mettons, 2000:2001:2002:2001::1 et 2000:2001:2002:2002::1, il n'aura pas à traduire d'adresses pour autant. Il fera un travail de passe-plat, comme n'importe quel switch réseau sait le faire.

C'est justement là la différence avec le NAT.
En IPv4, on a le serveur de linuxfr.org qui parle à mon switch port TCP 12345, et le switch pour chaque paquet doit dire «ho, c'est pour moi, merc… et merde, non, c'est encore le gros lourd qui veut passer un message à l'autre con… bon, je colle une nouvelle étiquette, et c'est parti».
Bien sûr, juste sur mon réseau local, serveurs et clients peuvent se parler sans NAT, sans trop se prendre la tête… par contre quand tu commences à avoir des serveurs exposés sur l'extérieur, ça devient plus rigolo à router justement à cause du NAT. Alors qu'en IPv6, tu n'as pas à faire tout ça.

Tu noteras par contre que je n'ai pas parler du firewall pour ce qui vient de l'extérieur ou ce qui va entre chaque zones, ni de l'allocation des IPs, ce sont d'autres sujets (on répète tous ensemble : «le NAT n'est pas une sécurité» − https://blog.webernetz.net/why-nat-has-nothing-to-do-with-security/)

Hum, je ne vois pas comment tu fais.
Prenons un cas simple : SSH.
Imaginons que tu doives avoir obligatoirement du SFTP sur le port 22 pour un logiciel ne supportant pas autre chose (j'ai déjà vu ça avec des banques), mais que le port 22 est déjà utilisé pour ton SSH normal et que tu ne peux pas le bouger. Comment tu veux faire la distinction sans avoir deux adresses IP ? Au niveau réseau, le nom d'hôte disparait, tu reçois des paquets TCP à destination de 1.2.3.4:22. Éventuellement, ils peuvent contenir une info sur la cible, comme le SNI de HTTPS… Mais donc il faut que ton reverse proxy gère spécifiquement chaque protocole ?
Ça me parait juste infaisable sans avoir des adresses IP en stock… et donc sans IPv6 pour la plupart des gens qui veulent faire de l'auto-hébergement, ou sur le long-terme.

Et tu fais quoi pour un service qui ne soit pas en HTTP/HTTPS ? Je sais que c'est plus à la mode, mais y'a quand même des protocoles plus adaptés pour certaines taches que HTTP :)

Malheureusement, ce que fait systemd est nécessairement invasif. À partir du moment où tu veux gérer les services comme ça, tu te retrouves à intégrer beaucoup de choses… Bon, réimplémenter un client SNTP ou DHCP, faut pas déconner, c'est pas nécessaire.

Une excellente présentation sur ce sujet, sans à mes yeux de fanatisme pro-systemd:
https://www.youtube.com/watch?v=o_AIw9bGogo