Yves a écrit 391 commentaires

Je ne comprends pas cette focalisation sur la gestion de tags, y compris dans le billet de départ.

Prenons un tel système de fichiers. On peut facilement imaginer (et un projet que j’avais suivi il y a des années — je ne me souviens plus du nom — avait une approche similaire) que :

• Ça présente une arborescence classique, dans laquelle les programmes divers se retrouvent facilement.
• Un mkdir toto à la racine crée implicitement un tag toto.
• Déposer un fichier dans le « répertoire » toto enregistre cet objet-fichier avec le tag toto, automatiquement.
• Créer un lien avec ln toto/nom1 titi/nom2 assigne implicitement le tag titi au document pointé par nom1 ou nom2, en plus du tag toto.

Évidement, ça ne répond pas à toutes les questions :

• Que signifie un lien symbolique ? Vers le même FS ; vers un autre FS ?
• Que se passe-t-il si on dépose à la racine du FS ? Non-classifié ?
• Quid des « sous-répertoires » ? repA/repB/file serait-il simplement l’assignation du tag repA/repB au document file ?

En tout cas, ça forme une base qui me semble extrêmement simple, que l’utilisateur lambda peut utiliser aussi naturellement qu’un ext4, sans être obligé de profiter des fonctionnalités avancées.

Bon… mais… finalement, tout ceci n’est-il pas déjà réalisable avec ext4, justement ? Les liens pas symboliques peuvent aider. Il suffirait (presque) d’être organisé. Le hic, c’est les applications qui, quand elles enregistrent une modifications, créent un nouveau fichier (inode) puis suppriment l’ancien. Donc non, on n’y est pas encore, mais il ne manque pas grand chose pour que ça convienne.

C’était pour alléger TinyCore Linux, pour tenter de l’utiliser à la place du vieillissant DamnSmallLinux sur mon PC portable Toshiba 300CDS avec 24MB RAM. Je n’ai pas réussi : le kernel moderne était toujours trop gros :-(

Sinon, avant ça, c’était il y a des années, pour mon PC de salon à base d’EPIA M10000N, un truc sans driver open-source (à l’époque). L’enfer.
Ça marchait, mais les mises à jour étaient compliquées. Je me suis juré de ne plus jamais acheter un périphérique non utilisable avec un driver open-source.

Bonjour et merci beaucoup de continuer à nous tenir informés sur cette suite bureautique, bien que nombreux parmi nous boudent cet outil libre, juste parce que le format natif est MS OpenXML.
Je fais partie de ces personnes, en grande partie parce que tous mes documents sont au format OpenDocument…

Néanmoins, je rencontre un soucis avec mon CollaboraOnline (LibreOffice OnLine aka. LOOL) : ça utilise des web-sockets, et derrière un certain nombre de « pare-feu », ça ne passe pas :-(

Du coup, avec regret, j’envisage OnlyOffice. Une seule question, donc : OnlyOffice utilise-t-elle des web-sockets ?

Oui, ça c’est le piège amusant de bc :-D
Au début, je croyais que bc avait un bug! J’ai fini par comprendre…
Du coup, si tu fais ibase=2, pour revenir en base 10, il faut faire ibase=1010, ce qui n’est pas forcément intuitif.

Merci pour ce récapitulatif des commandes disponibles. C’est instructif, et ça dépanne quand on est dans un environnement où la commande qu’on connait n’est pas disponible.

N’oublions pas :

• les tickets suivis par XMPP
• les tickets suivis par Git

Bon courage dans ta recherche de la solution idéale…

Salut ! et merci pour cet intéressant inventaire (quoique de mon côté j’utilise plutôt Ansible).

Pour vim, j’ai trouvé ça sur Internet et je trouve que c’est assez confortable à utiliser :

set list
set listchars=eol:⏎,tab:▸·,trail:␠,nbsp:⎵

(à copier tel quel avec les caractères Unicode)

J’y ai ajouté aussi :

set runtimepath^=~/.vim/bundle/vim-editorconfig

avec ~/.vim/bundle/vim-editorconfig qui est un clone de https://github.com/sgur/vim-editorconfig.git, en « detached HEAD » sur la dernière version (dernier tag).

Sur beaucoup de sites marchands, tu ne peux plus payer par carte bancaire si ton téléphone ne reçoit pas les SMS.

Je ne suis pas expert du sujet, mais je vais tenter une réponse.

Effectivement, il y a plusieurs rebonds. Cependant, en situation « nominale », le chemin est assez court :

1. ton client (ex. Thunderbird) contacte ton fournisseur (ex. monFAI.fr) ;
2. ton fournisseur contacte le fournisseur du destinataire (ex. sonFAI.fr).

C’est tout. En réalité, il peut y avoir plus de rebonds, car selon la topologie de réseau, on peut vouloir subdiviser le traitement des email, ou en externaliser certaines parties.

À l’origine, tout cela est un peu « open-bar », et petit à petit, on a protégé les choses, notamment l’étape 2. ci-dessus :

DKIM et SPF visent globalement à s’assurer que le domaine qui envoie (@monFAI.fr) est véridique. SPF liste les serveurs habilités à envoyer au nom de ce domaine, et DKIM permet de vérifier par une signature cryptographique que seul un serveur habilité a effectivement pu envoyer le mail.

Rien n’est spécifiquement fait pour s’assurer que le domaine récepteur est le bon. Là, on fait confiance au DNS (MX, AAAA…). C’est un autre sujet, pour lequel d’autres techniques existent.

Reste à sécuriser l’étape 1. ci-dessus. Là, en général, on s’appuie sur un login et un mot de passe. Et comme sur le web, tu n’entres pas ces données sans que le canal de communication ne soit sécurisé. Le serveur qui vérifie ton accès est celui qui gère @monFAI.fr, et donc c’est entre toi et ce serveur qu’il faut chiffrer la communication. Le besoin s’arrête là. Il ne s’agit pas de sécuriser tout le trajet jusqu’au destinataire.

Le trajet entre serveurs de messagerie (notamment l’étape 2. ci-dessus) passe par le port 25, généralement en clair. Pour cette raison, pour masquer le contenu d’un email, il faut une action de chiffrement à ton initiative, indépendante du transporteur. On utilise souvent S-MIME ou GnuPG pour ça. Il suffit que l’émetteur et le destinataire se comprennent.

C’est comme avec La Poste : tout le monde voit l’extérieur (émetteur, destinataire, tampons d’acheminement…), mais tu peux décider, à ton initiative, de mettre le contenu dans une enveloppe pour que seul le destinataire puisse le lire ; tu peux aussi décider de laisser tout visible par tout le monde : la carte postale, ce que pratiquement tout le monde fait en matière d’e-mail.

Enfin, pour la dernière question : non, il n’y a aucun moyen de savoir, à moins de connaître le « postmaster » ou que les logiciels côté serveur laissent des traces révélatrices en en-têtes.

Pour « Eu », « ¤ », et « × », d’excellentes réponses ont déjà été données.
Au passage, je ne comprends pas l’intérêt de prendre un espace précieux avec ¼, ½, ¾… même en BÉPO ; il aurait été plus judicieux de proposer les multiples possibilités d’Unicode avec Compose ; par exemple : Compose,1,4 pour ¼. Régulièrement, je veux faire 2/3, et là je me trouve coincé :-(

Pour « \ », au risque d’être provocateur, je dirais que c’est le séparateur standard sur Windows, et que « le législateur » ne connaît que ça. Si des déviants utilisent Linux ou OS.X, ça n’est pas leur problème ; eux sont des gens sérieux.
Alors, oui, parfois, il (le législateur) « lance Internet » (vous savez, le e bleu avec un anneau), et demande à l’accueil (ie. :-p Google) de lui montrer par exemple « résultats de sondage » ou encore « wikipedia.org » (qui a besoin de la barre d’adresse ?).
Bref, « / » ? Pourquoi faire ? « ÷ » le remplace avantageusement…

Allez, bon vendredi !

Je confirme.

Ayant eu une panne de Box FAI chez moi pendant 1 semaine ½, quelques jours de downtime ne m’ont aucunement pénalisé, le temps que je bouge le serveur chez quelqu’un d’autre.
Bon, évidemment, si j’avais attendu 1 semaine ½ pour faire ça, j’aurais pu perdre des mails… mais jusqu’à 5 jours, la probabilité de perdre des mails est assez faible.

Et ça, c’est une grande force de SMTP ! Eussions-nous été encore le 1er de ce mois, j’aurais bien évoqué SMTP-o-PV, « SMTP over Pigeon Voyageur » de son nom complet, mais j’arrive trop tard…
(en vrai, cette résilience de SMTP est très rassurante/apaisante pour un auto-hébergeur !)

Toujours en open-source, je ne peux que recommander le jeu BlackVoxel!

Dans une ambiance solitaire (imaginez-vous dans « Seul sur Mars ») — mais êtes-vous vraiment seul ? —, des missions vous guident dans le rétablissement d’un environnement technologique, en partant de la seule machine sauvée du crash de votre vaisseau…

Oui, sans hésitation.
C’est la norme dans quelques administrations françaises et grandes entreprises où j’ai travaillé.

Le principe est simple :

• Le navigateur (IE, Firefox…) connaît les autorités de confiance habilitées à valider un certificat de site web.
• L’entreprise/administration établit au sein du groupe un poste de travail standard, dans lequel le(s) navigateur(s) intègrent une « autorité de confiance » interne (gérée par l’IT du groupe).
• Quand tu visites un site, ça passe par le proxy-MITM du groupe, qui ne fait que te répondre (signé avec un certificat généré à la volée et authentifié par l’autorité de confiance interne) ce que le vrai site a répondu. Si tu ne regardes pas le certificat, c’est complètement transparent.

Pourquoi faire ça ? Tout simplement pour la « sécurité », la surveillance, etc.
Historiquement, les entreprises aiment bien regarder ce qui entre et sort du réseau interne, pour vérifier que ça ne parle pas de jeu, de boursicotage, de sites sociaux… bref tout ce qui pourrait faire perdre en productivité. Tout cela se fait sous couvert (en partie justifié) de « sécurité » : audit, lutte contre la fuite de données, etc.
Avec SSL puis TLS, c’est plus compliqué. MITM et le DPI sont vus comme des solutions à ce genre de difficulté.

Triste conclusion des actualités…
Merci Mozilla pour la poursuite des efforts et la maintenance de ce navigateur au service de ses utilisateurs.
Merci aux rédacteurs pour cette page d’information.

« Chacun voit midi à sa porte », comme on dit (heure d’hiver ou d’été, je laisse chacun décider :-p )

Pour ma part, sachant qu’une faille logicielle a déjà failli m’atteindre, sur un logiciel en lequel j’avais pleinement confiance (exim), sur une distribution en laquelle j’avais pleinement confiance (Debian stable + màj. securité), et sachant que derrière il y a toute ma vie en scan (revenus, impôts, etc.), en mails, etc., je mets du coup la barre assez haut.

Tout d’abord, je te remercie pour ton commentaire nuancé et constructif :-)

Je voulais juste donner une anecdote amusante sur l’absence de réseau (avec un lien pour les plus curieux), et non m’étendre sur les détails, qui sont un peu hors-sujet, mais bon… je vais essayer de donner quelques précisions… Il faut par contre garder à l’esprit que c’est un projet en cours (non achevé).

De base, dans ma DMZ, à quelques exceptions près, l’accès sortant à Internet est bloqué. Et ce, par un paramétrage nftables qu’aucun service systemd n’a le droit d’altérer.

— Du côté de HAProxy, en cible, il y aura une isolation de namespace filesystem (comme un chroot) donc aucun accès à du contenu. À ce jour, il n’y a que de la protection par l’obscurité : HAProxy ne « sait » tout simplement pas où sont les rares données accessibles en DMZ (mais ça n’est pas si difficile à deviner). Comme tu l’as souligné, ça apporte un certain degré de sécurité mais ce n’est pas idéal…

=> En cas de faille permettant de faire exécuter par HAProxy un binaire quelconque, ce dernier n’aura sur le principe rien à communiquer avec l’extérieur, et s’il pourra peut-être recevoir des requêtes, il ne pourra en revanche pas en émettre.

— Du côté de Nginx, seules les sockets-Unix exposées servent à communiquer avec l’extérieur : recevoir des requêtes et y répondre. C’est le résultat d’un effort en cours pour retirer tous les accès réseau à Nginx ; à ce stade, je devrais pouvoir prochainement mettre en place une véritable isolation par namespace réseau, ce qui est ma cible.

=> En cas de faille permettant de faire exécuter par Nginx un binaire quelconque, ce dernier ne pourra pas utiliser le réseau, et n’aura de toute façon que peu de données accessibles.

— Php-fpm m’ennuie davantage… l’accès au réseau est restreint de manière similaire, mais il est plus délicat de mettre en place des restrictions sans aller jusqu’à ségréguer les applications PHP…

Hors DMZ, mais accessible depuis celle-ci, non ?

Oui, dans la « SafeZone » (hors-DMZ), on a accès aux données sensibles. Le point important est surtout que les logiciels qui y sont, et sont donc plus sensibles, ne sont pas directement exposés sur Internet : Nginx (en DMZ) agit en proxy et limite les possibilités de créer des paquets sur-mesure pour déclencher des bugs. Ça n’est pas entièrement sûr, mais ça l’est davantage qu’un accès direct ou par simple redirection de port.

Bref, tu as l’air de déjà le savoir : la sécurité n’est pas un interrupteur qu’on active ; c’est un millefeuille où chaque couche participe… et est insuffisante. Le choix du « nombre de feuilles » au millefeuille est un équilibre à trouver entre le risque, le coût de mise en œuvre et le coût d’une faille.
Comme je fais ce projet dans un but d’apprentissage en plus de son utilité immédiate, pour ma part, tant que ça reste 100% automatisé (ansible), ça me va ;-)

Nginx a 3 sections de configuration :

• une pour le contenu HTTP, en écoute sur (je simplifie) /run/http ;
• une pour le contenu HTTPS, en écoute sur /run/https ;
• une pour le contenu HTTPS accédé depuis une IP de confiance ou une IP ayant port-knocké le bon « mot de passe », en écoute sur /run/https+.

Sur la DMZ, nftables gère le port-knocking et redirige sur un port interne spécifique en cas de port-knock réussi ; j’ai donc 3 ports HTTP(S), sur lesquels haproxy est en écoute.

Outre la gestion de quelques subtilités (type tunnel), haproxy se contente en gros de rediriger le traffic HTTP sur /run/http, le traffic HTTPS sur /run/https, etc. (je ne détaille pas les divers paramétrages systemd)

Ainsi :

• haproxy a accès au réseau mais à aucun contenu,
• nginx a accès au contenu (non-sensible) mais pas au réseau,
• pour le contenu sensible, nginx doit faire appel a un service back-end hors DMZ, par exemple Nextcloud qui tourne sur un uwsgi.

C’est en tout cas plus compliqué. En quoi est-ce plus sûr ?

Je comprends bien qu’en l’absence de carte réseau virtualisée l’OS invité n’en dispose plus et donc n’a plus, en théorie, de réseau.
Finalement, c’est un peu la même chose avec les espaces de nommage réseau.

Il me semble en fait que tu pars du principe qu’un programme malveillant pourra contourner l’isolation de son espace de nommage (et donc accéder à l’espace de nommage réseau de l’hôte), mais qu’une telle chose est impossible dans une VM… Il me semblait pourtant que des programmes malveillants avaient été observés, qui contournaient l’isolation de la VM pour accéder à l’hôte.

Plus de détails m’intéressent, si tu as des liens.

Anecdote amusante à ce sujet : sur mon serveur auto-hébergé, je suis probablement un des rares individus de la planète à faire tourner son serveur web (nginx) sans accès au réseau !

Depuis qu’une backdoor a failli s’installer sur mon serveur il y a quelques années via une faille d’Exim dans Debian (je n’y ai échappé que parce que j’avais monté ma partition noexec), je suis devenu un peu parano au niveau sécurité… Mais il y a encore pire que moi :-D

C’est simple : on appâte le chaland avec un prix imbattable, puis une fois qu’on l’a capturé, on lui fait payer le renouvellement bien plus cher… mais bon, qui a envie de s’embêter à changer une fois que tout fonctionne… Et donc, ça marche.

C’est exactement pareil que les offres du type :

Seulement 10€/mois ! (*)

(*) pendant 2 mois, puis 50€/mois.

Le plus dangereux, ce n’est pas ceux qui connaissent ou ceux qui ne connaissent pas.

C’est ceux qui croient connaître. C’est pratiquement une règle universelle…

Ah, peut-être pas, c’est vrai. Tout va bien, alors :-)

Et à part ça, s’être marié le jour de la bascule de 1999, c’est quand même une coïncidence amusante !

La correction est-elle du niveau du firmware ou du software ?
En gros, je me pose la question, pour OSMAnd, de savoir si on doit attendre une mise à jour Android, ou OSMAnd…

Démarche intéressante. Il est vrai qu’IPv6 change la donne à ce niveau. Mais encore faut-il que ton PC soit allumé quand tu n’es pas chez toi… Et un PC, c’est gourmand comparé à un petit serveur dédié et pas cher ;-)

Certes. Après, c’est son journal, que tu n’es pas obligé de lire. Il ne s’agit pas d’une dépêche…