Sujet
Cycle de vie logiciel et dépendance fournisseur
Au sein de la facette Sujet, la veille thématique Cycle de vie logiciel et dépendance fournisseur rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

Dossier
Chez Mozilla, l’accord d’un responsable de module n’est ni un accès de commit ni une promesse de livraison de Firefox
Les règles publiques de Mozilla séparent des actes que le langage courant rassemble volontiers. Un responsable de module ou l’un de ses pairs peut accepter une modification dans le périmètre du module; une personne peut obtenir séparément une autorisation d’écrire dans un dépôt…

IETF
Le modèle derrière la pile d’étiquettes : la RFC 9902 et le contrat opérationnel du routage segmenté IS-IS
Un seul leaf d’activation peut commencer à annoncer les extensions IS-IS de routage segmenté, mais une activation sûre dépend des ressources d’étiquettes SR, indépendantes du protocole, déjà configurées en dessous. La RFC 9902 rend cette jonction explicite: le commutateur…

Histoire d'Internet
Les bits que TCP a gardés pour l’avenir
En 1981, TCP a laissé six positions de son en-tête sans fonction immédiate. Leur valeur historique tient à la règle qui accompagnait ce vide: les émettre à zéro, ne pas leur attribuer de sens privé et réserver leur évolution à une future norme. En 2001, deux de ces positions sont…

Histoire d'Internet
Le bit qui a donné un sens au numéro d’accusé de réception TCP
Un champ de 32 bits peut être présent dans chaque segment TCP sans toujours constituer une information valide. Le bit ACK indique quand ce numéro devient la frontière cumulative de séquence attendue.

IETF
Les procès-verbaux « perdus » de l’IETF étaient là. L’archive a besoin d’un manifeste d’intégrité
Un lien muet peut faire passer un document conservé pour un document disparu. C’est ce qui s’est produit avec deux séances de l’IETF 84: les fichiers existaient dans une copie des actes, mais les anciennes pages ne savaient plus les atteindre. La correction apportée au serveur…

Histoire d'Internet
Le nombre qui indiquait à TCP où commençaient les données : Data Offset
Le champ Data Offset donne la limite fiable entre l’en-tête TCP — options et remplissage compris — et le premier octet de données applicatives.

Histoire d'Internet
L’en-tête qui n’a jamais été envoyé : pourquoi TCP somme des adresses IP
TCP ne transporte pas un en-tête supplémentaire pour protéger ses adresses d’extrémité. Il reconstruit plutôt, aux deux bouts, quelques informations fournies par IP avant de vérifier sa somme de contrôle.

Histoire d'Internet
Ces deux fanions qui occupent une position : pourquoi TCP compte SYN et FIN
TCP numérote les octets, mais réserve aussi une position logique à deux événements de contrôle. SYN ouvre l’espace de séquence avant les données et FIN le termine après le dernier octet: tous deux bénéficient ainsi des mêmes mécanismes d’accusé de réception et de retransmission…

Histoire d'Internet
Le PUSH qui n’a jamais été une frontière de message : le drapeau PSH de TCP
Une demande de progression dans un flux d’octets n’est pas une enveloppe de message.

Histoire d'Internet
La connexion oubliée par une extrémité : la réinitialisation d’une connexion TCP semi-ouverte
Quand une extrémité redémarre, elle peut oublier une connexion que l’autre croit encore établie. Le prochain échange révèle alors que leurs états de connexion ne coïncident plus: le segment RST met fin à l’état obsolète et laisse place à une nouvelle négociation.

Tendances institutionnelles mondiales
Qui décide du correctif ? Le pouvoir réel d’ISC sur BIND et Kea
Le pouvoir d’Internet Systems Consortium ne ressemble pas à celui d’un régulateur. Pour les versions prises en charge de BIND et Kea, il s’exerce surtout dans une séquence technique: coordonner l’information sur une vulnérabilité, organiser la production d’un correctif, publier…

Histoire d'Internet
Quand les deux côtés ont frappé à la porte : l’ouverture simultanée de TCP
*Le handshake TCP n’impose pas toujours un client et un serveur: deux hôtes peuvent commencer ensemble et synchroniser une seule connexion.*

Histoire d'Internet
L’hôte qui devait attendre avant de parler : le temps de silence de TCP après un redémarrage
Après un redémarrage, un hôte peut sembler propre parce qu’il a oublié une partie de son passé. Le temps de silence de TCP transforme cette perte de mémoire en délai contrôlé: les anciens segments doivent disparaître avant que de nouveaux numéros de séquence réutilisent le même…

Histoire d'Internet
Le reset qui a mis fin trop tôt à l’attente : le risque d’assassinat de TIME-WAIT
Un état TCP conservé après la fermeture peut sembler encombrant. RFC 1337 a montré qu’un paquet ancien pouvait provoquer une chaîne de réponses — ACK, puis RST — capable de supprimer prématurément la protection contre les doublons retardés.

Histoire d'Internet
La deadline qui n’était pas un minuteur de retransmission : le USER TIMEOUT TCP
Une retransmission tente encore la livraison; le USER TIMEOUT décide quand cette attente doit prendre fin.

Histoire d'Internet
L’offre qui n’était pas une négociation : comment le MSS TCP bornait chaque direction
Chaque SYN peut contenir une limite de réception propre à l’émetteur. Ces deux limites peuvent différer: le MSS ne fixe ni une taille commune de paquet ni la MTU du chemin.

Histoire d'Internet
Le handshake qui devait se souvenir du précédent : comment le RFC 5746 a lié la renégociation TLS
La renégociation TLS pouvait authentifier un nouveau handshake sans prouver quelle histoire de connexion l’avait précédé. Le RFC 5746 a transformé cette continuité en état cryptographiquement vérifiable.

Histoire d'Internet
Le voisin resté dans le cache après être devenu inaccessible : comment la RFC 7048 a séparé basculement et oubli
La troisième sollicitation sans réponse ne détruit plus forcément la dernière indication utile: IPv6 peut écarter un voisin du choix de route tout en conservant son adresse de couche liaison pour une nouvelle recherche.

Histoire d'Internet
L’adresse qui parlait avant d’être déclarée unique : les limites du DAD optimiste
Une adresse IPv6 nouvellement configurée pouvait commencer à transporter du trafic avant la fin de la vérification d’unicité, mais elle ne pouvait pas encore agir comme un voisin pleinement établi.

IETF
Le milieu vulnérable d’une migration TACACS+ sécurisée : RFC 9887 et le coût d’une double voie d’authentification
Un client TACACS+ utilisant TLS ne doit pas revenir au non-TLS lorsque la négociation TLS échoue. Pourtant, une migration peut conserver temporairement des serveurs TACACS+ non-TLS distincts pour les équipements qui ne peuvent pas changer en même temps. Cette coexistence n’est…
