Que faire de Gemfile.lock et composer.lock

L’objectif du Gemfile c’est de dire « le projet a besoin de la bibliothèque X en version 4.5 minimum, et de la bibliothèque Y en version 1.3 à 1.5 ». L’objectif du Gemfile.lock c’est de dire « ici on a X en 4.5.6 et Y en 1.3.8, c’est cet ensemble précis qui est testé et mis en production ».

J’ai encore vu passer la question il y a quelques jours

Le Gemfile.lock, c’est quoi la bonne pratique, je le pousse sur le git ?

Et la réponse classique « Oui, pour s’assurer que la production soit en phase avec les versions que tu as testé », avec parfois quelqu’un qui ajoute « sauf pour les paquets gem / composer, où là il ne faut pas le pousser dans le dépôt git ».

Sauf qu’en fait c’est plus complexe, et ce n’est pas une problématique technique. C’est une question d’organisation :

Qui fait la maintenance applicative ? Qui suit les mises à jour de sécurité au jour le jour ? Qui est disponible en astreinte en cas de besoin ? Avez-vous une procédure de test automatisé suffisamment fiable ? Quelle est la politique de numérotation de vos dépendances ?

Plus exactement, le Gemfile.lock et le composer.lock doivent être maitrisés par l’équipe qui gère la maintenance de sécurité.

Équipe de développement

Ce peut être l’équipe de développement. Dans ce cas c’est à elle de pousser le .lock sur son outil de versionnement, de le mettre à jour et de déclencher un déploiement en cas de besoin.

Attention : Dire « je pousse les .lock dans le git », c’est dire, « personne d’autre que moi ne doit y toucher ». C’est parfois présomptueux, mais ça veut aussi dire être responsable de la mise à jour, y compris quand on n’en n’a pas envie.

Ça veut dire surveiller en permanence le besoin de mettre à jour une des dépendances pour des raisons de sécurité. Ça veut dire une veille active sur le sujet, du temps dédié à ça, et des outils ou processus bien définis. Très peu d’équipes de dev ont ça.

Est-ce le rôle de votre équipe de dev ? en a-t-elle les moyens ? le temps ? l’autonomie ?

Équipe de production

À l’inverse ça peut être à l’équipe de production de gérer ces artefacts. Dans ce cas c’est à cette dernière de pousser les .lock sur leur propre versionnement, avec le reste des configurations. Eux ont des processus établis pour faire les veilles de sécurité, des astreintes en cas de mise à jour en urgence, etc.

En échange ça veut dire que les dépendances sont spécifiées très sérieusement et plus précisément dans le Gemfile. Parfois dire « je veux la version 4.5.* » et pas uniquement « je veux une version 4 ou supérieure ». Pousser le Gemfile.lock sur le git de l’équipe de développement peut aussi être un indicateur que le Gemfile d’origine est géré avec légèreté au départ.

L’équipe de production se basera sur ces définitions précises, sur les notes de mises à jour des dépendances, puis mettra à jour le code et le Gemfile.lock en fonction. Elle fera ensuite passer les tests automatisés, peut être une équipe de QA. À la fin elle prendra – ou non – la responsabilité de déployer en production la mise à jour sans passer par l’équipe de développement, en fonction de l’urgence et du risque. Ça impose donc aussi des tests automatisés suffisamment solides pour se baser dessus lors d’une mise à jour mineure.

Dans une grosse structure, ou avec une équipe de production dédiée de qualité, c’est probablement une des meilleures options. Mais… votre équipe de production est-elle compétente sur ces sujets ? a-t-elle l’autonomie suffisante pour cela ? le code, le Gemfile et les tests automatisés sont-ils suffisament à niveau ?

Les FAI devront livrer à l’Etat toutes les infos sur leurs réseaux

Dans le cadre de ce contrôle, qui pourra avoir lieu une fois par an (ou plus souvent en cas de défaillances), les FAI et hébergeurs concernés devront fournir à l’ANSSI ou au prestataire privé agréé « notamment la documentation technique des équipements et des logiciels utilisés dans ses systèmes ainsi que les codes sources de ces logiciels« 

En clair : En plus des boites noires et des accès directs, il est demandé tous les moyens pour que l’État puisse s’introduire de force dans les systèmes, en dehors des accès prévus pour ça. Sous couvert d’en vérifier la sécurité, mais même la marmotte ne croit plus à l’emballage artisanal du chocolat dans le papier d’alu. Ayez confiance…

– via Numerama

HTTP2 for front-end web developers

To get websites to load in an acceptable time using HTTP1 we have developed a series of techniques; hacks really; to eke performance out of this old protocol. They are:

  • Spriting: taking multiple images, combining them into one image, and using CSS to only show part of that image in a particular place.
  • Concatenating: Taking multiple CSS or JS files and sticking them into one large file.
  • Serving assets from a cookie-less domain.
  • Sharding: creating different domains or sub-domains to host assets like images.

Avec l’arrivée de HTTP 2, ces quatre optimisations tendent à devenir inutiles, voire contre productives.

Pour les deux premières, le pipelining devient plus intelligent (donc réellement utilisable) et au besoin le serveur peut pousser les contenus sans même attendre qu’ils soient demandés par le client.

Pour les deux suivantes, le système de compression des entêtes et de multiplexage rend le retour sur investissement d’une nouvelle connexion TCP à un domaine tiers franchement contestable. Vous risquez de perdre de la performance au lieu d’en gagner.

La leçon est intéressante. Pendant quelques années les développeurs ont cherché à contourner les navigateurs, croyant pouvoir être plus smart. Le problème c’est que les navigateurs et les protocoles ont évolué entre temps pour résoudre les mêmes problèmes. Les bouts de scotch des développeurs peuvent désormais faire plus de mal que de bien. C’est toute une littérature qu’il va falloir mettre à jour.

AT&T To Match Google Fiber In Kansas City, Charge More If You Want Privacy

The company plans to charge $70/month for gigabit service, but that’s a subsidized price. Subsidized by what, you ask? Your privacy. AT&T says if you want to opt out of letting them track your browsing history, you’ll have to pay $29 more per month. They say your information is used to serve targeted advertising, and includes any links you follow and search terms you enter.

L’information n’est pas surprenante par son contenu mais par ses chiffres. Vos informations personnelles valent 30€/mois d’après AT&T, uniquement pour mieux cibler les publicités (ça laisse donc entrevoir le gain des publicités elles-mêmes, forcément supérieur)

– via Slashdot