goeb a écrit 504 commentaires

Quand tu transmets un email chiffré, ça correspondant à quel besoin derrière ?
envoyer un document confidentiel ? avoir un échange sur un sujet confidentiel ?

Oui c'est ça : envoyer des documents, poser des questions, demander un devis, donner des réponses (tout cela de manière confidentielle).

il me semble bien plus facile et efficace d'utiliser un conteneur TrueCrypt, déposé sur le Cloud de la société

Mais quand la PME n'a pas de cloud ? ou que la personne d'un service lamba d'une entreprise du CAC40 n'a pas accès à un cloud dédié à ce genre d'usage ?
GPG me semble plus facile à mettre en oeuvre, notamment pour des échanges qui s'étendent sur quelques mois seulement, ou qui se résument à une dizaine d'emails.

Et pour rendre confidentiel l'échange d'emails, quelles alternatives meilleures que GPG existent ?
Les emails, c'est l'exemple typique d'échange entre deux organisations qui n'ont pas d'autre moyen simple pour échanger des informations.

C’est un cas d’utilisation réel ça, ou un cas d’utilisation que tu imagines ?

C'est un cas réel.
Des milliers d'entreprises industrielles ont des besoins de confidentialité des emails. Certaines que je connais utilisent GPG.

Un exemple de cas d'utilisation de GPG est le suivant.

Plusieurs entreprises industrielles échangent des emails dont le contenu doit rester confidentiel. L'usage de GPG permet de préserver cette confidentialité face aux attaques suivantes :

• écoute des échanges d'email
• accès au cloud de l'hébergeur d'email (avec IMAP les emails restent sur le serveur)

Pour illustrer mon propos, beaucoup d'entreprises utilisent les services de Microsoft pour l'hébergement des emails. Si la NSA peut accéder à la base de données de Microsoft, alors elle peut faire bénéficier les entreprises US concurrentes d'informations privilégiées (sauf si les emails sont chiffrés).

keyctl est utilisé pour ecryptfs (pour chiffrer un répertoire).

https://www.kernel.org/doc/Documentation/security/keys-ecryptfs.txt

Extrait :

Example of encrypted key usage with the eCryptfs filesystem:

Create an encrypted key "1000100010001000" of length 64 bytes with format
'ecryptfs' and save it using a previously loaded user key "test":

$ keyctl add encrypted 1000100010001000 "new ecryptfs user:test 64" @u
19184530

$ keyctl print 19184530
ecryptfs user:test 64 490045d4bfe48c99f0d465fbbbb79e7500da954178e2de0697
dd85091f5450a0511219e9f7cd70dcd498038181466f78ac8d4c19504fcc72402bfc41c2
f253a41b7507ccaa4b2b03fff19a69d1cc0b16e71746473f023a95488b6edfd86f7fdd40
9d292e4bacded1258880122dd553a661

$ keyctl pipe 19184530 > ecryptfs.blob

Mount an eCryptfs filesystem using the created encrypted key "1000100010001000"
into the '/secret' directory:

$ mount -i -t ecryptfs -oecryptfs_sig=1000100010001000,\
ecryptfs_cipher=aes,ecryptfs_key_bytes=32 /secret /secret-

Et pain salé + beurre salé, ça ne fait pas trop de sel ?
Trop de sel est mauvais pour la santé.

Et en nombre d'utilisateurs, vous en avez combien ?
L'éducation nationale, c'est 800000 enseignants et 12 millions d'élèves. Il faut combien de machines physiques pour un cloud avec autant d'utilisateurs ? (en comptant les backups, le load-balancing, etc.)

client-error-document-format-not-supported

Vérifie que tu as bien sélectionné format A4, et pas "letter".

Enfin, dommage que la bibliothèque soit sous GPL et non sous LGPL. Si le format est vraiment aussi prometteur qu'annoncé, cela sera sans doute un frein à son adoption…

Si le format est vraiment prometteur alors une autre implémentation pourrait voir le jour, sous une autre licence, choisie par ses auteurs. Donc possiblement LGPL.
(je suppose qu'on parle de la bibliothèque d'encodage / décodage de ce nouveau format…)

Je compile des images buildroot. Le répertoire des produits de la compilation prend environ 2Go.

J'ai mis 8 go en SWAP car j'ai lu qu'il fallait doubler la mémoire donc 2X 4GO est-ce JUSTE???

Ça fait 5 ans que je n'ai plus du tout de partition de swap sur mes 2 PC (domicile et travail). J'ai 4Go de RAM, et aucun souci. Et au moins je suis sûr que mon Linux ne swappe jamais.
(petite précision je n'utilise pas des window managers gourmands tels que KDE ou Gnome)

Oui, un "sub" devrait suffire pour commencer. Il faut pouvoir :

• remplacer des chaînes de caractères
• utiliser les groupes. Exemple :

sed -e "s/\(.*\):\(.*\)/\\2:\\1/"
abc:456
456:abc

Intéressant.
Je ne sais pas si j'en aurai l'utilité, mais je fais tout de même 2 remarques.

D'une part un commande de type "sed" serait utile je pense. "sed" est globalement très utilisée.

D'autre part, noyée au milieu d'autres noms de commandes unix, "filter" est trompeur car il ne correspond pas à la commande unix "filter".

man filter

filter - cups file conversion filter interface
…

Explication des erreurs que tu rencontres…

Le remplacement de :

awk "/$A/ "'{ nmatches++ } END { print nmatches, "found" }' /tmp/data

Donne dans ton cas :

awk '/DAY
WEEKLY/ { nmatches++ } END { print nmatches, "found" }' /tmp/data

Car A contient la chaîne "DAY\nWEEKLY" (le \n désignant un retour à la ligne).

Les autotools permettent d'utiliser :

• pkg-config à l'aide de la macro PKG_CHECK_MODULES
• des LDFLAGS dans le bon ordre. Il y a plusieurs moyens de manipuler les LDFLAGS :
  • dans le Makefile.am : xxx_LDADD ou xxx_LDFLAGS (xxx étant le nom de ton exécutable)
  • sur la ligne de commande : configure LDFLAGS=…

Je te conseille de regarder des exemples sur d'autres bibliothèques. Par exemple : radvd-2.10, coreutils-8.21, curl-7.37.0,…

Est-ce qu'il y a une sorte de normalisation du format de log binaire ?

C'est quelque chose qui manquait au début des logs textuels, dont la seule normalisation tacite était que les logs étaient en caractères imprimables (visibles), et séparés par des retours à la ligne.

Et ce serait utile pour les logs binaires afin d'utiliser les mêmes outils d'analyse de logs partout.

Plutôt que changer la procédure, tu pourrais aussi installer nativement Linux sur ton PC actuel. Éventuellement tu gardes Windows en double boot, ou dans une VM. C'est ce que j'ai fait. Le choses qui m'ont obligé à garder Windows en OS secondaire sont :
- Word, Excel, MS project, Outlook (dans une VM)
- un autre logiciel que j'utilise rarement (dans le boot Windows)

Ce sera plus rapide que changer la procédure.

Sinon, pour les arguments que tu demandes, les avantages d'un Linux natif :
- davantage d'outils de développement
- environnement de développement plus efficace (ex: le click du milieu pour copier-coller, les window managers)
- les man pages
- les drivers USB, ethernet, ports série, etc. mieux supportés que par Windows (moins buggés, et installés de base avec Linux)
- pas d'antivirus, donc gain de performance significatif

Précision : l'interface wifi est eth0

Comment ça se fait ? Çe devrait être wlan0, non ?

As-tu aussi un port ethernet ? N'y aurait-il pas un conflit de nom ?

J'ai souvent eu des problèmes pour ouvrir du CSV dans Excel. Selon la langue de l'OS (anglais ou français), il faut que les séparateurs soient des virgules ou des points-virgules, et même si Excel permet de choisir le séparateur, certaines versions d'Excel semblent limitées (bugguées ?) dans leur fonction d'import du CSV. Dans les cas durs rencontrés, il m'était impossible de bien répartir le contenu selon les colonnes.

Dans quels pays se situent les marques dont on parle (fondation GNOME et Gnome de Groupon) ? Car selon les pays, la logique de marque n'est probablement pas la même.

Tu fais bien de mettre les points sur les i, parce que je me suis mal exprimé.

Appuyons la discussion sur un petit schéma des flash translation layers :

Le correctif de firmware proposé par Samsung porte probablement sur les couches STL, BML et LLD.

Ce que je voulais dire c'est que peut-être que les couches STL, BML et LLD dans les disques SSD de Samsung utilisent les mêmes algorithmes et la même dispositions sur les cellules mémoires qu'un filesystem existant : F2FS, UBIFS, JFFS2, etc.

En reprenant les mêmes algorithmes et la même disposition sur le support physique, ils peuvent réutiliser du code open-source existant, et bénéficier de la robustesse de ce code et des algorithmes associés. Mais également à l'opposé, s'ils utilisent du code open-source existant et qu'ils ont le bug exposé dans le journal, c'est intéressant de le savoir, car le code open-source pourrait être infecté du même bug.

Comme tu dis, on parle de firmware/micrologiciel. Donc il s'agit bien de logiciel.

le filesystem (une composante logicielle) n'a pas grand chose à voir

Et pourquoi pas le filesystem ? Pour de la flash le logiciel de gestion du filesystem est loin d'être trivial. Regarde le code d'UBI et d'UBIFS dans le kernel linux…

Ce serait intéressant de savoir quel filesystem ils utilisent.
Est-ce qu'ils utilisent F2FS ? (F2FS est développé par Samsung pour le kernel Linux)

Référence : F2FS

Les grandes SSII sur Toulouse embauchent de temps en temps des docteurs. Je connais des docteurs en astrophysique et en mathématique qui ont été embauchés pour des projets chez Thalès ou Airbus : informatique avec une composante scientifique (données satellite, avionique).

Exemples de grandes SSII : Sogeti, Cap Gemini, Sopra, Thalès Services, …
(il y a eu récemment des fusions-acquisitions, et je ne sais pas si les noms sont encore d'actualité)

Et en ce moment, je ne sais pas s'il est facile de se faire embaucher… (Airbus a ralenti ses développements)

Si ton filesystem est déjà chiffré, c'est pareil : tu ne pourras pas déchiffrer les fichiers chiffrés par le pirate.