Babelouest a écrit 709 commentaires

Pour te donner un début de réponse (je suis dans la team js de Debian), le but est aussi de fournir des paquets javascript permettant de construire d'autres paquets Debian.

La politique de Debian (et probablement des autres distribs) est de ne pas dépendre de dépôts externes à la distrib quand on fabrique un paquet.
Ca permet de pouvoir construire un paquet même dans 2³² ans, quand les repos npm auront disparu sous la croûte terrestre mais que les paquets Debian seront toujours quelque part dans le coin d'un disque dur d'un barbu qui voudra pas migrer toute sa stack, juste recompiler pour sa nouvelle architecture.

Certes les paquets npm changent tous les matins, mais si un mainteneur Debian veut packager une application qui a des dépendances en libraries javascript (ex: GitLab: https://salsa.debian.org/ruby-team/gitlab/blob/master/debian/control, il ne s'occupe de packager qu'une version précise de l'application et ses dépendances, et n'est pas obligé de mettre à jour les dépendances à chaque nouvelle release, seulement quand il en a besoin.

Quand le mainteneur du paquet veut maintenir une nouvelle version, il met à jour les dépendances javascript si c'est nécessaire.

D'où l'importance des paquets javascript et npm dans Debian.

À coté de ca, Debian propose un paquet npm qui fait du npm comme prévu, en allant taper dans npm.js les dépendances en cascade quand tu fais un npm install.

Tu dois avoir une configuration spécifique, genre firefox est installé et mis à jour par ta distribution ou par ton administrateur système.

c'est à dire: t'es marron

D'après mes sources, il est possible de désactiver les mises à jour dans la configuration de firefox dans l'onglet général, en une section de cet onglet te demande si tu veux:

• Installer les mises à jour automatiquement (mode sain)
• Vérifier l'existence de mises à jour mais vous laisser décider de leur installation (mode expert)
• Ne jamais vérifier les mises à jour (mode hardcore metal tronçonneuse punk sous acide)

Selon une ancienne légende, il existerait aussi un mode Dieu Klingon de la Destruction qui consisterait à aller dans about:config, chercher l'option app.update.auto et la mettre à false.
Mais aucun aventurier ayant utilisé cette fonctionnalité n'est revenu de sa quête pour témoigner.

Alors non pour deux raisons.

• La première c'est que le mod gzip (ou deflate, plus mieux) s'applique au body de la réponse, pas à l'url ou aux headers malheureusement. Il faut passer en HTTP/2 ou HTTP/3 pour pouvoir compresser les headers.

• La seconde c'est que le code présenté s'exécute uniquement coté client, et que donc il n'y a pas d'appel à un serveur HTTP quand on clique sur le lien HREF qui contient un data URI scheme.

Comme on dit:

Pas de requête HTTP -> Pas de réponse HTTP
Pas de réponse HTTP -> Pas de body dans la réponse HTTP
Pas de body dans la réponse HTTP -> Pas de compression gzip
Pas de compression gzip -> Pas de compression gzip

Dans la page wikipedia que tu cites, quelques lignes plus haut il est écrit:

linefeeds within an element attribute value (such as the "src" above) are ignored

Pour des raisons historiques et de lisibilité, la norme dit d'ignorer les sauts de ligne dans un data URI scheme, ca permet d'avoir un texte long coupé en plusieurs lignes donc plus lisible.

Après chaque navigateur et moteur de rendu fait ce qu'il veut et ce n'est pas la seule incompatibilité qui existe.

L'exemple de la même page wikiepdia est:

<img src="data:image/png;base64,iVBORw0KGgoAAA
ANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4
//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU
5ErkJggg==" alt="Red dot" />

Même si tu as l'air de ne pas aimer le base64, et malgré la perte (relative) de place que ca provoque, je pense malgré tout que c'est la meilleure solution pour ton problème. Avec le base64, on est sûr que les données entre la source et la cible seront les mêmes et non interprétées.

OK alors tel que tu le décris, dans un contexte OAuth2 (ou OIDC ca marche aussi), ca m'a l'air de ressembler à ca:

• L'appli A est un service web qui utilise des access_token pour authentifier les accès pour envoyer ses données via une requête HTTP REST.
  Comment l'appli A récupère ses données et comment elle les stocke est hors scope du problème.
  Il existe plusieurs applis A différentes qu'on va appeler A1, A2, A3, etc. Le nombre de A varie dans le temps.

• L'appli C est un client OAuth2, celle-ci va chercher un access_token au nom d'un utilisateur connecté pour aller faire des requêtes sur l'appli A
  L'appli C doit être préalablement inscrite sur le serveur OAuth2 pour être autorisée à aller chercher des access tokens, mais c'est moins grave parce que le nombre de C m'a l'air moins variable que le nombre de A.

Glewlwyd utilise des JWT comme access_token, ce qui permet à A de valider la validité des access tokens tout seul, en validant la signature dudit JWT.

Si tu veux que l'utilisateur donne explicitement son consentement à C l'autorisation d'accéder aux applis A, il faut assigner à chaque A un scope différent, ce qui permettra dans Glewlwyd d'avoir des access_token pour un ensemble de scopes correspondant à ceux autorisés par l'utilisateur pour le client.
Tu peux créer dans le serveur OAuth2 un grand nombre de scopes pour permettre aux nouveaux A qui arrivent dans la fédération de se voir assigner un scope que pour lui.

Faut comprendre que dans ce que je viens de décrire, les A ne s'authentifient pas ni n'authentifient personne. Ils se contentent de fournir des données à un client C qui a un access_token valide, c'est à dire avec une signature et un scope valides.

Aussi, le serveur OAuth2 est seul donc un joyeux SPOF (single point of failure). Tu peux contourner ca en prévoyant plusieurs serveurs OAuth2 qui partageront la même configuration ce qui leur permettra de fournir des access tokens compatibles, mais il faudra permettre à C de connaitre l'ensemble de serveurs OAuth2 disponibles.

Mathieu a mentionné UMA, ca peut aussi répondre à ton problème mais je ne connais pas.

Une image Docker est prête :
https://github.com/babelouest/glewlwyd/blob/master/docs/INSTALL.md#docker

Petit erratum.

Inbound OAuth & OpenID

J'ai ca

Non j'ai pas en vrai, je supporte les protocoles OpenID et OAuth2 mais je ne permets pas de m'authentifier sur un autre SSO

Ah là j'ai trouvé la doc qui détaille les fonctionnalités!

Basic Authentication

J'ai ca, LDAP ou base de données. Pour MySQL et Postgre j'utilise les fonctions built-in pour stocker des mots de passe, pour SQLite3 j'encode en pbkdf2 via GnuTLS.
J'ai même la possibilité d'authentifier un utilisateur via un service HTTP tiers qui ferait du Basic authentication.

FIDO U2F et FIDO 2.0

J'ai ca via Webauthn, avec en plus le support des lecteurs d'empreinte digitale dans Android.

Super Gluu

J'ai pas ca mais ca m'amuserait d'en faire un

OTP Apps

J'ai ca

SMS OTP

J'ai pas ca mais j'ai E-Mail OTP

Inbound OAuth & OpenID

J'ai ca

Inbound SAML

J'ai pas ca. Je voulais le faire au début mais je ne connais pas SAML, et en lisant la doc, il m'a l'air pas mal compliqué, le jeu n'en valait pas la chandelle en tout cas pour le moment.
Cela dit, quelqu'un de motivé peut très bien créer un plugin qui fera de l'authentification SAML.

Duo Security

J'ai pas ca

ThumbSignIn

J'ai pas ca

Certificate Authentication

J'ai ca

Account Lockout

J'ai ca mais il faut un admin pour désactiver un compte

Forgot Password

J'ai pas ca mais c'est relativement facile à faire

Custom Script Tutorial

J'ai pas fait de SDK pour scripter les accès à Glewlwyd mais toute l'API REST est documentée.

TL;DR: Tu peux peu-être utiliser les response type client credential ou password dans OAuth2 pour répondre à ton besoin mais je ne suis pas sûr de l'avoir totalement compris.

On travaille sur l'échange de données énergétiques (et plus) en mode fédéré

Mais encore? Plus précisément qui échange avec qui?
Est-ce que ce sont des systèmes embarqués qui récoltent des données puis les poussent sur un service distant ou des services distribués?
Est-ce que ce sont des utilisateurs avec leur téléphone intelligent qui se connectent dans une app et qui rentrent des données à la main?
Autre chose?

nous avons réfléchi au RGPD

Quel est l'impact du RGPD dans ton cas?

ces protocoles nécessitent des paramètres amont

Plus précisément, ces protocoles nécessitent que les clients et les utilisateurs soient préalablement connus du serveur d'authentification. Mais je ne comprends pas ton besoin, donc je ne peux pas te dire si tu es dans le champ ou pas.

Nous voulons faire sen sorte que les échanges de données entre applications soient fluides, nous voulons tracer les autorisations

Dans un contexte à base d'API REST, je verrais quelque chose comme ca:

Chaque application est connue du serveur OAuth2 par un identifiant/mot de passe.
Il existe un ou plusieurs services REST qui ont pour tâche de te renvoyer un JWT signé contenant les données que tu lui as fournies. Seuls ces services REST connaissent les clés privées pour signer les messages, mais les clés publiques sont publiques justement, donc n'importe qui (n'importe quel noeud) peut vérifier la signature pour s'assurer que ledit message est bien valide, et résoudre une partie du problème des généraux byzantins: le message n'a pas été altéré pendant le transport.

Lorsqu'une application souhaite envoyer un message aux noeuds, elle se connecte au serveur OAuth2, lui réclame un access token en utilisant son identifiant/mot de passe.
Le message non signé est transmis au service REST de signature qui lui renvoie le message signé sous forme de JWT
Le message signé est enfin prêt à être distribué via XMPP ou tout autre moyen aux autres noeuds qui n'auront qu'à vérifier la signature tout seuls.

Bonus: les response type client credential ou password ne nécessitent pas d'url de retour.

Salut,

J'ai peut-être trouvé ce qui me manquait pour émettre des PKCS#12 à la volée, donc je vais essayer de placer ca dans la RC2.

Mais de ce que j'ai compris sur les certificats X509, ils stockent les informations suivantes:
- Clé publique (évidemment)
- Date d'émission
- Date d'expiration
- Numéro de série
- DN du certificat
- DN du signataire du certificat

Le seul sur lequel je ne sois pas sûr c'est le DN du certificat, comment est-il construit en général?

Je me mets à la place de l'admin qui paramètre son générateur de certificat.
Est-ce que le DN du certificat doit piocher ses paramètres dans les données de l'utilisateur genre cn=<son nom>,ou=<son groupe>,dc=plop,dc=grut?
Est-ce qu'il doit construire le DN en utilisant un format beaucoup plus rigide, comme cn=<chiffre random>,ou=coin,dc=plop,dc=grut?

Est-ce que je dois permettre à l'admin de contrôler très finement tous les paramètres ou pas tant que ca?

Ton cas d'usage est celui que j'utilise la plupart du temps, mais dans OAuth2/OIDC il faut distinguer deux notions différentes:

• Le client peut être public ou privé

Un client privé est un client qui doit s'authentifier sur le serveur OAuth2/OIDC pour faire une demande quelconque, avec un mot de passe, une clé RSA, ou un autre moyen pris en charge par le serveur OAuth2/OIDC. Il doit donc être capable de stocker ladite méthode d'authentification quelque part pour le donner au serveur OAuth2/OIDC à chaque requête.
Un client public n'a pas besoin de s'authentifier à chaque requête sur le serveur OAuth2/OIDC.
Je vois souvent les clients OAuth2/OIDC confidentiels qui sont des services web intermédiaires, biens que plein d'autres facons de faire existent.

Effectivement si ton client est une application javascript s'exécutant sur le navigateur de l'utilsateur (SPA), c'est inutile d'avoir un client confidentiel car avec un simple F12 n'importe quel utilisateur (authentifié ou non) peut accéder au secret du client.

• Le client peut demander un refresh token ou seulement un access token

S'il demande un refresh token, le client doit le stocker quelque part pour utiliser le refresh token à chaque besoin, d'autant que le token peut avoir une durée de vie longue, donc faut faire attention à ce que tu en fais.

Maintenant dans les faits, je ne vois pas de contre indication à utiliser un client public pour demander des refresh token. Si tu as confiance en ton navigateur pour stocker tes cookies de session, éventuellement tes mots de passe, je ne vois pas pourquoi tu ne pourrais pas non plus y stocker tes refresh token, via un cookie ou un stockage local.

J'aimerais bien pouvoir émettre des certificats depuis Glewlwyd pour que l'utilisateur l'installe facilement sur son navigateur mais je n'ai pas encore compris comment générer un PKS#12 avec GnuTLS.
Je peux le faire avec certtools ou openssl mais je préfère le faire avec la librairie GnuTLS toute seule (C'est celle que j'utilise dans Glewlwyd).

Après, comme je disais, je ne suis pas un expert de l'authentification TLS cert donc y'a encore des trucs qui m'échappent.
Mais si je dis pas de conneries, la validation du certificat est faite en amont par le framework HTTP, et Glewlwyd récupère le certificat du client si celui-ci est validé avec le CA qu'on a spécifié.
De fait, Glewlwyd se contente d'enregistrer les certificats des clients et de dire si oui ou non le certificat est connu. Pour l'instant il ne fait pas d'autres vérifications car je ne sais pas comment est validé un certificat TLS chez ceux qui le font, d'où mon appel à l'aide.

Je sais pas trop ce qu'il apporte de plus, je connais un peu keycloack mais je ne l'ai jamais utilisé.

À la louche, je dirais qu'il est moins lourd car Keycloack est écrit en Java alors que Glewlwyd est écrit en C.
Le paquet d'installation fait ~2.3 Mo et il tourne sans problèmes sur une config minimale type Raspberry Pi Zero pour une utilisation à petite échelle. C'est parce que j'aime le C que j'ai voulu faire ca comme ca.

Pour les fonctionnalités, notamment quels facteurs d'authentification sont supportés par l'un et pas l'autre, je sais pas vraiment, j'ai pas trouvé la liste complète sur le site de keycloack (j'ai pas cherché sur tout le site non plus)

Mais je n'ai pas la prétention de remplacer Keycloack, j'ai fait Glewlwyd pour m'amuser et pour répondre à mes besoins.

C'est un protocole d’autorisation, aucun moyen de valider une identité avec un acces_token avec OAuth2 seul, seulement d'autoriser l'accès sur une porté donnée (Et je ne vois pas ce qui à été supprimé).

Alors, dans l'absolu oui parce que OAuth2 ne dit pas ce qu'est un access token, sauf que dans mon cas le access token est un JWT, ce qui permet d'avoir des informations pertinentes dedans.
Dans le cas du plugin OAuth2 de Glewlwyd, le payload des JWT ressemble à ca:

{
  username: "user1",        // Username that was provided this access_token
  salt: "abcdxyz1234",      // Random string to avoid collisions
  type: "access_token",     // Hardcoded
  iat: 1466556840,          // Issued at time in Epoch Unix format
  expires_in: 3600,         // Number of seconds of validity for this token
  scope: "scope1 g_profile" // scopes granted to this access token in a string separated by spaces
}

Ce qui permet d'avoir l'information minimale de l'identité de l'utilisateur qui demande l'accès aux ressources.

Ce que OIDC a enlevé par rapport à OAuth2 vanille c'est les response types Resource Owner Password Credentials Grant et Client Credentials Grant.
Pour être précis ils ne disent pas explicitement "Ne mettez pas ca dans votre OIDC", mais la norme OIDC les ignore, donc on en fait ce qu'on veut.
Ca peut vouloir dire que si tu migres d'un serveur OAuth2 vers un serveur OIDC et que tu utilisais ces response types dans OAuth2, ils ne seront pas nécessairement implémentés dans le nouveau serveur, donc il faudra que tu trouves une autre solution.
Pour éviter ca, dans le plugin OIDC, j'ai mis une option pour le rendre "compatible" OAuth2.

que webauthn soit implémenté : tu l'exploites dans quel contexte ?

J'ai acheté deux Yubikeys (une Yubikey 4 et une 5 nfc), j'ai un téléphone android avec le lecteur d'empreinte et une tablette sans lecteur d'empreinte mais suffisamment récent pour que ca fonctionne quand même avec le code secret.
Ca me permet donc de faire de l'authentification sur ces deux machines sans utiliser de mot de passe ou de TOTP ou autre. Super pratique pour me connecter.

Mais comme je disais, je ne supporte que ces deux types de device webauthn parce que c'est les seuls que j'ai sous la main. J'aimerais bien supporter toute la chaine de composants webauthn mais j'ai rien pour le tester.

Dans quel contexte exploites tu ton projet ?

Chez moi pour mes autres projets personnels. Je suis un adepte de l'auto-hébergement et outre mes mails et mon nextcloud, je me suis fais un serveur domotique, un serveur de streaming audio et un gestionnaire de mots de passe. Je voulais pas me cogner la couche d'authentification dans chacun de ceux-là indépendamment.

Ps: tu n'as pas un container à nous soumettre pour faire des tests ?

En effet, à la demande générale je vais pousser bientôt une image docker pour ceux qui veulent tester facilement.

Si ca te tente, tu peux aussi installer les paquets Debian/Ubuntu/Alpine que je compile à chaque release.

Je me permets juste de rebondir sur la liste des pays éligibles, dans l'article linuxfr, il est marqué Canada (hors Québec).
Il n'en fallait pas plus pour que mon sentiment d'appartenance binational bondisse. Je suis donc allé chercher la source de cette information mais je ne l'ai pas trouvée…

Sur le site du concours, il est marqué Canada tout court (donc incluant le Québec j'imagine?). Dans le pdf des conditions générales, je ne vois pas de mention du Canada.

Est-ce que cette exclusion a été enlevée entre-temps ou est-ce que l'exclusion du Québec est toujours mentionnée quelque part où je ne l'aurais pas vu? Et si le Québec est toujours exclu du concours, pourquoi esti?!

Ahhh la joie de la réputation de ton domaine/adresse IP…

Je n'ai malheureusement pas de solution pour t'aider dans ton boss de fin, mais avec mon expérience, je ne peux que t'inciter à persévérer.

Je m'auto-héberge depuis pas mal d'années en ayant essayé différents modes: d'abord chez moi via mon FAI, puis avec un VM chez un hébergeur et enfin depuis environ 7 ans avec une Kimsufi (serveur dédié avec IP fixe).

Le souci des spams s'est posé quelques fois mais je ne me souviens pas avoir eu de problèmes bloquants (c'est pour ca que je le fais toujours moi-même).

Concrètement j'ai quand même mis en place tous les machins permettant de dire aux gens que je suis peut-être un bon gars: DKIM, SPF ou autres. Merci à tous les tutos disponibles et accessibles sur internet! Une obligation est d'avoir un accès complet au DNS de ton domaine pour pouvoir y mettre les règles que tu veux justement.

Des fois je dois demander à certains nouveaux destinataires de regarder dans leur dossier spam si mon courriel ne s'y trouve pas, même si j'ai aucun problèmes avec d'autres comptes du même fournisseur.

Après, ca m'arrive encore de temps en temps (une ou deux fois par an) d'avoir gmail (toujours lui) de me renvoyer dans ma face un courriel que j'ai envoyé en me disant "Non, toi t'es pas legit!". Je revérifie alors chez google si mon serveur est soudain devenu méchant, mais non. Ca doit venir de leur coté parce le même type de courriel renvoyé le lendemain ou un peu plus tard passe sans problèmes…

Je vois bien l'intérêt pour faire des fichiers de build pour des petits projets, et en lisant la description, je me demande si ca ne pourrait pas servir à autre chose qu'à compiler des programmes/librairies.

• Alimenter une BD avec des fichiers mais en ne poussant que les fichiers récents
• Redémarrer des services si des fichiers de config ont changé
• Faire des sauvegardes incrémentales assez simples

Je sais que tout ce que je décris existe déjà dans plein de solutions, mais ce que j'aime bien dans smk c'est sa simplicité de mise en place.
Je le garde dans un coin de l'oreille pour plus tard, merci!

Oui mais, au risque de ressembler à un post xkcd
(Il y a toujours un post xkcd pour illustrer son idée. En gros, quand tu penses à un truc, xkcd l'a fait avant toi…)

Je disais donc que j'aimais bien le format journaux dlfp parce que les liens j'y vais pas beaucoup.
À moins que ca m'ait échappé, une excellente alternative pour moi serait d'avoir un flux rss des émissions. Tu me diras, oui mais tu peux t'abonner, je te dirais oui, à défaut je ferai ca, mais je deviens dépendant d'un service tiers (google), alors que le flux rss est plus direct.

Quoi, tu utilises encore des flux rss? C'est tellement 2008!

Oui, parce que je n'ai jamais rien trouvé de plus pratique que rss2mail qui a plusieurs avantages:
- J'ai crontabé rss2mail qui me récupère les flux 3 fois par jour, aux moment où c'est pas trop intrusif: 6h, 12h, 17h
- Avec les courriels, je peux savoir ce que j'ai lu ou pas encore
- Avec les courriels, je peux lire mes flux sur tout support disponible

C'est une approche à base de webservice plutôt que de génération dynamique de page HTML.

C'est plutôt orienté pour faire des applications ou des services web, par opposition aux sites web qui sont efficaces pour afficher de l'information statique aux utilisateurs: site web de la boite, blog, etc.

On va prendre un cas d'utilisation simple: afficher dans une page la liste des courses stockée dans une BD.

Dans ce que tu appelles la "vieille méthode", tu as une page index.php dont le code php exécuté coté serveur va chercher la liste des courses en faisant la requête SQL directement dans la BD, parse le résultat et génère la page HTML correspondante avec ta liste de courses puis l'envoie au client.

Dans la "nouvelle méthode", la liste des courses est accessible sur une URL qui lui est propre et qui renvoie la liste des courses dans un tableau JSON par exemple, par exemple /api/courses/. À coté, tu as par exemple une page HTML statique mais contenant du code javascript, le javascript va appeler l'API /api/courses au chargement de la page, parser le résultat et générer le tableau en modifiant le DOM de la page.
Et dans cette approche, tu peux avoir le webservice hébergé sur un serveur, et la page HTML statique hébergée sur un autre serveur type apache qui ne servira que du statique et sera sous stéroïdes pour servir des simples fichiers plats.

Je vais pas te dire qu'une approche est mieux que l'autre, c'est pas le sujet, et puis ca dépend des cas.

Dans la "vieille méthode", on centralise la gestion des données et son affichage au même endroit, et ca peut limiter tes possibilités d'extension.

Dans l'approche par webservice, on a une distinction plus forte entre les données et l'affichage, ca permet d'accéder aux données via d'autres clients (application mobile, script shell, autre application web, une page PHP, etc.) sans avoir à changer le backend ou rajouter un nouveau backend à chaque fois.
Ca permet aussi de faire évoluer le backend et le front-end de manière distincte en limitant les impacts, voire de rajouter des fonctionnalités au backend dont on sait qu'elles ne seront pas utilisées par tous les clients, mais sans avoir à patcher les clients qui n'utiliseront pas les nouvelles fonctionnalités.

Mais rien n'est absolu et les deux approches sont plus complémentaires qu'autre chose, celui qui dira que PHP va mourir parce que SOAP/REST/Whatever va devenir la norme, je lui réponds que PHP était là bien avant sa naissance et sera encore là bien après sa mort.
De plus, si je mets des guillemets à "ancienne méthode", c'est parce que l'approche par webservice n'a pas réinventé l'eau chaude non plus. Entre une page html statique qui appelle une API en javascript pour afficher un tableau et une page php qui fait un require() pour appeler le module php qui va afficher le même tableau, l'approche n'est pas fondamentalement différente.

L'approche par webservice n'est pas magique non plus, c'est très facile de faire une application web qui sera lente voire inutilisable parce qu'elle fait trop d'appels à trop d'API en même temps par exemple. Ou tomber dans l'enfer des applications mal foutues par design comme expliqué dans un article pointé dans un autre journal.

Une idée me vient à l'esprit en lisant ton journal.

Serait-ce un chouette projet pour la postérité de faire un repository git qui contiendrai tout l'historique du noyau linux disponible avec les métadonnées disponibles (date, qui a commité, commentaire, etc.)?

J'avoue, ca ressemble à un projet de moine archiviste qui n'est peut-être pas utile en soi.

Mais ca peut avoir de l'intérêt pour un éventuel chercheur/journaliste/curieux/insomniaque qui veut faire des statistiques ou des analyses sociales liées aux commits dans le code source du noyau, voire pour une autre raison qui m'échappe parce que liée à un domaine qui n'existe pas encore ou que je ne connais pas…

Je me fourvoie?

J'ai la même approche que toi sur mes projets libres.

Quand je recois une demande de fonctionnalité sans rien d'autre derrière.
Si c'est facile à faire et justifié, je le fais et puis basta.
Si c'est moins facile, je le mets dans ma todo-list et je le ferai quand j'aurai le temps/l'envie.
Si je veux pas le faire, je dis non et j'explique pourquoi.
J'implique le demandeur pour m'assurer que la nouvelle version répond bien à sa demande.

Quand je recois un patch/une pull request, je regarde ce que ca apporte, et comment c'est codé.
Si ca ne sert à rien, je dis non merci et je dis pourquoi.
Si c'est un patch du genre if (mon_exception_rien_qu_a_moi) { faire_un_truc_hyper_spécifique(); }, je dis non merci également et j'essaie de trouver une solution pour résoudre le problème initial tout en évitant de modifier mon code de cette manière.
Si c'est pas propre ou doit être amélioré, je demande des corrections.
Enfin, si c'est fusionnable et correspond à mes critères de qualité, je m'assure de bien comprendre tout le nouveau code parce que je pars justement du principe que le contributeur va disparaître après, donc je veux maîtriser la contribution.

Je n'ai aucun état d'âme à refuser et fermer une pull request quand je ne la veux pas ou que je n'arrive pas à m'entendre avec la personne qui propose. J'argumente toujours avant et après ma décision, mais je ne souhaite pas faire de compromis là dessus, car au final, c'est moi qui maintient et fait évoluer le projet dans son ensemble.

Cela dit, mes projets sont suffisamment petits pour que je puisse les maintenir tout seul, donc je me permets de faire comme ca.

Un plug USB audio, ca coûte trois fois rien et ca fait entrée et sortie audio

Je croyais que l'auto-hébergement c'est quand tu avais une ferme de serveurs dans ta voiture qui te permettaient de fournir des services nomades et mobiles aux habitants de ton quartier dans un contexte de synergie agile Web 2.0 lié aux paradigmes de connectivité.

Le gros problème que je voyais avec cette méthode est que tu ne peux scaler ton service que horizontalement (en roulant). Néanmoins, la prochaine génération d'auto-hébergement initiée par SpaceX/Tesla permettra de scaler verticalement (vers Mars).

Au temps pour moi.

Par curiosité, j'ai fait un petit programme qui utilise libav pour redimensionner des images:
https://gist.github.com/babelouest/30e29d45dfba6173f0e74d2c848dc60f

J'ai pas à ma disposition des machines pour tester pleinement mais dans la plupart des cas les résultats sont du même ordre, exemple pour une image jpg qui fait 500*497:

$ time ./resize-libav file.jpg
real    0m1,038s
user    0m0,380s
sys     0m0,040s
$ time convert file.jpg -thumbnail 150x150 out-imgck.jpg
real    0m0,402s
user    0m0,360s
sys     0m0,080s