Il me semble que XP et Linux voient la RAM en sens inverse : là où l'un commence au début, l'autre commence par la fin.
Du coup, il est possible, suivant où se situe l'erreur dans la plage d'adresses, qu'un système accepte de fonctionner jusqu'à un certain point alors que l'autre ne voudra rien entendre.
En l'occurence, ce n'est pas le cas. Les signatures sont correctes, et le certificat de l'AC racine utilisé correspond bien à celui publié par AddTrust.
C'est en effet possible, mais ce n'est en aucun cas une obligation.
L'objectif de la cross-certification est double :
1. permettre la détection d'un spoofing d'AC ;
2. surtout, améliorer l'interopérabilité entre 2 domaines ayant chacun son AC. Avec la double-certification, pas besoin d'ajouter l'AC de l'autre domaine dans sa liste de confiance (puisque la chaîne va remonter jusqu'à "notre" AC).
Eh bien curieusement, Firefox ne m'affiche rien. Je viens de comparer le certificat reçu et celui publié par AddTrust, et oh miracle, ils sont identiques.
Tu as l'alerte de sécurité justement, donc ça ne passe pas. Firefox est super chiant dans ce cas, mais ils ont parfaitement raison.
Et non, il n'y a pas d'alerte de ce type concernant le site des galeries. La seule alerte qu'il y a est que seule une partie de la page bénéficie de la connexion SSL. Rien à voir avec une histoire de MitM.
le second cas est dû à un certificat auto-signé dans la chaîne de certification
Oui, et ?
Les Autorités de Certification (AC) fonctionnent sur un principe hiérarchique. On a :
1. une AC racine forcément auto-signée (ici AddTrust External Root) ;
2. une sous-AC signée par l'AC racine (ici UTN - DATACorp SGC) ;
3. le certificat du site (fr2.lafayettelistes.com).
Il est parfaitement normal que le certificat de l'AC racine apparaisse auto-signé. C'est la définition même d'une AC racine. Ce n'est en aucun cas une erreur.
Le message d'openssl vient du fait que tu n'indique aucune liste de certificats de confiance (liste qui devrait contenir le certificat, comme Firefox le fait par exemple).
Je viens enfin de laisser tomber mon 17" ViewSonic pour un Samsung P2370 (23" TN donc). Je viens de mesurer les écarts de conso (mesure à la prise).
Le 17" même éteint (pas en veille), juste branché pompe déjà 2W. Il monte ensuite à 64W en utilisation normale et 69W en "UltraBrite" (jeux/gimp).
Le 23" éteint ne consomme rien. Ensuite, suivant le réglage de luminosité, il oscille entre 20W (usage normal) et 28.5W (jeux). Le réglage de base de la luminosité est de 100%.
J'utilise maven quotidiennement, mais je ne suis pas pour autant toutes les infos sur le projet (j'ai pas que ça à faire non plus). Donc ta « légitime supposition »...
Ça marche comment en C avec les macros style #ifdef WIN32 ? C'est normalement pris en compte par le pré-processeur, donc perdu dans le bytecode (que le code soit présent dans le bytecode ou pas, la condition est perdue)...
Le support OpenGL ou Direct3D est principalement dans les pilotes. L'architecture des cartes propose les fonctions attendues par ces 2 APIs (pipeline, textures, shaders toussa), mais aucune carte n'a un câblage directement OpenGL ou Direct3D.
Pour t'aider à comprendre, tu peux regarder l'architecture de Gallium3D.
Tiens, c'est étrange, sur mon Macbook unibody, il y a justement une trappe qui permet de retirer la batterie ou le disque dur. Et la doc explique aussi comment changer la RAM...
Et sur une grosse appli, tu arrives à une fragmentation mémoire qui fait qu'au final, tu utilises de plus en plus de mémoire.
C'était le gros problème de Firefox 2.x. Les libérations étaient bien faites, mais la fragmentation était telle que le système n'arrivait pas à efficacement recycler les blocs libérés.
J'ai déjà eu à mettre en place une délégation d'authentification vers LemonLDAP à partir d'un autre système de SSO. En gros, on a 2 S.I., un avec LemonLDAP, l'autre avec un SSO X, et ce dernier doit accepter les authentifications délivrées par le premier. Si dans le S.I. X on reçoit le cookie d'authentification de LemonLDAP, on considère qu'on est déjà authentifié sur l'autre S.I. et on crée silencieusement une nouvelle session.
Ça marche, sauf qu'on n'a aucun moyen de valider le cookie LemonLDAP. Autrement dit, n'importe qui peut se forger un tel cookie et va passer. Ce qui est d'une pourritude sans nom :-/
Je n'ai pas trouvé mention d'un tel service sur le site de LemonLDAP::NG. Est-ce que ça existe enfin ?
[^] # Re: Cela confirme ce que je pense
Posté par Olivier Serve (site web personnel) . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 2.
[^] # Re: pourquoi ils n'utilisent pas une bibliothèque multi-plateforme ?
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Prototype du nouveau thème de Firefox 3.7 sous Linux. Évalué à 1.
Ça a l'énorme avantage de ne pas figer ou planter le navigateur à cause d'un plugin foireux (qui a dit flash ?).
[^] # Re: correction d'erreur linux vs windows
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Une analyse précieuse sur la fiabilité de la mémoire vive DRAM. Évalué à 7.
Du coup, il est possible, suivant où se situe l'erreur dans la plage d'adresses, qu'un système accepte de fonctionner jusqu'à un certain point alors que l'autre ne voudra rien entendre.
[^] # Re: Sécurité
Posté par Olivier Serve (site web personnel) . En réponse au journal Des paiements non sécurisés ?. Évalué à 1.
[^] # Re: Aucun problème de certificat
Posté par Olivier Serve (site web personnel) . En réponse au journal Des paiements non sécurisés ?. Évalué à 2.
L'objectif de la cross-certification est double :
1. permettre la détection d'un spoofing d'AC ;
2. surtout, améliorer l'interopérabilité entre 2 domaines ayant chacun son AC. Avec la double-certification, pas besoin d'ajouter l'AC de l'autre domaine dans sa liste de confiance (puisque la chaîne va remonter jusqu'à "notre" AC).
[^] # Re: Aucun problème de certificat
Posté par Olivier Serve (site web personnel) . En réponse au journal Des paiements non sécurisés ?. Évalué à 0.
[^] # Re: Sécurité
Posté par Olivier Serve (site web personnel) . En réponse au journal Des paiements non sécurisés ?. Évalué à 1.
Et non, il n'y a pas d'alerte de ce type concernant le site des galeries. La seule alerte qu'il y a est que seule une partie de la page bénéficie de la connexion SSL. Rien à voir avec une histoire de MitM.
[^] # Re: Sécurité
Posté par Olivier Serve (site web personnel) . En réponse au journal Des paiements non sécurisés ?. Évalué à 0.
[^] # Re: Aucun problème de certificat
Posté par Olivier Serve (site web personnel) . En réponse au journal Des paiements non sécurisés ?. Évalué à 2.
liste qui devrait contenir le certificat racine d'AddTrust
[^] # Re: Sécurité
Posté par Olivier Serve (site web personnel) . En réponse au journal Des paiements non sécurisés ?. Évalué à -1.
Tu m'explique comment tu fais un MitM sur une connexion SSL sans voler la clé privée ?
# Aucun problème de certificat
Posté par Olivier Serve (site web personnel) . En réponse au journal Des paiements non sécurisés ?. Évalué à 3.
Oui, et ?
Les Autorités de Certification (AC) fonctionnent sur un principe hiérarchique. On a :
1. une AC racine forcément auto-signée (ici AddTrust External Root) ;
2. une sous-AC signée par l'AC racine (ici UTN - DATACorp SGC) ;
3. le certificat du site (fr2.lafayettelistes.com).
Il est parfaitement normal que le certificat de l'AC racine apparaisse auto-signé. C'est la définition même d'une AC racine. Ce n'est en aucun cas une erreur.
Le message d'openssl vient du fait que tu n'indique aucune liste de certificats de confiance (liste qui devrait contenir le certificat, comme Firefox le fait par exemple).
Beaucoup de bruit pour rien.
[^] # Re: pareil par ici
Posté par Olivier Serve (site web personnel) . En réponse au journal Ordinosaure. Évalué à 2.
Le 17" même éteint (pas en veille), juste branché pompe déjà 2W. Il monte ensuite à 64W en utilisation normale et 69W en "UltraBrite" (jeux/gimp).
Le 23" éteint ne consomme rien. Ensuite, suivant le réglage de luminosité, il oscille entre 20W (usage normal) et 28.5W (jeux). Le réglage de base de la luminosité est de 100%.
[^] # Re: oui mais...
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 1.
J'utilise maven quotidiennement, mais je ne suis pas pour autant toutes les infos sur le projet (j'ai pas que ça à faire non plus). Donc ta « légitime supposition »...
[^] # Re: Rhaaa ! Trop bon.
Posté par Olivier Serve (site web personnel) . En réponse au journal Kde 4.4: Où en est on?. Évalué à 2.
[^] # Re: feu
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche OOo4Kids version 0.5 beta disponible au téléchargement. Évalué à 10.
# Bytecode vraiment portable ?
Posté par Olivier Serve (site web personnel) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 4.
[^] # Re: parce que je n'ai que cela à faire
Posté par Olivier Serve (site web personnel) . En réponse au journal Une analyse du développement du noyau Linux. Évalué à 7.
De qualité, non. On se croirait revenus en 1995.
[^] # Re: Intéressant
Posté par Olivier Serve (site web personnel) . En réponse au journal Expérience d'un musicien qui abandonne le Mac pour Linux. Évalué à 2.
J'ai pas PulseAudio mais Flash fonctionne comme à son habitude (je n'ose dire bien), avec le son.
[^] # Re: Pourquoi perdre du temps sur du propriétaire ?
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Kmess, Live messenger tout simplement. Évalué à 2.
[^] # Re: implémentation hardware
Posté par Olivier Serve (site web personnel) . En réponse au journal Sortie d'OpenGL 3.2. Évalué à 7.
Pour t'aider à comprendre, tu peux regarder l'architecture de Gallium3D.
# Page d'accueil en YAML ?
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 3.
[^] # Re: Apple
Posté par Olivier Serve (site web personnel) . En réponse au journal Manger des pommes.. Évalué à 2.
[^] # Re: Validation du cookie ?
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Sortie de LemonLDAP::NG 0.9.4. Évalué à 1.
Maintenant, il ne reste plus que mettre à jour leur LemonLDAP...
[^] # Re: Intéressant
Posté par Olivier Serve (site web personnel) . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 5.
C'était le gros problème de Firefox 2.x. Les libérations étaient bien faites, mais la fragmentation était telle que le système n'arrivait pas à efficacement recycler les blocs libérés.
# Validation du cookie ?
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Sortie de LemonLDAP::NG 0.9.4. Évalué à 3.
Ça marche, sauf qu'on n'a aucun moyen de valider le cookie LemonLDAP. Autrement dit, n'importe qui peut se forger un tel cookie et va passer. Ce qui est d'une pourritude sans nom :-/
Je n'ai pas trouvé mention d'un tel service sur le site de LemonLDAP::NG. Est-ce que ça existe enfin ?