Microsoft annonce la sortie de la première release candidate de .NET 6, disponible pour Linux, macOS et Windows,
elle résout les problèmes fonctionnels et les régressions des fonctionnalités

L’équipe de développement de .NET, le Framework de développement de Microsoft pour les applications d'entreprises, a annoncé le 14 septembre la sortie de la première release candidate de .NET 6. « Nous sommes heureux de publier Release Candidate 1 (RC1)de .NET 6. Il s'agit de la première de deux versions candidates "go live" qui sont supportées en production. Depuis environ un mois, l'équipe se concentre exclusivement sur les améliorations de la qualité qui résolvent les problèmes fonctionnels ou de performance des nouvelles fonctionnalités ou les régressions des fonctionnalités existantes », a déclaré Microsoft dans un billet de blog.

Nom : MiNETB.png
Affichages : 53264
Taille : 2,7 Ko

Microsoft .NET est le nom donné à un ensemble de produits et de technologies informatiques de l'entreprise Microsoft pour rendre des applications facilement portables sur Internet. .NET 6 RC1 a été testé et est pris en charge par la Preview 4 de Visual Studio 2022. Visual Studio 2022 permet de tirer parti des outils Visual Studio développés pour .NET 6, tels que le développement dans .NET MAUI, Hot Reload pour les applications C#, le nouveau Live Preview pour WebForms, et d'autres améliorations de performances dans l’expérience avec l’IDE. Les fonctionnalités présentées ci-dessous sont axées sur ce qui sera possible avec .NET 7 et au-delà. En effet, ces fonctionnalités n'ont pas encore atteint leur pleine maturité.

Source build

Source build est un scénario et une infrastructure sur lesquels Microsoft a travaillé en collaboration avec Red Hat avant de livrer .NET Core 1.0. Plusieurs années plus tard, Microsoft est sur le point de livrer une version entièrement automatisée de ce scénario. Pour les utilisateurs .NET de Red Hat Enterprise Linux (RHEL), cette capacité est très importante. Selon Red Hat, .NET est devenu une plateforme de développement importante pour son écosystème.

Le standard d'or pour les distributions Linux est de construire du code source ouvert en utilisant des compilateurs et des chaînes d'outils qui font partie de l'archive de la distribution. Cela fonctionne pour le runtime .NET (écrit en C++), mais pas pour le code écrit en C#. Pour le code C#, Microsoft utilise un mécanisme de construction en deux étapes pour satisfaire aux exigences.

Red Hat construit les sources du SDK .NET en utilisant la version Microsoft du SDK .NET (#1) pour produire une version purement open source du SDK (#2). Ensuite, le même code source SDK est reconstruit à l'aide de cette nouvelle version du SDK (n°2) pour produire un SDK open source prouvé (n°3). Ce SDK final (n°3) est ensuite mis à la disposition des utilisateurs de RHEL. Après cela, Red Hat peut utiliser ce même SDK (n° 3) pour créer de nouvelles versions de .NET et n'a plus besoin d'utiliser le SDK de Microsoft pour créer des mises à jour mensuelles.

Nom : redH.png
Affichages : 2790
Taille : 3,1 Ko

Ce processus peut être surprenant et déroutant. Les distributions open source doivent être construites par des outils open source. Ce modèle garantit que la version Microsoft du SDK n'est pas nécessaire, que ce soit intentionnellement ou par accident. Le projet de compilation de la source a permis à .NET de répondre à certaines exigences. Le livrable pour la construction de la source est une archive source. Cette archive contient toutes les sources du SDK (pour une version donnée). À partir de là, Red Hat (ou une autre organisation) peut construire sa propre version du SDK. La politique de Red Hat exige l'utilisation d'une chaîne d'outils construite à partir de la source pour produire le tar binaire, c'est pourquoi ils utilisent une méthodologie à deux passages. Mais cette méthode à deux passages n'est pas requise pour la construction de la source elle-même.

Il est courant dans l'écosystème Linux d'avoir à la fois des paquets ou des archives sources et binaires disponibles pour un composant donné. Microsoft disposait déjà des archives binaires et nous maintenant des archives sources également. Ainsi, .NET correspond au modèle de composant standard.
La grande amélioration de .NET 6 est que l’archive source est maintenant un produit de la construction Microsoft. Auparavant, sa production nécessitait un effort manuel considérable, ce qui entraînait également une latence importante dans la livraison de l'archive source de Red Hat. Aucune des deux parties n'était satisfaite de cette situation.

Microsoft travaille en étroite collaboration avec Red Hat sur ce projet depuis plus de cinq ans. Il a réussi, en grande partie, grâce aux efforts des excellents ingénieurs de Red Hat avec lesquels nous avons eu le plaisir de travailler. D'autres distros et organisations bénéficieront de leurs efforts. Cependant, l'un des principaux problèmes restants est l'utilisation d'algorithmes de compression stables pour le contenu compressé dans les assemblages.

Amélioration de la sécurité

Microsoft a publié une feuille de route sur la sécurité en début d’année afin de mieux comprendre comment aborder les techniques de sécurité et les caractéristiques matérielles standard du secteur. La feuille de route a également pour but d'alimenter la conversation. Microsoft a ajouté la prise en charge de deux mesures d'atténuation de sécurité clés dans cette version : CET, et W^X. L’entreprise souligne sa volonté de les activer par défaut dans .NET 7.

CET

La technologie CET (Control-flow Enforcement Technology) d'Intel est une fonction de sécurité disponible dans certains processeurs Intel et AMD récents. Elle ajoute des capacités au matériel qui protègent contre certains types d'attaques courantes impliquant le détournement du flux de contrôle. Avec les piles fantômes CET, le processeur et le système d'exploitation peuvent suivre le flux de contrôle des appels et des retours dans un thread dans la pile fantôme en plus de la pile de données, et détecter les modifications involontaires du flux de contrôle. La pile fantôme est protégée contre les accès à la mémoire du code d'application et permet de se défendre contre les attaques impliquant la programmation orientée retour (ROP).

En début d’année, Google Chrome et Microsoft Edgeont annoncé qu’ils prendront en charge la fonction de sécurité CET d'Intel, pour maintenir la sécurité et prévenir des vulnérabilités. Elle est conçue pour protéger les données des utilisateurs contre les attaques de la programmation orientée retour (ROP) et de la programmation orientée saut (JOP). Ces attaques de type ROP et JOP sont dangereuses et particulièrement difficiles à détecter ou à prévenir, car elles modifient le comportement normal d’un programme pour exécuter le code malveillant. Intel a collaboré activement avec Microsoft et d'autres partenaires industriels pour lutter contre ces types d’attaques en utilisant la technologie CET comme complément aux précédentes solutions implémentées.

Nom : cet.PNG
Affichages : 2819
Taille : 152,3 Ko

Avec ROP, le cybercriminel s'appuie sur l'instruction RET (return) pour assembler un flux de code malveillant, récupère l'adresse de l'instruction suivante dans la pile et exécute les instructions à partir de cette adresse. Dans le cas d'attaques basées sur des ROP, l'acteur de la menace recherche a priori l'exécution d'une séquence d'octets dans le code du programme existant en analysant le programme sur le disque ou en mémoire. Windows 10 prend en charge la fonction de sécurité CET d'Intel grâce à un exécutable appelé "Hardware-enforced Stack Defense". Dans un tweet, Johnathan Norman, le responsable de l'étude des vulnérabilités de Microsoft Edge, a laissé entendre que Microsoft Edge 90 prend en charge la technologie CET d'Intel dans les procédures sans moteur de rendu

W^X

W^X est l'une des mesures d'atténuation les plus fondamentales. Elle bloque le chemin d'attaque le plus simple en empêchant les pages de mémoire d'être accessibles en écriture et exécutables en même temps. L'absence de cette mesure d'atténuation nous a conduit à ne pas envisager des mesures d'atténuation plus avancées, car elles pourraient être contournées par l'absence de cette capacité. Avec W^X en place, Microsoft ajoute d'autres mesures d'atténuation complémentaires, comme CET.

Apple a rendu W^X obligatoire pour les futures versions du système d'exploitation de bureau macOS dans le cadre de la transition Apple Silicon. « Cela nous a motivés à programmer la mise en œuvre de cette mesure d'atténuation pour .NET 6, sur tous les systèmes d'exploitation pris en charge. Notre principe est de traiter tous les systèmes d'exploitation supportés de la même manière en matière de sécurité, dans la mesure du possible », déclare Microsoft. W^X est disponible sur tous les systèmes d'exploitation avec .NET 6 mais n'est activé par défaut que sur Apple Silicon. Il sera activé sur tous les systèmes d'exploitation pour .NET 7.

HTTP/3

HTTP/3 est une nouvelle version de HTTP. HTTP/3 résout les problèmes de fonctionnalité et de performance des versions précédentes de HTTP en utilisant un nouveau protocole de connexion sous-jacent appelé QUIC. QUIC utilise UDP et intègre TLS, ce qui permet d'établir plus rapidement les connexions car la poignée de main TLS fait partie intégrante de la connexion. Chaque trame de données est chiffrée de manière indépendante, de sorte que le protocole n'est plus confronté au défi du blocage de la tête de ligne en cas de perte de paquets. Contrairement au TCP, une connexion QUIC est indépendante de l'adresse IP, de sorte que les clients mobiles peuvent se déplacer entre les réseaux wifi et cellulaires, en conservant la même connexion logique, et peuvent poursuivre de longs téléchargements.

À l'heure actuelle, la RFC pour HTTP/3 n'est pas encore finalisée, et peut donc encore changer. Nous avons inclus HTTP/3 dans .NET 6 pour que vous puissiez commencer à l'expérimenter. Il s'agit d'une fonctionnalité en avant-première, qui n'est donc pas prise en charge. Il peut y avoir des imperfections et des tests plus larges doivent être effectués avec d'autres serveurs et clients pour garantir la compatibilité.

.NET 6 n'inclut pas la prise en charge de HTTP/3 sur macOS, principalement en raison de l'absence d'une API TLS compatible avec QUIC. .NET utilise SecureTransport sur MacOS pour son implémentation TLS, qui n'inclut pas encore d'API TLS pour supporter la poignée de main QUIC.

Source : Microsoft

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Microsoft annonce la disponibilité de .NET 6 Preview 4 qui apporte l'expérience Hot Reload, à Visual Studio et aux outils de ligne de commande

Google Chrome et Microsoft Edge prendront en charge la fonction de sécurité CET d'Intel, pour maintenir la sécurité et prévenir des vulnérabilités

Visual Studio 2022 Preview 4 est disponible et s'accompagne d'améliorations sur la productivité personnelle et d'équipe, le chargement à chaud dans ASP.NET Core et la gestion de thèmes

Red Hat annonce un RHEL sans frais pour les petits environnements de production, notamment pour les charges de travail de production avec jusqu'à 16 serveurs de production