Jean-Yves B. a écrit 873 commentaires

À part pour se la péter sur les captures d'écran ou auprès des potes, il y a des gens qui utilisent ce genre de « visualisateurs de musique » dans la vie de tous les jours ?
Parce que mon xmms il est plus souvent iconisé qu'autre chose ...

La sortie SPDIF peut être rendue inactive si le bit SCMS (Serial Copy Management System) est bien positionné dans le flux.
Donc soit le flux sort avec le bit SCMS posé (une seule génération de copie possible en théorie), donc il est tout à fait possible de le stripper ensuite ; soit le flux ne sort pas du tout car la chaîne refuse de sortir en SPDIF quelquechose de marqué comme étant déjà une copie ou la refusant simplement, il faut hacker la chaîne.

Le premier cas doit être le plus courant.
Il subsiste le problème principal : la copie se fait en 1:1 et c'est long, très long.

C'est hyper pénible de passer ses veilles de voyages à transférer des CDs sur minidisc (oui, je pourrais acheter pleins de minidisc pour chaque CD mais bon, ça coûte).

Mais qu'est-ce qu'une mesure technique efficace ?
Il n'y en a pas vraiment, que je sache (dans ce cadre en tous les cas).

OK, ça me va. Un truc de plus pour la FAQ ;)

Bon, qui pourrais-je interviewer ...

On a le droit de faire une copie de sauvegarde, mais le fournisseur du matériel d'origine n'a pas le devoir de rendre la chose aisée.

Donc tout va bien.

... de faire des interviews comme ça aussi, en plus de fournir des liens vers celles faites par d'autres.

Genre interviews de core-developers français de divers projets (linux, gnome, kde, *bsd, xfree, <ce que vous voulez>).

Après tout, presque n'importe qui pourrait se prétendre de linuxfr pour faire une interview et la soumettre ensuite à modéro mais ça manque d'un côté plus « officiel ».

ça permet de faire machin le bazar avec n'importe quel kernel.

Correction : ça permet de faire marcher le bazar avec n'importe quel kernel i386 ! La différence est énorme !

Oui mais dans les aspirateurs, c'est pour mettre une machine avec un OS qui suxe.

[-1, mais il fallait que je la fasse]

Le dico de l'Af est pas mal à jour quand même. Nos amis académiciens produisent neaucoup de recommandations en dehors de leur dico aussi. Si cover-girl (à girl) et logiciel sont dans leur dico, il est suffisamment à jour pour contenir crypter si ils en pensaient du bien, je pense ...

Oui, crypter est moins joli à mon sens. Oui, c'est subjectif. L'effort de prononciation est plus grand pour crypter que chiffrer quand même.

Je n'ai jamais prétendu que le fait qu'un mot vienne de l'anglais soit honteux (au contraire, cf mon autre commentaire sur les anglicismes). En même temps j'ai démarré un peu vite, aussi. C'est à force d'entendre des gens dire « encrypter » qui, lui, est encore plus odieux et surtout un bon anglicisme contemporain.

Merci pour les contre arguments à propos de crypter, j'en prends note (quête de demain : la bibliothèque pour trouver des références sur l'usage de l'un et de l'autre).

Au fait, l'Af n'est pas si rigide que ça, ils fournissent même des lignes de conduite pour faire évoluer la langue de manière correcte. C'est en grande partie à cause de ces conseils que je persiste à penser que chiffrer est mieux que crypter.

Je n'ai pas été clair.

Dans le cas idéal, si on veut que les données ne passent jamais dans le cache, on les bloque en mémoire. Dans la pratique, c'est rarement fait. Notamment parce que seul root peut fixer une zone de mémoire, donc cela impose aux applications d'être SUID root (ou lancées par lui).

Exemple : gnupg a besoin d'être root pour cela, si gpg n'est pas SUID root il affiche un avertissement :

Warning: using insecure memory

Le plus souvent ce n'est pas le filesystem qui est chiffré mais juste un ou plusieurs fichiers, la manipulation est donc faite par un utilisateur sans droits particuliers la plupart du temps. En plus, tout le monde ne passe pas au comportement de son application quand elle passe dans le swap (à tort).

Chiffrer existait avant crypter, qui a été pas mal importé de l'anglais to crypt, bien que l'origine soit grecque (mais où ai-je fourré ce dico étymologique ? Rhââââ, je suis plus sûr sans source sûre !).

Bon, à priori crypter semble dans l'usage, je m'incline donc, mais ... tsst, ça me gène.
Chiffrer est beaucoup plus sain comme mot, moins cryptique :)
Cryptographier au pire, mais crypter c'est vraiment dégeu (cryptographier n'est pas dans le dico de l'Af non plus, d'ailleurs).

Je pense que ça ne sert à rien, mis à part à interdire la lecture du swap par les patchs de sécurité de la NSA.

Même pas, tout le noyau accède au swap sans soucis.

Alors, à quoi ça sert ? C'est simple.

Dans la mémoire vive se trouve souvent des données qui ne doivent être écrites nulle part (principalement des clefs et certificats cryptographiques). Quand on ne peut pas chiffrer la zone d'échange sur disque, on bloque toutes ces données dans des zones mémoire qui sont fixées en mémoire vive, et ne passeront jamais dans la zone d'échange quelque soit la situation globale de la mémoire.
Avec cette possibilité de chiffrer, il n'est plus nécessaire d'immmobiliser une grande partie de la mémoire vive pour des raisons de sécurité quand le système a de gros besoins en mémoire.

L'intérêt pour l'être humain moyen ? Pas énorme à moins de travailler sur des données sensibles ou de tenir à sa vie privée plus que tout.

Exemple :
vous travaillez pour une entreprise et possédez un portable avec tout votre projet ultra-secret dessus. Sur un système de fichier chiffré, comme de bien entendu.
Seulement, lors d'une présentation, après avoir donné votre mot de passe au système qui gère le chiffrement du système de fichier ou tout autre truc sur la machine (clef pour accéder au VPN de la boîte, etc.), vous faites tourner vos transparents sous forme de PDF avec Acrobat Reader®.
Le portable n'a que 64 Mo de RAM, la machine swappe car Acrobat Reader® n'a pas été programmé par des ex-démomakers faisant attention a toutes les fuites de mémoire.
À ce moment-là, il est fort probable que votre mot de passe soit sur disque, dans la zone d'échange.
La présentation est finie, vous verrouillez la machine et répondez aux questions dans le public ... À ce moment-là un malandrin pique le portable (qui veut, peut). Il s'agit en fait d'un concurrent qui veut mettre la main sur le projet.
En 10 minutes d'autopsie, il récupère le mot de passe pour déchiffrer le projet et la clef pour accéder au VPN de la boîte pour espionner tranquille. Si le fichier d'échange était chiffré, cela ne serait pas possible. Voilà.

On peut trouver pleins d'exemples comme ça, même les banques qui foutent leur disques durs à la poubelle quand ils sont foirés (peu le font), avec un swap chiffré, moins de soucis.

Ça semble plus utile comme ça ?

[-1, Je vais continuer sur le hors-sujet]

Attention, je ne dis pas que la langue française doit être figée. Je signale juste qu'il y a des règles d'évolution.
Ajouter le mot « crypter » au lexique français n'a aucun intérêt, c'est tout. Comme « solutionner » par exemple, qui ne veut rien dire non plus (et qui comme par hasard est dans le dico de la francophonie Hachette (mais avec un avertissement)).
Et ne me dites pas que l'académie française est contre la simplification de la langue : ils ont déjà accepté toutes les orthographes où les accents inutiles sont supprimés (genre « gout » au lieu de « goût ») et pas mal d'autres concessions (cf leur site).

<PUB>

http://www.soekris.com(...)

Roulaize grave, surtout avec les cartes d'accélération crypto (gérées par OpenBSD) qui permettent de faire de l'IPsec à >50Mbps pour 3000 balles de matos.

</PUB>

Eh bien, c'est de pire en pire chez Hachette (et Larousse aussi tant que j'y suis (et sans doute d'autres mais je n'ai pas d'autres dicos pourris sous la main (le lisp c'est sympa))) !
Voilà de beaux anglicismes inutiles (ils ne le sont pas tous mais celui-là l'est particulièrement).

Personnellement je ne me fie qu'aux vieux croûtons pour valider mon français. Donc, ni dans le Littré ni dans le dico de l'académie française n'apparait « crypter ». Et je camperais sur cette position jusqu'à ma mort.

Je dois être trop conservateur pour préférer le français de France (fr_FR) au français international (fr).

Une petite citation[1] de mes potes immortels :

D'autres [anglicismes] sont nuisibles quand ils sont dus à une recherche de la facilité qui ne fait qu'introduire la confusion : on emploie un anglicisme vague pour ne pas se donner la peine de chercher le terme français existant parmi plusieurs synonymes ou quasi-synonymes.

Extraits du dictionnaire de l'Académie française :

CRYPTOGRAPHIE n. f. XVIIe siècle. Composé à l'aide du grec kruptos, « caché », et graphein, « écrire ».
Art d'écrire en langage codé, secret, chiffré.

CHIFFRER v. intr. et tr. XVIe siècle. Dérivé de chiffre.
II. V. tr. [...] 3. Transcrire un texte en langage conventionnel pour en assurer le secret. Chiffrer une dépêche diplomatique. User d'un langage chiffré. Un message chiffré.

[1] http://www.academie-francaise.fr/langue/questions.html#anglicismes(...)

Je ne vois pas l'intêret pour Conexant de ne pas rendre public les sources de la totalité des drivers étant donné que la technologie V92 n'est plus vraiment une nouveauté.

Ben ... ils le disent eux-mêmes : « Due to patent and licensing issues outside of our control ». Je suppose qu'il y a pléthore de brevets et autres joyeusetés de posées sur V.92 et V.44 (et c'est le cas, les boîtes qui « aident » à poser les standards de l'UIT posent des brevets à côté, genre http://www.vocal.com(...) pour V92 par exemple).

Je savais que cet appât fonctionnerait !

[-1]

Euh ... la MIB système accessible par sysctl n'est pas mappée dans /proc ?
Ce serait un peu idiot d'avoir ce genre de données réparties entre deux systèmes différents, non ?

sysctl permet d'y accéder si /proc n'est pas monté, je suppose. De plus sysctl est la commande classique pour ce genre de trucs sur pas mal d'Unix.

Bon, en français le verbe crypter n'existe pas. On dit « chiffrer ».

Notez, c'est un peu bourrin un loopback chiffreur sur la partition de swap ... en plus il n'y a qu'une clef pour tout le swap. Et si on rajoute en live du swap, il faut aussi les encapsuler dans un loopback chiffreur, pfff ... c'est un peu bidouille quand même.

<PUB>
Pour les fans de crypto, OpenBSD fait ça depuis quelques temps déjà mais le chiffrement/déchiffrement se fait au sein des manipulations de swap avec des clefs différentes pour chaque pages (à priori). Donc pas besoin d'encapsulation, un peu plsu de simplicité (en gros sysctl -w vm.swapencrypt.enable=1 et c'est tout bon).
</PUB>

En ce qui concerne le non-bouffage de perfs, c'est vrai ça ne consomme pas trop.
Pour une compilation de qt3+kdebase3+kdelibs3 qui bouffe bien plein de RAM, on sent la différence quand même entre avec et sans mais bon (entre -5 et -10% de temps total de compilation), la sécurité a un prix :)

Sinon, l'intérêt de chiffrer le swap : ça permet de ne pas retrouver en clair sur le disque des données dites sensibles (mots de passe, etc.)
Un exemple simple : plus besoin de mettre gnupg en suid root pour qu'il puisse fixer ses pages en mémoire car il n'a plus aucune raison d'éviter le swap, celui-ci étant « sûr », désormais.

euh ... a propos de ton dernier paragraphe :
Ca ne rajoute pas d'incompatibilite ipf>pf. Et tu le dit toi meme : le programme modifie les regles du firewall. Il n'y a rien de change dans le fichier de config du firewall en question. Tes fichiers ipf resteront facilement transposables sur pf. Le truc c'est qu'avec pf tu as une possibilite supplementaire (et separee de la config globale) : authpf.

Et hop ! J'ai ajoute un commentaire sur le produit demandant comment faire pour ecouter le CD au boulot sur son Mac. Mais il faut attendre au moins 5 jours pour que le commentaire soit publie ... :(

Ça c'est pour les nouveau utilisateurs. Quand tu a déjà 200000 homedirs, tu peux modifier ça tant que tu veux ça ne changera rien. Il faudra scripter un truc pour ajouter le rép partout.
Bon, on chipote tous les deux mais disons que je serais plus tranquille si la fonctionnalité (config utilisateur) était désactivée plutot que de faire confiance à un fichier sensé être immuable.

Finalement (après réflexion) c'est pas mal. Je bloque tout par défaut (sauf SSH) et je n'ouvre mon port imap et smtp que si je suis connecté en SSH, mais imap et smtp demandent quand même une authentification (avec chiffrement SSL).

Ouais, plus simple à mettre en place qu'IPsec mais forcément avec moins de fonctionnalités ... c'est correct. Et puis ça fera toujours ça de charge en moins sur mon démon imap ... (marre des scans de ports de porcs)

Si mais pour chaque utilisateur il faut créer le répertoire et le donner à root, c'est chiant. En bloquant la fonctionnalité au moins on est sûr.

À ce moment, je suppose que putty permet (tout comme le client OpenSSH) de faire du forwarding de port. Il suffit de forwarder vers un proxy (socks ou moins generique) sur la passerelle. C'est plus sûr.

Cela dit, je suis d'accord, c'est pas mal du tout comme truc authpf, surtout si il est rajouté une option pour empêcher de lire le fichier de configuration écrit par l'utilisateur (on peut pour l'instant, il suffit de bourriner dans le source, mais bon).

Sur Amazon[1], il est écrit : non lisible sur PC et MAC. La clientèle d'amazon étant ce qu'elle est, il ne vont pas en vendre beaucoup AMHA. Ou alors les gens ne feront pas gaffe.

[1] http://www.amazon.fr/exec/obidos/ASIN/B00005YXJG/(...)