Adrien Dorsaz a écrit 978 commentaires

Le pull request a bien été fusionné, mais il manque un peu d'explications. Les détails sont disponibles dans ce commentaire sur le rapport de problèmes qui relève que les clients de bitwarden ne respectaient plus la GPL.

En gros, ce qu'ils ont fait c'est séparer le répertoire du SDK en deux: une partie en licence GPLv3 pour les clients du gestionnaire de mot de passe de Bitwarden et une seconde partie en licence privatrice pour les clients du gestionnaire de secret de Bitwarden (Secret Manager).

Il semble que ce dernier produit n'a jamais été libre et qu'il est indépendant du produit Password Manager qui est libre.

Il ne manque plus qu'à publier des nouvelles versions des SDKs et des clients du Password Manager pour que ces derniers redeviennent correctement libre (le commentaire dit bien que les clients du password manager sont déjà indépendants du secret manager).

En Suisse, il y a la Qr Facture qui fait exactement ça : au fond de la facture tu mets toutes les informations pour le paiement et il y a un gros qr code au milieu avec les mêmes informations : https://www.six-group.com/fr/products-services/banking-services/payment-standardization/standards/qr-bill.html

Comme ça tu peux utiliser n'importe quel lecteur de qr code pour faire une saisie simplifiée des paiements dans ton ebanking, CRM…

Et si tu n'as pas de lecteur, smartphone, tout est encore lisible à la main comme avant.

Dans l'article, je présente comment signer automatiquement les fichiers initramfs avec le fichier 99-sbctl pour sécuriser le démarrage.
C'est le point qui m'a fait me poser la question si l'outil ne faisait pas un UKI (Noyau + initramfs + EFI Stub) pour le signer.
Est-ce que tu disposes des lignes linux et initrd dans ton fichier de configuration systemd-boot ou d'une seule ligne linux ?

Oui, j'ai bien les linux, initrd et les fichiers ".conf" qui contiennent les options de démarrage définies dans /etc/kernel/cmdline:

$ find /boot/efi | grep -v Microsoft
/boot/efi
/boot/efi/EFI
/boot/efi/EFI/systemd
/boot/efi/EFI/systemd/systemd-bootx64.efi
/boot/efi/EFI/BOOT
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/Linux
/boot/efi/loader
/boot/efi/loader/entries
/boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.1.0-22-amd64.conf
/boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.9.7+bpo-amd64.conf
/boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.9.10+bpo-amd64.conf
/boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.10.6+bpo-amd64.conf
/boot/efi/loader/loader.conf
/boot/efi/loader/random-seed
/boot/efi/loader/entries.srel
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.10+bpo-amd64
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.10+bpo-amd64/linux
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.10+bpo-amd64/initrd.img-6.9.10+bpo-amd64
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.1.0-22-amd64
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.1.0-22-amd64/linux
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.1.0-22-amd64/initrd.img-6.1.0-22-amd64
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.7+bpo-amd64
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.7+bpo-amd64/linux
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.9.7+bpo-amd64/initrd.img-6.9.7+bpo-amd64
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64/linux
/boot/efi/9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64/initrd.img-6.10.6+bpo-amd64
/boot/efi/System Volume Information
$ cat /boot/efi/loader/entries/9af3221b56764a7bb3cd7feeb31bbde9-6.10.6+bpo-amd64.conf
# Boot Loader Specification type#1 entry
# File created by /usr/lib/kernel/install.d/90-loaderentry.install (systemd 254.16-1~bpo12+1)
title      Debian GNU/Linux 12 (bookworm)
version    6.10.6+bpo-amd64
machine-id 9af3221b56764a7bb3cd7feeb31bbde9
sort-key   debian
options    cryptdevice=UUID=516d25d7-053c-424e-9822-35c15ee60dd1:Debian root=/dev/mapper/Debian rootflags=subvol=@ quiet splash systemd.machine_id=9af3221b56764a7bb3cd7feeb31bbde9
linux      /9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64/linux
initrd     /9af3221b56764a7bb3cd7feeb31bbde9/6.10.6+bpo-amd64/initrd.img-6.10.6+bpo-amd64

J'avais compris que UKI remplace le couple "initramfs et noyau". Ce n'est pas ça ?

L'UKI peut contenir beaucoup de chose :
- Noyau
- Initramfs
- Cmdline
- SplashImage
- DTB (majoritairement pour ARM/Risc-V)
- Metadonnées OS-Release
- EFIStub (pour être compatible UEFI)
Mais en effet la grosse plus-value est de pouvoir s'assurer de l'intégrité de l'initramfs et de la cmdline en plus de celle du noyau.

Ah oui, c'est pas mal tout ça, il faudra que j'essaie de le mettre en place en suivant l'article de copyninja. Il a d'ailleurs écrit un deuxième article pour activer Secure Boot avec l'utilisation d'UKI en utilisant sbsign à la place de sbctl (sbsign est déjà empaqueté par Debian, c'est à essayer).

L'extension TabStash semble être exactement ce que tu recherches.

Elle te permet de rapidement sauver tous les onglets en cours dans un groupe et également de tous les restaurer d'un clique.

Tu peux l'utiliser comme page d'accueil ou comme panneau latéral (et ainsi avoir une gestion verticale des onglets).

Enfin, l'extension est recommandée par le site Addon de Mozilla.

Hello,

Je cloture cette demande, parce que:

1. il n'y pas de volonté de gérer l'envoi massif d'emails depuis l'infrastructure de Linuxfr
2. un patch pour améliorer le tableau de bord de l'utilisateur a été proposé et il liste les entrées de suivi avec les nouveaux commentaires: https://github.com/linuxfrorg/linuxfr.org/pull/320

Hello,

Je vais clore cette demande parce que je pense que ça introduit un pistage inutile des actions utilisateurs.

Pour mettre en lumière le lien, il y a déjà la note qui est la somme des utilisateurs qui ont trouvé qu'il était important de donner son avis de pertinence / inutilité du lien.

L'action de la note est un acte volontaire et permet en plus de voter de manière négative.

J'ai commencé une branche pour utiliser des URLs complètes dans le code de LinuxFr (pas dans le contenu) et permettre de choisir le port publique: https://github.com/linuxfrorg/linuxfr.org/pull/395

L'initramfs n'étant pas signé, celui-ci peut être modifié.

Avec grub, l'initramfs peut être stocké dans une partition chiffrée et il n'a dans ce cas pas besoin d'être signé puisqu'il est déjà chiffré.

Avec systemd-boot, il faut placer le initramfs dans la partition ESP qui ne peut pas être chiffrée.

Dans l'article, je présente comment signer automatiquement les fichiers initramfs avec le fichier 99-sbctl pour sécuriser le démarrage.

Avec une image UKI tu signes l'image complète (noyau, initramfs et cmdline)

J'avais compris que UKI remplace le couple "initramfs et noyau". Ce n'est pas ça ?

Avec la solution de l'article, le fichier cmdline n'est pas chiffré. C'est donc un bon argument pour essayer UKI, merci d'avoir pointé cette idee :)

Il y a un article qui vient d'être publié qui explique comment utiliser les images UKI avec Debian et systemd-boot. Il faudra que j'essaie dans ma VM, ça pourrait être intéressant.

Hello,

Si je comprend bien la définition d'UKI, le démarrage de la machine passerait directement du firmware UEFI au fichier UKI sans passer par l'intermédiaire de GRUB ou systemd-boot.

Dans cet article, j'utilise la méthode à l'ancienne où on a un chargeur de noyau, systemd-boot, qui démarre une image temporaire de Linux qui inclue juste ce qu'il faut pour démarrer la distribution. Dans le cas du chiffrement, il est nécessaire de compléter cette image avec le paquet cryptsetup-initramfs.

Debian a une page qui explique l'initramfs: https://wiki.debian.org/initramfs

Le problème du sommaire avec un point vide vient à cause d'une erreur de transcription du HTML vers le Markdown de LinuxFr.

Si un membre de la modération peut remplacer:

Le second fichier à configurer est _/etc/crypttab_ pour que l’image _initramfs_ et le module _cryptsetup_ sachent comment déchiffrer le conteneur LUKS. Par exemple, le contenu de mon fichier est :

> # <target name> <source device> <key file> <options>
>
> luks-debian UUID=${UUID} none cipher=aes-xts-plain64,size=512,hash=sha256

par l'utilisation d'un bloque de code à la place d'un bloque de citation autour du contenu du fichier:

Le second fichier à configurer est /etc/crypttab pour que l’image initramfs et le module cryptsetup sachent comment déchiffrer le conteneur LUKS. Par exemple, le contenu de mon fichier est :

# <target name> <source device> <key file> <options>

luks-debian UUID=${UUID} none cipher=aes-xts-plain64,size=512,hash=sha256

Ca serait apprécié :)

Ca donnerait quelque chose comme ça.

Pour ta machine chez toi:

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = XXXX_PRIVATE_KEY_SERVER

[Peer]
PublicKey = XXXX_PUBLIC_KEY_CLIENT
AllowedIPs = 10.0.0.2/32
Endpoint = 192.168.1.202:51820

Attention à bien configurer ta box pour accepter le traffic UDP entrant vers le port 51820 sur la box et à faire rediriger ce traffic sur l'adresse IP et le port que tu as mis dans Endpoint au dessus.

Pour la config du client chez ton ami:

[Interface]
Address = 10.0.0.2/32
ListenPort = 51820
PrivateKey = XXXX_PRIVATE_KEY_CLIENT

[Peer]
PublicKey = XXXX_PUBLIC_KEY_SERVER
AllowedIPs = 10.0.0.1/24
Endpoint = IP_PUBLIC_DE_TA_BOX:51820
PersistentKeepAlive = 25

Avec ça ton serveur doit pouvoir faire des ping vers 10.0.0.2 correctement.

Par défaut, le tunnel Wireguard ne s'active que si du traffic réseau doit être envoyé à travers le tunnel (depuis le client chez ton ami vers le serveur chez toi).

Tu peux ajouter l'option PersistentKeepalive = 25 dans la section [Peer] du fichier de configuration qui se trouve sur ta machine chez ton ami. Cf le wiki de Arch: https://wiki.archlinux.org/title/WireGuard#Unable_to_establish_a_persistent_connection_behind_NAT_/_firewall

Cette option est à utiliser pour ce cas où le tunnel doit rester actif pour que le serveur puisse contacter le client à tout moment.

Comme ça, tu n'auras pas besoin de créer un tunnel inverse et donc tu ne devrais pas à modifier la configuration de la box de ton ami.

Je pense pareil il faudrait monter un service en local, comme ça il n'y a même pas besoin de TLS. Pour transférer des photos, j'imagine qu'il doit y avoir d'autres protocoles supportés par Windows et plus simple à mettre en place.

Comme ça, j'imagine à:

• un service FTP
• un partage SMB / CIFS (depuis une machine Windows c'est peut être encore plus simple)
• un service Webdav, voire une application web comme Nextcloud (en local sans chiffrement) ou KaraDAV

Je ne connais pas les possibilités de Windows Phone 7.5, mais je pense qu'il doit au moins avoir un navigateur web, ce qui permettrait d'utiliser Nextcloud / KaraDAV (peut être il vaut mieux installer une ancienne version ou un vieux ownCloud).

Et pour enlever le bruit, il faut forcer l'apparition du terme OCDE avec des guillemets:

"OCDE" liens site:linuxfr.org

Ce qui me surprend c'est que le lien de SpaceFox n'apparaît pas si on enlève le mot "liens" et les deux autres contenus sont toujours là 🤔 idem si on écrit lien au singulier Oo

Mise à jour: lien de la doc de la synatxe de recherche

Merci, je ne l'avais pas vu.

En regardant à nouveau Wikipedia, j'ai trouvé la liste des numéros de protocoles réservés: la liste est beaucoup plus grande que ce que j'imaginais et elle est déjà bien remplie !

Étonnamment, QUIC n'y apparaît pas. Elle n'y est pas non plus sur la liste de l'IANA.

Il serait donc impossible de déployer directement QUIC sans passer par UDP ?

UDP serait donc effectivement utile pour déployer de nouveaux protocoles sur IP :)

Tiens, je n'arrive pas à voir l'usage alors. Tu pourrais nous en dire plus sur cette interaction ?

Dans quel cas le système du container doit créé un fichier ? Ensuite il exécute quoi comme commande pour l'application web ?

Hello,

C'est avec quel système que l'application doit avoir une interaction ? Est-ce avec le Linux du container ou celui de l'hôte ?

Si c'est celui de l'hôte, tu peux profiter du systemd de l'hôte comme ça :

• tu partages le dossier de l'hôte avec le container via un volume
• sur l'hôte :
  • tu créés une unité systemd.path pour surveiller ce dossier (ou tu utilises, incron, mais systemd sait déjà faire ça nativement)
  • tu créés un service systemd qui exécute une commande dans le container avec quelque chose comme: docker exec le-nom-du-container la-commande (ce service doit avoir le même nom que l'unité path créé au point d'avant)

Comme ça l'hôte averti le container avec la commande voulue dès qu'un fichier est créé dans le volume partagé.

Cet été, j'ai trouvé ce message très intéressant dans un fil de discussion lancé par Julia Evans sur les utilisations (in)connues d'UDP.

En gros l'auteur du message dit que l'on peut voir UDP comme la couche IPv4 avec l'ajout d'un numéro de port et d'un checksum. Ça permettait de créer différents services sur IP sans avoir besoin de réserver un numéro de protocole à chaque service nécessaire (les paquets IPv4 ont un espace dans l'en-tête IP qui permet de définir 256 protocoles différents, IPv6 n'a apparemment plus cette information).

Du coup, de ce point de vue ça semble logique que QUIC utilise UDP pour se déployer: ça ajoute très peu de complexité (le numéro de port et un calcul de checksum) et ça utilise une fonctionnalité prévue d'UDP (déployer des nouveaux protocoles sans faire d'enregistrement formel pour réserver un numéro de protocole dans IPv4).

Tout un article sur une seule adresse IPv4 sans aucune mention d'IPv6 et son pendant :: 🙄

Sinon, ils disent faire un responsible disclosure, mais seul Webkit a déployé un correcrif… Je trouve ça étrange, non ?

Dans l'article ils disent que Google aura complètement distribuer le correctif avec la version 133 (en commençant avec la version 128) et actuellement, ils ont déployés la version 127 seulement.

C'est le moteur proposé par Gtk et GNOME Web (alias Epiphany). Malheureusement midori est devenu un dérivé de Firefox depuis.

Si je pouvais¹, j'essaierai pijul, on avait eu ici même de superbes discussions sur la théorie des patchs pour gérer le code source à la place de snapshots de système de fichier (ce que fait git).

Je ne me souviens plus dans quel contenu exactement, je vous laisse suivre l'étiquette pijul et lire les commentaires.

toutes les proses écrites par les internautes, qui n'ont pas réagi depuis plusieurs années, se voient oubliées de force, à l'encontre des citoyens, par la dicature de la RGPD..

Euh non, non pas du tout, les écrits restent si tu lis bien la FAQ: Quelles sont les données inutiles au service qui sont supprimées des comptes fermés ?

En résumé, en automatique, si du contenu a été publié publiquement¹ par le compte, alors les données pour identifier l'auteur restent et les autres données à caractère personnels sont supprimées (email, compte XMPP, compte Mastodon…).

Après, ça ressemble fort à ce qui s'est fait pour le signal TV de toute façon, et j'ai pas entendu beaucoup de cris à l'époque. Ou je suis passé à côté ?

Il y a quelques mois, j'ai récupéré une TV avec un récepteur DVB et je me suis rendu compte qu'il n'y avait plus de signal en Suisse depuis bien plus longtemps. Je n'avais pas vu passer la nouvelle¹ et personne ne m'en avait parlé 😅

Alors que j'avais entendu dans mon entourage des gens parler de la coupure de la diffusion par le câble TV (coaxial).

Il va falloir que j'investisse dans un adaptateur DAB+ et Bluetooth pour mon Opel de ~2012 qui n'a aucune des 2 technologies 😒

---

• [1]: Bon, je ne suis pas non plus un utilisateur typique: mon écran TV ne sert que d'écran pour les consoles de jeux et mon ordinateur, ça fait longtemps que je ne regarde plus d'émission.

J'étais passé à côté de cette nouvelle. Si c'est vraiment le cas, alors je ne vois pas pourquoi la carte sd de lym était vide 🧐