Le fait que l'on puisse se poser des questions sur la liberté de firefox n'est toujours pas ce qui empêche celui-ci d'être open-source (enfin, à partir de la version 3, cf talkback)...
open-source!=libre ... je pense notamment à des cartes d'acquis SDI (un peu le HDMI pro, pour les studios de montage), dont certaines (je n'arrive pas à retrouver le lien... il me semble que c'était une boîte indienne qui les fabriquait, pour gagner des sioux - autant la faire tout de suite) fonctionnent avec des drivers open-source (pour pouvoir les recompiler pour le kernel de son choix), mais absolument pas libres (seulement pour les clients, et absolument pas redistribuables).
Bon, après, il y a des trucs qui m'ont fait m'en éloigner : entre autres le fait que les versions Linux s'intègrent très pauvrement dans les environnements libres (massacre total des thèmes GTK qui prennent des apparences totalement fantasques [oui, je sais, ce n'est pas vraiment du GTK - c'est encore pire : c'est un truc à skins] c'est la seule application sur mon X.org qui ne tilte pas que je suis en 133 dpi - génial, faut que je me mette à 10cm de l'écran, intègre ses propres icônes alors que je préfèrerais avoir le même thème que dans les autres applis, ... plein de choses comme ça), alors que j'ai l'impression que ça se passe beaucoup mieux (dans une certaine mesure... je pense particulièrement au thème par défaut de la version 2, avec ses onglets, qui, sous un thème GTK à fond noir, présentent une apparence en dégradé "noir vers blanc", typiquement à-la-vista) pour la version destinée aux os redmondiens... c'est déjà assez représentatif d'une certaine idée que j'ai de ce que ce à quoi firefox est destiné.
Bon, ça, plus ce qu'il bouffe en CPU et en RAM, les plantages à l'enchaîne, ainsi que certains traits de la politique de la mofoco, ça fait qu'il y a un an, j'ai décidé que firefox n'était pas pour moi (pas de quoi en faire un fromage), et je suis passé à Konqueror (et par la même occasion, KDE, en lieu et place de FVWM)... et je ne le regrette en rien (je garde juste firefox iceweasel sous la main pour lire les pages avec du flash, une fois tous les quatre matins)...
... par contre, il faudrait sûrement une interface PKCS#11 pour en tirer partie sous une majorité de logiciels où ça pourrait être utile...
Je ne sais d'ailleurs pas si les puces TPM et cie sont déjà supportées sous Linux...
Par ailleurs, je ne trouve pas très pratique que les clés doivent être laissées dans une carte mère, pour ce qui est des clés SSH, des clés de signature, et cie : je trouve plus sécurisante l'idée de trimballer sur moi (ou de cacher physiquement) le "quelque chose que je possède", plutôt que de le laisser sur la machine ; parce que, niveau "quelque chose que je possède", une machine, c'est lourd, et plus difficile à garder du coin de l'oeil que quelque chose que je garderais la plupart du temps près de mes parties intimes, quand même...
... scénario type : mettons que je me serve d'une smartcard pour déchiffrer mon / ainsi que me logger, et de l'espace sur la clé USB pour mettre le /boot (histoire qu'il ne se fasse pas corrompre pour chopper le PIN). Je pars boire un café ou je vais satisfaire quelque autre besoin naturel (ou pas) : si c'est une smartcard que l'on peut dé-brancher, pas de souci, je verrouille ma session (en faisant en sorte d'avoir besoin de la smartcard pour la déverouiller) et j'emporte le token - il reste quelque chose à posséder et à connaître qui n'est absolument pas sur place... mettons que je me serve de la puce TPM de la mobo pour stocker les mêmes clés : ce qu'il faut protéger et ce qu'il faut posséder sont alors la même chose - ne reste vraiment qu'à connaître le PIN pour se servir de la machine... l'authentification forte, elle en devient borderline (même si la clé ne peut théoriquement pas être extraite... ce sur quoi j'ai des doutes, aussi bien pour les smartcards externe que pour TPM, mais qui m'inquiète beaucoup plus pour le dernier, vu que cacher la machine pour que n'importe quel grouillot n'en vienne pas à la posséder, ce n'est pas ce qu'il y a de plus simple...)...
Bon, après, ça dépend des usages... là où je verrais plus l'intérêt d'utiliser ces puces TPM, ce serait pour des choses de l'ordre des clés identifiant la machine dans SSH, d'avantage que pour les clés permettant de s'y connecter.
Alors, niveau certification, je n'en sais rien : comme je l'ai dit, je voudrais d'abord jouer avec... quant à me protéger, de rien d'autre que de ma paranoïa : je me prophylaxise joyeusement, c'est tout.
... mais en effet, le principe d'inviolabilité, si on n'a pas les specs complètes des cartes (et encore, faudrait aussi être sûr que le produit correspond aux spécifications), rien ne nous garantit qu'il n'est pas rendu caduque par une backdoor du constructeur ou des hacks de spécialistes, voire les Chinois du FBI.
J'ai juste essayé de trouver de quoi gérer du RSA 2048 bits sous linux, sans middleware proprio, et à part les Cryptoflex, je n'ai rien vu... idéalement, j'aurais aimé trouver quelque chose qui gère aussi l'AES (même si bon... apparemment, les outils sous Linux ne sont pas trop faits pour ça)...
M'enfin, déjà, le fait d'avoir une smartcard pour stocker mes clés privées (et plein d'autres trucs, avec le lecteur combiné à de la flash, et aussi la possibilité de stocker autre chose que des clés privées, en tant qu'objets privés accessibles via un PIN), ça me forcera toujours à y faire plus attention (artefact précieux, perte définitive des clés privées si on fait trop le con, nombre d'écritures probablement limité, nécessité de commander outre-Atlantique, ...), tout en augmentant le degré de sécurité par rapport à des clés à pasphrase qui peuvent trop facilement traîner n'importe où, voire qui peuvent même avoir été générées sur une Debian.
Tiens, c'est rigolo : elles gèrent les courbes elliptiques... et aussi AES. Par contre, RSA seulement en 1024 bits...
Vu que RSA est l'essentiel de ce que j'utilise, et que le peu de support pour les smartcards que l'on a semble se concentrer sur cet algo, je pense que je vais aller au plus simple en restant sur les Cryptoflex.
C'est vrai que j'ai un peu retranscrit mes trips du moment pèle-mêle, aussi ;)
Disons qu'à la base j'aurais plutôt voulu attendre de recevoir les smartcards et d'avoir joué avec elles avant de faire un journal... puis, voulant réagir au message du forum, et quand même faire partager ce que j'avais pu comprendre de la problématique, j'ai un peu tout enchaîné d'un trait.
Sinon, si ce que j'ai évoqué, sur le fait que les smartcards sont en fait des ordinateurs crypto qui gèrent des clés (notamment RSA) et la manière de s'en servir, pour ne jamais les exposer et faire de la smartcard quelque chose que l'on possède, il y a deux bons articles sur UnixGarden [1] [2], originellement parus dans Linux Magazine qui donnent un bon aperçu de ce dont il s'agit... mea culpa de ne pas les avoir mis en lien, pour débroussailler le sujet.
Et je prends bonne note pour les sections : à ce stade de flood, mettre un peu plus de retours à la ligne, pour vaguement tenter de séparer, ne rend ostensiblement pas les choses assez claires...
l'interface est tellement riche qu'elle te parasite l'utilisation basique que tu en as
Eh, oui... je n'ai ostensiblement pas tout à fait la même utilisation du player que toi... de temps en temps, j'aime bien voir la playlist, la laisser affichée (j'aime aficher plein de trucs en même temps... je suis d'ailleurs un multi-écran fanboy, à tendance bordélique éparpilleur, bien triste de voir la régression du multi-cartes dans X.org 7.3)... sans pour autant qu'elle me bouffe autant de place...
Après, certes, il y a d'autres trucs que je n'aime pas dans Amarok : déjà, la gestion des tags, pour laquelle j'utilise aussi EasyTag (qui me sert à avoir des tags propres pour MythMusic et le SlimCenter... et à renommer les fichiers en fonction des tags pour qu'ils soient mieux rangés pour quand je les utilise avec un lecteur "classique"... et je trouve EasyTag vraiment efficace dans ce job, en tout cas plus qu'Amarok)...
... ou la gestion des covers... je préfère les scanner, voire les télécharger moi-même (enfin, surtout les scanner... les jpg d'Amazon, en 1080p, à 2,5m d'un 42", ça rend moyen, quand même), plutôt que de les voir balancer dans un répertoire qui n'a rien à voir avec celui où est stockée la musique, et dont il va falloir les exporter (ou les importer, pour chaque machine où j'aurais Amarok)... ne me servant pas que d'un player en clickodrome classique, mais aussi d'une interface TV permanente, et pouvant afficher les covers dans l'interface web du SlimCenter, le plus simple pour moi est encore d'avoir un cover.jpg ou assimilé dans le répertoire de l'album...
... tous ces trucs dont je n'ai pas besoin une demi-seconde dans un simple player, et qu'il intègre, ça témoigne d'une démarche visant à intégrer moult fonctionnalités dans un client lourd (pas forcément au niveau des perfs, n'ayant pas des masses à me plaindre du matos que j'ai pour ça, mais rien qu'au niveau de l'interface, en ce qui me concerne)...
Bon, très bien : je ne lapide pas, je critique - ce n'est pas ce que je recherche, et j'ai du mal à m'y faire, même si je comprends que ce soit parfait pour certains (l'un de mes potes est un fan inconditionnel d'Amarok depuis qu'il est sur la banquise... et lorsqu'il était redmondien, son winamp remplissait tout l'écran, avec je ne sais combien de plugins... il en faut pour tous les goûts... perso, j'ai toujours aimé les petits players)...
... à la limite, un truc comme Amarok qui lirait les videos, et qui serait accompagné d'un serveur en backend pour les tags sur les éléments videos (une espèce de MythTV-like, mais en fenêtré), ça pourrait m'intéresser... mais un truc aussi versatile juste pour la musique (c'est plutôt pour les videos que je veux plus de réglages... et pour ça, j'ai Kaffeine et SMPlayer), alors que j'en ai une utilisation très basique (enchaîne une playlist, la modifie un poil et zou), non, c'est trop pour moi... pas la peine de le prendre pour toi, hein : c'est juste une question de goûts...
Mouais... Amarok, c'est déjà une mini-fenêtre de lecteur style XMMS dont je n'arrive pas à trouver l'utilité (heureusement qu'on peut la virer... mais je ne comprends pas pourquoi ça a été implémenté, si c'est pour que ça le soit sans liste de lecture minimale), puisqu'elle est en sus de la fenêtre à tout faire que tu décris... notamment à faire la playlist, que je dois pour ainsi dire mettre en plein écran pour la trouver "agréable" (ne serait-ce que l'affichage de la liste à écouter est, je trouve, désagréable si on modifie la taille de la fenêtre, ce qui vient foutre le box dans la largeur des colonnes)...
... bon, ce n'est pas que je trouve ça déroutant... juste peu ergonomique, obèse, et foutré d'une tonne de fonctionnalités dont je n'ai pas besoin une demi-seconde... et bien, quitte à avoir un lecteur qui ne lit que la musique, je préfère quelque chose de léger, compact, minimal : quelque chose du tonneau de cette vieille école qui a apporté XMMS et Audacious (mais sans skin, et si possible, sans GTK, SVP)...
Après, je veux bien croire qu'il est bien, hein... vu la tonne de gens qui l'encensent... mais ce n'est pas le genre de trucs que je trouve, à titre personnel, agréables à utiliser...
Yes ! Quelque chose que je trouve qui manque vraiment en QT (player léger, sans truc à skin, basique mais efficace, et tout intégré compactement - ie pas 36000 fenêtres pour le lecteur, la playliste et cie : juste une seule)...
... oui, j'ai vraiment du mal avec Amarok, Noatun (pour prendre les extrêmes, bien qu'ils partagent des caractéristiques avec lesquelles j'ai du mal) et autres existants...
Autant pour la video, j'adore aussi bien Kaffeine que SMPlayer, autant pour l'audio, je trouve que le genre de compromis que j'aime bien manquait...
Je trouvais Sonata pas mal, mais comme je ne suis pas plus fan de GTK que ça... en tout cas merci, et bonne continuation, à toi et à ce projet.
Certes, mais on dispose justement de plusieurs types de clés : personnellement, j'utilise essentiellement du RSA, qui ne semble pas avoir été gêné par ce problème, si j'en crois l'alerte sur la liste Debian, pour openssh...
Je ne dis pas que c'eût été la solution à tout... je me demande juste si ça n'aurait pas limité la casse d'avoir la possibilité d'utiliser du token dans le cas d'openssh, avec de la RSA dedans... le token devrait s'occuper tout seul de générer les clés si on lui demande, et sans devoir demander à openssl de les générer, non ?
Et, je peux me tromper, mais comme il ne semble pas que RSA ait besoin d'une valeur aléatoire via openssl pour athentifier/signer, le problème devrait se limiter à celui de la génération des clés, justement confiée au token, contrairement aux clés DSA dont la simple utilisation avec la version incriminée d'openssl suffit pour être dans la panade...
Lorsqu'il m'est arrivé de faire du lego tortueux pour ne pas exposer mes clés SSH (en les mettant sur une clé USB dont je me sers vaguement comme d'un token du pauvre... avant tout pour que n'importe qui ne puisse pas avoir accès à des clés privées que je laisserais traîner dans mon /home, plus qu'autre chose), on m'a souvent suggéré d'utiliser un token (donc, pour des raisons différentes de celles qui me turlupinent dans ce bug)... mais ça a quand même l'air assez peu répandu et cher (d'autant que la plupart des offres que j'ai vues demandaient à commander des quantités conséquentes... orienté entreprise probablement)...
D'ailleurs, quand j'ai demandé des précisions sur le sujet à ceux qui m'en parlaient : silence radio... je n'ai jamais trop vu de retours sur ce genre de choses ; j'ai beau être passionné par ce qu'on peut faire avec un réseau et les OS libres, je reste un profane autoditacte, non-professionnel, en la matière... je ne crache pas non plus sur des retours argumentés sur ces tokens : sont-ils vraiment si surfaits que ça, pour qu'ils aient l'air si peu répandus et que leur gestion soit si peu implémentée dans des choses comme openssh, notamment, pour la distro dont il est question dans ce journal (et que j'utilise au quotidien), par Debian ? Bref, pourquoi, monde cruel !?
Et là, je me dis que c'est dommage que le support d'opensc ne semble pas présent dans les paquets d'openssh de Debian... ça fait un moment que ça traîne dans la wishlist, avec patch disponible, du paquet ( http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&d(...) )...
... bon, le problème semble plutôt être que ça créerait trop de dépendances, et que ça pourrait gêner les petits systèmes... m'enfin, à la limite, ce serait bien d'avoir un autre .deb en plus, ie openssl-opensc...
Mais a priori, les clés privées n'étant pas censées quitter un token pour êtres exposées au système, et le couple clés privée/publique y étant généré, le problème ne se poserait pas, en ce cas, pour openssh, qui est, pour ce qui me concerne, le plus pénible...
... enfin, si probablement : pour ce qui est de la clé chiffrant la communication, une fois la transaction établie : mais ça ne supposerait que d'attendre la mise à jour d'openssl, et pas de régénérer toutes ses clés.
Voilà que la paranoia recommence à me démanger...Ce serait bien, quand même, une petite smartcard...
On ne sait jamais, mais au moins, il n'y a plus grand chose à propos de quoi s'étonner...
... l'usine de yoghourts et autres produits laitiers (a priori, plutôt blancs) de la marque *@#0#€ (chut-chut, pas de marque... allez, indice... ils ont été médiatiquement boycottés, il y a quelques années) qui est aux bords de la ville la plus proche de chez moi recrache bien une fumée noire de chez noire (à tel point que l'on peut estimer la direction moyenne du vent, en regardant la décoloration avancée des cheminées d'évacuation)...
En voulant télécharger l'ISO, via cet http://videos.iosn.net/codebreakers/ , pour joindre sous-titre et video, et encoder avec un codec, dans un conteneur, selon mes choix (h264 à quand même la moitié du bitrate du DVD, son non retouché, dans un mkv, avec les sous-titres) et puisque c'est modifiable, bah...
En même temps, le mp3 est (qu'on le veuille ou non) devenu incontournable... même la TV que je viens de m'acheter accepte de lire des mp3 via sa prise USB... une TV, quoi !
... une fois, j'ai même voulu faire écouter un CD que je venais d'encoder en FLAC a un pote... la réponse fut : "c'est bien la peine de faire des mp3 aussi gros : on ne peut même pas les lire sur mon PC" (eh ! oui ... le codec n'était pas installé...).
Bon, et puis, au moins, ils proposent autre chose que ce mp3 très bête... ça place quand même l'initiative bien au-dessus de ce qui se fait dans la grande majorité du commerce...
... mais j'achète un ordinateur pour y mettre ce que je veux, comme par exemple un OS libre (ou pas... enfin, ça fait longtemps, que "ou pas", sur mes PC et assimilés, modulo ce que les gens peuvent trimballer dans leurs sacs quand ils viennent à me rendre visite)... j'achète une carte wifi pour établir une connexion sans-fil (voire en surveiller, tout au plus)...
Les versatilités respectives des deux catégories d'artefact ne sont quand même pas identiques, pour le commun des mortels...
... en outre, on trouve beaucoup de choses qui demandent d'y injecter un firmware, pour éviter la lourdeur de la logique câblée... mais si les firmwares libres devaient s'imposer, il ne faut pas rêver : les constructeurs reviendraient à des limitations en hard pour ce qui est de différencier les capacités de gammes de matériels qui ne diffèrent aujourd'hui que par le firmware, et pas physiquement... pour ce qui est du matériel destiné à des marchés de niches, vendu à une différence de prix pouvant aisément flirter ou cumuler l'ordre de grandeur, c'est d'ailleurs le cas, alors que le matériel, à une ou deux résistances prêt, est identique aux gammes pour les grouillots dont la plupart, moi le premier, sont (je pense notamment aux GPU "pro")...
Pour ce qui est du wifi d'ailleurs, régulations de ce qu'on peut faire sur les ondes radios obligent, il y a fort à parier qu'on doive se coltiner soit des limitations physiques du hard, soit des limitations codées dans le firmware... si l'on se débarasse des deuxièmes, il y a légalement peu de doutes quant à ce qu'on doive subir les premières... et face à un noyau qui implémente ces régulations légales dans un blob (comme les cartes Intel post IPW2xxx, avant la migration des régulations dans le firmware), personnellement, ça me semble être un moindre mal.
Maintenant, loin de moi l'idée de ne pas souhaiter la venue de matériel libre... pour utiliser avec mes OS libres... mais ce sont pour moi deux luttes distinctes, et il ne me paraît pas absurde que la première ne soit qu'une suite, sans corrélation absolue, à la deuxième... par contre, les confondre me paraît un peu trop intégriste (sans connotation fondamentalement négative, pour l'intégrisme, sinon, je n'aurais pas ajouté le "trop" : je ne vois conceptuellement rien de mal à être intègre... juste qu'à l'être trop, on en vient à être, probablement trop également, idéaliste... voire rêveur ; et on peut s'y perdre).
Mais là on était bien dans le cas blob en userland avec le HAL binaire, non?
Pour ce qui est du HAL binaire qui tourne avec madwifi, oui, complètement.
Et c'est une très bonne chose qu'on se dirige vers un futur où on en sera débarrassés... d'autant plus s'ils prévoient d'implémenter les "Virtual Access Points" (gérer plusieurs points d'accès complètement distincts, notamment sur le mode de chiffrement) de l'ancien driver, que je trouve, je le confesse, bougrement sexy... chose sur laquelle je peine, à mon grand dam, à trouver des précisions...
... et d'autant plus si on n'aura même pas à se soucier d'un firmware...
Par contre, la confusion que je vois surtout avec la chasse aux firmwares non libres, elle me semble issue de cette chasse même... à la base, on en vient essentiellement à utiliser des firmwares pour ne pas avoir à implémenter du matériel trop spécialisé, qu'il serait plus difficile de débuguer et de concevoir...
... mais le firmware reste pour moi du domaine du matériel... avoir un mauvais firmware revient à avoir un mauvais matériel, en ce qui me concerne.... et avoir un firmware non libre, à avoir du matériel non libre.
"This driver requires no firmware or binary-only HAL!"
ie " Ce pilote ne requiert aucun micrologiciel, ou couche d'abstraction matérielle uniquement binaire ! " ...
... bon, après, je dois avouer que, bien que Debianeux, je ne comprends pas trop le fouin autour des firmwares non libres, du moment qu'ils sont librement redistribuables (ce qu'ils sont déjà loin de toujours être, certes)...
Je vois un peu ça du même oeil que du matériel non libre, qu'on utilise avec du logiciel libre, et qui ne dérange pas tant de monde que ça... certes, je préfèrerais avoir des firmwares libres, qui tourneraient sur du matériel libre... mais mettre ça au même rang que les blobs en plein kernel ou userland, je trouve qu'il y a de l'abus, et que ça sème plus la confusion qu'autre chose...
je comprends pas pourquoi le tiens a du mal alors que mon athlon xp @2.2GHz s'en sort sans soucis particuliers
Sûrement parce que tu lis des trucs à faible bitrate (faits pour être téléchargés, comme des démos en 1080p, mais à l'encodage faiblard)... ou alors, pas en AVC (on trouve même du MPEG2 en 1080p, sur certains disques hache-day... après, tu compromises sur la taille des données ou leur qualité)...
... bref, un C2D@2,66GHz, c'est vraiment le strict minimum pour lire du 1080p en MPEG4-AVC à gros bitrate (genre 30MBps), sans aide matérielle au décodage... et encore, pendant les scènes riches en données, le CPU est au-dessus de 90%, quand il ne décroche pas, sur certaines videos...
Essaye de lire une video comme ça avec ton Athlon XP, en décodage software, tu vas être déçu...
Tant qu'en sus, ils ne sont pas pédophiles et chômeurs, la plus grande personne de petite taille en ce pays, elle (ou il ? ) s'en cogne la rollex contre les poches sperminales, tout en rédigeant un SMS grivois et en faisant une prière...
D'autant que reste encore à matroska à être "bien" supporté...
Je crée personnellement des rips en matroska pour mes DVD, et il m'arrive de faire des choses "exotiques"...
Du genre, ripper un épisode de Futurama, avec plusieurs langues (vo et commentaires), et plusieurs sous-titres (vo, vf, commentaires... en vobsub... l'ocr, c'est beaucoup trop aléatoire et saoulant), et même fusionner deux mkv (par exemple, l'épisode, et les scènes coupées)...
Déjà, il faut que les scènes coupées aient le même nombre de pistes audio et sous-titres que l'épisode, pour ne pas faire craquer la plupart des players (il me semble que ça ne marche qu'avec mplayer, pour ce que j'ai testé)... après, même en rusant, impossible de lire quoi que ce soit de ce genre avec totem (bon, kplayer s'en tire bien quand même, une fois qu'on a rusé en rajoutant des pistes plusieurs fois, ce qui est dommage pour l'espace bouffé, mais qui marche, au moins)...
Après, je ne dis pas : s'il y a des améliorations notables dans NUV (notamment, en plus de l'overhead en espace qu'induit l'utilisation de mkv, il faut aussi compter sur de l'overhead CPU, par rapport à des conteneurs plus basiques), ça pourrait être intéressant... Mais, s'il faut attendre que les lecteurs mainstream supportent encore un nouveau conteneur, il y a des risques que ça dure un peu plus longtemps que jusqu'à demain...
[^] # Re: Arf...
Posté par Aefron . En réponse au journal Firefox est-il toujours libre ?. Évalué à 3.
open-source!=libre ... je pense notamment à des cartes d'acquis SDI (un peu le HDMI pro, pour les studios de montage), dont certaines (je n'arrive pas à retrouver le lien... il me semble que c'était une boîte indienne qui les fabriquait, pour gagner des sioux - autant la faire tout de suite) fonctionnent avec des drivers open-source (pour pouvoir les recompiler pour le kernel de son choix), mais absolument pas libres (seulement pour les clients, et absolument pas redistribuables).
Bon, après, il y a des trucs qui m'ont fait m'en éloigner : entre autres le fait que les versions Linux s'intègrent très pauvrement dans les environnements libres (massacre total des thèmes GTK qui prennent des apparences totalement fantasques [oui, je sais, ce n'est pas vraiment du GTK - c'est encore pire : c'est un truc à skins] c'est la seule application sur mon X.org qui ne tilte pas que je suis en 133 dpi - génial, faut que je me mette à 10cm de l'écran, intègre ses propres icônes alors que je préfèrerais avoir le même thème que dans les autres applis, ... plein de choses comme ça), alors que j'ai l'impression que ça se passe beaucoup mieux (dans une certaine mesure... je pense particulièrement au thème par défaut de la version 2, avec ses onglets, qui, sous un thème GTK à fond noir, présentent une apparence en dégradé "noir vers blanc", typiquement à-la-vista) pour la version destinée aux os redmondiens... c'est déjà assez représentatif d'une certaine idée que j'ai de ce que ce à quoi firefox est destiné.
Bon, ça, plus ce qu'il bouffe en CPU et en RAM, les plantages à l'enchaîne, ainsi que certains traits de la politique de la mofoco, ça fait qu'il y a un an, j'ai décidé que firefox n'était pas pour moi (pas de quoi en faire un fromage), et je suis passé à Konqueror (et par la même occasion, KDE, en lieu et place de FVWM)... et je ne le regrette en rien (je garde juste firefox iceweasel sous la main pour lire les pages avec du flash, une fois tous les quatre matins)...
[^] # Re: tpm
Posté par Aefron . En réponse au journal Smartcard, X.509, OpenLDAP... et OpenSSH... pourquoi, monde cruel ?. Évalué à 2.
... par contre, il faudrait sûrement une interface PKCS#11 pour en tirer partie sous une majorité de logiciels où ça pourrait être utile...
Je ne sais d'ailleurs pas si les puces TPM et cie sont déjà supportées sous Linux...
Par ailleurs, je ne trouve pas très pratique que les clés doivent être laissées dans une carte mère, pour ce qui est des clés SSH, des clés de signature, et cie : je trouve plus sécurisante l'idée de trimballer sur moi (ou de cacher physiquement) le "quelque chose que je possède", plutôt que de le laisser sur la machine ; parce que, niveau "quelque chose que je possède", une machine, c'est lourd, et plus difficile à garder du coin de l'oeil que quelque chose que je garderais la plupart du temps près de mes parties intimes, quand même...
... scénario type : mettons que je me serve d'une smartcard pour déchiffrer mon / ainsi que me logger, et de l'espace sur la clé USB pour mettre le /boot (histoire qu'il ne se fasse pas corrompre pour chopper le PIN). Je pars boire un café ou je vais satisfaire quelque autre besoin naturel (ou pas) : si c'est une smartcard que l'on peut dé-brancher, pas de souci, je verrouille ma session (en faisant en sorte d'avoir besoin de la smartcard pour la déverouiller) et j'emporte le token - il reste quelque chose à posséder et à connaître qui n'est absolument pas sur place... mettons que je me serve de la puce TPM de la mobo pour stocker les mêmes clés : ce qu'il faut protéger et ce qu'il faut posséder sont alors la même chose - ne reste vraiment qu'à connaître le PIN pour se servir de la machine... l'authentification forte, elle en devient borderline (même si la clé ne peut théoriquement pas être extraite... ce sur quoi j'ai des doutes, aussi bien pour les smartcards externe que pour TPM, mais qui m'inquiète beaucoup plus pour le dernier, vu que cacher la machine pour que n'importe quel grouillot n'en vienne pas à la posséder, ce n'est pas ce qu'il y a de plus simple...)...
Bon, après, ça dépend des usages... là où je verrais plus l'intérêt d'utiliser ces puces TPM, ce serait pour des choses de l'ordre des clés identifiant la machine dans SSH, d'avantage que pour les clés permettant de s'y connecter.
# Ca...
Posté par Aefron . En réponse au journal Douce France, pays rétrograde. Évalué à -6.
C'est malin : maintenant, chat échaudé craint l'eau froide...
[^] # Re: Carte OpenPGP
Posté par Aefron . En réponse au journal Smartcard, X.509, OpenLDAP... et OpenSSH... pourquoi, monde cruel ?. Évalué à 2.
[^] # Re: Sécurité physique
Posté par Aefron . En réponse au journal Smartcard, X.509, OpenLDAP... et OpenSSH... pourquoi, monde cruel ?. Évalué à 3.
... mais en effet, le principe d'inviolabilité, si on n'a pas les specs complètes des cartes (et encore, faudrait aussi être sûr que le produit correspond aux spécifications), rien ne nous garantit qu'il n'est pas rendu caduque par une backdoor du constructeur ou des hacks de spécialistes, voire les Chinois du FBI.
J'ai juste essayé de trouver de quoi gérer du RSA 2048 bits sous linux, sans middleware proprio, et à part les Cryptoflex, je n'ai rien vu... idéalement, j'aurais aimé trouver quelque chose qui gère aussi l'AES (même si bon... apparemment, les outils sous Linux ne sont pas trop faits pour ça)...
M'enfin, déjà, le fait d'avoir une smartcard pour stocker mes clés privées (et plein d'autres trucs, avec le lecteur combiné à de la flash, et aussi la possibilité de stocker autre chose que des clés privées, en tant qu'objets privés accessibles via un PIN), ça me forcera toujours à y faire plus attention (artefact précieux, perte définitive des clés privées si on fait trop le con, nombre d'écritures probablement limité, nécessité de commander outre-Atlantique, ...), tout en augmentant le degré de sécurité par rapport à des clés à pasphrase qui peuvent trop facilement traîner n'importe où, voire qui peuvent même avoir été générées sur une Debian.
[^] # Re: Basiccard
Posté par Aefron . En réponse au journal Smartcard, X.509, OpenLDAP... et OpenSSH... pourquoi, monde cruel ?. Évalué à 2.
Vu que RSA est l'essentiel de ce que j'utilise, et que le peu de support pour les smartcards que l'on a semble se concentrer sur cet algo, je pense que je vais aller au plus simple en restant sur les Cryptoflex.
[^] # Re: c'est bien, mais j'ai pas tout compris
Posté par Aefron . En réponse au journal Smartcard, X.509, OpenLDAP... et OpenSSH... pourquoi, monde cruel ?. Évalué à 2.
Disons qu'à la base j'aurais plutôt voulu attendre de recevoir les smartcards et d'avoir joué avec elles avant de faire un journal... puis, voulant réagir au message du forum, et quand même faire partager ce que j'avais pu comprendre de la problématique, j'ai un peu tout enchaîné d'un trait.
Sinon, si ce que j'ai évoqué, sur le fait que les smartcards sont en fait des ordinateurs crypto qui gèrent des clés (notamment RSA) et la manière de s'en servir, pour ne jamais les exposer et faire de la smartcard quelque chose que l'on possède, il y a deux bons articles sur UnixGarden [1] [2], originellement parus dans Linux Magazine qui donnent un bon aperçu de ce dont il s'agit... mea culpa de ne pas les avoir mis en lien, pour débroussailler le sujet.
Et je prends bonne note pour les sections : à ce stade de flood, mettre un peu plus de retours à la ligne, pour vaguement tenter de séparer, ne rend ostensiblement pas les choses assez claires...
[1] http://www.unixgarden.com/index.php/securite/gestion-des-sma(...)
[2] http://www.unixgarden.com/index.php/securite/smartcards-appl(...)
[^] # Re: Voilà qui me manquait...
Posté par Aefron . En réponse au journal Lecteur Audio Phinix. Évalué à 3.
Et une meilleure apparence des widgets que via un adaptateur de thèmes GTK/QT ?
... ou plus simplement le désir d'avoir le moins de GTK possible ?
[^] # Re: Voilà qui me manquait...
Posté par Aefron . En réponse au journal Lecteur Audio Phinix. Évalué à 4.
Eh, oui... je n'ai ostensiblement pas tout à fait la même utilisation du player que toi... de temps en temps, j'aime bien voir la playlist, la laisser affichée (j'aime aficher plein de trucs en même temps... je suis d'ailleurs un multi-écran fanboy, à tendance bordélique éparpilleur, bien triste de voir la régression du multi-cartes dans X.org 7.3)... sans pour autant qu'elle me bouffe autant de place...
Après, certes, il y a d'autres trucs que je n'aime pas dans Amarok : déjà, la gestion des tags, pour laquelle j'utilise aussi EasyTag (qui me sert à avoir des tags propres pour MythMusic et le SlimCenter... et à renommer les fichiers en fonction des tags pour qu'ils soient mieux rangés pour quand je les utilise avec un lecteur "classique"... et je trouve EasyTag vraiment efficace dans ce job, en tout cas plus qu'Amarok)...
... ou la gestion des covers... je préfère les scanner, voire les télécharger moi-même (enfin, surtout les scanner... les jpg d'Amazon, en 1080p, à 2,5m d'un 42", ça rend moyen, quand même), plutôt que de les voir balancer dans un répertoire qui n'a rien à voir avec celui où est stockée la musique, et dont il va falloir les exporter (ou les importer, pour chaque machine où j'aurais Amarok)... ne me servant pas que d'un player en clickodrome classique, mais aussi d'une interface TV permanente, et pouvant afficher les covers dans l'interface web du SlimCenter, le plus simple pour moi est encore d'avoir un cover.jpg ou assimilé dans le répertoire de l'album...
... tous ces trucs dont je n'ai pas besoin une demi-seconde dans un simple player, et qu'il intègre, ça témoigne d'une démarche visant à intégrer moult fonctionnalités dans un client lourd (pas forcément au niveau des perfs, n'ayant pas des masses à me plaindre du matos que j'ai pour ça, mais rien qu'au niveau de l'interface, en ce qui me concerne)...
Bon, très bien : je ne lapide pas, je critique - ce n'est pas ce que je recherche, et j'ai du mal à m'y faire, même si je comprends que ce soit parfait pour certains (l'un de mes potes est un fan inconditionnel d'Amarok depuis qu'il est sur la banquise... et lorsqu'il était redmondien, son winamp remplissait tout l'écran, avec je ne sais combien de plugins... il en faut pour tous les goûts... perso, j'ai toujours aimé les petits players)...
... à la limite, un truc comme Amarok qui lirait les videos, et qui serait accompagné d'un serveur en backend pour les tags sur les éléments videos (une espèce de MythTV-like, mais en fenêtré), ça pourrait m'intéresser... mais un truc aussi versatile juste pour la musique (c'est plutôt pour les videos que je veux plus de réglages... et pour ça, j'ai Kaffeine et SMPlayer), alors que j'en ai une utilisation très basique (enchaîne une playlist, la modifie un poil et zou), non, c'est trop pour moi... pas la peine de le prendre pour toi, hein : c'est juste une question de goûts...
[^] # Re: Voilà qui me manquait...
Posté par Aefron . En réponse au journal Lecteur Audio Phinix. Évalué à 3.
... bon, ce n'est pas que je trouve ça déroutant... juste peu ergonomique, obèse, et foutré d'une tonne de fonctionnalités dont je n'ai pas besoin une demi-seconde... et bien, quitte à avoir un lecteur qui ne lit que la musique, je préfère quelque chose de léger, compact, minimal : quelque chose du tonneau de cette vieille école qui a apporté XMMS et Audacious (mais sans skin, et si possible, sans GTK, SVP)...
Après, je veux bien croire qu'il est bien, hein... vu la tonne de gens qui l'encensent... mais ce n'est pas le genre de trucs que je trouve, à titre personnel, agréables à utiliser...
# Voilà qui me manquait...
Posté par Aefron . En réponse au journal Lecteur Audio Phinix. Évalué à 3.
... oui, j'ai vraiment du mal avec Amarok, Noatun (pour prendre les extrêmes, bien qu'ils partagent des caractéristiques avec lesquelles j'ai du mal) et autres existants...
Autant pour la video, j'adore aussi bien Kaffeine que SMPlayer, autant pour l'audio, je trouve que le genre de compromis que j'aime bien manquait...
Je trouvais Sonata pas mal, mais comme je ne suis pas plus fan de GTK que ça... en tout cas merci, et bonne continuation, à toi et à ce projet.
[^] # Re: Wishlist
Posté par Aefron . En réponse au journal Vulnérabilité Debian. Évalué à 2.
Je ne dis pas que c'eût été la solution à tout... je me demande juste si ça n'aurait pas limité la casse d'avoir la possibilité d'utiliser du token dans le cas d'openssh, avec de la RSA dedans... le token devrait s'occuper tout seul de générer les clés si on lui demande, et sans devoir demander à openssl de les générer, non ?
Et, je peux me tromper, mais comme il ne semble pas que RSA ait besoin d'une valeur aléatoire via openssl pour athentifier/signer, le problème devrait se limiter à celui de la génération des clés, justement confiée au token, contrairement aux clés DSA dont la simple utilisation avec la version incriminée d'openssl suffit pour être dans la panade...
Lorsqu'il m'est arrivé de faire du lego tortueux pour ne pas exposer mes clés SSH (en les mettant sur une clé USB dont je me sers vaguement comme d'un token du pauvre... avant tout pour que n'importe qui ne puisse pas avoir accès à des clés privées que je laisserais traîner dans mon /home, plus qu'autre chose), on m'a souvent suggéré d'utiliser un token (donc, pour des raisons différentes de celles qui me turlupinent dans ce bug)... mais ça a quand même l'air assez peu répandu et cher (d'autant que la plupart des offres que j'ai vues demandaient à commander des quantités conséquentes... orienté entreprise probablement)...
D'ailleurs, quand j'ai demandé des précisions sur le sujet à ceux qui m'en parlaient : silence radio... je n'ai jamais trop vu de retours sur ce genre de choses ; j'ai beau être passionné par ce qu'on peut faire avec un réseau et les OS libres, je reste un profane autoditacte, non-professionnel, en la matière... je ne crache pas non plus sur des retours argumentés sur ces tokens : sont-ils vraiment si surfaits que ça, pour qu'ils aient l'air si peu répandus et que leur gestion soit si peu implémentée dans des choses comme openssh, notamment, pour la distro dont il est question dans ce journal (et que j'utilise au quotidien), par Debian ? Bref, pourquoi, monde cruel !?
# Wishlist
Posté par Aefron . En réponse au journal Vulnérabilité Debian. Évalué à 2.
... bon, le problème semble plutôt être que ça créerait trop de dépendances, et que ça pourrait gêner les petits systèmes... m'enfin, à la limite, ce serait bien d'avoir un autre .deb en plus, ie openssl-opensc...
Mais a priori, les clés privées n'étant pas censées quitter un token pour êtres exposées au système, et le couple clés privée/publique y étant généré, le problème ne se poserait pas, en ce cas, pour openssh, qui est, pour ce qui me concerne, le plus pénible...
... enfin, si probablement : pour ce qui est de la clé chiffrant la communication, une fois la transaction établie : mais ça ne supposerait que d'attendre la mise à jour d'openssl, et pas de régénérer toutes ses clés.
Voilà que la paranoia recommence à me démanger...Ce serait bien, quand même, une petite smartcard...
[^] # Re: Bon rétablissement !
Posté par Aefron . En réponse au journal proche de la mort, puis msn. Évalué à 1.
... l'usine de yoghourts et autres produits laitiers (a priori, plutôt blancs) de la marque *@#0#€ (chut-chut, pas de marque... allez, indice... ils ont été médiatiquement boycottés, il y a quelques années) qui est aux bords de la ville la plus proche de chez moi recrache bien une fumée noire de chez noire (à tel point que l'on peut estimer la direction moyenne du vent, en regardant la décoloration avancée des cheminées d'évacuation)...
# DVD ?
Posté par Aefron . En réponse à la dépêche Publication des sous-titres en français du documentaire « The CodeBreakers ». Évalué à 2.
=> "videos.iosn.net inconnu" ...
Bon, puisque c'est redistribuable, un petit tour de gogole, et on tombe bien sur http://www.2flub.org/~fana/propaganda/video/The-Codebreakers(...) ou autres http://www.torrentz.com/f0b5bca1c435e75af190229b29f7a090d5b4(...) (je n'affirme rien quant à la validité de ce que contiennent les liens, étant en train de télécharger l'ISO)...
... mais c'est dommage, quand même.
[^] # Re: Tout bête
Posté par Aefron . En réponse au journal NIN - The Slip. Évalué à 8.
... une fois, j'ai même voulu faire écouter un CD que je venais d'encoder en FLAC a un pote... la réponse fut : "c'est bien la peine de faire des mp3 aussi gros : on ne peut même pas les lire sur mon PC" (eh ! oui ... le codec n'était pas installé...).
Bon, et puis, au moins, ils proposent autre chose que ce mp3 très bête... ça place quand même l'initiative bien au-dessus de ce qui se fait dans la grande majorité du commerce...
[^] # Re: Une précision pour un mal comprenant
Posté par Aefron . En réponse au journal Atheros veut être compatible avec Linux. Évalué à 2.
... mais j'achète un ordinateur pour y mettre ce que je veux, comme par exemple un OS libre (ou pas... enfin, ça fait longtemps, que "ou pas", sur mes PC et assimilés, modulo ce que les gens peuvent trimballer dans leurs sacs quand ils viennent à me rendre visite)... j'achète une carte wifi pour établir une connexion sans-fil (voire en surveiller, tout au plus)...
Les versatilités respectives des deux catégories d'artefact ne sont quand même pas identiques, pour le commun des mortels...
... en outre, on trouve beaucoup de choses qui demandent d'y injecter un firmware, pour éviter la lourdeur de la logique câblée... mais si les firmwares libres devaient s'imposer, il ne faut pas rêver : les constructeurs reviendraient à des limitations en hard pour ce qui est de différencier les capacités de gammes de matériels qui ne diffèrent aujourd'hui que par le firmware, et pas physiquement... pour ce qui est du matériel destiné à des marchés de niches, vendu à une différence de prix pouvant aisément flirter ou cumuler l'ordre de grandeur, c'est d'ailleurs le cas, alors que le matériel, à une ou deux résistances prêt, est identique aux gammes pour les grouillots dont la plupart, moi le premier, sont (je pense notamment aux GPU "pro")...
Pour ce qui est du wifi d'ailleurs, régulations de ce qu'on peut faire sur les ondes radios obligent, il y a fort à parier qu'on doive se coltiner soit des limitations physiques du hard, soit des limitations codées dans le firmware... si l'on se débarasse des deuxièmes, il y a légalement peu de doutes quant à ce qu'on doive subir les premières... et face à un noyau qui implémente ces régulations légales dans un blob (comme les cartes Intel post IPW2xxx, avant la migration des régulations dans le firmware), personnellement, ça me semble être un moindre mal.
Maintenant, loin de moi l'idée de ne pas souhaiter la venue de matériel libre... pour utiliser avec mes OS libres... mais ce sont pour moi deux luttes distinctes, et il ne me paraît pas absurde que la première ne soit qu'une suite, sans corrélation absolue, à la deuxième... par contre, les confondre me paraît un peu trop intégriste (sans connotation fondamentalement négative, pour l'intégrisme, sinon, je n'aurais pas ajouté le "trop" : je ne vois conceptuellement rien de mal à être intègre... juste qu'à l'être trop, on en vient à être, probablement trop également, idéaliste... voire rêveur ; et on peut s'y perdre).
[^] # Re: Moi
Posté par Aefron . En réponse au journal Pierre-Feuille-Ciseaux... Puits-Toile d'araigné. Évalué à 7.
[^] # Re: Une précision pour un mal comprenant
Posté par Aefron . En réponse au journal Atheros veut être compatible avec Linux. Évalué à 5.
Pour ce qui est du HAL binaire qui tourne avec madwifi, oui, complètement.
Et c'est une très bonne chose qu'on se dirige vers un futur où on en sera débarrassés... d'autant plus s'ils prévoient d'implémenter les "Virtual Access Points" (gérer plusieurs points d'accès complètement distincts, notamment sur le mode de chiffrement) de l'ancien driver, que je trouve, je le confesse, bougrement sexy... chose sur laquelle je peine, à mon grand dam, à trouver des précisions...
... et d'autant plus si on n'aura même pas à se soucier d'un firmware...
Par contre, la confusion que je vois surtout avec la chasse aux firmwares non libres, elle me semble issue de cette chasse même... à la base, on en vient essentiellement à utiliser des firmwares pour ne pas avoir à implémenter du matériel trop spécialisé, qu'il serait plus difficile de débuguer et de concevoir...
... mais le firmware reste pour moi du domaine du matériel... avoir un mauvais firmware revient à avoir un mauvais matériel, en ce qui me concerne.... et avoir un firmware non libre, à avoir du matériel non libre.
[^] # Re: Une précision pour un mal comprenant
Posté par Aefron . En réponse au journal Atheros veut être compatible avec Linux. Évalué à 9.
"This driver requires no firmware or binary-only HAL!"
ie " Ce pilote ne requiert aucun micrologiciel, ou couche d'abstraction matérielle uniquement binaire ! " ...
... bon, après, je dois avouer que, bien que Debianeux, je ne comprends pas trop le fouin autour des firmwares non libres, du moment qu'ils sont librement redistribuables (ce qu'ils sont déjà loin de toujours être, certes)...
Je vois un peu ça du même oeil que du matériel non libre, qu'on utilise avec du logiciel libre, et qui ne dérange pas tant de monde que ça... certes, je préfèrerais avoir des firmwares libres, qui tourneraient sur du matériel libre... mais mettre ça au même rang que les blobs en plein kernel ou userland, je trouve qu'il y a de l'abus, et que ça sème plus la confusion qu'autre chose...
[^] # Re: Autre proposition : le hippie.
Posté par Aefron . En réponse au journal Pierre-Feuille-Ciseaux... Puits-Toile d'araigné. Évalué à 2.
[^] # Re: Ouf!
Posté par Aefron . En réponse au journal BrDesktop et le concept de distribution. Évalué à 5.
... c'est pas comme si ça faisait vraiment un troll de moins.
[^] # Re: ?
Posté par Aefron . En réponse au journal Si vous avez envie d'un mini-pc.... Évalué à 3.
Sûrement parce que tu lis des trucs à faible bitrate (faits pour être téléchargés, comme des démos en 1080p, mais à l'encodage faiblard)... ou alors, pas en AVC (on trouve même du MPEG2 en 1080p, sur certains disques hache-day... après, tu compromises sur la taille des données ou leur qualité)...
... bref, un C2D@2,66GHz, c'est vraiment le strict minimum pour lire du 1080p en MPEG4-AVC à gros bitrate (genre 30MBps), sans aide matérielle au décodage... et encore, pendant les scènes riches en données, le CPU est au-dessus de 90%, quand il ne décroche pas, sur certaines videos...
Essaye de lire une video comme ça avec ton Athlon XP, en décodage software, tu vas être déçu...
[^] # Re: Test
Posté par Aefron . En réponse au journal Des hontes au logi !. Évalué à 1.
[^] # Re: Trop tard
Posté par Aefron . En réponse au journal Connaissez vous le format NUT?. Évalué à 3.
Je crée personnellement des rips en matroska pour mes DVD, et il m'arrive de faire des choses "exotiques"...
Du genre, ripper un épisode de Futurama, avec plusieurs langues (vo et commentaires), et plusieurs sous-titres (vo, vf, commentaires... en vobsub... l'ocr, c'est beaucoup trop aléatoire et saoulant), et même fusionner deux mkv (par exemple, l'épisode, et les scènes coupées)...
Déjà, il faut que les scènes coupées aient le même nombre de pistes audio et sous-titres que l'épisode, pour ne pas faire craquer la plupart des players (il me semble que ça ne marche qu'avec mplayer, pour ce que j'ai testé)... après, même en rusant, impossible de lire quoi que ce soit de ce genre avec totem (bon, kplayer s'en tire bien quand même, une fois qu'on a rusé en rajoutant des pistes plusieurs fois, ce qui est dommage pour l'espace bouffé, mais qui marche, au moins)...
Après, je ne dis pas : s'il y a des améliorations notables dans NUV (notamment, en plus de l'overhead en espace qu'induit l'utilisation de mkv, il faut aussi compter sur de l'overhead CPU, par rapport à des conteneurs plus basiques), ça pourrait être intéressant... Mais, s'il faut attendre que les lecteurs mainstream supportent encore un nouveau conteneur, il y a des risques que ça dure un peu plus longtemps que jusqu'à demain...