GuiGui's Show

Comme à chaque passage à une nouvelle version de Debian GNU/Linux, voici un résumé de tout ce qui a foiré ou changé pour moi quand je suis passé à Trixie (Debian 13).

Comme d'hab, les changements majeurs sont dans la doc, tout comme la procédure de mise à jour.

Cette dernière se résume à :

apt update && apt -y dist-upgrade && apt clean && apt -y autoremove --purge
apt list '?obsolete'
apt list '?config-files'
apt list '?narrow(?installed, ?not(?origin(Debian)))'
apt-mark showhold
find /etc -iname '*.dpkg-old'
find /etc -iname '*.dpkg-new'
find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
dpkg --audit
Modifier sources.list
apt update
apt upgrade --without-new-pkgs
apt full-upgrade
reboot
apt autoremove --purge <ancien_noyau>
apt clean
apt modernize-sources
apt list '?obsolete'
apt list '?config-files'
apt list '?narrow(?installed, ?not(?origin(Debian)))'
find /etc -iname '*.dpkg-old'
find /etc -iname '*.dpkg-new'
find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'

APT

Pour les fichiers de sources de paquets, passage au format deb822 et à sources.list.d (qui existe depuis belle lurette, on est d'accord).

La doc préconise de le faire avant la mise à jour. Je préconise de le faire après, car alors l'outil apt modernize-sources sera disponible et fera tout le boulot. D'ailleurs, la doc préconise aussi cela 😀️. Via.

BIND

J'utilise BIND en tant que serveur DNS faisant autorité. J'attends qu'il mette à disposition exclusivement mes zones DNS (comme j'attends de mon serveur web qu'il serve uniquement le contenu que je lui indique). J'avais donc supprimé toutes les zones par défaut (.local, 127.in-addr.arpa, 168.192.in-addr.arp, etc. Pour la culture, lire ceci.).

Sauf que :

The default empty zones, and localhost forward and reverse zones have been removed from the package in favor of BIND 9 native directive empty-zones yes (that is on by default).

This include following configuration files:

• /etc/bind/db.0
• /etc/bind/db.127
• /etc/bind/db.255
• /etc/bind/db.empty
• /etc/bind/db.local
• /etc/bind/named.conf.default-zones
• /etc/bind/zones.rfc1918

Please make sure you are not including any of these files in your configuration.

Dit autrement, pour ces zones, BIND va désormais répondre tout seul, sur la base d'une config intégrée (built-in), que ces zones sont vides. Mais moi je veux qu'il ne réponde pas du tout.

D'après la doc, la directive « empty-zones » n'existe pas. Il s'agit de « empty-zones-enable ».

Malgré ce que dit la doc de BIND et celle de Debian (ci-dessus), je constate que BIND 9 ne sert pas ces zones par défaut, il faut « empty-zones-enable yes; ».

Dans le doute, j'ai quand même ajouté empty-zones-enable no; dans la config.

curl

Implémente http/3. --http3 / --http3-only. Oui, ces commandes figuraient dans le manuel de la version livrée avec Debian 12 mais ça ne fonctionnait pas.

CRON

Running 'cron -N' triggers a cron tick, causing all job definitions to be processed immediately, and then exits. This is useful for testing changes in crontabs.

devilspie

Je l'utilise pour centrer mon terminal, celui de Mate, et en changer la taille. (Les paramètres de Mate permettent uniquement de changer la taille, pas de centrer.)

Le terminal de Mate a changé de nom au niveau du système de fenêtrage : « terminal » => « Mate-terminal ». Donc Devilspie ne sait plus agir dessus.

Dans ~/.devilspie/terminal.ds, j'ai changé la valeur du « application_name » :

(if (is (application_name) "Mate-terminal")
    (geometry "1800x900+55+60"))

J'ai aussi renommé ce fichier en mate-terminal.ds, simplement pour la cohérence.

Pour trouver le nouveau nom :

$ echo '(debug)' > ~/.devilspie/debug.ds
$ devilspie

Dovecot

D'une part, la réplication a été abandonnée. (Via Johndescs.)

D'autre part, la syntaxe du fichier de configuration a changé. (Via Aeris.)

Il doit commencer par :

dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0

Des paramètres ont été renommés ou supprimés.

Dovecot propose un outil de migration. Je l'ai essayé et il y a eu des ratés.

Si ça peut aider, voici ce qui a changé chez moi :

• Les blocs « userdb » et « passdb » doivent être nommés (le nom est sans importance) ;
  
  
• « disable_plaintext_auth = yes » => auth_allow_cleartext = no (la valeur par défaut est « no ») ;
  
  
• « ssl_cert » => ssl_server_cert_file (du coup, plus de redirection de fichier, « = </chemin/vers/certificat », juste « = /chemin/vers/certificat) ;
  
  
• « ssl_key » => ssl_server_key_file (même remarque) ;
  
  
• « ssl_prefer_server_ciphers = yes » => ssl_server_prefer_ciphers = server ;
  
  
• « ssl_dh » => ssl_server_dh_file ;
  
  
• Directive « sieve » d'un bloc « plugin » (qui permet d'indiquer l'emplacement du script Sieve d'un utilisateur) => directive path d'un bloc sieve_script qui doit être nommé ;
  
  
• Directive « sieve_extensions » d'un bloc « plugin » (qui permet d'activer des extensions Sieve supplémentaires) => <nom_dune_extension> = yes (ex. « editheader = yes ») dans un bloc sieve_extensions.

Ces changements de syntaxe m'ont contraint à lire la documentation de Dovecot.

J'y ai découvert que le processus anvil peut être exécuté en non-root.

Il est également possible de faire tourner les processus d'authentification en non-root lorsqu'on utilise passwd+shadow, puisque tout membre du groupe d'utilisateurs shadow peut lire /etc/shadow.

Pour mettre tout cela en œuvre, j'ai ajouté ou modifié ceci dans ma config Dovecot :

service auth {
  user = dovecot
  group = shadow
}

service auth-worker {
  user = dovecot
  group = shadow
}

service anvil {
  user = dovecot
}

Ne pas oublier d'appliquer la conf : systemctl reload dovecot.

ejabberd et AppArmor

$ systemctl status --state failed
apparmor.service

journalctl -u apparmor crache le morceau :

apparmor.systemd[2371]: Restarting AppArmor
apparmor.systemd[2371]: Reloading AppArmor profiles
apparmor.systemd[2469]: profile has merged rule with conflicting x modifiers
apparmor.systemd[2469]: ERREUR lors du traitement Regex du profil su, le chargement a ?chou?
apparmor.systemd[2371]: Error: At least one profile failed to load
apparmor.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: apparmor.service: Failed with result 'exit-code'.
systemd[1]: Failed to start apparmor.service - Load AppArmor profiles.

Solution :

$ /sbin/apparmor_parser -N /etc/apparmor.d | grep su
surfshark
/usr/sbin/ejabberdctl//su

L'origine du problème serait donc le profil AppArmor pour ejabberd.

La date de dernière modification du fichier /etc/apparmor.d/usr.sbin.ejabberdctl est janvier 2021.

$ dpkg -S /etc/apparmor.d/usr.sbin.ejabberdctl
ejabberd: /etc/apparmor.d/usr.sbin.ejabberdctl

Ce fichier aurait été déposé par le paquet logiciel ejabberd.

C'était le cas dans Debian 12, mais plus dans Debian 13.

apt-file search /etc/apparmor.d/usr.sbin.ejabberdctl indique qu'il n'est pas déposé par un autre paquet.

Il reste la possibilité d'un fichier créé par un script de post-installation, mais apt install --reinstall ejabberd ne recrée par le fichier.

Un redémarrage d'ejabberd après un effacement du fichier fonctionne.

Conclusion : rm /etc/apparmor.d/usr.sbin.ejabberdctl.

Commande free

free: Used memory is Total - Available This means versions of free after 4.0.0 will show different Used values for older frees and some other system utilities.

Gajim

Problème majeur : plus d'icône dans la zone de notification, que ce soit avec mate ou avec gnome-shell.

Si on lance Gajim depuis le terminal, on obtient l'erreur :

(E) gajim.c.tray.linux     g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.kde.StatusNotifierWatcher was not provided by any .service files (2)

L'affichage de l'icône et du menu se fait désormais via DBus, via l'interface « org.kde.StatusNotifierItem » (= SNI). Source. Il faut donc que l'environnement de bureau implémente cette interface, écoute ces messages.

Solution :

If you remove mate-indicator-applet from the panel then you need to set enable-sni-support to True in org/mate/panel/general using dconf-editor.

mate-indicator-applet est bien installé. J'ai bien ajouté, à mon tableau de bord mate, tous les types d'applet de notification qui me sont proposés, sans succès. En revanche, l'activation de SNI dans dconf-editor, suivie d'un redémarrage, a fonctionné \o/.

Il faut s'assurer de ne pas avoir d'autres logiciels qui écoutent le bus SNI, comme ayatana-indicator-application ou ayatana-indicator-notifications ou taffybar ou…

Pour gnome-shell, il faut installer cette extension.

Quelques améliorations notables de Gajim (comparément à ma dernière critique) :

• On peut désormais préciser une plage de dates pour la recherche par mot-clés dans l'historique de conversation ;
  
  
• On peut remonter aussi loin que possible dans l'historique d'une conversation et autour des résultats de recherche : il n'y a plus de "saut" aléatoire vers le présent ou le lendemain du résultat ou… En revanche, la lenteur du défilement pour arriver jusqu'à l'extrait de conversation après un clic sur un résultat de recherche, pouah. Parfois, le défilement revient même en arrière, en direction du présent et il faut bourriner du clic sur le résultat de recherche pour arriver jusqu'à l'extrait de convers 🙁️.
  
  
• On peut exporter ou supprimer l'historique pour un seul contact ;
  
  
• Dans un historique exporté, il y a bien la date pour chaque message, même quand ils sont proches et qu'ils ont été groupés dans Gajim.

En revanche, dans l'interface Gajim, le copier-coller se fait toujours à la granularité d'un message 😑️.

Avant de rétablir l'icône de notification (supra), j'ai envisagé, à nouveau, de migrer vers un autre logiciel. Mais le seul autre logiciel livré dans Debian qui ne fasse que du Jabber, dino, refuse d'accepter les certificats x509 autosignés…

GnuPG

The upstream GnuPG project now explicitly and deliberately diverges from the OpenPGP standard. Debian's own workflows rely heavily on OpenPGP, and we ship several different OpenPGP implementations, so interoperability via standardization is a priority for the project.

While Debian still has significant dependencies on GnuPG, the version of GnuPG shipped in Debian will default to emitting only OpenPGP-compatible artifacts if at all possible. As of 2.4.7-4, the default is --compliance=openpgp, and we apply several patches to ensure that this mode is respected.

Rien de neuf, le chasme se confirme.

GnuPG et Yubikey

GnuPG 2.4 will not automatically fallback to the PC/SC driver for smartcard access if direct access fails. Users using pcscd for hardware access will need to explicitly disable the gnupg CCID driver. See --disable-ccid in scdaemon.1 and #1102717

Cela se confirme en pratique. GPG ne voyait plus ma Yubikey (présentation de mon installation et tutoriel ici).

$ gpg --card-status
gpg: selecting card failed: Aucun périphérique de ce type
gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type

En VO :

$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

Solution :

$ echo disable-ccid > ~/.gnupg/scdaemon.conf
$ pkill gpg-agent

(Pour le pkill : source.)

GnuTLS

Cette bibliothèque de fonctions n'est plus utilisée par apt, ni par openldap. Dommage, ça faisait de la diversité à openssl 🙁️.

hash-slinger

Ce paquet fournit les scripts tlsa, sshfp et openpgpkey.

Comme les scripts que j'avais mis dans /usr/local/bin, la version empaquetée est toujours la "vieille" 3.1. Elle affiche des avertissements python, ce qui est pénible quand on bosse sur ces sujets.

À partir de la version 3.5, ces logiciels utilisent les bibiothèques Python cryptography + ssl au lieu de M2Crypto (source). Or, elles rejettent les certificats x509 autosignés (alors que DANE TLSA permet de s'émanciper des autorités de certification…).

J'ai donc mis la version 3.4 de mi-2025 dans /usr/local/bin/.

hermetic-usr pattern

Je constate que de plus en plus de programmes suivent la bonne pratique « hermetic-user », c'est-à-dire qu'ils rangent leurs fichiers de conf par défaut dans /usr et permettent leur surcharge dans /etc, sous le même nom. Si ça peut éviter des comparaisons fastidieuses de fichiers de config lors des mises à jour majeures et/ou le recours à dpkg-divert, pourquoi pas 🙂️.

En l'espèce : NetworkManager (pour ses scripts dispatcher) ou iproute2 ou sysctl (même si cela est plutôt dû au passage à systemd-sysctl).

iproute2

La coloration des noms d'interfaces, des adresses (IPv4, IPv6, MAC), et de l'état physique (up/down) améliore grandement la lisibilité de la sortie des commandes ip […] \o/.

Cela m'a permit de réaliser que, dans ip l, « state UP » est l'état physique de l'interface réseau (câble branché, Wi-Fi actif, etc.), qu'il n'y a plus besoin de logiciel additionnel comme ethtool pour le constater, et que l'état logique figure entre « < » et « > » 😄️.

last, lastlog, wtmp

La doc expose qu'en prévision du bug de l'an 2038, les commandes last et lastlog ne sont plus fournies.

Conséquence : les commandes w et who n'affichent plus les utilisateurs connectés, excepté root. Je m'en sers sans cesse pour vérifier si je suis connecté en IPv4 ou IPv6, si je n'ai pas laissé traîner des sessions, et pour vérifier viteuf s'il n'y a pas d'intrus.

lslogins -uo USER,LAST-HOSTNAME affiche uniquement la dernière connexion d'un utilisateur, pas l'ensemble de ses connexions actives.

lastlog2 -a : idem. Et si l'on a une connexion SSH en IPv6 et l'autre en IPv4, que l'on clôture proprement celle en IPv6, alors c'est l'IPv6 qui lui est associée (ce qui est faux, on est désormais en IPv4). De plus, ça affiche « Last login: » après chaque « su - », ce qui est pénible.

wtmpdb last -p now fait le job. \o/ Dans mon ~/.bashrc, j'ai ajouté alias w="w ; wtmpdb last -p now guigui root".

J'ai eu quelques connexions rémanentes (« still logged in ») après des redémarrages du système ou des connexions SSH interrompues. J'ai attendu plusieurs jours : il ne semble pas y avoir de purge automatique. On peut nettoyer ça à la main : echo 'delete from wtmp where User = "guigui" and Logout is null and Login < <timestamp_sur_16_chiffres> ;' | sqlite3 /var/log/wtmp.db. (Pour rappel, pour obtenir un timestamp sur 10 chiffres à partir d'une date : date -d 'YYYY-MM-JJ HH:MM' +%s. Ajouter six « 0 » pour obtenir un timestamp 16.)

J'apprécie de lire « Last login: » lors d'une connexion SSH. PrintLastLog yes dans /etc/ssh/sshd_config.

Pour que ça continue, il ne faut pas supprimer /var/log/lastlog, contrairement à ce qu'expose la doc' sus-pointée.

On peut effacer /var/log/btmp* et /etc/logrotate.d/btmp.

Par défaut /etc/logrotate.d/wtmpdb conserve /var/log/wtmp.db pendant 4 ans ! Je trouve ça excessif, j'ai passé ça à 4 semaines, conformément à ma politique de journalisation :

# sed -i 's/yearly/weekly/' /etc/logrotate.d/wtmpdb
# dpkg-divert --add --no-rename --divert /etc/logrotate.d/wtmpdb.dpkg-dist /etc/logrotate.d/wtmpdb

mesg et write

The mesg(1) and write(1) programs are no longer provided. It is believed chatting between users is nowadays done using more secure facilities.

Même si je les ai très peu utilisés il y a un bail, ça fait quand même quelque chose, le temps que les moins de vingt ans, tout ça 💔️.

nftables

La syntaxe « meter » est dépréciée, mais nft continue de la traduire en limitation de débit utilisant des ensembles d'adresses IP (= des sets).

Ainsi, la règle « tcp dport 443 ct state new meter RL-HTTP-v6 { ip6 saddr and ffff:ffff:ffff:ffff:0000:0000:0000:0000 limit rate over 15/second } counter drop »
est traduite tcp dport 443 ct state new add @RL-HTTP-v6 { ip6 saddr and ffff:ffff:ffff:ffff:0000:0000:0000:0000 limit rate over 15/second burst 5 packets } counter drop.

Je précise que « burst » a toujours été implicitement défini à 5 par défaut. Le set « RL-HTTP-v6 » est créé automatiquement.

La présence d'une IP ou d'un réseau dans un tel set ne signifie pas qu'elle fait l'objet de la restriction de débit, simplement qu'elle a initié au moins une communication.

Ce qui m'ennuie, puisque toute IP qui a envoyé au moins un paquet restera dans le set possiblement indéfiniment (sauf redémarrage du système ou du pare-feu ou atteinte du nombre maximal d'éléments dans un set, ou…).

Pour y remédier, on peut :

• Recourir à une limitation de débit qui n'utilise pas les sets : tcp dport 443 ct state new limit rate over 15/second counter drop. Cela n'est pas possible si l'on veut limiter des réseaux au lieu d'adresses éparses.
  
  
• Créer soi-même l'ensemble en précisant la durée de vie des éléments avec la directive timeout. Le décompte commence dès l'ajout. La réception de futurs paquets tant que la durée de vie n'est pas écoulée ne la prolonge pas.

nginx

D'une part :

the "listen ... http2" directive is deprecated, use the "http2" directive instead

D'autre part, nginx met en œuvre http/3 \o/.

Tout est dans la doc : générale, module.

En gros, dans le bloc server de mon site web, j'ai ajouté :

• listen [::]:443 default_server ipv6only=off quic reuseport; ;
  
  
• quic_retry on;. Pour éviter les attaques par réflexion+amplification ;
  
  
• ssl_early_data off;. Pour désactiver le mode O-RTT qui ne m'inspire pas confiance. Cloudflare le désactive aussi (source : expérimentation).

J'ai testé avec curl --http3-only. On peut aussi tester avec openssl s_client -quic -alpn h3 -connect <hostname>:443.

Pour que ça fonctionne avec un navigateur web, il faut ajouter un enregistrement DNS de type « HTTPS ». Contenu minimal : 1 . alpn="h2,h3" (« h2 » car mon nginx met également en œuvre HTTP/2). (Un CNAME est autorisé.) Ça devrait aussi fonctionner avec un entête HTTP « Alt-Svc », mais je n'ai pas essayé.

Si tu utilises un certificat x509 autosigné, il faut configurer Firefox : network.http.http3.disable_when_third_party_roots_found => false. Il faut redémarrer Firefox.

Firefox ne cherchera pas toujours l'enregistrement DNS HTTPS. Je pense qu'il garde cela dans les « données de site ». À chaque fois que j'ai effacé ces données, Firefox a demandé l'enregistrement DNS HTTPS et a fait des requêtes HTTP/3.

nicinfo

Client RDAP. Toujours pas disponible dans les dépôts officiels de Debian.

Erreur : « bash: /usr/local/bin/nicinfo : ne peut exécuter : le fichier requis n'a pas été trouvé ».

Même solution que la dernière fois.

OpenDNSSEC

Mon serveur met plus de 1 m 30 pour s'éteindre. Ça sent la tâche coincée et le délai d'attente par défaut de systemd-system.

journalctl -xn 5000 crache le morceau :

systemd[1]: opendnssec-enforcer.service: State 'stop-sigterm' timed out. Killing.
systemd[1]: opendnssec-enforcer.service: Killing process 567 (ods-enforcerd) with signal SIGKILL.
systemd[1]: opendnssec-enforcer.service: Main process exited, code=killed, status=9/KILL
systemd[1]: opendnssec-enforcer.service: Failed with result 'timeout'.

journalctl -u opendnssec-enforcer :

systemd[1]: Stopping opendnssec-enforcer.service - OpenDNSSEC Enforcer daemon...
░░ Subject: L'unité (unit) opendnssec-enforcer.service a commencé à s'arrêter
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ L'unité (unit) opendnssec-enforcer.service a commencé à s'arrêter.
ods-enforcerd[567]: free(): invalid pointer
ods-enforcerd[567]: Aborted:
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: gsignal
ods-enforcerd[567]: abort
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: __libc_free
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: Aborted
ods-enforcerd[567]: :
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: gsignal
ods-enforcerd[567]: abort
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: __libc_free
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown

Outcha, un logiciel qui termine en segfault ou en sigabrt (arrêt anormal), c'est mauvais signe.

Mais OpenDNSSEC n'est plus fourni par Debian, il n'est plus maintenu, et son remplaçant n'est pas encore prêt.

Donc il faut faire avec :

# mkdir /etc/systemd/system/opendnssec-{enforcer,signer}.service.d/

# tee /etc/systemd/system/opendnssec-{enforcer,signer}.service.d/override.conf << EOF
[Service]
TimeoutStopSec=5s
EOF

# systemctl daemon-reload

OpenRDAP

Le client RDAP OpenRDAP est enfin empaqueté dans Debian.

Il était temps puisque certains opérateurs de registre de noms de domaine ne mettent plus en œuvre l'ancien protocol whois, comme celui de .info.

OpenVPN

Le client OpenVPN 3 est désormais livré par Debian.

Il utilise la même architecture et la même bibliothèque de fonctions que les clients OpenVPN Connect ou OpenVPN for Android, ce qui peut être pratique pour homogénéiser un parc.

N'étant toujours pas une interface graphique, il ne permet pas d'émanciper les utilisateurs non-informaticiens d'un gestionnaire de réseau comme NetworkManager, ce qui est dommage vu les dysfonctionnements qu'ils peuvent induire (route par défaut IPv6 alors que la conf OpenVPN ne la prévoit pas, réseau qui bagotte = déco/reco intégrale, etc.).

Je ne l'ai pas essayé.

OpenSSH

sshd(8): this release disables finite field (a.k.a modp) Diffie-Hellman key exchange in sshd by default. Specifically, this removes the "diffie-hellman-group" and "diffie-hellman-group-exchange-" methods from the default KEXAlgorithms list. The client is unchanged and continues to support these methods by default.

Uhu l'échange de clés DHE qui se fait sortir. Donc, par défaut, il ne reste plus que les algos post-quantiques ML-KEM (ex. Kyber) et sntrup761, ainsi que les algos basés sur les courbes elliptiques curve25519 et ECDH 😮️.

sshd(8): the server will now block client addresses that repeatedly fail authentication, repeatedly connect without ever completing authentication or that crash the server. Operators of servers that accept connections from many users, or servers that accept connections from addresses behind NAT or proxies may need to consider these settings.

Plus besoin de fail2ban devant sshd ? Lire aussi. Via Johndescs.

sshd(8): several log messages have changed. In particular, some log messages will be tagged with as originating from a process named "sshd-session" rather than "sshd".

Ce changement a été pris en compte dans le filtre dédié du paquet fail2ban.

Paquets

Paquets qui n'existent plus, qui ont changé de nom, etc., en sus de ceux présentés séparément dans le reste de cet article.

• dnsutils (clients DNS, dig, etc.) => bind9-dnsutils ; bind9utils (outils pour administrer un serveur DNS BIND, rncd, etc.) => bind9-utils ;
  
  
• dstat => pcp, mais on passe d'un simple binaire à des démons qui tournent en permanence ;
  
  
• mitmproxy n'est plus présent dans les dépôts officiels Debian stable (mais il est dans testing, donc il devrait revenir) ;
  
  
• p7zip / p7zip-full => 7zip ;
  
  
• vino / vinagre ne sont plus fournis (mais ils le sont dans unstable, donc ils devraient revenir).

pipx

Il a désormais l'option --global qui permet de rendre disponible sans effort un logiciel Python à tous les utilisateurs. \o/

Exemple : python upgrade --global yt-dlp.

Postfix

postfix[1501]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: support for parameter "smtpd_tls_dh1024_param_file" will be removed; instead, do not specify (leave at default)
postfix[1515]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: support for parameter "smtpd_tls_eecdh_grade" will be removed; instead, do not specify (leave at default)

Concernant « smtpd_tls_dh1024_param_file », la doc expose :

With Postfix ≥ 3.7, built with OpenSSL version is 3.0.0 or later, if the parameter value is either empty or "auto", then the DH parameter selection is delegated to the OpenSSL library, which selects appropriate parameters based on the TLS handshake. This choice is likely to be the most interoperable with SMTP clients using various TLS libraries, and custom local parameters are no longer recommended when using Postfix ≥ 3.7 built against OpenSSL 3.0.0.

Concernant « smtpd_tls_eecdh_grade », la doc consigne :

As of Postfix 3.6, the value of this parameter is always ignored, and Postfix behaves as though the auto value (described below) was chosen.
This feature is not used as of Postfix 3.6. Do not specify.

Donc j'ai supprimé ces deux directives.

La valeur de compatibility_level passe à 3.9.

saslauthd

Je l'utilise pour l'authentification submission de Postfix.

Lors de l'envoi d'un courriel :

postfix/smtpd[1496]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
postfix/smtpd[1496]: warning: SASL authentication failure: Password verification failed

journalctl -u saslauthd -xn 20 crache le morceau :

systemd[1]: /usr/lib/systemd/system/saslauthd.service:8: PIDFile= references a path below legacy directory /var/run/, updating /var/run/saslauthd/saslauthd.pid → /run/saslauthd/saslauthd.pid; please update the unit file accordingly.
systemd[1]: saslauthd.service: Can't open PID file '/run/saslauthd/saslauthd.pid' (yet?) after start: No such file or directory
systemd[1]: saslauthd.service: start operation timed out. Terminating.
systemd[1]: saslauthd.service: Failed with result 'timeout'.
systemd[1]: Failed to start saslauthd.service - SASL Authentication Daemon.

À partir de Debian 13, saslauthd est lancé par une unit systemd (/usr/lib/systemd/system/saslauthd.service). Elle reprend les paramètres de /etc/default/saslauthd, dont un chemin différent où créer sa socket, écrire son numéro de processus, etc., si, comme moi, tu chroot ton postfix (ce qui est la config par défaut de Debian). Source d'inspiration.

Or, l'unit systemd cherche le numéro de processus hors du chroot postfix. Ne le trouvant pas, systemd-system considère que salsauthd n'a pas démarré correctement et le tue.

Solution :

# mkdir /etc/systemd/system/saslauthd.service.d/

# cat > /etc/systemd/system/saslauthd.service.d/override.conf << EOF
[Service]
PIDFile=/var/spool/postfix/var/run/saslauthd/saslauthd.pid
EOF

# systemctl daemon-reload
# systemctl restart saslauthd.service
# systemctl enable saslauthd.service

Ce problème m'a contraint à lire le manuel. J'y ai découvert :

saslauthd should be started from the system boot scripts when going to multi-user mode. When running against a protected authentication database (e.g. the shadow mechanism), it must be run as the superuser. Otherwise it is recommended to run daemon unprivileged as saslauth:saslauth […]

Or, nous avons vu avec Dovecot qu'il suffit de faire partie du groupe « shadow » pour être en capacité de lire /etc/shadow. On peut donc exécuter saslauthd avec un utilisateur dédié au lieu de root \o/ :

# adduser --system saslauth
# usermod -aG sasl saslauth

# chown saslauth /var/spool/postfix/var/run/saslauthd

# cat >> /etc/systemd/system/saslauthd.service.d/override.conf << EOF
User=saslauth
Group=shadow
EOF

# systemctl daemon-reload
# systemctl restart saslauthd.service

systemd-sysctl

Il ne lit plus /etc/sysctl.conf, qui a été déplacé en /usr/lib/sysctl.d/50-default.conf.

Les fichiers dans /etc/sysctl.d sont toujours pris en compte.

systemd-tmpfiles

/tmp est désormais stocké en RAM (= tmpfs) par défaut. (Je pensais que ça avait déjà été fait depuis longtemps 😮️.) C'est systemd-mount qui s'en occupe.

Le contenu de /tmp et de /var/tmp est régulièrement nettoyé automatiquement par systemd-tmpfiles. Pour /tmp, les fichiers plus vieux que 10 jours sont supprimés, 30 jours pour /var/tmp.

La doc de systemd-tmpfiles consigne que toutes les dates d'un fichier sont prises en compte dans la comparaison : mtime (dernière modification), atime (dernier accès), et ctime (modification des métadonnées). (La date de création aussi, mais elle n'est pas usuelle sur un système Gnu/Linux.)

Le processus de mise à jour depuis Debian 12 crée un fichier /etc/tmpfiles.d/tmp.conf qui empêche le nettoyage de /tmp.

Sur mes serveurs, seul nsd conserve des éléments relatifs aux transferts de zone dans /tmp. Un des fichiers est créé au démarrage et n'est plus actualisé ensuite. Donc systemd-tmpfiles pourrait l'écraser à tort. Donc je conserve /etc/tmpfiles.d/tmp.conf. Par cohérence, j'en fais de même sur mes autres serveurs.

Sur mon poste de travail, je suis dubitatif qu'une purge de /tmp n'engendre aucun problème, donc je conserve également /etc/tmpfiles.d/tmp.conf.

tldr

tldr est un client codé en Haskell pour récupérer des pages « too long; didn’t read » qui résument, par des exemples concrets, le manuel de tout un tas de programmes.

Il n'est plus livré par Debian, même dans testing et unstable, donc il ne reviendra probablement pas.

tldr-hs (hs = Haskell = probable continuité) est fourni uniquement dans unstable.

tealdeer (en rust, a priori) est empaqueté mais il reste bloqué sur :

Error: Could not update cache

Caused by:
0: Could not decompress downloaded ZIP archive
1: invalid Zip archive: Could not find EOCD

tldr-py est disponible dans les dépôts officiels Debian, mais il est tout autant cassé :

$ git clone https://github.com/tldr-pages/tldr.git ~/.tldr

$ tldr init
Input the tldr repo path(absolute path): /home/guigui/.tldr
Input your platform(linux, osx or sunos): linux
Initializing the config file at /home/guigui/.tldrrc

$ tldr update
Check for updates...
fatal : argument 'master' ambigu : révision inconnue ou chemin inexistant. [en VO : « fatal: ambiguous argument 'master': unknown revision or path not in the working tree. »]
Utilisez '--' pour séparer les chemins des révisions, comme ceci :
'git <commande> [<révision>...] -- [<chemin>...]'
Traceback (most recent call last):
[…]

De plus, la syntaxe change : tldr ls => tldr find ls. Flemme…

Et, de toute façon, le logiciel plante lorsqu'on consulte une fiche : FileNotFoundError: [Errno 2] No such file or directory: '/home/guigui/.tldr/pages/index.json. Le dossier « pages » est désormais sous-divisé par système…

Au final, j'ai suivi les instructions du site web officiel qui figure dans la description du paquet Debian tldr que j'utilisais jusque-là :

# pipx install --global tldr
$ tldr -u

Il fonctionne au poil et sans changement de syntaxe.

#Debian 12 à Debian 13

nftables, et son interface nft, est le (pas si) nouveau pare-feu de Linux (remplaçant de Netfilter, dont l'interface était iptables).

J'ai déjà rapporté quelques syntaxes ici (à la fin) et là.

Factorisation

Désormais, on peut appliquer une même règle à UDP et à TCP. Exemple pour le DNS (qui fonctionne sur UDP et sur TCP) : meta l4proto { udp, tcp } th dport 53 accept. Exemple pour Torrent : meta l4proto { udp, tcp } th dport 6881-6891 accept. Avant, ce n'était possible que via une surcouche comme ufw.

Les sélecteurs meta permettent plein d'autres choses, j'vais y revenir infra.

Pour appliquer une même règle en IPv4 et en IPv6, il faut utiliser une table de type inet. Avant, cela se faisait uniquement avec une surcouche comme ufw. Pour appliquer une règle uniquement aux flux IPv6 ou IPv4 au sein d'une table inet, on peut utiliser meta protocol ip6 ou meta nfproto ipv6. Notons que nftables n'a pas besoin d'une telle précision pour une limitation du débit via un ensemble (sets) : la version d'IP sera déduite du type du set.

Comme quand ils étaient un sous-système dédié du noyau Linux, les ensembles (sets), nommés ou non, permettent d'appliquer une même règle à plusieurs interfaces réseau, adresses IP, ports, ou, nouveauté, à plusieurs types (ex. les types ICMP). (en sus des ipsets, iptables permettait de factoriser les ports avec son module multiport.)

Plus forts que les ensembles, il y a les dictionnaires (ou tableaux associatifs). Pratique pour du couplage géographique. Quand c'est poussé à l'extrême, notamment pour les règles de NAT, je trouve ça illisible.

Toujours aucun moyen de factoriser un même type ICMP et ICMPv6 (comme echo-request ‒ ping), ni IPv4 et IPv6 dès que l'on peut préciser une source ou une destination (même avec un nom de domaine, c'est soit l'un, soit l'autre). nft interprète à sa sauce certaines commandes, donc une abstraction qui ajouterait deux règles à partir d'une n'est pas inconcevable.

Chaînes et priorités

Avec Netfilter/iptables, le trafic arrive dans des chaînes prédéfinies et incontournables (ex. : chaîne INPUT de la table filter). On pouvait renvoyer le trafic dans des sous-chaînes personnelles via des règles recourant à la cible JUMP.

Désormais, il n'y a plus de chaînes prédéfinies. Exemple : la chaîne INPUT existe si tu la nommes ainsi.

On peut accrocher (hook) des chaînes à plusieurs endroits du traitement des paquets. Une priorité permet d'ordonner les chaînes. Un paquet traversera toutes les chaînes dans l'ordre des priorités jusqu'à rencontrer un accept final ou un drop.

J'insiste : un drop est définitif, le traitement d'un paquet s'arrête, le paquet n'ira pas dans les chaînes de priorités plus hautes. En revanche, un accept peut être remise en cause par une chaîne ultérieure. Source.

Cet enchaînement de chaînes est plus pratique et lisible pour la cohabitation entre logiciels qui tripotent le pare-feu. Exemples : cumul de règles personnelles et de règle libvirt ; cumul avec fail2ban.

Capturer par programme

On peut capturer des flux réseau par propriétaire ou par groupe d'une socket d'émission : skuid, skgid.

Très pratique pour filtrer les flux sortants quand la destination n'est pas connue (ex. : flux sortants d'un serveur emails ou d'un récursif DNS, mises à jour du système, etc.). Ça autorise de ne pas permettre un flux sortant à destination de tel port (ou autre) à tous les logiciels (une application compromise reste donc confinée aux ports qu'on lui a autorisé).

iptables permettait ça avec son module owner. (Il pouvait même filtrer par nom du programme, mais uniquement sur un système non-SMP.)

La nouveauté par rapport à il y a 15-20 ans, c'est qu'un plus grand nombre de logiciels s'exécutent avec un utilisateur dédié. Exemple : apt = utilisateur _apt.

Journalisation

Avec iptables, une règle pouvait avoir une unique cible. Il fallait donc une règle pour journaliser (log) et une règle pour agir. nftables permet de cumuler counter, log et une action (comme drop). \o/

La cible log permet toujours d'ajouter un préfixe (log prefix "TEST", par ex.) afin de distinguer, dans le journal, la provenance d'une trace (= quelle règle l'a journalisé).

Plusieurs caractéristiques d'un paquet ne sont pas journalisées par défaut, comme le proprio de la socket. Il est possible d'activer ceci : log flags skuid.

Pour debug, on peut aussi utiliser nft monitor dont j'ai parlé ici.

Limitation du nombre de connexions

Par défaut, la limitation de débit s'applique par nombre de paquets ou par débit (quantité transférée par intervalle de temps).

Pour limiter le nombre de connexions (pour une IP ou un réseau ou…), il suffit de l'appliquer aux seuls paquets d'initialisation d'une connexion TCP (drapeau SYN), voir ci-dessous, ou d'utiliser le suivi des connexions (ce qui est déconseillé en cas d'attaque par déni de service).

Avant : icmp type echo-request limit rate 10/minute accept.
Après : ct state new icmp type echo-request limit rate 10/minute accept.

Dans le premier cas, une même commande ping n'obtiendra plus de réponse après environ 10 secs. Dans le deuxième cas, si.

(Je rappelle qu'une même connexion réseau peut acheminer plusieurs requêtes applicatives. Ex. : dès HTTP/1.1, un client peut demander plusieurs ressources web dans une même connexion TCP, c'est le pipelining HTTP. Dès lors, une limite en nombre de connexions réseau peut impliquer un plus grand nombre de requêtes applicatives.)

Drapeaux TCP

Pour appliquer une règle en fonction des flags TCP, la syntaxe a un peu évolué par rapport à iptables.

Synproxy

Pour contrer les attaques SYN flood.

Quotas

Pour agir au-delà d'une certaine quantité cumulée de données (pas d'un débit, ça, c'est de la limitation de débit, dont j'ai déjà cause ici).

Tester

La vérification de la syntaxe d'un fichier de règles s'effectue au chargement de celui-ci (nft -f). nft ne propose aucune option pour vérifier sans charger.

De même, il vaut mieux recharger (systemctl reload nftables) que redémarrer le pare-feu (restart), car restart implique stop qui implique nft flush ruleset qui purge les règles en cours d'application. Si la syntaxe de la configuration est incorrecte, pouf, plus de pare-feu. Un « flush ruleset » dans le fichier de règles ne sera exécuté que si la syntaxe de l'ensemble du fichier est OK, donc aucune absence du pare-feu.

Utiliser des noms de domaine ?

Quand on gère les flux de son infrastructure, on est tenté de filtrer les flux vers des destinations tierces qu'on ne maîtrise pas en utilisant des noms de domaine (ex. : ip daddr toto.example accept).

Sauf qu'au redémarrage, on se retrouvera sans pare-feu : « Error: Could not resolve hostname: Temporary failure in name resolution ».

Hé oui, on charge toujours un pare-feu avant le réseau, précisément pour protéger la machine dès le début. Pour confirmer cela : systemctl list-dependencies nftables. Charger les règles après le réseau est une mauvaise idée.

Déporter le chargement des règles contrôlant les flux sortants est compliqué (en sus d'être une mauvaise idée pour la raison que je viens de rappeler). Il faudrait faire un jeu de règle séparé, avec une unit systemd séparée pour le charger, ce qui rend propice aux erreurs et oublis le chargement intégral du pare-feu (je rappelle que iptables -D n'a pas d'équivalent, pour supprimer une règle, il faut récupérer son handle).

Utiliser des noms, c'est faire dépendre d'autrui son pare-feu, ce qui est une giga mauvaise idée. Si la destination ajoute une deuxième IP à son nom, vlam, le pare-feu ne démarrera plus (« Error: Hostname resolves to multiple addresses »). Si elle se met à pratiquer l'équilibrage de charge avec un TTL court, vlam, la règle de pare-feu laissera passer que par intermittence.

Je préconise de tout faire pour filtrer sur d'autres critères (skuid, etc.), quitte à ce que ça soit moins précis (autoriser tout un port, au lieu de destination + port).

Si un filtrage à partir d'un nom de domaine est absolument nécessaire, le moins pire est d'utiliser des sets avec un script pour les remplir. Ce script, qui sera déclenché quand le réseau sera activé, devra prendre en compte les différentes possibilités : plusieurs adresses IP, CNAME, absence de réponse, erreur de résolution, etc. Mais, au moins, un défaut n'entraînera pas le pare-feu dans sa chute.

La propension des services publics à ne pas traiter, ou mal, ou pas à temps, les dossiers dont ils sont saisis tout en prenant le chou à ceux qui ne leur ont rien demandé est consternante. Toujours une merde à gérer, même quand tu demandes rien… 😡️

Courriel sorti de nulle part de l'Assurance maladie (AM) « Un document important est disponible dans votre compte ameli ». Ha… Couillonnade en perspective.

Sujet : « ACCOMPAGNEMENT À LA RECHERCHE D’UN MÉDECIN TRAITANT ». ÉCRIRE TOUT EN MAJUSCULE, C'EST LA VIE 😑️.

Nous faisons suite à nos précédents contacts au sujet de notre accompagnement pour la recherche d’un médecin traitant.

La mobilisation de l’ensemble des acteurs nous permet de vous proposer le nom d’un médecin qui accepte de vous recevoir pour une première consultation. Ce professionnel de santé pourra ensuite vous intégrer dans sa patientèle.

[…]

N’ayant pas réussi à vous joindre pour recueillir directement votre consentement sur cette proposition, nous allons réaliser pour vous la déclaration de choix de médecin traitant auprès de ce médecin dans un délai d’un mois.

Si toutefois, vous ne souhaitez pas que nous procédions à cette déclaration pour vous ou que vous ne souhaitez pas être suivi par ce médecin, vous pouvez nous contacter

Et sinon, me foutre la paix, non ? 😑️

Ça fait des années que l'AM m'envoie deux courriels par an pour m'inviter à déclarer un médecin traitant.

Je n'ai jamais déclaré de médecin traitant, car ça n'a aucun intérêt. Être mieux remboursé = percevoir 2,78 € au lieu de 2,24 € sur une presta en dizaines d'euros, ou truc du genre. L-O-L 🤡️.

Ça fait des années que je ne présente pas ma carte vitale et que je n'envoie pas les feuilles de soin à l'AM. Même raison : être remboursé quelques euros sur des prestas en dizaines d'euros et de quelques centaines sur des prestas en milliers d'euros, merci mais non merci.

De manière générale, je suis dégoûté de ce système de santé avec ses bases de remboursement arbitraires, ses taux de remboursement différenciés, ses franchises, ses ceci, ses cela… Ce n'est pas le système collectif de soins auquel j'aspire.

Je décide de m'opposer à la déclaration d'un médecin traitant.

Mais, surprise (non), contrairement à ce qu'annonce le courriel, l'espace d'échanges sur Ameli ne comporte aucune option pour envoyer une prose 😡️.

Le bouton « J'ai une question » renvoie vers AmeliBot, qui, évidemment, me recrache le courriel, à savoir que je peux contacter l'AM via l'espace échanges blablabla. C'est l'progrès, y paraît !

De toute façon, un robot de causerie ne peut rien pour moi vu que j'attends une action de l'AM.

Bonus : le copier-coller est désactivé dans le bot, parce que pourquoi pas, quand on peut faire chier… 😑️ Pour rappel : dans Firefox, dom.event.clipboardevents.enabled => false, et zout.

Solution : il faut explicitement dire à AmeliBot que l'on veut écrire à l'AM. Il répond alors un lien vers un autre espace d'échange qui, lui, contient un bouton « Écrire un message ». Si ça intéresse, le lien en question, toujours utilisable des jours plus tard : https://assure.ameli.fr/PortailAS/appmanager/PortailAS/assure?_nfpb=true&_pageLabel=as_vos_questions_page.

Pense à faire une capture d'écran de l'envoi de ta prose car ton message n'apparaîtra pas dans « messages envoyés » tant qu'il ne sera pas pris en compte par l'AM (tu recevras un courriel de notification) 😑️.

J'ai bien écrit à l'AM que « Je m'oppose à tout accompagnement à la recherche d'un médecin traitant. Je n'ai pas besoin de vous. ».

Mon message a été pris en compte environ 1 h plus tard.

Quatre jours plus tard, transfert au service expert. Trolololo 🤡️.

Même jour, 2 h plus tard : message « Nous prenons bonne note […] ».

Encore trois jours plus tard, nouveau document disponible : « ERRATA ACCOMPAGNEMENT À LA RECHERCHE D’UN MÉDECIN TRAITANT ». « Nous vous prions de ne pas tenir compte du courrier reçu précédemment, relatif à l’accompagnement à la recherche d’un médecin traitant. »

On pari combien que l'AM va revenir me gonfler dans quelque temps ? 😏️

Bilan : environ 45 minutes perdues de mon côté pour lire les documents, causer à un robot merdique, rédiger une prose, et suivre le dossier. Alors que je n'ai rien demandé, hein.

Côté AM, 1 message de plus à traiter, 3 réponses, par 3 agents différents. Trololo 🤡️.

Et après, ça vient te dire que c'est débordé, que ça manque de thune, patati, patata 😑️. Les services publics ne manquent pas de temps, ni d'argent, mais, comme les sociétés commerciales, ils passent leur temps à faire n'importe quoi, surtout ce qui n'est pas demandé par les usagers 😡️.

Côté positif : au moins, l'AM informe et permet de s'opposer à la transmission de données à caractère personnel. Ce n'est pas le cas de tous les services publics, pas vrai, France Travail ?! 😉️

En tout cas, cela a attisé ma curiosité : qu'est-ce qui se cache derrière le concept de médecin traitant ? Si c'était uniquement un meilleur remboursement des soins, l'AM ne se donnerait pas autant de peine, n'enverrait pas deux courriels par an, ne désignerait pas d'office des docteurs. Le concept de médecin traitant doit forcément rapporter à l'AM. Il y a anguille sous roche. De même, j'aimerais bien savoir la contrainte exercée sur les médecins qui sont désignés. Si quelqu'un à des lectures à me conseiller, je prends.

A netfilter synproxy intercepts new TCP connections and handles the initial 3-way handshake using syncookies instead of conntrack to establish the connection. Running synproxy on a listening server port thus prevents a SYN flood attack on that port from consuming limited conntrack resources.

Ça évite également d'envoyer des messages TCP SYN ACK à répétition à un interlocuteur possiblement usurpé.

Les cookies TCP laissent passer une partie du trafic pourri (mais je n'ai pas affiné les paramètres noyau), Netfilter ne laisse rien passer.

Sur un système Debian GNU/Linux, les cookies et timestamps TCP sont activés par défaut.

Il ne reste plus qu'à activer le mode strict du suivi des connexions TCP au démarrage. (Par défaut, ce suivi est souple : les connexions existantes sont automatiquement ajoutées à la table des états. Donc un émetteur qui ne terminerait pas la poignée de main TCP pourrait quand même créer un état, pile ce qu'on veut éviter.) Il s'agit du paramètre noyau /proc/sys/net/netfilter/nf_conntrack_tcp_loose (0 = strict ; 1 = loose = souple).

Au démarrage, ce paramètre n'existe pas. Il est créé par un module noyau. Vu son nom, on devine que c'est le module nf_conntrack. On vérifie avec lsmod : quand on crée une règle avec une action synproxy en l'absence de toute autre règle, le module nft_synproxy est chargé et entraîne celui du module nf_conntrack (lsmod : « nf_conntrack 204800 3 nft_ct,nft_synproxy,nf_synproxy_core »).

Lors d'un démarrage, il nous faut donc charger un module noyau puis changer l'un des paramètres du noyau (pas du module, donc modprobe nf_conntrack nf_conntrack_tcp_loose=0 ne fonctionnera pas). Possible race condition, donc (si le paramétrage se déclenche avant le chargement du noyau, ça ne le fera pas). Heureusement, par défaut, systemd-sysctl est configuré pour démarrer après systemd-modules-load (pour vérifier : systemctl list-dependencies --after systemd-sysctl | grep modules-load).

Du coup, au travail :

echo 'nft_synproxy' > /etc/modules-load.d/nft_synproxy.conf
echo 'net.netfilter.nf_conntrack_tcp_loose = 0' > /etc/sysctl.d/98-synproxy.conf

Pour le reste, on suit le tutoriel du wiki officiel nftables pointé par ce shaarli.

Contrairement à ce qu'on peut lire sur le web, et comme l'expose le wiki nftables, il ne faut pas mettre le synproxy devant l'ensemble des ports TCP, mais uniquement devant les ports en écoute. Sinon, il sera impossible d'établir des connexions sortantes.

Comme l'expose succinctement le wiki nftables, l'action synproxy vaut acceptation de la connexion entrante si la poignée de main TCP est achevée. Il n'y a donc pas besoin d'une règle d'acceptation en sus. Si je reprends l'exemple du wiki nftables qui travaille sur les connexions au port 8888, il n'y a pas besoin, dans « input », d'une règle additionnelle de la forme « tcp dport 8888 accept ».

Si l'on veut être pointilleux, la règle prerouting « tcp dport 8888 tcp flags syn notrack » proposée par le wiki nftables est trop permissive : elle sera déclenchée par tous les messages TCP dont au moins le drapeau SYN est activé. Dit autrement : un message SYN FIN, par exemple, sera aussi accepté, alors qu'il est invalide, au sens de la norme TCP, pour initier une connexion TCP.

Pour ne déclencher que sur les paquets qui ont uniquement le drapeau SYN : « tcp dport 8888 tcp flags & (urg|ack|psh|rst|syn|fin) == (syn) notrack ».

Explications :

• Les drapeaux TCP existants sont publiés par l'IANA. On peut voir les constantes associées avec nft describe tcp flags. Notons que les constantes « ALL » et « NONE » d'iptables n'existent plus et que les autres s'écrivent désormais en minuscule ;
  
  
• La syntaxe est environ celle d'iptables : « DRAPEAUX_DANS_MSG ET LOGIQUE (MASQUE_BINAIRE) == (DRAPEAUX_RECHERCHÉS) ». Le masque est les drapeaux que l'on regarde (pour y chercher ce que l'on veut). Dans le masque et dans la liste des drapeaux recherchés, les drapeaux sont séparés par un OU LOGIQUE (au lieu d'une virgule à l'époque d'iptables). « flags » est comme une variable (que j'ai nommé « DRAPEAUX_DANS_MSG »), elle fait partie du calcul. Pour réviser le masquage binaire, c'est ici. Pour lire une autre explication et d'autres exemples, c'est là ;
  
  
• Ici, on cherche SYN dans un ensemble de drapeaux. L'ensemble de drapeaux (= masque) vaut 00111111. (Les drapeaux sont des bits ordonnés, cf. le registre IANA supra, et je mets à 1 les 6 bits que je veux étudier. URG = 00100000, ACK = 00010000, etc., donc SYN | ACK | etc. = 00100000 | 00010000 | etc. = 00111111.) Le seul drapeau que l'on veut, c'est SYN, soit 00000010. Si un message SYN arrive, ses « flags » valent 00000010. Le résultat du ET LOGIQUE entre le message et le masque vaut 00000010, ce qui correspond à ce que l'on cherche (SYN = 00000010), donc la règle sera déclenchée. Si un message SYN FIN arrive, flags vaudra 00000011. Le résultat du ET LOGIQUE sera 00000011, ce qui n'est pas égal à SYN (00000010), donc la règle ne sera pas déclenchée ;
  
  
• Si je reprends la règle proposée par le wiki nftables, « tcp dport 8888 tcp flags syn notrack », cette fois-ci le masque vaut 00000010, car on regarde uniquement SYN. Si un message SYN FIN se présente, le résultat du ET LOGIQUE sera 00000010, ce qui correspond à SYN, donc la règle sera déclenchée, d'où sa permissivité. La règle détecte le SYN mais ne voit pas le FIN, puisque, à travers le masque choisi, elle ne l'étudie pas ;
  
  
• Les plus attentifs auront remarqué que, dans la règle que je propose, je travaille sur 6 drapeaux, donc 6 bits, alors que, dans mes exemples de masques, je travaille sur 8 bits donc 8 drapeaux. Actuellement, 8 drapeaux sont normalisés (un 9^e est en projet), dont 2 servent à la gestion de la congestion d'un réseau. La norme en cette matière dit qu'ils sont cumulables avec le drapeau SYN. Donc je ne les regarde pas, afin de les autoriser, d'où les 2 premiers bits à 0 et leur absence de la règle nft.

Si l'on filtre aussi les connexions sortantes (dans « output »), la règle usuelle, « ct state established,related counter accept », ne laissera pas passer le message SYN ACK de la poignée de main, donc les connexions entrantes ne seront pas établies.

Il faut ajouter une règle supplémentaire. Pour l'exemple du wiki nftables, qui ouvre le port TCP 8888, cette règle est : tcp sport 8888 ct state invalid,untracked tcp flags & (fin|syn|rst|psh|ack|urg) == (syn|ack) accept. Le ct state invalid,untracked est superfétatoire puisque les connexions suivies et relatives auront été capturées en amont par la règle usuelle, donc, forcément, il ne reste que les connexions invalides ou non-suivies.

Pour mettre à jour mon smartphone sous GrapheneOS et ses logiciels, j'émets un point d'accès Wi-Fi ponctuel avec hostapd sous GNU/Linux.

J'me dis que ça serait sympa d'avoir IPv6 sur ce point d'accès.

Android ne met pas en œuvre DHCPv6 (source).

Le logiciel clé pour faire de la l'autoconfiguration IPv6 sur GNU/Linux est radvd. Je l'ai déjà utilisé ici.

Points d'attention :

• radvd émet des messages ICMPv6 Router Advertisement (RA) uniquement si : l'interface réseau est up, son état est up (= câble branché ou hostapd lancé), et qu'aucun gestionnaire de réseau (comme NM) n'a la main dessus ;
  
  

• radvd ne prévient pas quand sa configuration est incorrecte (hors syntaxe), il se contente de ne rien faire 😑️. Si aucun RA n'est émis au démarrage, aucun ne le sera par la suite, quelle que soit la valeur des paramètres (Min|Max)RtrAdvInterval. Au démarrage, radvd émet une salve plus rapide que MaxRtrAdvInterval ;

• Il faut forcément préciser MaxRtrAdvInterval.

  • Il ne peut pas être supérieur à 300 secondes. (Le manuel dit que la valeur par défaut est 600 secondes, mais tu pourras attendre autant que tu veux au-delà de 10 minutes, tu ne verras aucun RA) ;
    
    
  • Pour descendre en-dessous de 10 secs, il faut également préciser MinRtrAdvInterval ;
    
    
  • Min et Max doivent être compatibles. Le plus petit couple possible est Min = 3 + Max = 5 ;
    
    
  • Pour descendre en-deça, il faut activer les extensions Mobile IPv6 (sans les utiliser). Exemple : AdvHomeAgentFlag on;.

• radvd émet plusieurs RA espacés quand il reçoit un message Router Solicitation (RS). Mais Android (recherche mises à jour, NTP, etc.) et les applis commencent à échanger avec l'extérieur, en IPv4, bien avant l'émission du RS. Donc s'il on veut maximiser les échanges au-dessus d'IPv6, on peut configurer radvd pour émettre un RA toutes les quelques secondes ;

• Un RA contient la durée de vie d'un routeur qui permet de préciser l'utilité de son émetteur en tant que routeur par défaut des préfixes IPv6 annoncés. Android >= 15 refuse une durée inférieure à 180 secs (source), donc il faut forcément préciser AdvDefaultLifetime >= 180 si tu tripotes un peu trop MaxRtrAdvInterval (car AdvDefaultLifetime vaut 3 * AdvDefaultLifetime) ;

  • Si la durée de vie est inférieure à 180 secs, Android assignera les IPv6 (standard et privée) à l'interface Wi-Fi du smartphone et les affichera dans les détails de la connexion Wi-Fi, mais aucune route par défaut ne sera insérée (on voit cela avec adb shell ip -6 route show table all ‒ abrégé ip -6 r s t all), donc : adb shell ping6 shaarli.guiguishow.info sortira en erreur « connect: Network is unreachable ».
• Android ne fonctionne pas sur un réseau uniquement IPv6 et dénué de tout mécanisme de transition puisque il ne permet pas de saisir une adresse IPv6 comme serveur DNS récursif ;
  
  
• La messagerie Signal fonctionne sur un réseau purement IPv6 😮️ ;
  
  
• Mes applis qui accèdent à Internet (màj GrapheneOS, assistance GPS GrapheneOS, magasin d'applis GrapheneOS, magasin d'applis sous licence libre F-Droid, le GPS avec cartes hors-ligne OSMAnd~, et la messagerie Signal ‒ grâce à son recours à AWS) le font en IPv6. 😎️

Ma configuration radvd :

interface wlp61s0
{
    AdvSendAdvert on;

    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 5;

    AdvDefaultLifetime 300;

    prefix 3fff:0042::/64
    {
    };

    RDNSS 2001:910:800::40
    {
    };

    RDNSS 2a00:5881:8100:1000::3
    {
    };
};

(Le réseau 3fff:0::/20 est réservé pour la documentation. RDNSS permet de préciser les serveurs DNS récursifs, ici de FDN et d'ARN.)

Nouvelle version du correcteur grammatical sous licence libre Grammalecte 😮️, et reprise par Algoo. À suivre.

Via https://sebsauvage.net/links/?Idep_w.

Expédition scientifique 18 mois dans un bateau arrondi, la Tara Polar Station, pris dans la glace mouvante (en dérive) de l'Arctique.

Le chien qui signale les ours.

Le puits central (moonpool) pour accéder à l'eau. Un ours s'est déjà introduit dans un puits similaire de 7 mètres de profondeur. 😀️

Arctique (Nord) = eau + banquise ; Antarctique (Sud) = continent + glaciers.

#Amixem

apt list '~i ?section(contrib)'

apt list '~i ?section(non-free)'

+ Bannières cookies : la CNIL met en demeure AliExpress, Darty, Ouest-France, OVHcloud, SFR…

+ Bannière de cookies : l'association Purr à l'offensive

+ CNIL : des mises en demeure visant notamment RED by SFR ou OVH pour leurs bannières cookies obtenues par l’Association PURR

+ Red by SFR dans le viseur de la CNIL pour ses pratiques en matière de cookies

Cette semaine, la CNIL a achevé le traitement de quinze de « nos » plaintes. (Les autres sont toujours pendantes.)

En résumé : la CNIL a rappelé leurs obligations à ces éditeurs et les a mis en demeure de se mettre en conformité sous deux mois.

[…]

Sur instruction de ses mandants, l’association veillera à ce que les éditeurs épinglés se mettent en conformité dans le délai prescrit par la CNIL.

Elle veillera également à ce que la CNIL adopte des mesures correctrices en matière de cookies déposés sans consentement, de difficulté de retrait du consentement, d’absence de caractère éclairé du consentement, de bandeaux cookies trompeurs, d’absence de prise en compte des signaux visant à réduire la fatigue du consentement, etc.

[…]

Notre association rappelle que les cookies ne sont pas son unique sujet d’intérêt. Pour le compte de ses mandants, elle intervient aussi sur les fuites de données personnelles, sur les durées de conservations abusives, sur l’insuffisante sécurité des données, etc.

Au final, la CNIL a fait environ n'importe quoi, au lancé de dé, et le résultat est plutôt décevant. Tout cela est détaillé.

Via les listes de FDN.