Mais par contre cela peut (et doit) etre utilise pour modifier les binaires et propager des trucs pas propres non?
D'un point de vue sécurité, dés que tu peux modifier le code exécutable d'un process, tu as le même niveau d'accès que lui. La méthode décrite ne change rien au niveau des barrières. Si tu avais le droit de modifier le code, ça te permet de le faire proprement. Si tu n'avais pas le droit, ça ne te facilitera pas la vie.
chiffrement/déchiffrement côté serveur. C'est une limitation de sécurité que je trouve hallucinante en 2017
Je ne connais pas NextCloud, mais je vois quelques considérations d'ordre générale sur le fait que le chiffrement côté client ne soit pas implémenté sur toutes les applications en 2017 :
- Ça complique le dédoublonnage de fichiers à des fins d'économie d'espace disque (le serveur ne peut pas savoir que 2 utilisateurs ont uploadé la même photo)
- Ça empêche les recherches côté serveur (une recherche de tous les fichiers contenant un mot donné devient concrétement impossible)
- Si les métadonnées sont chiffrées, il devient aussi impossible de trier côté serveur pour par exemple afficher les 20 commentaires les plus récents (il faut rapatrier toutes les données côté client pour les trier, ce qui a un impact sur les performances)
- De manière générale, toute opération en masse qu'on aurait tendance à effectuer côté serveur devient impossible (générer des miniatures des photos, recherche de contacts en doublons, …)
- Impossible d'être compatible avec des protocoles standards (diffusion de fichiers multimédia par exemple) qui n'ont pas prévu cette fonctionnalité.
Pour répondre à certaines de ces problématiques, on aurait besoin de chiffrement totalement homomorpe sacrément performant. On ne sait pas faire aujourd'hui. Du coup, il faut choisir entre le chiffrement côté client ou les fonctionnalités.
A noter que les 2 options ne sont pas exclusives. Il se pourrait très bien qu'il y ait un module de gestion de photos avec du chiffrement côté serveur et un module de gestion de mots de passe avec du chiffrement côté client.
Par contre, dans un contexte pro l'avantage est certain ; l'administrateur peut avoir une clé de déchiffrement de secours qui permet de déchiffrer les fichiers de tous les utilisateurs si besoin est
Si le besoin c'est que l'administrateur soit capable de déchiffrer les fichiers car un utilisateur a perdu son mot de passe, c'est compatible avec le chiffrement côté client. Il suffirait que les clefs de chiffrement des utilisateurs soit chiffrées avec une clef publique de l'administrateur et stockées sur le serveur. Ça nécessite cependant de faire confiance aux utilisateurs (pour pas qu'ils envoient une clef bidon, ce que le serveur serait incapable de détecter). Ça ne répondrait donc pas à un besoin de l'administrateur de vérifier par exemple que le contenu des fichiers uploadés respecte certaines règles (et encore il pourrait supprimer a posteriori les fichiers qu'il ne peut pas lire).
Je vois bien que ça marche sur l'exemple donné plus haut, mais ce n'est pas du tout évident pour moi que l'arrondi bancaire donne cette garantie. Tu peux détailler stp ?
N'étant pas convaincu de la garantie, j'ai essayé de comprendre l'intérêt de l'arrondi bancaire par rapport à l'arrondi au plus proche (celui où quand la partie à arrondir vaut exactement 5, on arrondit au supérieur).
Intuitivement, l'arrondi au plus proche est meilleur car les plages d'arrondis font exactement la même taille pour tous les nombres. Par exemple si on arrondit à l'entier (pour simplifier, ça ne change rien si on arrondit à 2 décimales) :
- La plage [0.5- 1.5[ s'arrondit à 1
- La plage [1.5- 2.5[ s'arrondit à 2
- La plage [2.5- 3.5[ s'arrondit à 3
- La plage [3.5- 4.5[ s'arrondit à 4
- …
Alors qu'avec l'arrondi bancaire, on a un biais qui favorise les nombres pairs :
- La plage ]0.5- 1.5[ s'arrondit à 1
- La plage [1.5- 2.5] s'arrondit à 2
- La plage ]2.5- 3.5[ s'arrondit à 3
- La plage [3.5- 4.5] s'arrondit à 4
- …
Cependant vu que c'est utilisé en plein d'endroits par plein de gens plus compétents que moi, il y a sûrement une raison mais je ne l'ai pas trouvée. Wikipedia évoque un biais corrigé par l'arrondi bancaire, mais sans expliquer lequel.
Sur le web, on peut lire que le problème de l'arrondi au plus proche c'est que quand la partie à arrondir vaut exactement 5, on arrondit toujours au supérieur. Mais je ne vois pas en quoi c'est un problème. Pour moi, c'est une nécessité si on veut une bonne répartition des arrondis.
Et sont remplacés par un problème qui est probablement encore plus fréquent (quand a et b ont la même valeur, l'algorithme met les 2 valeurs à 0).
En python, la bonne manière de faire est celle de François Guerin.
Il faut arrêter de se dire que plus un code repose sur une technique complexe, plus il est stylé/beau. C'est faux. Pas de bénéfice et des inconvénients par rapport à la méthode standard, ça veut dire que c'est un mauvais code.
le 1 an ca ressemble au stagiaire/technicien qui paye avec ses sous le renouvellement pour "aider", comme a la fin du mois il sait que la compta ne va pas valider ses frais "car il manque le numéro de tva intracommunautaire", une impression d'ecran n'est pas une facture etc … . a propos ta demande de congé est refusé, le chef prend les même date que toi.
Et encore, le stagiaire/technicien a eu de la chance que le renouvellement ne se fasse pas par payment CB protégé par 3D Secure
En 2017, il faut inverser le raisonnement. On ne devrait plus avoir à justifier l'usage du HTTPS qui devrait être le choix par défaut. Au contraire, c'est quand on propose du HTTP qu'il faut le justifier.
L'apport de https semble assez faible. Les paquets Debian étant signés gpg par leur mainteneurs, la préservation de leur intégrité est indépendante du protocole comme du pigeon par lequel ils ont été acheminés.
HTTPS propose plus que l'intégrité de la réponse du serveur. Il y a la confidentialité comme abordé dans un autre commentaire, mais aussi l'intégrité de la requête du client. Est-ce que par exemple, un attaquant ne pourrait pas forcer un downgrade de la version d'un paquet ? Au lieu de télécharger la version N sur un serveur de Debian, le client se retrouve à télécharger la version N-1 qui contient des failles de sécurité sur le serveur de l'attaquant. Cette version N-1 ayant été "légitime" en son temps, elle aussi est signée.
Il y a peut-être des mécanismes dans Debian qui protège de ça, mais clairement la signature GPG à elle toute seule n'est pas suffisante pour se dire que le HTTP c'est sécurisé.
Dans l'exemple donné sur SO, tu as 2 parties :
1. La première consiste à écrire du code pour convertir ta liste. Ce code est à écrire en C# et à compiler pour obtenir un fichier DLL (y compris sous linux)
1. La deuxième consiste à utiliser cette DLL en y faisant référence. L'auteur de la réponse a supposé qu'elle était présente dans C:\Debug\ListInConstr
Si j'ai bien compris, tu n'as appliqué que la 2ème partie, c'est pour ça que ça ne marche pas. Par contre, j'avoue ne pas comprendre non plus à quoi sert la 1ère partie.
Vous savez comment convertir une liste Python vide en .NET ?
Si la liste que tu veux passer est vide, c'est peut-être plus simple de créer directement une List .NET vide que de convertir une liste python.
Je ne connais rien à PythonNet mais d'après le readme ça pourrait donner quelque chose comme :
un certificat délivré par eux a la même utilité et offre la même sécurité qu'un certificat délivré par n'importe quelle autre autorité (tant que vous générez votre CSR de votre côté)
Si on parle de la sécurité de la clef privée : oui c'est la même qu'avec une autre CA. Si on parle de la sécurité du service qui utilise le certificat : non la sécurité est plus faible qu'avec une autre CA. Il y a un risque non négligeable que du jour au lendemain WoSign ne soit plus reconnue comme CA de confiance :
if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots.
Il y a donc un risque que le service devienne indisponible du jour au lendemain.
De plus, est-ce que demander des certificats à une CA en laquelle on ne peut pas avoir confiance est vraiment une bonne idée ? Est-ce que ça ne donne pas du poids à cette CA pour dire "si vous nous retirez de la liste des CA reconnues, ça va causer beaucoup de problèmes. Donc ne le faites pas / donnez nous un plus long sursis !" ?
Oui, ben je sais pas. J'utilise le debugger inclus dans Firefox (touche F12) pour voir les headers, dans l'onglet network. Il me donnait que les headers copiés plus haut, mais je me rends compte que si je fais "edit and resend", la nouvelle requête a plus de headers, avec notamment le Content-type. C'est étrange. Je sais pas trop comment ce debugger marche (et si même c'est là le problème).
Ok j'ai compris, ce n'est pas le debugger le problème. Tu avais pris ta trace alors que la page était en cache. Du coup Firefox a juste demandé au serveur si la page avait changé. Le serveur a répondu 304 (not modified) : la page n'a pas changé, tu peux afficher celle en cache. Dans ce cas, il n'a pas besoin de redonner l'encoding.
Si tu forces une réactualisation de la page (ctrl+F5), tu verras bien passer les bons en-têtes.
T'utilises quoi pour voir les headers?
Sous linux, le debugger inclus aussi. Sous Windows, j'utilise http://www.telerik.com/fiddler. Sapuçaypalibre mais c'est une boîte à outils très pratique pour le trafic HTTP / HTTPS. C'est notamment avec ça que j'ai modifié la réponse du serveur pour retirer l'en-tête et la balise meta pour faire mes tests.
J'ai vérifié entre ma connexion du boulot (FF 42 / Windows), mon ADSL perso (FF 42 / Linux) et http://headers.cloxy.net/ : c'est la même chose. Tu ne serais pas derrière un proxy ?
Concernant la balise meta, j'ai bien du windows-1252. Je l'avais retirée dans mes tests pour forcer Firefox à faire une détection d'encodage.
Notez pour l'anecdote, et c'est assez marrant, que Firefox rend mal la page même qui explique l'algo de leur ancienne méthode de détection (on voit des caractères cassés, typique d'un encodage raté). En fait, Mozilla n'utilise plus cet algo et a remplacé par une détection par langue.
Or un simple test avec uchardet montre que ce dernier détecte correctement le codage comme "WINDOWS-1252" (bon c'était probablement de l'ISO-8859-1, mais Windows-1252 est un superset donc acceptable). Comme quoi, je pense que c'était une erreur de la part de Mozilla d'abandonner cet algo.
Firefox utilise UTF-8 pour décoder la page car c'est que le serveur indique d'utiliser dans les en-têtes HTTP.
Si on supprime l'en-tête fautif et qu'on supprime la balise meta embarquée dans la page, Firefox décode correctement la page (mais je ne saurais pas dire si c'est grâce à l'algorithme de détection de la langue ou grâce à un autre mécanisme).
L'erreur ici se situe donc dans la configuration du serveur, non dans l'algorithme de détection de la langue utilisé par Firefox.
Dans le chapitre Estimation des ressources requises, qu'est-ce qui permet de dire que est une constante ? Pourquoi ça ne serait pas une fonction de (n,p) ?
Intuitivement, plus il y a de fils (n), plus il est difficile de "deviner" le bon fils à explorer. De même, plus il y a de coups à jouer (p), moins la fonction de prédiction est fiable. Ça signifierait que dépend de n et p.
J'ai voulu faire un test de paperwork, je n'ai pas réussi à scanner de documents. Quand je clique sur le bouton "scanner", j'arrive sur la fenêtre de réglage. Mon scanner (Samsung M2070) est bien affiché dans le champ "Périphérique". Le champ source est vide et la liste déroulante est désactivée. Le bouton "Scanner" est désactivé lui aussi.
Une idée du problème ou de ce que j'ai raté ?
Pour info, le scanner fonctionne avec Simple Scan (Ubuntu 14.04).
[^] # Re: Patch à la volée
Posté par NicolasP . En réponse au journal Il y a de grand malade sur Terre.... Évalué à 2.
D'un point de vue sécurité, dés que tu peux modifier le code exécutable d'un process, tu as le même niveau d'accès que lui. La méthode décrite ne change rien au niveau des barrières. Si tu avais le droit de modifier le code, ça te permet de le faire proprement. Si tu n'avais pas le droit, ça ne te facilitera pas la vie.
# Patch à la volée
Posté par NicolasP . En réponse au journal Il y a de grand malade sur Terre.... Évalué à 7.
Chez MS, ils font ça tellement souvent qu'ils ont prévu de quoi patcher leur code à la volée.
[^] # Re: Autres retour d'expérience : 2 utilisateurs, synchro calendrier et contacts
Posté par NicolasP . En réponse au journal Retour d'expérience Nextcloud. Évalué à 1.
Je ne connais pas NextCloud, mais je vois quelques considérations d'ordre générale sur le fait que le chiffrement côté client ne soit pas implémenté sur toutes les applications en 2017 :
- Ça complique le dédoublonnage de fichiers à des fins d'économie d'espace disque (le serveur ne peut pas savoir que 2 utilisateurs ont uploadé la même photo)
- Ça empêche les recherches côté serveur (une recherche de tous les fichiers contenant un mot donné devient concrétement impossible)
- Si les métadonnées sont chiffrées, il devient aussi impossible de trier côté serveur pour par exemple afficher les 20 commentaires les plus récents (il faut rapatrier toutes les données côté client pour les trier, ce qui a un impact sur les performances)
- De manière générale, toute opération en masse qu'on aurait tendance à effectuer côté serveur devient impossible (générer des miniatures des photos, recherche de contacts en doublons, …)
- Impossible d'être compatible avec des protocoles standards (diffusion de fichiers multimédia par exemple) qui n'ont pas prévu cette fonctionnalité.
Pour répondre à certaines de ces problématiques, on aurait besoin de chiffrement totalement homomorpe sacrément performant. On ne sait pas faire aujourd'hui. Du coup, il faut choisir entre le chiffrement côté client ou les fonctionnalités.
A noter que les 2 options ne sont pas exclusives. Il se pourrait très bien qu'il y ait un module de gestion de photos avec du chiffrement côté serveur et un module de gestion de mots de passe avec du chiffrement côté client.
Si le besoin c'est que l'administrateur soit capable de déchiffrer les fichiers car un utilisateur a perdu son mot de passe, c'est compatible avec le chiffrement côté client. Il suffirait que les clefs de chiffrement des utilisateurs soit chiffrées avec une clef publique de l'administrateur et stockées sur le serveur. Ça nécessite cependant de faire confiance aux utilisateurs (pour pas qu'ils envoient une clef bidon, ce que le serveur serait incapable de détecter). Ça ne répondrait donc pas à un besoin de l'administrateur de vérifier par exemple que le contenu des fichiers uploadés respecte certaines règles (et encore il pourrait supprimer a posteriori les fichiers qu'il ne peut pas lire).
[^] # Re: juste chiffrer le home?
Posté par NicolasP . En réponse au message Equivalent bitlocker en mode transparent. Évalué à 1.
Je ne suis pas sûr de comprendre les implications. En gros ma clef wifi ne serait pas protégée, c'est ça ?
Ça voudrait dire qu'en cas de perte du PC, il faudrait que je modifie la clef. Si c'est juste ça, ça reste acceptable pour moi.
[^] # Re: juste chiffrer le home?
Posté par NicolasP . En réponse au message Equivalent bitlocker en mode transparent. Évalué à 2.
Parce que je n'y ai pas pensé :) Effectivement je viens de regarder ça semble correspondre à mon besoin et c'est simple à mettre en place.
Merci !
[^] # Re: Exemple simple
Posté par NicolasP . En réponse au journal SQL Decimal vs Double. Évalué à -1.
Merci pour cette explication.
[^] # Re: Exemple simple
Posté par NicolasP . En réponse au journal SQL Decimal vs Double. Évalué à 2.
Je vois bien que ça marche sur l'exemple donné plus haut, mais ce n'est pas du tout évident pour moi que l'arrondi bancaire donne cette garantie. Tu peux détailler stp ?
N'étant pas convaincu de la garantie, j'ai essayé de comprendre l'intérêt de l'arrondi bancaire par rapport à l'arrondi au plus proche (celui où quand la partie à arrondir vaut exactement 5, on arrondit au supérieur).
Intuitivement, l'arrondi au plus proche est meilleur car les plages d'arrondis font exactement la même taille pour tous les nombres. Par exemple si on arrondit à l'entier (pour simplifier, ça ne change rien si on arrondit à 2 décimales) :
- La plage [0.5- 1.5[ s'arrondit à 1
- La plage [1.5- 2.5[ s'arrondit à 2
- La plage [2.5- 3.5[ s'arrondit à 3
- La plage [3.5- 4.5[ s'arrondit à 4
- …
Alors qu'avec l'arrondi bancaire, on a un biais qui favorise les nombres pairs :
- La plage ]0.5- 1.5[ s'arrondit à 1
- La plage [1.5- 2.5] s'arrondit à 2
- La plage ]2.5- 3.5[ s'arrondit à 3
- La plage [3.5- 4.5] s'arrondit à 4
- …
Cependant vu que c'est utilisé en plein d'endroits par plein de gens plus compétents que moi, il y a sûrement une raison mais je ne l'ai pas trouvée.
Wikipedia évoque un biais corrigé par l'arrondi bancaire, mais sans expliquer lequel.
Sur le web, on peut lire que le problème de l'arrondi au plus proche c'est que quand la partie à arrondir vaut exactement 5, on arrondit toujours au supérieur. Mais je ne vois pas en quoi c'est un problème. Pour moi, c'est une nécessité si on veut une bonne répartition des arrondis.
Quelqu'un peut m'éclairer ?
[^] # Re: permutations
Posté par NicolasP . En réponse au message problème sur Codecademy réaffecter deux valeurs. Évalué à 3.
Et sont remplacés par un problème qui est probablement encore plus fréquent (quand a et b ont la même valeur, l'algorithme met les 2 valeurs à 0).
En python, la bonne manière de faire est celle de François Guerin.
Il faut arrêter de se dire que plus un code repose sur une technique complexe, plus il est stylé/beau. C'est faux. Pas de bénéfice et des inconvénients par rapport à la méthode standard, ça veut dire que c'est un mauvais code.
[^] # Re: Des branquignoles
Posté par NicolasP . En réponse au journal Panne du système 3D Secure… pour cause de non renouvellement de nom de domaine. Évalué à 10.
Et encore, le stagiaire/technicien a eu de la chance que le renouvellement ne se fasse pas par payment CB protégé par 3D Secure
[^] # Re: HTTP remplacent ?
Posté par NicolasP . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 10.
En 2017, il faut inverser le raisonnement. On ne devrait plus avoir à justifier l'usage du HTTPS qui devrait être le choix par défaut. Au contraire, c'est quand on propose du HTTP qu'il faut le justifier.
HTTPS propose plus que l'intégrité de la réponse du serveur. Il y a la confidentialité comme abordé dans un autre commentaire, mais aussi l'intégrité de la requête du client. Est-ce que par exemple, un attaquant ne pourrait pas forcer un downgrade de la version d'un paquet ? Au lieu de télécharger la version N sur un serveur de Debian, le client se retrouve à télécharger la version N-1 qui contient des failles de sécurité sur le serveur de l'attaquant. Cette version N-1 ayant été "légitime" en son temps, elle aussi est signée.
Il y a peut-être des mécanismes dans Debian qui protège de ça, mais clairement la signature GPG à elle toute seule n'est pas suffisante pour se dire que le HTTP c'est sécurisé.
[^] # Re: Créer une liste en .NET depuis Python ?
Posté par NicolasP . En réponse au message Ou trouver de l'aide pour une question Python / Matlab/ .NET ?. Évalué à 5.
Dans l'exemple donné sur SO, tu as 2 parties :
1. La première consiste à écrire du code pour convertir ta liste. Ce code est à écrire en C# et à compiler pour obtenir un fichier DLL (y compris sous linux)
1. La deuxième consiste à utiliser cette DLL en y faisant référence. L'auteur de la réponse a supposé qu'elle était présente dans C:\Debug\ListInConstr
Si j'ai bien compris, tu n'as appliqué que la 2ème partie, c'est pour ça que ça ne marche pas. Par contre, j'avoue ne pas comprendre non plus à quoi sert la 1ère partie.
Si la liste que tu veux passer est vide, c'est peut-être plus simple de créer directement une List .NET vide que de convertir une liste python.
Je ne connais rien à PythonNet mais d'après le readme ça pourrait donner quelque chose comme :
# WoSign VS autres autorités
Posté par NicolasP . En réponse au journal Qui traite des autorités SSL WoSign, Startcom et du peu de professionnalisme qui a causé leur perte. Évalué à 3.
Si on parle de la sécurité de la clef privée : oui c'est la même qu'avec une autre CA. Si on parle de la sécurité du service qui utilise le certificat : non la sécurité est plus faible qu'avec une autre CA. Il y a un risque non négligeable que du jour au lendemain WoSign ne soit plus reconnue comme CA de confiance :
Il y a donc un risque que le service devienne indisponible du jour au lendemain.
De plus, est-ce que demander des certificats à une CA en laquelle on ne peut pas avoir confiance est vraiment une bonne idée ? Est-ce que ça ne donne pas du poids à cette CA pour dire "si vous nous retirez de la liste des CA reconnues, ça va causer beaucoup de problèmes. Donc ne le faites pas / donnez nous un plus long sursis !" ?
[^] # Re: exemple
Posté par NicolasP . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 2.
Ok j'ai compris, ce n'est pas le debugger le problème. Tu avais pris ta trace alors que la page était en cache. Du coup Firefox a juste demandé au serveur si la page avait changé. Le serveur a répondu 304 (not modified) : la page n'a pas changé, tu peux afficher celle en cache. Dans ce cas, il n'a pas besoin de redonner l'encoding.
Si tu forces une réactualisation de la page (ctrl+F5), tu verras bien passer les bons en-têtes.
Sous linux, le debugger inclus aussi. Sous Windows, j'utilise http://www.telerik.com/fiddler. Sapuçaypalibre mais c'est une boîte à outils très pratique pour le trafic HTTP / HTTPS. C'est notamment avec ça que j'ai modifié la réponse du serveur pour retirer l'en-tête et la balise meta pour faire mes tests.
[^] # Re: exemple
Posté par NicolasP . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 1. Dernière modification le 26 novembre 2015 à 20:28.
Salut,
J'ai ça en en-têtes :
J'ai vérifié entre ma connexion du boulot (FF 42 / Windows), mon ADSL perso (FF 42 / Linux) et http://headers.cloxy.net/ : c'est la même chose. Tu ne serais pas derrière un proxy ?
Concernant la balise meta, j'ai bien du windows-1252. Je l'avais retirée dans mes tests pour forcer Firefox à faire une détection d'encodage.
[^] # Re: exemple
Posté par NicolasP . En réponse au journal toutf8: autodétecter et convertir de n'importe quel encodage de caractères vers UTF8. Évalué à 2.
Firefox utilise UTF-8 pour décoder la page car c'est que le serveur indique d'utiliser dans les en-têtes HTTP.
Si on supprime l'en-tête fautif et qu'on supprime la balise meta embarquée dans la page, Firefox décode correctement la page (mais je ne saurais pas dire si c'est grâce à l'algorithme de détection de la langue ou grâce à un autre mécanisme).
L'erreur ici se situe donc dans la configuration du serveur, non dans l'algorithme de détection de la langue utilisé par Firefox.
# Alpha constant ?
Posté par NicolasP . En réponse au journal Résolution du jeu d'échecs : patience, ça arrive.... Évalué à 2.
Dans le chapitre Estimation des ressources requises, qu'est-ce qui permet de dire que
est une constante ? Pourquoi ça ne serait pas une fonction de (n,p) ? 
dépend de n et p.
Intuitivement, plus il y a de fils (n), plus il est difficile de "deviner" le bon fils à explorer. De même, plus il y a de coups à jouer (p), moins la fonction de prédiction est fiable. Ça signifierait que
# Impossible de scanner
Posté par NicolasP . En réponse à la dépêche Sortie de Paperwork 0.2. Évalué à 1.
Salut,
J'ai voulu faire un test de paperwork, je n'ai pas réussi à scanner de documents. Quand je clique sur le bouton "scanner", j'arrive sur la fenêtre de réglage. Mon scanner (Samsung M2070) est bien affiché dans le champ "Périphérique". Le champ source est vide et la liste déroulante est désactivée. Le bouton "Scanner" est désactivé lui aussi.
Une idée du problème ou de ce que j'ai raté ?
Pour info, le scanner fonctionne avec Simple Scan (Ubuntu 14.04).