Le choix des logiciels libres est souvent argumenté en avançant la stabilité et la sécurité ; cela ne tient pas uniquement à la qualité intrinsèque du code et d'accès aux sources
Non ca certainement pas, parce que les LL ne sont pas plus stables ou plus surs, et l'acces aux sources n'amene pas grand chose de ce cote la (la preuve : ils ne sont pas plus stables ou plus surs justement).
mais aussi du fait que l'on essaye d'apprendre aux gens à ne pas faire "tout et n'importe quoi" avec le système, y compris utiliser le compte root sans raison.
Non ca a surtout a voir que Linux derive d'Unix (tous ces principes de securite viennent d'Unix, pas du libre) et a toujours ete pousse dans une optique serveur plutot que grand publique. C'est pas par hasard qu'il a fait un bide sur le desktop.
Si tu veux simplement lire le fichier PDF oui, mais quand tu as des operations a faire dessus (conversion, etc…) va bien falloir faire le parsing du PDF, stocker tes objets, etc…
Ben non :/ C'est juste découpé en morceau et traité en morceau.
Mais de nouveau, c'est le cas uniquement si ton probleme se prete a etre traite en morceaux.
Peut-être chez toi. Mais pas chez moi.
Quand t'es le gars qui ecrit le soft, t'as aucun controle la dessus, t'es sense faire pour que cela marche dans la plupart des cas correctement.
???
Selon la fragmentation de l'espace memoire du soft, t'as beau avoir 60Mb de libre, tu n'arriveras pas a faire une alloc de plus de 2Mb…
Et pour quoi donc avec morcellement ? On garantit juste que 1024 clients seront très bien servis ! Tant pis pour les autres. De toutes manières le système ne supportera pas mieux.
Ce sera vrai uniquement si tu prealloue 1024 blocs de 8Mb, resultat tu forces ton processus a avoir 8Gb alloues tout le temps, super…. (et evidemment en imaginant que ton probleme se prete au modele ou aucune autre allocation dynamique est necessaire)
Et sur Windows c'est 1Mb… Dans un systeme avec plein de processus et/ou threads, ca commence a te couter pas mal et tu vas le reduire.
Tu ne réserves pas vraiment. Tu alloues sur le stack.
J'ai bien compris, mais quand tu fais ca dans une librairie, tu ne sais pas tout ce qu'il y a au dessus de toi sur la stack, resultat tu tend a etre conservateur pour eviter de te prendre un stack overflow.
Pour les serveurs, travailler par petits morceau, minimiser les allocations, ce sont de très très bonnes pratiques.
Tout a fait, quand c'est possible. Le truc est qu'il y a plein de cas ou tu n'as pas trop le choix parce que le probleme ne s'y prete pas.
Tous les cas ou ta taille de bloc est "presque" aleatoire par exemple. Si tu ne sais pas d'avance quelle taille tu va devoir gerer, tu dois soit allouer dynamiquement, soit avoir un tas de buffers gardes de cote que tu n'utilises quasiment jamais et qui coutent sur le systeme.
Ça tombe bien j'ai dis qu'il fallait l'ignorer (windows fait quoi lorsqu'il n'a plus de mémoire ?).
Tout depend de l'operation. Si c'est le noyau qui fait l'allocation et c'est pour un truc absolument critique, ben il finit en ecran bleu, pas le choix. Si c'est quoi que ce soit d'autre (kernel et truc pas critique, processus utilisateur…), le code gere le fait que l'allocation rate et continue. Pas de OOM killer du tout.
Et tu voudrais qu'on processus en traite des centaines ? (puisque tu refuse les pools de processus)
Si c'est un serveur (fait des conversions, extrait du texte, de l'edition en groupes, etc… que sais-je) oui. Quel interet d'avoir plusieurs processus identiques? Ca te coute en ressources et le service fournit est identique.
Si tu as un malloc() qui plante tu perdra quoi qu'il en soit des connexions quoi qu'il arrive.
Tu m'expliqueras comment. malloc retourne NULL, tu essaie de renvoyer une erreur au client, si ca ca rate, tu fermes le socket. Tu as perdu cette connection la, mais toutes les connections en cours sont toujours la.
En theorie c'est joli et je suis plutot d'accord, mais cela a ses limites. Deja la pile ne contiendra pas de buffer qui fasse plus que qqe dizaines de Kbs sous peine de te taper un stack overflow potentiellement. Ensuite tes buffers alloues statiquement, soit tu traites des petites requetes et c'est tout bon, soit tu gardes sous la main assez de gros buffers (genre 10Mb on dira) et la tu bouffes de la RAM pour rien le plus souvent.
Il va bien falloir que tu alloues a un moment ou un autre (t'as pas reserve assez de buffers, etc…), pas de miracle.
Ensuite pour le traitement pas petits morceaux… tout depend de ce que ton service fournit, si c'est faisable oui, si ca ne l'est pas, ben t'as pas le choix.
Rappel : OOM Killer c'est specifique a Linux… Tous les OS ne traitent pas le manque de memoire de la meme maniere.
Je veux bien que les tres grosses allocs soient a eviter, mais le truc est que 10 ou 20Mb c'est pas si enorme… Regarde les PDF d'aujourd'hui, il y en a plein qui font cette taille. Si ton serveur explose en vol a cause d'une alloc de 20Mb parce que t'es temporairement a court de RAM il y a quand meme un sacre probleme.
Un pool de processus c'est toujours pourri au niveau du design, tu te tapes le cout de chaque processus a part le 1er (stack assignee au process, tous les buffers statiques, etc…) en extra. Tout ce que tu fais au final c'est accelerer le moment ou tu seras OOM vu que tu consommes plus, et tu perdras toujours des connections vu que c'est un pool, a moins de faire 1 process / connection mais la c'est tellement un desastre niveau architectural qu'il vaut mieux pas imaginer.
Et tu te retrouves avec une limite totalement artificielle qui t'empeche de gerer des requetes de taille tout a fait normale, toujours sans avoir aucune garantie que ton allocation fonctionnera car tu n'as aucun controle sur la pression memoire du systeme en entier (tu ne sais pas ce que le serveur contient d'autre) et peu sur la fragmentation de l'espace memoire de ton soft.
Resultat, meme avec ta limite a 8Mo, tu as toujours des chances de planter.
Et si le client t'envoie 30Mb, que ton systeme est sous pression memoire temporairement mais peut quand meme gerer des requetes de moins de 20Mb tu fais quoi ? Tu exploses parce que c'est plus de 20Mb, tu coupes le service et coupe toutes les connections qui etaient en cours ?
Mais c'est quoi "raisonnable" ? Tu ne sais pas quelle est la taille de ton plus gros chunk disponible dans l'espace memoire, tu ne sais pas si le systeme a du swap/ram physique dispo pour garantir ton chunk.
Le seul moyen de savoir si tu as de la place pour ton alloc c'est de … faire l'alloc.
C'est quoi la longueur maximum alors ? Lorsque ton systeme est sous pression memoire, c'est quoi la longueur maximum que tu peux accepter ? Parce que t'auras pas besoin d'une allocation de 2Gb pour exploser ton allocation a ce moment la.
Lorsque ton protocole te passe une collection de structures tu fais quoi ? Tu fais un comptage manuel de combien de memoire tu as dispo (bonne chance pour ca vu que les autres threads/processus changeront ca sous tes pieds) a chaque allocation pour savoir a quel point c'est trop ?
Evidemment que non, la solution restante est de verifier la valeur de retour de malloc…
Toi tu n'as visiblement jamais eu a ecrire du code serveur ou tu recois une requete avec un champs decrivant la longueur et les donnees derriere.
Tu t'amuserais a faire quoi si le champs longueur est tellement grand que ta requete d'allocation echoue ? Tu tues le serveur et toutes les connections qui sont en cours ?
Embarquer des donnees sur la clef, c'est tres limitatif : espace disponible, savoir quand la clef est enlevee, absence de communication 2-ways contrairement a la radio pour command & control, etc…
Tu me montres ou ils recommandent Linux/OpenBSD/jenesaisquoi plutot que Windows ?
Ah oui, nulle part. Tu preferes prendre absence de recommendation comme une accusation, sans meme chercher a voir qu'ils ne recommandent aucun autre systeme.
Tu penses sincèrement qu'ils l'utilisent partout, y compris pour les plus hauts niveau de sécurité ? Non parce que sinon (discussion de bas étage), il suffit qu'il y ait un cuisinier allemand dans une base militaire qui utilise un système de gestion de stocks de nourriture pour la cantine basé sous windows pour dire que le ministère de la défense allemande utilise windows, hein…
PARTOUT non, dans la plupart des endroits, y compris des elements sensibles, oui.
There's been enough backlash on Patrick's article that the German Federal Office for security in information technology has provided an actual press release to set the story straight. The press release is HERE, but I've included the translated bits below.
The press release states that the German government did not warn against using Windows 8. It only highlighted that steps needed to be taken to ensure that Windows 8, with TPM, provided a safe computing environment****
J'ai cité IBM avec Lotus Notes. En remontant plus loin, IBM avait poussé le standard DES qui était volontairement affaibli par la NSA (clef de 56 bits au lieu de 64, soit 256 fois plus faciles à péter).
De nouveau, du blabla qui ne vaut rien. La loi etait claire et publique : a l'international l'entropie etait limitee a 40bits. Les societes US vendaient les softs avec des elements crypto repondant a ces criteres, qui etaient publiques, les clients savaient ce qu'ils achetaient. Rien de cache, pas de backdoor dissimulee.
Accessoirement, tous les services en ligne (donc offerts à l'étranger) d'industriels américains renommés (y compris ceux de Microsoft) sont accessibles à la NSA, d'après les documents fuités par Snowden.
De nouveau, je ne vois pas le rapport avec le soft. Les fournisseurs de services sont lies a des lois specifiques, auquelles l'edition de soft n'est pas soumis.
Sans déconner, la première clef serait détruite par inadvertance ou perdue ? Et il faudrait utiliser la deuxième, qu'on met donc en double chez tous les clients ?? Tu ne te foutrais pas de tous ceux qui suivent la conversation (et de moi en particulier) ?
Non du tout, c'est l'explication, et elle a ete donnee publiquement par MS. Je t'ai mis le lien precedemment, mais visiblement tu n'as pas estime qu'il fallait lire la version de MS.
Si la première clef, qui sert régulièrement (grosso modo à chaque mise à jour, pour les signatures), qui fait maximum 4Ko (c'est large) et peut donc être stockée sur deux feuilles A4 dans 36 banques différentes, est perdue, que dire de la deuxième, qui selon tes dires n'aura servi à rien jusqu'ici ?
J'imagines bien qu'ils la gardaient separement.
Et Microsoft ne serait pas capable de conserver ne serait-ce que 4 kilo-octets aussi sensibles ?
J'en sais rien, je sais pas quelle infrastructure ils avaient a l'epoque, visiblement il devait y avoir une crainte, et j'imagines bien que dans les annees 90 MS n'etait pas le mastodonte avec une organisation rigoureuse qu'il est aujourd'hui.
Ben dis moi, vous étiez mauvais à ce point chez Microsoft à l'époque ? Il ne me semble pas avoir entendu parler de beaucoup de mails détruits chez les utilisateurs hotmail, par exemple… Et ça représentait un peu plus que 4 Ko.
Les pertes de donnees ca arrive partout, les annees 90 c'est pas les annees 2000, les societes murissent, s'organisent mieux… Tu remarqueras que les versions recentes de l'OS n'ont pas de clefs de backup.
a) Les allemands et les francais utilisent Windows dans leur departement de la defense depuis plus de 10 ans, ca suffit pour voir a quel point ils en ont peur…
b) Tu es le seul ici a dire que d'autres industriels americains exportent des produits compromis par la NSA et qu'ils le savent/ont collabore.
Dans le cas de l'AS/400 les agences gouvernementales n'ont effectivement pas « forcé » IBM. Mais, elles ont quand même imposé certaines caractéristiques de l'OS pour accepter de l'utiliser. Ce n'est pas n'importe quel client qui peut formuler de telles demandes.
N'importe quel client qui represente un gros pourcentage de ventes le peut, c'est le cas du gouvernement, et ajouter cela ne pose aucun risque a IBM envers ses autres clients donc ils le font, normal.
Si la première clef n'est pas révoquée, autant continuer à l'utiliser, même si elle est compromise, et pas besoin d'une deuxième clef.
Mais pourquoi parles tu de compromission ?! Je t'ai dit depuis le debut que la 2eme clef est la au cas ou la 1ere est PERDUE
Je te dis pas qu'elle est volee, mais qu'elle est perdue (tremblement de terre qui explose le lieu ou elle est stockee, etc…)
Dans ce cas la, il n'y a aucun besoin de revoquer la 1ere clef.
Note : pour bien nous comprendre, on ne perd jamais une clef au sens "l'oublier", "avoir perdu l'unique papier sur lequel elle était écrite" ; surtout une clef de cette importance, qui sert très régulièrement.
Elle peut etre detruite, et c'est bien ca le risque qui a amene la 2eme clef, cela a ete dit clairement.
[^] # Re: Pourquoi faire ?
Posté par pasBill pasGates . En réponse au journal Contre la phobie du root. Évalué à -10.
Non, c'est pour faire mousser les petits rigolos sur linuxfr qui parlent sans meme savoir de quoi ils parlent.
(indice : il n'y a jamais eu de difference sur ce point entre les versions d'un meme OS)
[^] # Re: Pourquoi faire ?
Posté par pasBill pasGates . En réponse au journal Contre la phobie du root. Évalué à -9.
Non ca certainement pas, parce que les LL ne sont pas plus stables ou plus surs, et l'acces aux sources n'amene pas grand chose de ce cote la (la preuve : ils ne sont pas plus stables ou plus surs justement).
Non ca a surtout a voir que Linux derive d'Unix (tous ces principes de securite viennent d'Unix, pas du libre) et a toujours ete pousse dans une optique serveur plutot que grand publique. C'est pas par hasard qu'il a fait un bide sur le desktop.
[^] # Re: rétro-compatibilité
Posté par pasBill pasGates . En réponse au journal SUSE SolidDriver de nouveau sur les rails pour développer des drivers Linux en toute sécurité !. Évalué à -3.
Parce que t'as toujours un driver ici ou la qui fait des cochonneries plutot que respecter l'API publique.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à -3.
Si tu veux simplement lire le fichier PDF oui, mais quand tu as des operations a faire dessus (conversion, etc…) va bien falloir faire le parsing du PDF, stocker tes objets, etc…
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 1.
Ben non :/ C'est juste découpé en morceau et traité en morceau.
Mais de nouveau, c'est le cas uniquement si ton probleme se prete a etre traite en morceaux.
Peut-être chez toi. Mais pas chez moi.
Quand t'es le gars qui ecrit le soft, t'as aucun controle la dessus, t'es sense faire pour que cela marche dans la plupart des cas correctement.
???
Selon la fragmentation de l'espace memoire du soft, t'as beau avoir 60Mb de libre, tu n'arriveras pas a faire une alloc de plus de 2Mb…
Et pour quoi donc avec morcellement ? On garantit juste que 1024 clients seront très bien servis ! Tant pis pour les autres. De toutes manières le système ne supportera pas mieux.
Ce sera vrai uniquement si tu prealloue 1024 blocs de 8Mb, resultat tu forces ton processus a avoir 8Gb alloues tout le temps, super…. (et evidemment en imaginant que ton probleme se prete au modele ou aucune autre allocation dynamique est necessaire)
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à -2.
J'ai 8M, par défaut, chez moi.
Et sur Windows c'est 1Mb… Dans un systeme avec plein de processus et/ou threads, ca commence a te couter pas mal et tu vas le reduire.
Tu ne réserves pas vraiment. Tu alloues sur le stack.
J'ai bien compris, mais quand tu fais ca dans une librairie, tu ne sais pas tout ce qu'il y a au dessus de toi sur la stack, resultat tu tend a etre conservateur pour eviter de te prendre un stack overflow.
Pour les serveurs, travailler par petits morceau, minimiser les allocations, ce sont de très très bonnes pratiques.
Tout a fait, quand c'est possible. Le truc est qu'il y a plein de cas ou tu n'as pas trop le choix parce que le probleme ne s'y prete pas.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 1.
Tous les cas ou ta taille de bloc est "presque" aleatoire par exemple. Si tu ne sais pas d'avance quelle taille tu va devoir gerer, tu dois soit allouer dynamiquement, soit avoir un tas de buffers gardes de cote que tu n'utilises quasiment jamais et qui coutent sur le systeme.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à -2.
Ça tombe bien j'ai dis qu'il fallait l'ignorer (windows fait quoi lorsqu'il n'a plus de mémoire ?).
Tout depend de l'operation. Si c'est le noyau qui fait l'allocation et c'est pour un truc absolument critique, ben il finit en ecran bleu, pas le choix. Si c'est quoi que ce soit d'autre (kernel et truc pas critique, processus utilisateur…), le code gere le fait que l'allocation rate et continue. Pas de OOM killer du tout.
Et tu voudrais qu'on processus en traite des centaines ? (puisque tu refuse les pools de processus)
Si c'est un serveur (fait des conversions, extrait du texte, de l'edition en groupes, etc… que sais-je) oui. Quel interet d'avoir plusieurs processus identiques? Ca te coute en ressources et le service fournit est identique.
Si tu as un malloc() qui plante tu perdra quoi qu'il en soit des connexions quoi qu'il arrive.
Tu m'expliqueras comment. malloc retourne NULL, tu essaie de renvoyer une erreur au client, si ca ca rate, tu fermes le socket. Tu as perdu cette connection la, mais toutes les connections en cours sont toujours la.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 2.
Eviter de faire des mallocs ?
En theorie c'est joli et je suis plutot d'accord, mais cela a ses limites. Deja la pile ne contiendra pas de buffer qui fasse plus que qqe dizaines de Kbs sous peine de te taper un stack overflow potentiellement. Ensuite tes buffers alloues statiquement, soit tu traites des petites requetes et c'est tout bon, soit tu gardes sous la main assez de gros buffers (genre 10Mb on dira) et la tu bouffes de la RAM pour rien le plus souvent.
Il va bien falloir que tu alloues a un moment ou un autre (t'as pas reserve assez de buffers, etc…), pas de miracle.
Ensuite pour le traitement pas petits morceaux… tout depend de ce que ton service fournit, si c'est faisable oui, si ca ne l'est pas, ben t'as pas le choix.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à -4.
Rappel : OOM Killer c'est specifique a Linux… Tous les OS ne traitent pas le manque de memoire de la meme maniere.
Je veux bien que les tres grosses allocs soient a eviter, mais le truc est que 10 ou 20Mb c'est pas si enorme… Regarde les PDF d'aujourd'hui, il y en a plein qui font cette taille. Si ton serveur explose en vol a cause d'une alloc de 20Mb parce que t'es temporairement a court de RAM il y a quand meme un sacre probleme.
Un pool de processus c'est toujours pourri au niveau du design, tu te tapes le cout de chaque processus a part le 1er (stack assignee au process, tous les buffers statiques, etc…) en extra. Tout ce que tu fais au final c'est accelerer le moment ou tu seras OOM vu que tu consommes plus, et tu perdras toujours des connections vu que c'est un pool, a moins de faire 1 process / connection mais la c'est tellement un desastre niveau architectural qu'il vaut mieux pas imaginer.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 2.
Et tu te retrouves avec une limite totalement artificielle qui t'empeche de gerer des requetes de taille tout a fait normale, toujours sans avoir aucune garantie que ton allocation fonctionnera car tu n'as aucun controle sur la pression memoire du systeme en entier (tu ne sais pas ce que le serveur contient d'autre) et peu sur la fragmentation de l'espace memoire de ton soft.
Resultat, meme avec ta limite a 8Mo, tu as toujours des chances de planter.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 2.
Et si le client t'envoie 30Mb, que ton systeme est sous pression memoire temporairement mais peut quand meme gerer des requetes de moins de 20Mb tu fais quoi ? Tu exploses parce que c'est plus de 20Mb, tu coupes le service et coupe toutes les connections qui etaient en cours ?
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 0.
Mais c'est quoi "raisonnable" ? Tu ne sais pas quelle est la taille de ton plus gros chunk disponible dans l'espace memoire, tu ne sais pas si le systeme a du swap/ram physique dispo pour garantir ton chunk.
Le seul moyen de savoir si tu as de la place pour ton alloc c'est de … faire l'alloc.
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 4.
C'est quoi la longueur maximum alors ? Lorsque ton systeme est sous pression memoire, c'est quoi la longueur maximum que tu peux accepter ? Parce que t'auras pas besoin d'une allocation de 2Gb pour exploser ton allocation a ce moment la.
Lorsque ton protocole te passe une collection de structures tu fais quoi ? Tu fais un comptage manuel de combien de memoire tu as dispo (bonne chance pour ca vu que les autres threads/processus changeront ca sous tes pieds) a chaque allocation pour savoir a quel point c'est trop ?
Evidemment que non, la solution restante est de verifier la valeur de retour de malloc…
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 4.
Un processus par requete ? Vive le design pourri qui ne monte pas en charge…
[^] # Re: Laissez malloc tranquille !
Posté par pasBill pasGates . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 0.
Toi tu n'as visiblement jamais eu a ecrire du code serveur ou tu recois une requete avec un champs decrivant la longueur et les donnees derriere.
Tu t'amuserais a faire quoi si le champs longueur est tellement grand que ta requete d'allocation echoue ? Tu tues le serveur et toutes les connections qui sont en cours ?
[^] # Re: I love you
Posté par pasBill pasGates . En réponse au journal sauter l'airgap avec des ultrasons. Évalué à -1.
clef ou autre oui.
Embarquer des donnees sur la clef, c'est tres limitatif : espace disponible, savoir quand la clef est enlevee, absence de communication 2-ways contrairement a la radio pour command & control, etc…
[^] # Re: I love you
Posté par pasBill pasGates . En réponse au journal sauter l'airgap avec des ultrasons. Évalué à 3.
T'as pas compris l'objectif.
L'objectif est de permettre l'extraction de donnees d'un reseau isole ('airgap'). En ayant 2 machines infectees et proches : une dedans, une dehors.
Maintenant que cela ait ete utilise dans le monde reel, aucune idee… mais cela a definitivement un interet.
[^] # Re: Comment oser?
Posté par pasBill pasGates . En réponse à la dépêche Open Bar Microsoft/Défense : des documents confirment les jeux de pouvoir et la décision politique. Évalué à -10.
Je ne vois nulle part ou ils disent de ne pas utiliser Windows et d'utiliser autre chose.
[^] # Re: Comment oser?
Posté par pasBill pasGates . En réponse à la dépêche Open Bar Microsoft/Défense : des documents confirment les jeux de pouvoir et la décision politique. Évalué à -10.
Et de nouveau du grand blabla…
Tu me montres ou ils recommandent Linux/OpenBSD/jenesaisquoi plutot que Windows ?
Ah oui, nulle part. Tu preferes prendre absence de recommendation comme une accusation, sans meme chercher a voir qu'ils ne recommandent aucun autre systeme.
[^] # Re: Comment oser?
Posté par pasBill pasGates . En réponse à la dépêche Open Bar Microsoft/Défense : des documents confirment les jeux de pouvoir et la décision politique. Évalué à -9.
Tu penses sincèrement qu'ils l'utilisent partout, y compris pour les plus hauts niveau de sécurité ? Non parce que sinon (discussion de bas étage), il suffit qu'il y ait un cuisinier allemand dans une base militaire qui utilise un système de gestion de stocks de nourriture pour la cantine basé sous windows pour dire que le ministère de la défense allemande utilise windows, hein…
PARTOUT non, dans la plupart des endroits, y compris des elements sensibles, oui.
Tiens et sinon, les allemands en reviennent, pour toutes leurs administrations centrales : http://www.wpcentral.com/german-government-calls-security-within-windows-8-unacceptable-continues-switching-their-machines
LOL ! Ou comment poster un lien sans meme savoir de quoi il en revient : http://windowsitpro.com/industry/germany-has-its-own-snowden
There's been enough backlash on Patrick's article that the German Federal Office for security in information technology has provided an actual press release to set the story straight. The press release is HERE, but I've included the translated bits below.
The press release states that the German government did not warn against using Windows 8. It only highlighted that steps needed to be taken to ensure that Windows 8, with TPM, provided a safe computing environment****
J'ai cité IBM avec Lotus Notes. En remontant plus loin, IBM avait poussé le standard DES qui était volontairement affaibli par la NSA (clef de 56 bits au lieu de 64, soit 256 fois plus faciles à péter).
De nouveau, du blabla qui ne vaut rien. La loi etait claire et publique : a l'international l'entropie etait limitee a 40bits. Les societes US vendaient les softs avec des elements crypto repondant a ces criteres, qui etaient publiques, les clients savaient ce qu'ils achetaient. Rien de cache, pas de backdoor dissimulee.
Accessoirement, tous les services en ligne (donc offerts à l'étranger) d'industriels américains renommés (y compris ceux de Microsoft) sont accessibles à la NSA, d'après les documents fuités par Snowden.
De nouveau, je ne vois pas le rapport avec le soft. Les fournisseurs de services sont lies a des lois specifiques, auquelles l'edition de soft n'est pas soumis.
[^] # Re: Comment oser?
Posté par pasBill pasGates . En réponse à la dépêche Open Bar Microsoft/Défense : des documents confirment les jeux de pouvoir et la décision politique. Évalué à -9.
Sans déconner, la première clef serait détruite par inadvertance ou perdue ? Et il faudrait utiliser la deuxième, qu'on met donc en double chez tous les clients ?? Tu ne te foutrais pas de tous ceux qui suivent la conversation (et de moi en particulier) ?
Non du tout, c'est l'explication, et elle a ete donnee publiquement par MS. Je t'ai mis le lien precedemment, mais visiblement tu n'as pas estime qu'il fallait lire la version de MS.
Si la première clef, qui sert régulièrement (grosso modo à chaque mise à jour, pour les signatures), qui fait maximum 4Ko (c'est large) et peut donc être stockée sur deux feuilles A4 dans 36 banques différentes, est perdue, que dire de la deuxième, qui selon tes dires n'aura servi à rien jusqu'ici ?
J'imagines bien qu'ils la gardaient separement.
Et Microsoft ne serait pas capable de conserver ne serait-ce que 4 kilo-octets aussi sensibles ?
J'en sais rien, je sais pas quelle infrastructure ils avaient a l'epoque, visiblement il devait y avoir une crainte, et j'imagines bien que dans les annees 90 MS n'etait pas le mastodonte avec une organisation rigoureuse qu'il est aujourd'hui.
Ben dis moi, vous étiez mauvais à ce point chez Microsoft à l'époque ? Il ne me semble pas avoir entendu parler de beaucoup de mails détruits chez les utilisateurs hotmail, par exemple… Et ça représentait un peu plus que 4 Ko.
Les pertes de donnees ca arrive partout, les annees 90 c'est pas les annees 2000, les societes murissent, s'organisent mieux… Tu remarqueras que les versions recentes de l'OS n'ont pas de clefs de backup.
[^] # Re: Comment oser?
Posté par pasBill pasGates . En réponse à la dépêche Open Bar Microsoft/Défense : des documents confirment les jeux de pouvoir et la décision politique. Évalué à -9.
a) Les allemands et les francais utilisent Windows dans leur departement de la defense depuis plus de 10 ans, ca suffit pour voir a quel point ils en ont peur…
b) Tu es le seul ici a dire que d'autres industriels americains exportent des produits compromis par la NSA et qu'ils le savent/ont collabore.
[^] # Re: Comment oser?
Posté par pasBill pasGates . En réponse à la dépêche Open Bar Microsoft/Défense : des documents confirment les jeux de pouvoir et la décision politique. Évalué à -9.
Dans le cas de l'AS/400 les agences gouvernementales n'ont effectivement pas « forcé » IBM. Mais, elles ont quand même imposé certaines caractéristiques de l'OS pour accepter de l'utiliser. Ce n'est pas n'importe quel client qui peut formuler de telles demandes.
N'importe quel client qui represente un gros pourcentage de ventes le peut, c'est le cas du gouvernement, et ajouter cela ne pose aucun risque a IBM envers ses autres clients donc ils le font, normal.
[^] # Re: Comment oser?
Posté par pasBill pasGates . En réponse à la dépêche Open Bar Microsoft/Défense : des documents confirment les jeux de pouvoir et la décision politique. Évalué à -9.
Si la première clef n'est pas révoquée, autant continuer à l'utiliser, même si elle est compromise, et pas besoin d'une deuxième clef.
Mais pourquoi parles tu de compromission ?! Je t'ai dit depuis le debut que la 2eme clef est la au cas ou la 1ere est PERDUE
Je te dis pas qu'elle est volee, mais qu'elle est perdue (tremblement de terre qui explose le lieu ou elle est stockee, etc…)
Dans ce cas la, il n'y a aucun besoin de revoquer la 1ere clef.
Note : pour bien nous comprendre, on ne perd jamais une clef au sens "l'oublier", "avoir perdu l'unique papier sur lequel elle était écrite" ; surtout une clef de cette importance, qui sert très régulièrement.
Elle peut etre detruite, et c'est bien ca le risque qui a amene la 2eme clef, cela a ete dit clairement.