Vincent Danjean a écrit 143 commentaires

Il y a un truc que je ne comprends pas dans ton explication avec LUKS. L'étape 3 est :

Cryptsetup vérifie cette signature avec la clé publique stockée dans l’en-tête LUKS
Si la signature est valide :
cryptsetup débloque la clé LUKS (la vraie clé de chiffrement).
[…]

Que signifie "cryptsetup débloque la clé LUKS (la vraie clé de chiffrement)" ?

Pour l'instant, je n'ai pas de clé FIDO2. Quand je démarre mon ordi, l'initramfs (non crypté) me demande le secret d'un slot LUKS pour accéder à la (vraie) clé privée LUKS => même si je remplace cryptsetup par une version vérolée dans mon initramfs, il me faut le secret d'un slot pour avoir l'info permettant d'accéder à la (vraie) clé privée LUKS.

Quand je lis ton explication, ça donne l'impression que cryptsetup vérifie une signature sur un challenge et, si tout est ok, il débloque la (vraie) clé privée LUKS tout seul. Et donc qu'une version vérolée de cryptsetup pourrait sauter l'étape de vérification de la signature et aller directement débloquer la (vraie) clé privée LUKS. Je n'y crois pas. Qu'est-ce que je manque, qu'est-ce que j'ai mal compris ? Pour moi, il y a nécessairement un secret qui doit venir de la FIDO2 et qui est nécessaire pour débloquer la (vraie) clé privée LUKS.

Effectivement, on était passé à côté. Je vais voir si je peux recontacter l'étudiant pour lui proposer cela.

• Nous la problématique c'est le manque de wifi sur les tours qu'on récupère, donc j'ai acheté des mini clés Wifi, vous avez des bonnes ref pas cher et bien compatible Linux car certains chipset n'était pas directement compatible Linux.

C'est effectivement un point parfois problématique. C'est déjà difficile de savoir si une carte est supportée nativement ou pas par le noyau Linux : parfois, un support Linux est annoncé, mais avec un driver propriétaire qui n'est pas toujours mis à jour avec les évolutions du noyau (certaines cartes realtek, etc.) J'avais commencé à taper un grand texte, mais finalement j'en ai fait un journal séparé : https://linuxfr.org/users/vdanjean/journaux/support-des-cartes-wifi-sous-linux

Cette année, j'ai vu un étudiant avec un portable sous Windows à qui on n'a pas pu fournir un Linux, ni en dual-boot, ni en VM. C'était un portable ARM64 avec un Windows ARM. Le CD Debian ARM démarrait mais gelait très vite : je suppose que la table de description de matériel (DTD?) n'était pas disponible dans le noyau pour cette machine. Et je n'ai trouvé aucun hyperviseur tournant dans un Windows ARM. Il en existe pour les Mac ARM pourtant, qui peuvent faire tourner des Windows ARM en VM. Mais ce n'est pas le sens qu'on cherchait.

Les Mac Intel fonctionnent très bien avec Linux (en dual/single boot ou en VM).
Pour les Mac Apple Silicon, les M1 et M2 peuvent être installé en dual-boot (presque tout le matériel est supporté). Asahi Linux fait son développement avec fedora il me semble, mais le travail est utilisé par les autres distrib. Debian a une doc pour installer trixie sur ce matériel.
Sinon les M1, M2, M3 et M4 peuvent faire tourner Linux en VM (avec utm, VMWare, etc.)

Même si on autorise n'importe quelle distrib (on a eu des gentoo, des Arch, etc.), les enseignants présents ont une connaissance plus complète des distribution basée sur du deb (plutôt que rpm, etc.) Pour ma part, je suis développeur Debian, donc je connais très bien ce système et le passage vers Ubuntu est assez simple. Même si j'arrive à me débrouiller avec d'autres distrib (fedora, etc.), je suis moins à l'aise pour trouver des paquets dédiés à du matériel spécifique (cartes vidéo, etc.) ou pour forcer l'installation de certains paquets d'une version plus récente (backports voire testing ou unstable pour Debian) quand le matériel le nécessite. On annonce donc un support complet pour Ubuntu/Debian et du mieux qu'on peut pour les autres (les étudiants doivent alors être grandement autonome).

Depuis de nombreuses années, j'organise avec des collègues des Linux Install Party à destination d'étudiants. On cible des promos entières de parcours (L3 Info, M1 Info, 1ère année d'école d'ingénieur, etc.) en essayant de faire des groupes d'au maximum 50 étudiants environ quand la promo est trop grande. Je dois donc atteindre maintenant plusieurs milliers d'installation de Linux (en dual-boot principalement, mais aussi en VM et quelques unes en single-boot)

Notre méthode d'installation a varié au cours du temps. Initialement, on avait mis en place une installation par PXE (avec un serveur qui faisait proxy) : but limiter la bande passante consommée par plusieurs dizaines d'installations en parallèle (avec du 100Mb/s en uplink). On installait des Ubuntu (LTS) par défaut, on supportait Debian pour les étudiants qui le souhaitaient et on aidait du mieux possible en fonction du temps disponible les étudiants qui voulaient une autre distribution.

Il y a quelques années, on est passé à l'installation par clé USB. Certes, il faut les acheter et les préparer, mais l'infra matérielle est plus simple (plus de serveur DHCP+PXE+DNS+Squid+…), de même que l'installation dans une VM (configurer le réseau d'une VM en PXE, c'est faisable mais pas classique). C'était d'autant plus nécessaire que la prise RJ45 a disparu de nombreux portables (la borne wifi de nos locaux n'a pas un débit suffisant et ne permet pas de placer un serveur entre le wifi et internet (pour PXE, Squid, …)

Cette année, on est passé à Debian par défaut : Ubuntu ne permet plus d'être installée avec LVM en dual-boot (on a utilisé un contournement à base de scripts home-made l'an dernier mais c'est trop lourd) et l'utilisation systématique de snap pour des choses comme firefox conduit expérimentalement à une consommation d'espace disque non raisonnable au bout de quelques mois. L'installation avec LVM, en option les premières années, a été rendue obligatoire pour les installations en dual-boot (trop de travail sinon pour rééquilibrer l'espace windows/linux après quelques mois). Pour Debian, on utilise le DVD1 (et pas le netinst qui demande trop de ressources réseau). Là encore, j'ai quelques scripts pour retoucher le DVD1 et l'adapter à notre environnement (Français par défaut, sudo par défaut, paquets supplémentaires ajoutés dans l'image et installés automatiquement, ajout des paquets de security/updates depuis la sortie du DVD1 officiel, etc.)

Au niveau organisation, on prévoit aussi systématiquement un amphi (cours avec tous les étudiants intéressés) où on présente ce qu'on va faire, les choix qu'ils auront (dual-boot/VM, encryption ou pas, etc.) et quelques screenshots des étapes importantes. On fait cela dans la semaine précédente généralement. Ça permet aussi de leur dire de faire une sauvegarde complète de leurs données (et de leur dire que les sauvegardes doivent être faites tout le temps, pas seulement avant une install-party, message qui a toujours du mal à passer tant qu'ils n'ont pas perdu un disque dur…)

Quelques anecdotes tout au long de ces années (probablement environ 15 ans) :

• chaque année, on découvre de nouveaux problèmes. Ça peut venir du BIOS (les constructeurs sont inventifs avec l'UEFI/SecureBoot), de Windows, de matériels particuliers (mémoire Optane, …), etc.
• la règle du 80/20 (voire 90/10) est vérifiée chaque année : 80% des installations se font en moins de 20% du temps prévu, 20% des installations prennent 4 fois plus de temps (les machines avec les problèmes évoqués au point précédent). Pour les installations qui roulent (la plupart), le plus long est la réduction de la partition Windows (en cas de dual-boot) et l'installation des paquets Linux proprement dits ;
• jusqu'à maintenant, les sauvegardes imposées à tous les (milliers) d'étudiants qui ont installé Linux avec nous ont servi deux fois : une fois où je n'ai vraiment pas compris ce qui s'est passé. L'installation Windows s'est retrouvée dans un état complètement non fonctionnel. Et une fois où l'étudiant a mal lu ce qui était indiqué (prendre l'option "Installer Linux sur la totalité du disque" a effectivement détruit sa partition Windows…)

On essaie de compléter chaque année notre base de connaissance des problèmes rencontrés. Si ça peut servir à d'autres personnes, c'est ici : https://air.imag.fr/index.php/Linux_Install_Party (et aussi ici pour des points plus techniques : https://air.imag.fr/index.php/LIP_recovery )

Autant sur PC, c'est admis d'utiliser des logiciels alternatifs (Linux etc.), même si je pense qu'ils (Microsoft et co.) adoreraient qu'on soit obligé d'installer un système d'exploitation signé sur nos machines (SecureBoot étant facilement contournable), autant sur mobile/tablette, c'est de plus en plus compliqué.

Sur les PC, ça reste possible d'installer un autre OS même avec SecureBoot car, dès le début, pour faire taire les oppositions, il a été obligatoire pour les constructeurs d'offrir une méthode pour changer les clés. De fait, on utilise plutôt celle de MS avec shim (grub signé par MS), mais normalement, on doit pouvoir mettre ses propres clés dans le BIOS (avec une procédure propre à chaque constructeur voir modèle).

Ça, c'était la norme SecureBoot pour x86.

Pour ARM/ARM64, la possibilité de pouvoir changer de clé n'a pas été garanti dans la norme. En pratique, je ne connais pas de matériel Arm64 qui le permette (même s'il est probable qu'on arrive à en trouver, ça restera extrêmement rare)…

Mes téléphones (le mien et tous ceux que je gère autour de moi) sont sous lineageos depuis des années. Au printemps dernier, j'ai passé à mes beaux-parents un téléphone supplémentaire sous Android "officiel", sans carte SIM, juste pour pouvoir faire fonctionner de manière pérenne leur appli bancaire :-(

Sur mon téléphone, je "joue" régulièrement avec magisk et modules supplémentaires pour que les applis aient l'illusion d'un téléphone certifié (pour les applis bancaires en très grosse majorité) mais c'est un jeu du chat et de la souris entre Google et ces modules. Et avec le TPM, quand Google fera les choses correctement, j'ai bien peur qu'il gagnera. Mes beaux-parents n'étant pas sur place, je ne pouvais pas leur faire tester ces manips régulièrement pour refaire fonctionner leur appli bancaire.

Je ne vois pas trop comment éviter à terme ce portable en plus pour ce genre d'applis (sauf à se passer de ces applis, mais là, ça implique de très grosses contraintes supplémentaires pour le moment) si on veut garder un portable principal avec un Android alternatif. Je m'étais posé la question de contrôler ce portable supplémentaire à distance (genre écran déporté) pour éviter de devoir le prendre en plus en déplacement, mais je n'ai pas encore testé. Si des gens ont des retours d'expérience là dessus, ça m'intéresse.

Je suis surpris (agréablement) par le fait qu'un lycée ait pu passer sous Linux de part sa propre décision.

Dans les écoles, collèges et lycées autour de moi (Grenoble, Isère, Auvergne-Rhône-Alpes), la gestion du parc informatique (matériel et logiciel) est sous la responsabilité des collectivités concernées (commune, département et région respectivement). Et, par exemple, la région délègue/sous-traite cet aspect à une boîte (d'info gérance ?) ce qui fait que tous les postes des lycées sont sous Windows, y compris ceux utilisés par la spécialité NSI (où il y aurait parfois besoin avoir un vrai shell, de pouvoir tester (pédagogiquement) des configs réseaux, etc.) Et donc, même si localement il peut y avoir des personnes motivées, ça ne suffit pas pour récupérer la main sur le contenu des ordinateurs achetés par la collectivité.

Vous avez des infos sur comment ces passages sous Linux ont été possibles ? (collectivités qui participent ?)

Bonjour,

Pour moi, à partir de la description et du dépôt git indiqué, il reste plusieurs zones d'ombre sur le fonctionnement de ce logiciel :

• ré-empaqueter un AppImage dans un .deb (par exemple) permet que les fichiers installés soient visibles par le gestionnaire de paquet. Mais ça ne change rien aux mises à jour ? Elles sont toujours invisibles avec APT (par exemple) puisqu'il faut explicitement recréer un nouveau .deb à partir d'un nouveau AppImage

• je ne vois pas comment le boulot des mainteneurs de paquets pourra être fait automatiquement par aeryth : comment s'assurer que les bibliothèques systèmes sont utilisées et compatibles avec le logiciel AppImage (ou comme gérer quand l'AppImage apporte une bibliothèque déjà présente sur le système), comment s'assurer que le logiciel est bien compatible avec le reste des logiciels installés (système de son, etc.), …

Si c'est juste pour dépaqueter le AppImage dans /opt/, ça respecte peut-être le FSH, mais pas le standard des .deb officiels par exemple (et ça ne fait rien contre la multiplication des bibliothèques et donc de l'empreinte mémoire de ces bibliothèques en RAM qui ne peuvent plus partager leur code, ni pour la sécurité par mise à jour des bibliothèques problématiques)

Un téléphone portable n'est pas suffisant. Il faut en outre qu'il soit équipé d'Android (ou celui d'Apple) souvent dans une version récente.

Tous les téléphones portables dont je m'occupe sont sous lineageos. Je suis informaticien, je ne vois pas pourquoi je ne pourrais pas exploiter complètement le matériel que je paye suffisamment cher. Et que je fais fonctionner bien plus longtemps que le constructeur ne l'a prévu (en 15 ans, je n'en suis qu'à mon second smartphone). Adblock en root est une appli magique pour éviter les bandeaux de pub.

Et bien, même avec un lineageos bien plus récent que l'Android stock qu'on pourrait avoir sur ces machines, les applis bancaires refusent de s'exécuter. Pour le moment, on trouve encore des solutions de contournement pour faire croire que l'appareil est certifié, mais quand la certification matérielle va devenir obligatoire (ça risque d'arriver assez vite vu que Google l'a imposé dans le matériel depuis quelques années maintenant), alors ça sera fini.

La seule manière de pouvoir continuer à utiliser ces appli sera d'avoir un smartphone supplémentaire dédié à ces applis !

Toute la difficulté est de savoir où placer la limite.

Moins de dépendances, c'est effectivement moins de code (surface d'attaque moindre) et moins de personnes extérieures à qui faire confiance. Le journal l'explique très bien. Et, quand on peut obtenir moins de dépendances juste en changeant la bibliothèque qu'on utilise, c'est très bien.

Mais si on enlève des dépendances en réécrivant soi-même le code de la bibliothèque, là, on peut partir dans l'excès inverse : on risque de recoder mal ce qui a été codé bien par une équipe compétente. On perd la force du travail d'équipe, le partage du travail.

La frontière est mince. Dans le journal, les exemples donnés semblent raisonnables (grosses bibliothèques enlevées en (re)codant quelques cas particuliers) mais il serait facile d'aller trop loin si on ne fait pas attention. J'ai vu nombres d'étudiants recoder (très) mal des fonctionnalités de bibliothèques pour de mauvaises raisons (ignorance de l'existant, c'est plus rigolo de tout (re)faire soi-même, etc.)
Dans le contexte d'enseignement, ça peut être bien (on apprend quand on (re)code), mais dans un contexte plus professionnel (stage, emploi), ça peut vite apporter des problèmes (performances, sécurité, maintenabilité, etc.)

tronc commun à partir de l'équivalent de la 6ème

Si ce n'est pas indiscret, c'est dans quel pays ? Et avec quel volume horaire ? (juste pour voir à quel point la France est en retard)

Le gros intérêt des SMS à mon sens, c'est leur disponibilité sans internet.

J'ai des enfants qui n'ont pas de data (vieux téléphone pour l'un, smartphone mais sans data pour l'autre), les SMS permettent de dialoguer avec eux par texte.

Je suis convaincu que le protocole est nul, avec aucune sécurité, aucune garantie, mais vu la teneur des messages échangés, ça ne me dérange pas trop. Ça permet même de les éduquer au fait que ce n'est pas parce qu'on envoie une info qu'elle est reçue.

Récemment, j'ai fait une passerelle SMS - web pour le service de passage des bus/tram de mon agglo. Les afficheurs aux arrêts sont presque tous HS, les enfants appelaient régulièrement pour connaître les horaires de passage. Maintenant, ils envoient un SMS chez nous et ils obtiennent leurs horaires. (Le site web de la compagnie est bien fait avec une récupération des données directement en JSON, donc faciles à manipuler et à convertir en texte pour SMS)

La clé SIM/USB que j'utilise fonctionne en 3G. Il faudra peut-être que je la change pour une 4G ou 5G si le réseau 3G s'arrête :-(

Pour ma part, j'essaie toujours de coller (et utiliser) au maximum les paquets python de ma distrib (Debian pour ne pas la citer), et de n'installer que le minimum supplémentaire lorsque cela est nécessaire (installation d'un logiciel python avec des dépendances pas toutes présentes dans ma distrib).

Ma raison, c'est que j'aime bien que apt upgrade fasse l'essentiel du travail de mises à jour de sécurité. Il y a des gens qui surveillent ce qui se passe pour les logiciels de ma distrib, j'aime bien leur faire confiance. Évidemment, avec des logiciels/dépendances externes, c'est plus compliqué, il faut faire plus de veille (et donc ça demande plus de boulot de maintenance/administration).

J'évite généralement les venv ou virtualenv ou conda ou … : ça installe trop de chose en double (au moins). Évidemment, je sais ce que je fais, et je sais que je peux arriver sur des problèmes difficilement solvables sans ses outils. Mais tant que ce n'est pas le cas, j'évite.

En pratique, j'essaie de trouver les dépendances nécessaires. J'installe en priorité celles de ma distrib. J'installe les manquantes sur un compte utilisateur (surtout pas dans /usr ou /usr/local) avec (de mémoire) pip install --user --break-system-packages paquet
Je regarde alors ce qui est installé. Si des sous-dépendances ont été tirées, je les vire (rm .local/lib/python3.11/site-packages/...), j'installe leur version packagée et je recommence avec pip.

Ça me permet souvent de minimiser les paquets installés avec pip (uniquement ceux non présents dans ma distrib) mais ça veut dire que je n'utilise pas forcément une combinaison de versions très testée par le développeur ou les autres utilisateurs (même si cette combinaison respecte des infos de dépendance).

Si je me souviens bien, le TO7-70 avait son système sur une "cartouche" (qui était probablement adressable directement par le processeur) avec, au choix, Basic ou Logo.

Et mon premier ordinateur à la maison (Atari 1040 STe) avait son OS en ROM. C'était un argument de vente : le code de l'OS ne prenait pas de place en RAM donc il restait plus de RAM pour les applis…

11 à 20% de cache-misses supplémentaires quand cstdlib est absent

J'ai déjà vu ce genre de choses même à l'exécution plutôt qu'à la compilation. La présence ou non de variables d'environnement (non utilisées par le programme) modifiait les perfs de manière significative. Après enquête, la taille des données des variables d'environnement modifiait la place initiale de la pile, ce qui modifiait les conflits de cache de l'application. Ça avait été long à comprendre également.

Ça fait des années que j'utilise woob pour récupérer mes opérations bancaires journalières avec quelques scripts pour 1) sauver les transactions en CSV, 2) me faire des alertes (min/max/mouvement/…) suivant mes comptes.

Ça a marché très bien longtemps. Puis il a fallu s'authentifier sur le site web / en ligne avec un truc en plus (téléphone, etc.) donc la crontab s'arrêtait de fonctionner tous les mois. Puis, depuis quelques mois, c'est systématique. Mes scripts cron échouent systématiquement. Je dois les lancer manuellement en réalisant systématiquement une double authentification manuelle.

Bon, ben en pratique, je surveille beaucoup moins mes comptes depuis ces changements :-(

Est-ce que vous connaissez des banques permettant de récupérer automatiquement l'état des comptes et les transactions (je conçois que l'authentification puisse être plus importante quand on veut faire des mouvements d'argent).

fetchmail permet aussi de récupérer des boîtes et des les transférer ailleurs (local ou réexpédition vers une autre adresse) en effaçant ou pas le mail de la boîte initiale. Bon, faut écrire le fichier de config à l'ancienne, mais ça peut faire le boulot.

Mon premier ordi à la maison était un Atari 1040 STE. Raison de mon choix : je voulais faire de la musique (MIDI) et l'Atari avec ce port par défaut (avec Notator puis Notator Logic comme logiciel, concurrent de Cubase). Le vendeur nous avait conseillé cela ou un Mac (ce dernier étant beaucoup plus cher).

Il arrivait avec une interface graphique, une résolution de 640x400 ! (en monochrome). Et le Omicron Basic. Je n'ai jamais acheté de compilateur (les programmes étaient lents) et j'avais été sidéré par la vitesse de l'assembleur quand un magazine en avait fourni un (version précédente d'une version commerciale).

De mon point de vue, Atari a beaucoup tardé avant de passer au 68030 (processeur avec une MMU) avec le Falcon 030 qui a permis un vrai multitâche (et le multitâche coopératif n'a pas été développé/poussé sur les précédents ordis où le système était en ROM). Les PC avaient alors pris leur envol. Mon dernier Atari a été effectivement un Falcon030. C'est aussi là où j'ai appris le sens de "Debian fait sa release quand elle est prête" : j'ai attendu plus d'un an Debian Hamm (2.0) qui devait tourner sur 680x0. J'ai finalement installé une Slack avant que Hamm soit dispo (au moins une vingtaine de disquettes pour la distrib Slack !). Cela avait en outre nécessité une cross-compilation du noyau (il fallait intégrer un patch pour émuler les instructions flottantes non présente dans le Falcon030) faite en semaine sur les ordis de mon lycée de prépa (salle entière en réseau sous Linux !, accès limité à Internet avec le lien RDNIS (pas sûr de l'acronyme) vers le rectorat). C'était le bon temps ;-) (Gropher puis Netscape, slip/plip pour les réseaux locaux, etc.)

Le SecureBoot/TMP, c'est un SecureBoot temporaire ? ;-)

Tu as essayé de mettre init=/bin/bash à la ligne de grub [sur un système installé de base] ? Je trouve cela généralement plus pratique que de trouver/utiliser une clé USB bootable.

Chiffrer les données n'est intéressant que si on est confiant dans l(es) administrateur(s) de la machine (actuel(s) et passé(s)) quand on déchiffre les données. Sinon, s'il y a un keyloguer ou autre truc équivalent, alors c'est tout perdu. Et ça peut être très rapide si les données chiffrées ont déjà été copiées (encore chiffrées) avant (juste le mot de passe intercepté à transmettre en plus).

Si une machine passe dans les mains de quelqu'un de compétent et motivé (une douane par exemple, au hasard), et si la machine contient des données réellement précieuses, il vaut mieux laisser tomber l'ordi. TPM2 (avec secure boot) est censé protéger de cela (si tout est bien et complètement implémenté), mais bon, il faut encore faire confiance au constructeur de matériel (la puce TPM2). Et je ne connais pas l'interaction possible avec Intel® Management Engine (le processeur dans le processeur avec un OS non connu, capable d'intercepter les données des bus…)

Il est par contre facilement possible de bloquer les attaques qui respectent l'intégrité de la machine (pas de démontage, …), ce qui est généralement le cas dans les salles de TP dans l'enseignement par exemple. Il faut alors configurer et protéger le BIOS (accès BIOS avec mot de passe, démarrage forcé sur le média choisi, interdit sur les autres média) et protéger Grub (pas de console sans mot de passe).

Pour les curieux, ce que je reproche à dialog c'est:

• l'utilisation de STDERR pour récupérer le résultat, donc on ne peux pas faire INPUT=$(dialog foobar), il faut passer par un fichier temporaire qu'il faut ensuite lire.

Je ne comprends pas vraiment cette remarque :
- avec les redirections shell, il est possible d'inverser stdout/stderr d'un process
- dialog semble capable de sortir son résultat sur stdout

Dans les exemples de dialog, voir par exemple timebox et timebox-stdout (dans /usr/share/doc/dialog/examples sur une Debian)

Je suis impressionné par tout ce que vous avez fait (et votre message m'a fait penser à vous soutenir).

Je suis par contre dégoûté par ce que je vois dans les milieux professionnels du public dont je suis proche avec les millions dépensés en solutions propriétaires qui ont plein de défauts. L'exemple le plus frappant pour moi est ADE, un logiciel de gestion d'emploi du temps (avec les salles) utilisé dans de nombreuses universités. Il est proposé par l'AMUE donc il éclipse progressivement toutes les solutions locales parfois meilleures techniquement (mais reposant alors souvent sur une personne, et quand elle part, paf la solution "clé en main" AMUE est la plus "simple"). Il a d'énormes défauts connus depuis de nombreuses années. Par exemple, pour la partie consultation (web), une ergonomie limitée pour le moins, des filtres quasi inexistants, etc. Pour la partie modification (avec un client lourd), il est possible d'effacer un emploi du temps d'une filière entière en un seul clic, sans confirmation, sans possibilité d'annulation de l'action ! Seule solution alors : restaurer une sauvegarde de la base de données.
Vu le nombre d'établissements du supérieur qui payent ce logiciel, je ne comprends pas qu'une partie de l'argent n'ait pas été utilisé pour développer une solution libre (d'autant que, vu le milieu et les utilisateurs impliqués, il est évident qu'il y aurait de nombreuses contributions extérieures).

Plus généralement, je ne comprends pas que l'état n'impose pas une licence libre dans les appels d'offre qu'il soumet pour ses missions de service public. On paye pour un développement, certes, mais ensuite on le maîtrise et on peut le faire évoluer comme bon nous semble. Il y a quelques sociétés qui proposent cela et ça marche.