Dernièrement m'a pris l'idée de recompiler virt-manager de redhat qui avait l'air sympathique.
Chaque paquet dépend d'un nombre innombrable de trucs qui eux-mêmes dépendent de machins qui sont souvent dans des version instables avec des machins à rebours terrible quand la lib qui te permet de recompiler un paquet te dit que le second paquet qui dépend du premier est trop récent. Mais le premier paquet est du coup trop récent par rapport à la lib et il faut tout reprendre de zéro en espérant qu'au final ça passe...
Bien sûr, pas de docs donnant la liste des versions à un instant 't' qui fonctionne ainsi que les dépendances secondaires... (genre X-window, par exemple).
Honnêtement, les histoires de phidget, de cartes colibri et tout ça, c'est quand même un peu du passé.
Des gars au MIT on fait pleins de petits trucs rigolos, mais au final rien d'intéressant n'en est sorti.
Cf: http://ambient.media.mit.edu/ ou l'on trouve par exemple: http://web.media.mit.edu/~dmerrill/siftables.html
Comme indiqué, c'est rigolo, mais bon, que faire de ce genre de trucs? Honnetement? Même les stickies, ça à l'air sympa, mais qui voudrait utiliser ce truc?
A mon avis, tout est présent pour faire de l'ubiquitous computing, mais pas avec ces machins, il faut bien évidemment utiliser les téléphones portables! Ils sont de plus en plus puissant, ils communiquent de plus en plus (GSM, wifi, bluetooth) il faut partir dans cette direction. Google va sortir une reconnaissance d'images, il y a la réalité augmentée qui va casser la baraque!
Le problème avec la réalité augmentée, c'est le non échange entre les téléphones. La dessus, il y aurait à faire. Quel capteur ajouter sur un téléphone? GPS? pourquoi pas. Mouvement? Positionnement, je pense encore oui. Ensuite, quelle information échanger? La géolocalisation, ok. Eventuellement dans un musée ou une salle de cinéma ou un embouteillage. Coupler avec de la reconnaissance optique, ça pourrait bien déchirer, je pense.
Ex: tu es dans ta voiture, embouteillage. Tu sors ton téléphone, et tu visionnes via la caméra la route. En temps réél et en surimpression écran, tu as les différentes durées de trajet jusqu'à ta destination selon la route prise. Mais l'image que tu prends est aggrégée avec d'autres images que d'autres automobilistes prennent. Par exemple, la seconde route est bloquée par un accident. Un autre utilisateur a pris cette image, géolocalisée. Cet itinéraire t'est instantanément montré comme peu intéressant. Le téléphone vérifie que les pompiers ont bien été appelé, et les premières images de l'accident sont envoyées. Etc, etc..
Un système collaboratif non intrusif qui permettrait énormément de choses.
Pour les bugs reports, je n'en ai fait aucun. J'ai vu qu'il en existait, vachement mieux décrit que ce que j'aurais pu faire. Donc je suis venu raler sur linuxfr puisque je n'ai rien de mieux à faire :)
"Dans ce cas les premieres requetes du mechant seront reboutee parce que pas encore logge, et par la suite il ne peut plus rien faire, donc il est baise."
Si si, et c'est là ou l'attaque est percutante.
L'attaquant peut forger un début de requête, mais pas la suite.
Alice pense envoyer un entête HTTP:
GET /secure/moncompte.html
Host: mabanque
Authent: mon-authent-que-j'ai
Cookie: blablabla
Mais l'attaquant peut ajouter en préambule quelque chose. L'idée de l'attaquant c'est d'ajouter une ligne d'entête 'avaleuse', cf:
GET /secure/moncompte/virement-plein-de-pepetes
X-blackhole: -- attention il n'y a pas de retour chariot ici.
Puis il lance les renégos, etc...
La requête parvenant à la banque sera donc:
GET /secure/moncompte/virement-plein-de-pepetes
X-blackhole: GET /secure/moncompte.html
Host: mabanque
Authent: mon-authent-que-j'ai
Cookie: blablabla
HTTP-ptotocolairement parlant, c'est valide. Les lignes d'entete démarrant par X sont ignorées, et l'attaquant récupère du même coup les credentials d'authent, les cookies éventuels, etc etc..
Mais avec les explications, c'est très pratique :-)
Ceci dit, pour monter des images disques j'utilise qemu-nbd.
Ca fonctionne très bien avec tous les formats supportés par qemu.
Il n'y a pas de liens vers qemu, c'est dommage, c'est vraiment une super solution de virtualisation pour le cloisonnement, tout ça.
Pour spice, ça a l'air super intéressant, effectivement.
Xen, j'ai complètement abandonné. Comme tu le dis, c'est fouilli, c'est compliqué, c'est le bronx de partout.
KVM, par contre, faut que je m'y remette.
Enfin, je conseille toujours lguest, c'est ce que j'utilise actuellement. C'est loin d'être aussi complet que les autres solutions de virtualisation, mais pour ce que je fais (test de pleins de trucs gruik en console sous linux) ça me convient très bien.
Posté par octane .
En réponse au journal Proxmox-ve.
Évalué à 1.
Avec le confinement type OpenVZ, les pertes sont _presque_ nulles.
Et donc tout est dans ce _presque_ .
Et tous les programmeurs d'hyperviseurs disent: wé, wé, on est vitesse native. Quand on creuse, ça se transforme en ''wé, c'est du presque natif, hein''. L'ennuyeux, c'est ce presque. A combien faut il l'estimer?
Ensuite, ce ''presque'', c'est une fonction qui dépend du nombre de machines invitées, ou pas? qui dépend de l'utilisation faite de ou des invités (genre I/O plus que CPU ou inversement).
C'est ce manque de chiffres que je trouve dommage.
Posté par octane .
En réponse au journal Proxmox-ve.
Évalué à 4.
Mais le noyau d'openVZ est modifié. Modifié justement pour permettre le lancement de plusieurs instances.
Donc qu'il tourne _strictement_ aussi vite qu'un noyau normal, ça m'étonne. Quil s'approche nominalement de la vitesse d'un noyau normal OK.
Mais lorsque je lis''les VMs sont aussi rapides qu'en normal'', bin non. Là, je veux casser du mot de passe, par exemple. Sur ma machine (unique), ça prend du temps:
20770 pts/2 RN+ 25610:16 ./john passwd
Alors je vais installer sur ma machine un VZ, puis un cluster de 1000 machines donc j'irais 1000 fois plus vite?
La virtualisation, c'est bien, c'est plein de qualités, mais un des principes de la virtualisation, c'est de se baser sur le fait que le soft actuel n'utilise pas entièrement la puissance offerte par le hard.
Dès lors, oui, ''apparement'' on peut faire tourner plusieurs machines qui ont une vitesse ''apparente'' aussi rapide; mais si on commence à creuser, on se rend compte que ce n'est plus vrai du tout...
J'ai un autre exemple avec du débit réseau qui est au taquet d'une carte gigabit. Sur cette carte gigabit, un hyperviseur qui redistribue trois VM. Pas de chances, mes VM ne bénéficient pas de 3x 1Gbit/s. Quel dommage!
Et donc, à chaque fois que je lis ''mais si ma solution de virtualisation permet de faire fonctionner à vitesse native 'x' machines'' je râle. La virtualisation, ce n'est pas natif.
Je rapproche plus la virtualisation au concept du temps partagé d'unix. On est passé d'un système monoprocessus, à un système multiprocessus (multiutilisateur). De manière brute, un processus va plus lentement. De manière générale, l'ensemble des processus va plus vite que s'ils étaient lancés séquentiellement.
Pour la virtualisation, pareil. Les machines ne fichant rien 70% du temps, il est plus rentable de les coller toutes sur le même hardware. Globalement, on y gagne, même si certains cas limites sont problématiques...
Posté par octane .
En réponse au journal Proxmox-ve.
Évalué à 1.
Les VM sont aussi rapide qu'en natif.
Je n'y crois pas une seule seconde. Qu'on soit proche de la rapidité d'un OS unique sur le même hardware, lorsqu'une seule VM tourne pourquoi pas; mais là, l'interêt consiste à connaître la baisse de perfs, et ou (I/O, CPU, etc..)
L'espace disque utilisé est divisé par 10 par rapport à la virtualisation complète car il est mutualisé (1 seul FS pour toute les VM).
Je croyais que c'était openVZ qui faisait ça. Pour KVM, on a encore une image disque?
La migration à froid n'occasionne qu'une coupure inférieur à 5 secondes
S'il s'agit d'une migration à froid, le downtime, on s'en fiche, non?
Ceci dit: L'attaquant a juste besoin de consulter sa base avec le login recherchait et de tester tous les mots de passes qu'il a pu récolté pour ce login. Bref , beaucoup plus rapide qu'un brut force ^^.
Oui, et ça se fait beaucoup. Trouver un bon fichier de mots de passe c'est difficile. Et les pirates partagent peu ce genre de fichiers. Ils permettent de casser à une vitesse impressionnante énormément de mots de passe.
Il est difficile de casser un mot de passe précis, mais lorsque tu tombes sur un site communautaire, tu as de grandes chances de casser très vite la majorité des mots de passes à l'aide de ce type de fichiers.
4 milliard d'humain, 1 à 10 mot passe par humain , chacun faisant 1 à 10 caractères. Dans le meilleurs des cas, 4 milliard * 10 * 10 = 400 milliard d'octet soit une base de 400 Go.
Heu..
4 milliards d'humain qui ont plusieurs comptes, donc plusieurs logins. (je devrais compter le nombre de login que j'utilise, mais à première vue je dirais plus de 20 facile).
Ensuite:
10 mots de passes de 10 caractères ==> 10x10 = 100 ???? WTF
Si tu as 10 caractères dans un mot de passe, tu as un choix (bas) de 62 caractères par caractères (26 lettres min, 26 lettres maj, 10 chiffres et je ne compte pas les caractères spéciaux..) donc c'est 62^10 possibilités...
Si je recompte, on obtient donc, rien que pour les mots de passe: 745 Petta Octets de données....
Ensuite, tu indiques que les mots de passe sont stockés sur le site de sourceforge. J'espère que ce n'est pas le cas. Normalement, les mots de passe sont hachés. Lorsque tu donnes ton mot de passe, il est haché à son tour et les hashs sont comparés. (Regarde le contenu de ton /etc/shadow par exemple, les mots de passe ne sont pas présents. De plus, pour éviter les attaques par précalcul des hash, les mots de passes sont souvent 'salés' puis hachés. Le sel est contenu entre les $ du mot de passe. Le mot de passe est toujours: $sel$hash si tu regardes bien).
Ceci dit, pleins de sites conservent les mots de passe en clair, mais c'est MAL.
Et pour finir, ton point 5) 5) Exécutez le programme sur une machine seine et m'assurer que celle-ci ne présente pas de signe de compromission à l'exécution
C'est sans doute le plus dur... Imagine un attaquant qui introduit un subtil buffer overflow dans ton code. Une exécution du code ne le trouvera pas. N'oublie pas, comme disais un grand chercheur en sécurité:
un programme fiable, c'est un programme qui fait ce qu'on lui demande. Un programme secure, c'est un programme qui ne fait que ce qui lui est demandé
N'oublions pas que c'est pour de vieilles personnes, moins il y a de fils, mieux c'est, le clavier se cache sous l'écran (ce qui sera sa place 99% du temps sauf les jours ou ils ''iront sur internet''), ce machin ne s'upgradera jamais (sous linux, j'espere être tranquille pour + de cinq ans avec ce matos), et surtout l'écran est _grand_. Pour des vieilles personnes, encore, c'est essentiel.
Ca coute 350euros, moins cher effectivement qu'un ecran 21'' Et surtout beaucoup moins cher qu'un iMac (le concept ressemble vachement).
L'objectif du truc c'est vraiment je l'installe, et surtout JE L'OUBLIE! Administrer des machines, c'est bien, mais administrer le week end les machines de la famille, ca va un moment..
Après test, donc Moblin c'est Bof, KDE m'a l'air surprenant (à tester plus longuement, quoi); easy peasy m'a l'air pas mal. Il y a trop d'onglets sur la gauche, mais ça doit bien se configurer quelque part. J'aurais besoin de
1. Internet (avec firefox sur google, firefox sur wikipedia, et firefox sur un site ou un autre)
2. travail avec Openoffice calc et openoffice writer
3. autres: Jeux de cartes et webradio.
elles n'existent plus : tu peux toujours chercher, les netbooks vendus sous GNU/Linux, c'est fini.
A la limite, mais j'ai hélas pas trop le temps pour en ce moment, je pensais juste récupérer la surcouche Acer Aspire. Dessous, c'est une Fedora et XFCE.
Si je pouvais juste extraire cet espèce de menu en 4 blocs pour le replaquer sur un autre XFCE, en conservant les paramètres (tout s'ouvre en full screen etc..) ça m'irait bien.
[^] # Re: Si quelqu'un a le temps :
Posté par octane . En réponse à la dépêche Comment détruire votre communauté. Évalué à 4.
Chaque paquet dépend d'un nombre innombrable de trucs qui eux-mêmes dépendent de machins qui sont souvent dans des version instables avec des machins à rebours terrible quand la lib qui te permet de recompiler un paquet te dit que le second paquet qui dépend du premier est trop récent. Mais le premier paquet est du coup trop récent par rapport à la lib et il faut tout reprendre de zéro en espérant qu'au final ça passe...
Bien sûr, pas de docs donnant la liste des versions à un instant 't' qui fonctionne ainsi que les dépendances secondaires... (genre X-window, par exemple).
Et ça, c'est vachement bii----p.
# M****s
Posté par octane . En réponse au journal Ayez les cou**** d'assumer votre grossièreté. Évalué à 4.
E* h********t s***n l****e ne v****t r**n d**r.
[^] # Re: Extension des jeux de rôle grandeur nature ?
Posté par octane . En réponse au journal Le jeu auquel vous ne jouerez pas. Évalué à 4.
Je cherche sur google, je ne vois rien, mais ça m'intéresse énormément.
[^] # Re: Rien
Posté par octane . En réponse au journal Le jeu auquel vous ne jouerez pas. Évalué à 10.
Le nexus one a aussi une caméra et un écran. Comme la majorité des smartphones.
# Un ancien journal
Posté par octane . En réponse au journal Cache du système de fichier en RAM. Évalué à 3.
Lis les commentaires, il ya une ou deux amélios.
Ca marche très bien, je n'utilise plus que ça.
# ambient intelligence etc...
Posté par octane . En réponse au journal Ubiquitous computing. Évalué à 9.
Honnêtement, les histoires de phidget, de cartes colibri et tout ça, c'est quand même un peu du passé.
Des gars au MIT on fait pleins de petits trucs rigolos, mais au final rien d'intéressant n'en est sorti.
Cf: http://ambient.media.mit.edu/ ou l'on trouve par exemple:
http://web.media.mit.edu/~dmerrill/siftables.html
Comme indiqué, c'est rigolo, mais bon, que faire de ce genre de trucs? Honnetement? Même les stickies, ça à l'air sympa, mais qui voudrait utiliser ce truc?
A mon avis, tout est présent pour faire de l'ubiquitous computing, mais pas avec ces machins, il faut bien évidemment utiliser les téléphones portables! Ils sont de plus en plus puissant, ils communiquent de plus en plus (GSM, wifi, bluetooth) il faut partir dans cette direction. Google va sortir une reconnaissance d'images, il y a la réalité augmentée qui va casser la baraque!
Le problème avec la réalité augmentée, c'est le non échange entre les téléphones. La dessus, il y aurait à faire. Quel capteur ajouter sur un téléphone? GPS? pourquoi pas. Mouvement? Positionnement, je pense encore oui. Ensuite, quelle information échanger? La géolocalisation, ok. Eventuellement dans un musée ou une salle de cinéma ou un embouteillage. Coupler avec de la reconnaissance optique, ça pourrait bien déchirer, je pense.
Ex: tu es dans ta voiture, embouteillage. Tu sors ton téléphone, et tu visionnes via la caméra la route. En temps réél et en surimpression écran, tu as les différentes durées de trajet jusqu'à ta destination selon la route prise. Mais l'image que tu prends est aggrégée avec d'autres images que d'autres automobilistes prennent. Par exemple, la seconde route est bloquée par un accident. Un autre utilisateur a pris cette image, géolocalisée. Cet itinéraire t'est instantanément montré comme peu intéressant. Le téléphone vérifie que les pompiers ont bien été appelé, et les premières images de l'accident sont envoyées. Etc, etc..
Un système collaboratif non intrusif qui permettrait énormément de choses.
[^] # Re: Archlinux - configuration identique
Posté par octane . En réponse au journal Intel 82845, windows, double video et rant gratuit. Évalué à 3.
Pour les bugs reports, je n'en ai fait aucun. J'ai vu qu'il en existait, vachement mieux décrit que ce que j'aurais pu faire. Donc je suis venu raler sur linuxfr puisque je n'ai rien de mieux à faire :)
[^] # Re: et sinon ...
Posté par octane . En réponse au journal Intel 82845, windows, double video et rant gratuit. Évalué à 2.
Aujourd'hui, le fichier de conf Xorg est vide, grâce aux dernières versions de X.
De fait, je ne sais plus du tout comment modifier les paramètres :-/
[^] # Re: "rant"
Posté par octane . En réponse au journal Intel 82845, windows, double video et rant gratuit. Évalué à 1.
Et d'ailleurs, le double vidéo du titre n'a rien à foutre là. C'est une erreur.
(là, vous avez le droit de faire du rant contre les gugus qui postent des journaux avec un titre sans rapport :) )
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par octane . En réponse au journal Attaque contre SSL/TLS. Évalué à 4.
Si si, et c'est là ou l'attaque est percutante.
L'attaquant peut forger un début de requête, mais pas la suite.
Alice pense envoyer un entête HTTP:
GET /secure/moncompte.html
Host: mabanque
Authent: mon-authent-que-j'ai
Cookie: blablabla
Mais l'attaquant peut ajouter en préambule quelque chose. L'idée de l'attaquant c'est d'ajouter une ligne d'entête 'avaleuse', cf:
GET /secure/moncompte/virement-plein-de-pepetes
X-blackhole: -- attention il n'y a pas de retour chariot ici.
Puis il lance les renégos, etc...
La requête parvenant à la banque sera donc:
GET /secure/moncompte/virement-plein-de-pepetes
X-blackhole: GET /secure/moncompte.html
Host: mabanque
Authent: mon-authent-que-j'ai
Cookie: blablabla
HTTP-ptotocolairement parlant, c'est valide. Les lignes d'entete démarrant par X sont ignorées, et l'attaquant récupère du même coup les credentials d'authent, les cookies éventuels, etc etc..
# 16h?!!
Posté par octane . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 5.
Ah, j'ai pas compris? :)
# Encore un journal pour mettre des liens
Posté par octane . En réponse au journal Un petit tour sur le paysage de la virtualisation Linux. Évalué à 1.
Ceci dit, pour monter des images disques j'utilise qemu-nbd.
Ca fonctionne très bien avec tous les formats supportés par qemu.
Il n'y a pas de liens vers qemu, c'est dommage, c'est vraiment une super solution de virtualisation pour le cloisonnement, tout ça.
Pour spice, ça a l'air super intéressant, effectivement.
Xen, j'ai complètement abandonné. Comme tu le dis, c'est fouilli, c'est compliqué, c'est le bronx de partout.
KVM, par contre, faut que je m'y remette.
Enfin, je conseille toujours lguest, c'est ce que j'utilise actuellement. C'est loin d'être aussi complet que les autres solutions de virtualisation, mais pour ce que je fais (test de pleins de trucs gruik en console sous linux) ça me convient très bien.
[^] # Re: Hop
Posté par octane . En réponse au journal Proxmox-ve. Évalué à 1.
Et donc tout est dans ce _presque_ .
Et tous les programmeurs d'hyperviseurs disent: wé, wé, on est vitesse native. Quand on creuse, ça se transforme en ''wé, c'est du presque natif, hein''. L'ennuyeux, c'est ce presque. A combien faut il l'estimer?
Ensuite, ce ''presque'', c'est une fonction qui dépend du nombre de machines invitées, ou pas? qui dépend de l'utilisation faite de ou des invités (genre I/O plus que CPU ou inversement).
C'est ce manque de chiffres que je trouve dommage.
[^] # Re: Hop
Posté par octane . En réponse au journal Proxmox-ve. Évalué à 4.
Donc qu'il tourne _strictement_ aussi vite qu'un noyau normal, ça m'étonne. Quil s'approche nominalement de la vitesse d'un noyau normal OK.
Mais lorsque je lis''les VMs sont aussi rapides qu'en normal'', bin non. Là, je veux casser du mot de passe, par exemple. Sur ma machine (unique), ça prend du temps:
20770 pts/2 RN+ 25610:16 ./john passwd
Alors je vais installer sur ma machine un VZ, puis un cluster de 1000 machines donc j'irais 1000 fois plus vite?
La virtualisation, c'est bien, c'est plein de qualités, mais un des principes de la virtualisation, c'est de se baser sur le fait que le soft actuel n'utilise pas entièrement la puissance offerte par le hard.
Dès lors, oui, ''apparement'' on peut faire tourner plusieurs machines qui ont une vitesse ''apparente'' aussi rapide; mais si on commence à creuser, on se rend compte que ce n'est plus vrai du tout...
J'ai un autre exemple avec du débit réseau qui est au taquet d'une carte gigabit. Sur cette carte gigabit, un hyperviseur qui redistribue trois VM. Pas de chances, mes VM ne bénéficient pas de 3x 1Gbit/s. Quel dommage!
Et donc, à chaque fois que je lis ''mais si ma solution de virtualisation permet de faire fonctionner à vitesse native 'x' machines'' je râle. La virtualisation, ce n'est pas natif.
Je rapproche plus la virtualisation au concept du temps partagé d'unix. On est passé d'un système monoprocessus, à un système multiprocessus (multiutilisateur). De manière brute, un processus va plus lentement. De manière générale, l'ensemble des processus va plus vite que s'ils étaient lancés séquentiellement.
Pour la virtualisation, pareil. Les machines ne fichant rien 70% du temps, il est plus rentable de les coller toutes sur le même hardware. Globalement, on y gagne, même si certains cas limites sont problématiques...
# Hop
Posté par octane . En réponse au journal Proxmox-ve. Évalué à 1.
Je n'y crois pas une seule seconde. Qu'on soit proche de la rapidité d'un OS unique sur le même hardware, lorsqu'une seule VM tourne pourquoi pas; mais là, l'interêt consiste à connaître la baisse de perfs, et ou (I/O, CPU, etc..)
L'espace disque utilisé est divisé par 10 par rapport à la virtualisation complète car il est mutualisé (1 seul FS pour toute les VM).
Je croyais que c'était openVZ qui faisait ça. Pour KVM, on a encore une image disque?
La migration à froid n'occasionne qu'une coupure inférieur à 5 secondes
S'il s'agit d'une migration à froid, le downtime, on s'en fiche, non?
[^] # Re: Mots de passe? 400Go??
Posté par octane . En réponse au journal Compromission de code source.. Évalué à 2.
Je ne comprends pas plus ton calcul 10 x10..
Ceci dit:
L'attaquant a juste besoin de consulter sa base avec le login recherchait et de tester tous les mots de passes qu'il a pu récolté pour ce login. Bref , beaucoup plus rapide qu'un brut force ^^.
Oui, et ça se fait beaucoup. Trouver un bon fichier de mots de passe c'est difficile. Et les pirates partagent peu ce genre de fichiers. Ils permettent de casser à une vitesse impressionnante énormément de mots de passe.
Il est difficile de casser un mot de passe précis, mais lorsque tu tombes sur un site communautaire, tu as de grandes chances de casser très vite la majorité des mots de passes à l'aide de ce type de fichiers.
Il n'y a pas longtemps, le site phpBB s'était fait pirater. Et un gars s'était amusé à faire des stats sur les mots de passe utilisés.
C'est là
http://pentester.fr/blog/index.php?post/2009/02/09/Audit-des(...)
et c'est super instructif.
# Mots de passe? 400Go??
Posté par octane . En réponse au journal Compromission de code source.. Évalué à 0.
Heu..
4 milliards d'humain qui ont plusieurs comptes, donc plusieurs logins. (je devrais compter le nombre de login que j'utilise, mais à première vue je dirais plus de 20 facile).
Ensuite:
10 mots de passes de 10 caractères ==> 10x10 = 100 ???? WTF
Si tu as 10 caractères dans un mot de passe, tu as un choix (bas) de 62 caractères par caractères (26 lettres min, 26 lettres maj, 10 chiffres et je ne compte pas les caractères spéciaux..) donc c'est 62^10 possibilités...
Si je recompte, on obtient donc, rien que pour les mots de passe: 745 Petta Octets de données....
Ensuite, tu indiques que les mots de passe sont stockés sur le site de sourceforge. J'espère que ce n'est pas le cas. Normalement, les mots de passe sont hachés. Lorsque tu donnes ton mot de passe, il est haché à son tour et les hashs sont comparés. (Regarde le contenu de ton /etc/shadow par exemple, les mots de passe ne sont pas présents. De plus, pour éviter les attaques par précalcul des hash, les mots de passes sont souvent 'salés' puis hachés. Le sel est contenu entre les $ du mot de passe. Le mot de passe est toujours: $sel$hash si tu regardes bien).
Ceci dit, pleins de sites conservent les mots de passe en clair, mais c'est MAL.
Et pour finir, ton point 5)
5) Exécutez le programme sur une machine seine et m'assurer que celle-ci ne présente pas de signe de compromission à l'exécution
C'est sans doute le plus dur... Imagine un attaquant qui introduit un subtil buffer overflow dans ton code. Une exécution du code ne le trouvera pas. N'oublie pas, comme disais un grand chercheur en sécurité:
un programme fiable, c'est un programme qui fait ce qu'on lui demande. Un programme secure, c'est un programme qui ne fait que ce qui lui est demandé
[^] # Re: PC-Frigo , portabilty over efficency ?
Posté par octane . En réponse au journal Distribution linux simplifiée. Évalué à 2.
http://www.blogeee.net/2009/07/24/presentation-video-du-acer(...)
N'oublions pas que c'est pour de vieilles personnes, moins il y a de fils, mieux c'est, le clavier se cache sous l'écran (ce qui sera sa place 99% du temps sauf les jours ou ils ''iront sur internet''), ce machin ne s'upgradera jamais (sous linux, j'espere être tranquille pour + de cinq ans avec ce matos), et surtout l'écran est _grand_. Pour des vieilles personnes, encore, c'est essentiel.
Ca coute 350euros, moins cher effectivement qu'un ecran 21'' Et surtout beaucoup moins cher qu'un iMac (le concept ressemble vachement).
L'objectif du truc c'est vraiment je l'installe, et surtout JE L'OUBLIE! Administrer des machines, c'est bien, mais administrer le week end les machines de la famille, ca va un moment..
Après test, donc Moblin c'est Bof, KDE m'a l'air surprenant (à tester plus longuement, quoi); easy peasy m'a l'air pas mal. Il y a trop d'onglets sur la gauche, mais ça doit bien se configurer quelque part. J'aurais besoin de
1. Internet (avec firefox sur google, firefox sur wikipedia, et firefox sur un site ou un autre)
2. travail avec Openoffice calc et openoffice writer
3. autres: Jeux de cartes et webradio.
[^] # Re: LXDE va plus vite
Posté par octane . En réponse au journal Distribution linux simplifiée. Évalué à 2.
Et puis ce gros tas d'icônes..
Ce n'est pas pour moi, mais bien pour une personne agée, donc bon si on peut avoir un truc ou deux coloré, c'est tout de même plus sympa..
[^] # Re: KDE Plasma Netbook
Posté par octane . En réponse au journal Distribution linux simplifiée. Évalué à 1.
[^] # Re: Distributions ASUS et compagnie
Posté par octane . En réponse au journal Distribution linux simplifiée. Évalué à 2.
A la limite, mais j'ai hélas pas trop le temps pour en ce moment, je pensais juste récupérer la surcouche Acer Aspire. Dessous, c'est une Fedora et XFCE.
Si je pouvais juste extraire cet espèce de menu en 4 blocs pour le replaquer sur un autre XFCE, en conservant les paramètres (tout s'ouvre en full screen etc..) ça m'irait bien.
[^] # Re: wikiliens
Posté par octane . En réponse au journal Un nouvel espoir pour la voiture électrique?. Évalué à 6.
[^] # Re: Viralité positive
Posté par octane . En réponse au journal Microsoft sort un pilote libre : du flan !. Évalué à 8.
comme d'habitude dans le monde de la virtualisation, je suis à peu près sûr que c'est du code de qemu. qemu c'est bon, mangez-en.
[^] # Re: Générateur matériel?
Posté par octane . En réponse à la dépêche Générer des nombres aléatoires avec Hasard 0.9.6. Évalué à 2.
Ceci dit, pourquoi ne pas utiliser uniquement cette source aléatoire 'forte' comme graîne d'une suite génératrice d'aléa software, donc rapide?
[^] # Re: Hum...
Posté par octane . En réponse à la dépêche Générer des nombres aléatoires avec Hasard 0.9.6. Évalué à 4.