C'est normal que tu ais rien lu dessus: "Among other things, the attack took down the French mobile data network and blinded police surveillance" Si il y avait eu une coupure de l'internet mobile, on aurait été au courant.
Si tu sais que ton correspondant chiffre, tu peux refuser de communiquer en clair (bon ca demande une BDD des personnes chiffrant) il manque certe un truc du genre HSTS pour bien limiter les dégats
Non ce n'est pas une bonne chose !: L'ANSII ne va pas jusqu'au bout de sa logique: les bad guy utilisent le chiffrement donc ce n'est pas la peine de freiner le chiffrement à moins que l'on ne vise pas les bad guy.
C'est possible de refuser de communiquer avec un serveur ne faisant pas de chiffrement mais aucun moyen de savoir ce qu'il fera ensuite avec tes envois
La seule solution viable en l'absence de volonté des autorités pour enfin sécuriser le maximum les communications de bout à bout me semble caliopen https://caliopen.org/
Deux projets simples sont un jeu de + grand/+ petit (très simple) et un pierre/papier ciseau (un peu plus compliqué), une fois qu'ils sont fait on peut s'amuser avec sans avoir à programmer.
Le gros avantage de id+HMAC c'est le stockage en base (tu n'as que l'id a stocker)
Le fait que ce soit toi qui gère les token garanti leur unicité (le client on sait pas comment il va les générer)
Un truc important c'est la révocation des token. Si le client en génère autant qu'il veut, il faudra que potentiellement tu stocke tout ceux qui sont révoqués. Tandis que si c'est toi qui les génère, tu stocke que les token valide
un HMAC c'est risqué dans la mesure ou si le secret avec lequel il est construit fuit, n'importe qui peu en construire. De toute manière tu es obligé d'avoir une base de donnée pour stocker les secret avec lequel sont construit les hmac.
Sinon c'est aussi sur que n'importe quelle technologie cryptographique.
Pour bien faire les token doivent être généré aléatoirement (avec un générateur d'aléa cryptographique) à mon avis. Je pense qu'utiliser un HMAC est relativement risqué pour un gain douteux.
L'utilisateur final connait un token public qui lui est spécifique, donc le client peut le révoquer, si celui ci en fait un mauvais usage.
le fait que ce soit les INSERT moins nombreux qui accélèrent le processus, me fait clairement penser que c'est le manque de transaction qui pénalise la solution originale. En effet, chaque INSERT correspond a une transaction par défaut, si tu groupe plusieurs enregistrements dans un INSERT, c'est quasi identique a grouper plusieurs INSERT d'un enregistrement dans une transaction.
A mon avis, c'est parce que le poste de travail est en MyISAM. Une des différence principale entre MyISAM et InnoDB est que InnoDB supporte les transactions. Mais une transaction a un cout relatif. Si tu fait plusieurs insertion/updates au sein d'une même transaction tu réparti le cout de la transaction.
Un truc qui accélère normalement les mise à jour d'une base de donnée est d'effectuer les insertion au sein d'une transaction.
pour cela, comme documenté ici il faut faire un START TRANSACTION; au début du script et un COMMIT; à la fin (une alternative est de grouper les INSERT par 1 000 ou 10 000 au sein de différente transaction, permettant de reprendre en cas d'erreur sans devoir tout recommencer)
Par contre je ne comprends pas pourquoi c'est sensiblement plus rapide lorsque ton script est exécuté sur le serveur plutôt que sur le client (en partant de l'hypothèse que c'est le même script et que dans les deux cas ta base de donnée est sur le serveur)
ATTENTION, si tu ne fais pas de COMMIT à la fin, aucune donnée n'est enregistrée.
L'idée c'est en gros sur un serveur, de permettre à quelqu'un d'autre que toi de déployer ses propres appli web sur ton serveur, sans mettre en cause la sécurité de ton serveur (d'où l’intérêt des technologies de sandboxing) . La différence avec apt-get c'est que tu dois être root pour déployer une application avec apt-get. Il y a des bonus pour celui qui veut héberger son app chez toi, par exemple il peut rapatrier les données de l'application qu'il a hébergé chez toi pour redéployer a l'identique chez quelqu"un d'autre.
Je vois pas pourquoi tu affirme que pour tout contrat utile, tu as besoin de donnée qui ne viennent pas du blockchain. Par exemple, des contrats avec escrow sont utile et marche très bien sans oracle (d'ailleurs elle marche avec bitcoin, par exemple si tu veux échanger des marchandises sur le darkweb)
Il apparait qu'il y a des solutions relativement partielles, mais que rien n’empêche un attaquant de dérober mon argent en exploitant une faille, c'est un peu similaire aux failles des générateurs aléatoires de bitcoin qui ont fait un certain nombre de malheureux (et d'heureux), mais avec une échelle plus grande. Donc je pense que je vais garder mon argent dans une banque contre laquelle je peux me retourner légalement.
[^] # Re: Quelqu'un a-t-il lu quelque chose là-dessus?
Posté par Xavier Combelle (site web personnel) . En réponse au journal Paris sous les balles. Évalué à 4.
C'est normal que tu ais rien lu dessus: "Among other things, the attack took down the French mobile data network and blinded police surveillance" Si il y avait eu une coupure de l'internet mobile, on aurait été au courant.
# sysdig ?
Posté par Xavier Combelle (site web personnel) . En réponse au message Evince crée une connexion réseau. Évalué à 4.
Un bon outil pour tracer l'activité du système:
sysdig
La commande suivante devrait te permettre de voir a quels serveur et sur quel port
evince
se connecteA lancer avant le démarrage d'evince
[^] # Re: rahh
Posté par Xavier Combelle (site web personnel) . En réponse au message Trouver source d'un log. Évalué à 1.
oui avec sysdig
# Je trouve l'idée de libreidea intéressant mais...
Posté par Xavier Combelle (site web personnel) . En réponse à la dépêche LibreIdea.org fête son premier anniversaire. Évalué à 1.
Ce projet n'a abouti a aucune réalisation concrète (à part un max de communication autour d’où un rapport signal/bruit élevé) à ma connaissance.
[^] # Re: Chiffrement opportuniste
Posté par Xavier Combelle (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 3.
Si tu sais que ton correspondant chiffre, tu peux refuser de communiquer en clair (bon ca demande une BDD des personnes chiffrant) il manque certe un truc du genre HSTS pour bien limiter les dégats
# réponses
Posté par Xavier Combelle (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 3.
# projets simples
Posté par Xavier Combelle (site web personnel) . En réponse au message Un projet scolaire ?. Évalué à 1. Dernière modification le 12 octobre 2015 à 13:09.
Deux projets simples sont un jeu de + grand/+ petit (très simple) et un pierre/papier ciseau (un peu plus compliqué), une fois qu'ils sont fait on peut s'amuser avec sans avoir à programmer.
[^] # Re: comment ca marche ?
Posté par Xavier Combelle (site web personnel) . En réponse au message Authentification par token. OAuth, openId . Évalué à 1.
Le gros avantage de id+HMAC c'est le stockage en base (tu n'as que l'id a stocker)
Le fait que ce soit toi qui gère les token garanti leur unicité (le client on sait pas comment il va les générer)
Un truc important c'est la révocation des token. Si le client en génère autant qu'il veut, il faudra que potentiellement tu stocke tout ceux qui sont révoqués. Tandis que si c'est toi qui les génère, tu stocke que les token valide
[^] # Re: comment ca marche ?
Posté par Xavier Combelle (site web personnel) . En réponse au message Authentification par token. OAuth, openId . Évalué à 1.
un HMAC c'est risqué dans la mesure ou si le secret avec lequel il est construit fuit, n'importe qui peu en construire. De toute manière tu es obligé d'avoir une base de donnée pour stocker les secret avec lequel sont construit les hmac.
Sinon c'est aussi sur que n'importe quelle technologie cryptographique.
# comment ca marche ?
Posté par Xavier Combelle (site web personnel) . En réponse au message Authentification par token. OAuth, openId . Évalué à 1.
Pour bien faire les token doivent être généré aléatoirement (avec un générateur d'aléa cryptographique) à mon avis. Je pense qu'utiliser un HMAC est relativement risqué pour un gain douteux.
L'utilisateur final connait un token public qui lui est spécifique, donc le client peut le révoquer, si celui ci en fait un mauvais usage.
[^] # Re: Dump
Posté par Xavier Combelle (site web personnel) . En réponse au message MariaDB (MySQL) MDB Tools → trés nombreux insert, extrêmement lent :( ? [résolu]. Évalué à 1.
le fait que ce soit les INSERT moins nombreux qui accélèrent le processus, me fait clairement penser que c'est le manque de transaction qui pénalise la solution originale. En effet, chaque INSERT correspond a une transaction par défaut, si tu groupe plusieurs enregistrements dans un INSERT, c'est quasi identique a grouper plusieurs INSERT d'un enregistrement dans une transaction.
[^] # Re: créer une transaction ?
Posté par Xavier Combelle (site web personnel) . En réponse au message MariaDB (MySQL) MDB Tools → trés nombreux insert, extrêmement lent :( ? [résolu]. Évalué à 1.
A mon avis, c'est parce que le poste de travail est en MyISAM. Une des différence principale entre MyISAM et InnoDB est que InnoDB supporte les transactions. Mais une transaction a un cout relatif. Si tu fait plusieurs insertion/updates au sein d'une même transaction tu réparti le cout de la transaction.
# créer une transaction ?
Posté par Xavier Combelle (site web personnel) . En réponse au message MariaDB (MySQL) MDB Tools → trés nombreux insert, extrêmement lent :( ? [résolu]. Évalué à 1.
Un truc qui accélère normalement les mise à jour d'une base de donnée est d'effectuer les insertion au sein d'une transaction.
pour cela, comme documenté ici il faut faire un
START TRANSACTION;
au début du script et unCOMMIT;
à la fin (une alternative est de grouper lesINSERT
par 1 000 ou 10 000 au sein de différente transaction, permettant de reprendre en cas d'erreur sans devoir tout recommencer)Par contre je ne comprends pas pourquoi c'est sensiblement plus rapide lorsque ton script est exécuté sur le serveur plutôt que sur le client (en partant de l'hypothèse que c'est le même script et que dans les deux cas ta base de donnée est sur le serveur)
ATTENTION, si tu ne fais pas de
COMMIT
à la fin, aucune donnée n'est enregistrée.# changer les raccourcis clavier
Posté par Xavier Combelle (site web personnel) . En réponse au message GNU/Linux Mint 17.2 MATE et ses 3 calculatrices, comment choisir ?. Évalué à 2.
J'ai trouvé ça: https://askubuntu.com/questions/7411/changing-media-key-defaults-in-gnome apparemment c'est lié à la configuration du clavier
[^] # Re: alpha = 2 pas prudent à mon avis
Posté par Xavier Combelle (site web personnel) . En réponse au journal Résolution du jeu d'échecs : patience, ça arrive.... Évalué à 1.
merci !
[^] # Re: entrée standard et arguments
Posté par Xavier Combelle (site web personnel) . En réponse au message Python / (linux) shell : interfacer l'un avec l'autre. Évalué à 1.
par défaut
xargs
lance une commande avec chaque ligne d'entrée comme étant un argument supplémentaire à la commande[^] # Re: alpha = 2 pas prudent à mon avis
Posté par Xavier Combelle (site web personnel) . En réponse au journal Résolution du jeu d'échecs : patience, ça arrive.... Évalué à 1.
Aurais tu des lectures (en accès gratuit) à me conseiller sur la résolution des jeux ?
[^] # Re: alpha = 2 pas prudent à mon avis
Posté par Xavier Combelle (site web personnel) . En réponse au journal Résolution du jeu d'échecs : patience, ça arrive.... Évalué à 1.
C'est un bon argument, dont j'ignorais l'existence jusque là.
[^] # Re: Sandstorm
Posté par Xavier Combelle (site web personnel) . En réponse au message Sandstorm, installer des appli serveur comme des appli mobiles. Votre avis ?. Évalué à 1.
Il me semble que ce n'est que pour des applis web
[^] # Re: Faille dans les programmes ?
Posté par Xavier Combelle (site web personnel) . En réponse au journal Ethereum, désormais officiellement lancé. Évalué à 1.
Il y a une mémoire persistante, il y a des entrées sorties.
Le code source du truc doit + ou - ressembler à ca: https://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol
[^] # Re: Sandstorm
Posté par Xavier Combelle (site web personnel) . En réponse au message Sandstorm, installer des appli serveur comme des appli mobiles. Votre avis ?. Évalué à 2.
L'idée c'est en gros sur un serveur, de permettre à quelqu'un d'autre que toi de déployer ses propres appli web sur ton serveur, sans mettre en cause la sécurité de ton serveur (d'où l’intérêt des technologies de sandboxing) . La différence avec apt-get c'est que tu dois être root pour déployer une application avec apt-get. Il y a des bonus pour celui qui veut héberger son app chez toi, par exemple il peut rapatrier les données de l'application qu'il a hébergé chez toi pour redéployer a l'identique chez quelqu"un d'autre.
# en quel langage ?
Posté par Xavier Combelle (site web personnel) . En réponse au message Écrivez votre propre fonction.... Évalué à 1.
En quel langage doit tu écrire ta fonction ?
[^] # Re: Faille dans les programmes ?
Posté par Xavier Combelle (site web personnel) . En réponse au journal Ethereum, désormais officiellement lancé. Évalué à 1.
Ce contrat fait plus de 2500 opocodes: https://etherchain.org/account/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae#codeDisasm Si j'ai tout compris, c'est plus ou moins le salaire des développeurs qui bossent dessus et la valeur stockée dedans correspond à environ 600 000 dollars au cours courant de l'ether (environ 1 dollars).
[^] # Re: Intérêt vis-à-vis de bitcoin.
Posté par Xavier Combelle (site web personnel) . En réponse au journal Ethereum, désormais officiellement lancé. Évalué à 1.
Je vois pas pourquoi tu affirme que pour tout contrat utile, tu as besoin de donnée qui ne viennent pas du blockchain. Par exemple, des contrats avec escrow sont utile et marche très bien sans oracle (d'ailleurs elle marche avec bitcoin, par exemple si tu veux échanger des marchandises sur le darkweb)
# Failles dans les programme (suite)
Posté par Xavier Combelle (site web personnel) . En réponse au journal Ethereum, désormais officiellement lancé. Évalué à 3.
J'ai soulevé mon problème concernant les failles d'une façon moins polémique sur reddit. (https://www.reddit.com/r/ethereum/comments/3l5uuh/three_major_concern_about_ethereum/)
Il apparait qu'il y a des solutions relativement partielles, mais que rien n’empêche un attaquant de dérober mon argent en exploitant une faille, c'est un peu similaire aux failles des générateurs aléatoires de bitcoin qui ont fait un certain nombre de malheureux (et d'heureux), mais avec une échelle plus grande. Donc je pense que je vais garder mon argent dans une banque contre laquelle je peux me retourner légalement.