# Sortie de PostgreSQL 15  [PostgreSQL, SGBD, SQL]

par Aurélien Morlé

Le PostgreSQL Global Development Group a annoncé le 13 octobre 2022 la sortie de PostgreSQL 15, la dernière version de la base de données open source de référence.

PostgreSQL 15 ajoute la commande MERGE du standard SQL qui était très attendue par les développeurs. MERGE permet d’écrire des requêtes SQL conditionnelles combinant des actions INSERT, UPDATE et DELETE en une seule requête. 

Mais l’on regrettera le retrait dans la Bêta 4 des fonctionnalités autour de SQL/JSON qui a été repoussé pour une prochaine version. La stabilité est toujours privilégiée par rapport à l’ajout de nouvelles fonctionnalités, ce qui en fait aussi une des forces de PostgreSQL.

Vous pouvez retrouver tous les détails de cette nouvelle version dans la release note :

https://www.postgresql.org/docs/15/release-15.html

# Passkeys, password killers

par Thomas Broyer

Ils avaient annoncé en mai dernier leur collaboration pour faire avancer le standard Passkeys de la FIDO Alliance devant mener à un monde sans mot de passe, Apple, Google et Microsoft ont montré ce début d’automne que ce n’étaient pas des paroles en l’air.

Apple a dégainé le premier avec le support des Passkeys dans iOS/iPadOS 16 et macOS Ventura sortis en septembre.

Google a ensuite mis le paquet en octobre sur la communication autour des Passkeys (annonce sur le blog Android Developers, présentation sur Google Developers, et deux articles sur web.dev) et une implémentation disponible dans les Play Services beta et Chrome Canary, pour une version stable “d’ici la fin de l’année”, et le support pour les applications natives un peu plus tard.

Enfin Microsoft n’est pas en reste puisque même si l’implémentation n’arrivera dans Windows que l’année prochaine, une démonstration en a été faite lors de la conférence Authenticate 2022 (Microsoft proposant déjà depuis quelques temps un mécanisme d’authentification sans mot de passe grâce à Windows Hello et Microsoft Authenticator), et a indiqué que ses services en lignes supporteraient les Passkeys (pour les appareils Apple, puis Android donc) “dans un futur proche”.

Cerise sur le gâteau, PayPal a également annoncé le support des Passkeys sur son site, d’ores et déjà utilisable avec les appareils Apple équipés de la dernière version de leur OS.

# Le (presque) non-événement OpenSSL

par Thomas Broyer

Le 25 octobre, l’équipe OpenSSL annonce une vulnérabilité de niveau critique qui sera rendue publique, avec son correctif, le premier novembre (jour férié dans plusieurs dizaines de pays à travers le monde). La dernière faille critique dans OpenSSL, tout le monde s’en souvient, c’était il y a 10 ans, elle avait fait le tour des journaux télévisés et nous avait montré à quel point le monde dépendait du travail quasi-bénévole de deux développeurs : HeartBleed.

Cette nouvelle vulnérabilité ne concerne que les versions 3.0.0 à 3.0.6 de la bibliothèque, relativement récentes, la plupart des déploiements (hors machines de développement) utilisant toujours la version 1.1, voire 1.0.

La tension est palpable sur les réseaux sociaux en ce premier novembre dans la plage horaire annoncée… pour finalement faire *plouf* après plus de 2 heures d’attente quand la vulnérabilité est finalement rendue publique avec une sévérité abaissée à haute.

Il s’agit en fait de deux vulnérabilités (CVE-2022-3786 et CVE-2022-3602) dont le danger est effectivement élevé puisqu’elles permettent la prise de contrôle des machines à distance (RCE), mais l’exploitabilité est en fait extrêmement improbable.

Les experts sont assez unanimes dans leurs commentaires : “sur une échelle de 1 à 10 de bonne raison de paniquer, je lui donnerai moins de zéro” (Marcus Hutchins, célèbre pour avoir bloqué le rançongiciel WannaCry il y a 5 ans), “Ne l’ignorez pas. Patchez. Mais n’en perdez pas le sommeil.” (Pwn All The Things, expert anonyme), ou encore “honnêtement, je pense qu’elle pourrait même être medium” (Filippo Valsorda, qui avait fait le premier test en ligne pour HeartBleed).

Un autre se demande quand même pourquoi ça n’a pas été vu avant : le code est récent (on ne peut donc pas invoquer l’argument d’une complexité historique) et un test de fuzzing (où on injecte des valeurs aléatoires) l’aurait détecté. Donc même si le développement d’OpenSSL depuis HeartBleed est désormais scruté par de nombreux acteurs, et surtout financé, il reste semble-t-il une marge d’amélioration notable dans les processus, habitudes et exigences de qualité. Certains ne mâchent d’ailleurs pas leurs mots : “overflow sur un exemple de la spécification […] Sur la Pull Request, quelqu’un a rapidement demandé des tests, ça a été ignoré […] La relecture s’est concentrée sur des choses plus importantes comme le rangement des fichiers, les commentaires de licence, le formatage et le style de code […] Aucun des 127 commentaires de cette Pull Request ne portait sur le code effrayant lui-même.” (Theo Buehler, développeur LibreSSL et OpenBSD).

Affaire à suivre…