Sommaire
TL;DR: Avec Microsoft SQL Server, la sécurité est une option. Et une option payante.
Microsoft aime Linux, nous dit-il, et il nous permet maintenant d'installer nativement son serveur de base de données SQL Server (cf. cette vidéo technique pour comprendre comment ils on fait le portage). Seulement, la configuration par défaut n'est pas sécurisée du tout. Petite revue de quelques éléments à rectifier quand vous installez et utilisez SQL Server. La plupart de ces conseils sont aussi valables si vous utilisez le cloud de Microsoft.
remarque : ce journal ne prétend pas à l'exhaustivité. Je n'ai qu'une toute petite expérience de SQL Server.
Version testée : SQL server 2019 sur Ubuntu 18.04 (en l'occurrence installée sur Debian Buster). Les recommandations valent aussi pour d'autres distributions Linux.
Configuration de SQL server
Voici le manuel d'installation. Ce qu'il ne précise pas, c'est que par défaut :
- SQL server écoute sur toutes les adresses réseau (et pas uniquement localhost)
- Le chiffrement n'est pas activé
Selon votre cas d'usage, vous devrez nécessairement corriger l'un de ces deux points.
Désactiver l'écoute sur le réseau
Si vous prévoyez d'interroger SQL Server uniquement depuis localhost, alors il faut limiter son écoute au réseau local seulement. Pour ça, il faut ajouter les lignes suivantes au fichier de configuration, qui est par défaut /var/opt/mssql/mssql.conf :
[network]
ipaddress = 127.0.0.1
Il faut ensuite redémarrer mssql-server :
$ sudo systemctl restart mssql-server
Activer TLS (1.2)
Si le serveur doit écouter sur le réseau, il est indispensable d'activer TLS. Pour cela, après avoir créé une paire clé privée / clé publique et un certificat correspondant à cette paire, il faut ajouter les options suivantes au fichier de configuration :
[network]
privatekey=/chemin/de/votre/clé/privée
cert=/chemin/de/la/chaine/de/certification/de/votre/clé
forceencryption=1
min-tls-version=1.2
cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
Signification des options :
- privatekey/cert : fichiers de clé et certificats utilisés pour chiffrer et authentifier la connexion
- forceencryption : refuser les connexions non chiffrées. Ça protège d'un équipement réseau indiscret (écoute passive). Ça ne protège d'une attaque active type homme-du-milieu que si le client vérifie le certificat présenté (voir ci-dessous).
- min-tls-version : par défaut, SQL Server 2019 fonctionne avec TLS 1.0 (1999), TLS 1.1 (2006) et TLS 1.2 (2008). Il ne fonctionne pas avec TLS 1.3 (2018), qui apporte des garanties de sécurité supplémentaires. TLS 1.0 et 1.1 sont considérés comme "non sûrs" aujourd'hui : à moins que vous n'ayez de très vieux équipements qui doivent communiquer avec votre serveur, il vaut mieux désactiver complètement ces versions.
- cipherlist : si TLS 1.2 est encore considéré comme raisonnablement sûr, toutes les suites de chiffrement n'ont pas les mêmes qualités. En particulier, certaines n'offrent pas la confidentialité persistante, la protection contre un attaquant qui enregistrerait les flux réseau chiffrés dans un premier temps puis, dans un second temps, mettrait la main sur la clé privée du serveur. Dans un cas (sans confidentialité persistante), cette clé permet de déchiffrer les échanges passés, dans l'autre cas (avec) cela ne le permet pas. La liste indiquée ici reprend celle de la configuration "intermédiaire" proposée par Mozilla.
Désactiver TLS 1.0 et 1.1 sur le cloud Azure SQL Database
Si vous avez une base de données Azure, la situation est à peine meilleure : un certificat vous est fourni et le chiffrement est activé. Ils utilisent un certificat par datacenter, valable pour tous leurs clients (cf. la liste des "Subject Alternative Name" de ce certificat, par exemple).
Seulement, là encore TLS 1.0 et 1.1 sont proposés par défaut, vous exposant à une attaque type "downgrade". Depuis mai 2020, vous pouvez désactiver ces protocoles à l'aide de la commande suivante :
az sql server update -n sql-server-name -g sql-server-group --set minimalTlsVersion="1.2"
Les remontées d'informations vers Microsoft
Données d'utilisation : Par défaut, Microsoft collecte des données sur l'utilisation du produit. Il n'est possible de désactiver cette remontée d'informations que sur la version payante, avec les options suivantes dans le fichier de configuration :
[telemetry]
customerfeedback = false
Crash dumps : Microsoft collecte aussi les images mémoires lors des plantages de l'application (crash dump) et les conservent jusqu'à un mois. Ils préviennent que ces images sont susceptibles de contenir les identifiants d'accès à la base et des données personnelles contenus dans la base. Il ne semble pas possible de désactiver cette remontée d'informations, mais vous pouvez toujours restreindre l'accès de SQL server au réseau en créant le fichier /etc/systemd/system/mssql-server.conf.d/blocage-reseau.conf :
[Service]
IPAddressDeny=all
# Adaptez la ligne suivante : quelles IP auront besoin d'accéder à votre serveur ?
IPAddressAllow=localhost 192.168.0.0/16
Puis, pour prendre en compte cette modification et redémarrer SQL Server :
$ sudo systemctl daemon-reload
$ sudo systemctl restart mssql-server.service
sqlcmd : --insecure par défaut
Vous connaissez l'option "--insecure" de curl, celle qui signifie que "oui, je me connecte en httpS, mais je me fiche de la validité du certificat, vas-y quand même" ?
Sqlcmd, l'outil en ligne de commande pour se connecter à SQL server proposé par Microsoft, active ce comportement par défaut. Si vous voulez la sécurité apportée par TLS, il faut l'expliciter avec le drapeau "-N". La documentation explique sobrement "This switch is used by the client to request an encrypted connection".
Sans cette indication, vous êtes vulnérable à une attaque type homme du milieu qui peut soit retirer le chiffrement (s'il est partageur) soit vous présenter un certificat autosigné pour espionner la transaction et récupérer les identifiants d'accès.
L'option "-C (trust the server certificate)" n'a d'effet que si l'option -N est présente et a pour effet de forcer l'utilisation de TLS mais sans vérification du certificat du serveur. On est donc protégé d'un attaquant se contentant d'observer la connexion, mais pas d'un équipement trafiquant les données (homme-du-milieu).
Résumé
Synthèse des attaques possibles selon la configuration (NdM: image perdue)
Serveur :
[network]
privatekey=/chemin/de/votre/clé/privée
cert=/chemin/de/la/chaine/de/certification/de/votre/clé
forceencryption=1
min-tls-version=1.2
cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
Client : sqlcmd -N
Si vous hébergez des données très sensibles ou que votre serveur est accessible depuis internet, il vaut mieux payer une licence SQL Server et désactiver la remontée d'informations.
# Dans quel cas ?
Posté par Christophe B. (site web personnel) . Évalué à 9.
Bonjour,
J'aurais juste une question basique qui ne concerne pas SQL SERVER directement mais …
Dans quel cas de figure un serveur de base de données serait exposé depuis internet ?
[^] # Re: Dans quel cas ?
Posté par woffer 🐧 . Évalué à 2.
Dans l'optique de participer à l'attaque de SQL Slammer peut-être ? Je reconnais, dans ce cas, que c'est un peu contradictoire à la sécurisation de SQL Server…
[^] # Re: Dans quel cas ?
Posté par Pinaraf . Évalué à 8.
J'ai déjà vu des applications clientes qui devaient se connecter à un serveur SQL central à déployer «soi-même».
Dans certaines entreprises, si des gens pas assez formés font ce genre de déploiement, cela va aboutir à un serveur SQL directement exposé pour que l'application marche pour tout le monde… Hé oui, tout le monde n'a pas encore compris le VPN. De plus, là c'est SQL Server qui écoute sur toutes les interfaces. Tu peux très bien avoir ton serveur avec eno0 (internet) et un tun0 (vpn), si on n'y prend garde le SQL server qui écoute sur les deux par méprise…
[^] # Re: Dans quel cas ?
Posté par guppy . Évalué à 8.
Dans le cas où on a besoin de s'y connecter depuis internet ?
Il y a des applications dites "métier" écrites sous la forme d'un client lourd qui se connectent à un serveur SQL distant. Ce n'est probablement pas l'architecture qui serait choisie si le développement des applications concernés avait démarré cette année, mais toutes les applications ne datent pas de cette année.
[^] # Re: Dans quel cas ?
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Du bon code, ça dure au moins 20 ans !
[^] # Re: Dans quel cas ?
Posté par ff9097 . Évalué à 1.
Une architecture ça se change
[^] # Re: Dans quel cas ?
Posté par guppy . Évalué à 2.
Tout est possible, mais pour quel gain ?
[^] # Re: Dans quel cas ?
Posté par ff9097 . Évalué à -1.
Ne pas exposer sa BDD en direct sur internet
[^] # Re: Dans quel cas ?
Posté par Pinaraf . Évalué à 10.
Quelle est la différence fondamentale entre exposer la BDD et exposer une API type REST qui donne accès à tout le contenu de la BDD ?
Le pilote pour ta BDD sera probablement dispo dans tous les environnements de développement que tu pourras imaginer, sans même avoir besoin d'un générateur de code pour traduire ton API dans le langage ciblé, voire avec des composants avancés déjà disponibles (traduire une requête en modèle directement exploitable avec tes composants graphiques, par exemple).
La BDD peut faire la gestion de l'authentification, en allant jusqu'au niveau de la ligne dans les tables (Row Level Security dans PostgreSQL, je suppose que SQL Server a un équivalent)
La BDD peut faire abstraction des différents changements (vues, procédures stockées et fonctions, schémas séparés…)
Qu'est-ce-qui ferait donc que fondamentalement, exposer une BDD avec un code lu, relu et rerelu, audité moultes fois, soit moins bien qu'exposer un service HTTP maison par dessus un serveur Web (lui aussi lu, relu etc) ?
[^] # Re: Dans quel cas ?
Posté par fearan . Évalué à 2.
je suppose qu'il souhaiterait que la bdd n'écoute que sur l'interface VPN.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Dans quel cas ?
Posté par Pinaraf . Évalué à 6.
Si tu conçois une application distribuée au delà du réseau d'une entreprise, le VPN n'est pas nécessairement une option… À moins d'assimiler, par exemple, du TLS avec authentification du client par certificat à l'équivalent en sécurité du VPN…
Je pointais simplement que l'argument «la base de données doit être planquée sur un réseau privé» est plus proche du dogme que de l'argument étayé.
[^] # Re: Dans quel cas ?
Posté par NicolasP . Évalué à 2. Dernière modification le 18 mars 2021 à 20:47.
Ça dépend de ce que tu compares. Est-ce que tu compares une base de données + 1 service par dessus (type serveur web), tous les 2 exposés sur internet, à l'équivalent avec uniquement le service web exposé et la base en back-end privé ?
Dans ce cas, la solution avec la base planquée est clairement meilleure, elle diminue la surface d'attaque.
Par contre, si tu compares 1 base de données exposée directement par rapport à 1 base de donnés "planquée" avec 1 service par dessus qui l'expose, effectivement là les arguments sont moins évidents.
[^] # Re: Dans quel cas ?
Posté par Samuel (site web personnel) . Évalué à 6.
Dans le cloud Azure proposé par Microsoft, c'est l'option par défaut :
L'authentification entre les 2 se fait soit via mot de passe, soit via authentification Azure Active Directory (exemple en .net). Dans cette dernière situation, la gestion des droits d'accès se fait dans l'Active Directory du cloud.
[^] # Re: Dans quel cas ?
Posté par Christophe B. (site web personnel) . Évalué à 2.
C'est marrant mais cela ne m'étonne pas de M$ :)
mais laissons de coté les sarcasmes, trop facile, envers petitmou et soyons objectif …
IMHO je prefere que l'éditeur se concentre sur les performances et les fonctionnalités de sa base de données que sur l'aspect sécuritaire.
Et pour moi une base de données devrait être a l'abri derrière des parefeux et ne pas être accessible depuis le net.
Tout comme n'importe quelle application, même codé correctement en prenant en compte l'aspect sécuritaire …
En gros, si une faille de sécurité est découverte dans une base de données ou une application cela peut arriver … l'éditeur doit la corriger, mais la sécurité n'est pas forcément son activité principale et cela peut se comprendre. Difficile d'être bon partout
C'est pour cette raison que l'accès a l'application et/ou à la base de données, pour moi, doit se faire via un VPN, au minimum, dont la raison d'être est la sécurité … cela me paraît logique.
Je ne validerais jamais un accès direct depuis le net a une application ou une base de données dont le but premier n'est pas la sécurité.
Il est possible de scier avec une lime et de limer avec une scie … tout dépend du niveau de résultat attendu :)
[^] # Re: Dans quel cas ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
…Dans le cas d'applications claoudisées où les compétences disponibles ne permettent pas de faire/envisager du vpn par exemple.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# pourquoi SQL server
Posté par CharlesMoritz . Évalué à 5.
Peut-être une question naïve, mais dans quel cas voudrait-on préférer SQL server à ses concurrents (Oracle, Postgres). SQL server a t-il un quelconque avantage?
[^] # Re: pourquoi SQL server
Posté par Pinaraf . Évalué à 3.
Si tu es maqué avec les technologies Microsoft, c'est un choix très intéressant : intégration avec un active directory, procédures stockées en C#, intégration avec visual studio… Cf. https://en.wikipedia.org/wiki/SQL_CLR pour la partie procédures stockées (et autres joyeusetés) en .net.
[^] # Re: pourquoi SQL server
Posté par Buf (Mastodon) . Évalué à 3.
Par rapport à Oracle : principalement le prix. Pour une grosse installation, le prix des licences Oracle est ridiculement élevé, typiquement un ordre de grandeur au-dessus de l'équivalent en SQL Server.
Par rapport à PostgreSQL : comme déjà mentionné, c'est le choix "naturel" quand on a déjà un environnement Microsoft ou qu'on développe en .Net, tous les outils sont conçus pour fonctionner ensemble et s'intègrent facilement. On a aussi un ensemble de fonctionnalités avancées disponibles en standard qui n'existent que sous forme d'outils externes pour PostgreSQL (au niveau de la réplication et haute disponibilité, par exemple, ou pour les données géographiques). Et pour les installations plus petites, il y a une version "Express", gratuite. Elle est évidemment très limitée (en particulier, il y a une limite sur la taille maximale de la db), mais ça reste suffisant dans beaucoup de cas.
Pour avoir travaillé sur SQL Server, je dois dire que c'est un plutôt bon produit, que ça soit niveau fonctionnalités, stabilité, performance ou facilité d'utilisation.
[^] # Re: pourquoi SQL server
Posté par Bruno (Mastodon) . Évalué à 2.
Si tu es maqué il faut essayer de te libérer plutôt que de t'enfermer encore plus non ?
[^] # Re: pourquoi SQL server
Posté par Pinaraf . Évalué à 2.
Évidemment, mais la questions était bien «SQL server a-t-il un quelconque avantage ?», pas «produire un comparatif détaillé des avantages et inconvénients de SQL server» :)
Globalement, si tu veux vraiment exploiter toutes les performances de ta base de données, tu seras très liée à elle. Dans le cas de SQL Server tu utiliseras les fonctionnalités comme .Net intégré, pour PostgreSQL ce sera le système de typage avancé type hstore/jsonb/ltree, les index gin/gist ou encore les trigrammes… (je suis DBA PostgreSQL, pas SQL Server, donc dur pour moi de faire une comparaison).
[^] # Re: pourquoi SQL server
Posté par Bruno (Mastodon) . Évalué à 1.
Oui mais moi je rebondissais sur "maqué aux technologies Microsoft" , celles qui te font choisir Sql Server…on est bien d'accord que une fois que tu as choisi une base tu peux être lié à elle.
Mon propos était de dire que si tu n'es pas maqué avec les technologies Microsoft tu peux choisir une autre base , libre de préférence.
[^] # Re: pourquoi SQL server
Posté par Christophe B. (site web personnel) . Évalué à 3.
Je connais les 2 bases Oracle SQL SERVER dans des environnements de Production
La question est plutôt pourquoi un éditeur ne choisi pas PostGRESQL et MySQL ?
ORACLE est une excellente base de données, certainement une des plus avancèes techniquement parlant, mais cela se paye et très très cher.
De plus la politique commerciale est une des pires que j'ai connues avec un mépris manifeste de certain de leur client.
Oracle ou comment flinguer un bijou technologique par une politique commerciale absurde.
SQLSERVER est une bonne base de données pour peu qu'elle soit gérée par des gens formés. (Oui malgré tout DBA est encore un métier …) son coté facile yakacliké est un leurre mais avec les ressources en adéquations des besoins et bien géré cela fonctionne.
dernièrement elle a bénéficiée, en tout cas dans mon microcosme, de la politique commerciale d'oracle. Mais récemment je trouve qu'elle coute chere quand même sans pour autant offrir des fonctionnalités exceptionnelles.
[^] # Re: pourquoi SQL server
Posté par Mathias Bavay (site web personnel) . Évalué à 1.
Mon avis à 2 centimes comme simple utilisateur d'Oracle: la base de données est bien, mais les outils périphériques sont épouvantables!! Je l'utilise (enfin cela fait un moment que je n'ai pas fait de mise à jour, voir ci-dessous) depuis c++ via occi, en gros il est illusoire de vouloir déployer Oracle occi chez un utilisateur de base. Il faut choisir le bon package qui contienne occi (ce qui n'est pas toujours facile), puis installer un package à moitié cassé (liens symboliques cassés, fichiers pas toujours à un emplacement logique) et enfin espérer retrouver les éléments dont on à besoin car à chaque nouvelle version, l'arborescence change (par example la bibliothèque n'est plus au même endroit donc rien ne fonctionne). Et évidement, reconfigurer PATH et LDLIBRARY_PATH à chaque installation (du fait des points ci-dessus). Pendant quelques années j'ai refait un package propre du client Oracle pour Linux pour les utilisateurs de mon soft sans jamais avoir le courage de faire de même pour Mac et Windows et maintenant, j'ai même arrêté pour Linux…
Si on ajoute les interactions avec le support… en gros, il faut installer d'autres outils Oracle (que l'on doit acheter) avant de renvoyer les résultats et diagnostiques demandés par le support pour enfin se voir répondre qu'ils ne savent pas et ils nous recontacterons (je l'ai vécu plusieurs fois, maintenant je ne prends même pas la peine de contacter le support).
[^] # Re: pourquoi SQL server
Posté par Christophe B. (site web personnel) . Évalué à 2.
IL faut que tu utilises l'instant client
c'est fait pour ça …
si tes besoins son juste de se connecter cela suffit amplement
bien choisir la version car depuis qq années un instant_client ne peu servir que pour 2 versions
en gros tu decompresse dans un répertoire puis tu cree un oracle.sh dans /etc/profile.d
ou tu modifie ton .profile
Ex:
apres c'est tout sqlplus system/manager@SERVEUR:1521/ORACLE_SID
mais de toute facon change … la politique commerciale d'Oracle est a vomir
# Et c'est quoi la pratique en général ?
Posté par Dring . Évalué à 3.
J'ai un peu honte de le dire, mais je suis pas vraiment surpris.
Et je me pose la question : c'est comment avec les autres SGBDR ? Oracle ? PostgreSQL ? MySQL/MariaDB ?
J'installe pratiquement jamais de SGBDR from scratch, et je l'ai pas fait depuis très longtemps, mais de mémoire à chaque fois que j'ai installé un PostgreSQL, que ce soit sur Windows ou Linux, j'ai pas l'impression d'avoir eu à faire des trucs compliqués pour que le serveur soit accessible depuis une autre machine.
Et comme dit par ailleurs, à part de rares cas d'architecture obsolète (client/serveur), on n'expose pas un serveur SQL sur internet. Ou même en dehors d'une DMZ à laquelle seule la couche applicative a accès.
En grande entreprise, pour ce que j'en sais, c'est souvent :
[^] # Re: Et c'est quoi la pratique en général ?
Posté par Pinaraf . Évalué à 8.
Casquette de DBA PostgreSQL !
Par défaut, les paramètres suivants sont appliqués dans PostgreSQL
1) L'écoute par PG pour les connexions
Il s'agit du paramètre listen_addresses, valorisé par défaut à localhost.
Donc quand tu installes un PostgreSQL, sans opération volontaire ou altération par ton distributeur, il est impossible de s'y connecter depuis un autre endroit que la machine elle-même.
https://www.postgresql.org/docs/current/runtime-config-connection.html
2) L'authentification
L'authentification est gérée par le fichier pg_hba.conf de PostgreSQL.
https://www.postgresql.org/docs/13/auth-pg-hba-conf.html
Le fichier par défaut est comme suit:
En français :
- les connexions classiques sont autorisées sur la socket UNIX pour les utilisateurs dont le login correspond à un utilisateur dans la base de données
- les connexions classiques sont autorisées sur la loopback pour les utilisateurs identifiés par login/mot de passe dans la base de données
- les connexions pour réplication sont autorisées de la même manière que les connexions classiques.
Je ne répondrai pas pour les autres SGBDR, je laisse des spécialistes de ces derniers s'en charger.
[^] # Re: Et c'est quoi la pratique en général ?
Posté par fearan . Évalué à 0. Dernière modification le 19 mars 2021 à 07:48.
Tu serais pas en train de comparer un SGBD de qualité professionnel à un jouet quand même ?
(j'ai le droit c'est vendredi!)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Et c'est quoi la pratique en général ?
Posté par vv222 . Évalué à 3.
C’est pas super honnête de qualifier le SQL Server de Microsoft de jouet, il y a des gens qui se reposent très sérieusement dessus dans leur activité professionnelle.
[^] # Re: Et c'est quoi la pratique en général ?
Posté par fearan . Évalué à 3.
Au vu de ma note, au moins trois personnes sont d'accord avec toi :D
Mais blague à part, au vu de la conf par défaut, c'est à se demander si l'éditeur lui même ne le considère pas comme tel.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Et c'est quoi la pratique en général ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 21 mars 2021 à 17:43.
L'un n'a jamais empêché l'autre ; il y a eu plein d'entreprise qui ont utilisé les ordinateurs domestiques à des fins professionnelles. (je ne parle pas que de l'époque Atari, puisqu'on a vu plus tard en entreprise plein de fenêtre xp puis vista qui n'étaient pas estampillées pro s'utiliser comme poste de travail pro… et récemment dans un grand groupe j'ai vu utiliser la version express de sql-server en production)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et c'est quoi la pratique en général ?
Posté par vv222 . Évalué à 2.
Ça ne me surprend pas plus que ça.
Dans ma dernière boîte (une agence Web), le pré-requis pour utiliser un produit ou service était que celui-ci soit gratuit.
[^] # Re: Et c'est quoi la pratique en général ?
Posté par Samuel (site web personnel) . Évalué à 4.
Sur ma Debian, mariadb écoute en local par défaut. Dans le fichier /etc/mysql/mariadb.conf.d/50-server.conf, j'ai :
Par contre, avec YaSSL on est limité à TLSv1.1 et Debian utilise YaSSL depuis 2014, suite à des embrouilles de licence autour d'OpenSSL 😐 .
[^] # Re: Et c'est quoi la pratique en général ?
Posté par vv222 . Évalué à 4.
Sur Debian, mariadb-10.5 dépend bien de libssl-dev pour la construction des paquets binaires depuis les sources. Ça devrait être la version fournie avec la prochaine stable, Debian 11 Bullseye.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.