J'ai fait quelques tests et je peux vous donner une réponse (qui, je l'espère, fera autorité).

Réponse courte : les versions sont stockées sur le même disque (ou image disque) que le fichier réel, donc les versions ne devraient pas divulguer d'informations en dehors de votre image chiffrée. Mais il peut y avoir une autre fuite, voir ci-dessous.

Longue réponse : Versions crée un dossier invisible au sommet de chaque volume, nommé ".DocumentRevisions-V100" avec une structure interne comme celle-ci :

.DocumentRevisions-V100
    .cs
        ChunkStorage    (this is presumably used to store chunks of large files that didn't entirely change between versions)
    AllUIDs             (this is only created on disks that have permissions ignored)
    ChunkTemp
    db-v1
        db.sqlite      (this is the primary index of document IDs, etc)
    PerUID             (this is only created on disks that have ownership respected)
        501            (documents created/owned by user #501)
        502            (etc...)
    staging            (???)

Pour plus d'informations sur l'index sqlite et le démon d'arrière-plan qui en gère l'accès, lisez le document suivant L'excellente critique de John Siracusa sur ars technica .

Les versions du document elles-mêmes sont stockées dans des sous-répertoires dans AllUIDs ou PerUID/youruserid. Sous ce dernier, chaque document versionné obtient son propre sous-répertoire, numéroté en commençant par 1. Sous ce dernier se trouve un dossier unique nommé "com.apple.documentVersions", et sous celui-ci, chaque révision est stockée comme un document séparé (à moins qu'il ne soit cassé en morceaux -- je n'ai pas expérimenté avec de gros documents) nommé avec un UUID et une extension de type. Par exemple, si je (utilisateur #501) édite un document rtf sur mon volume de démarrage et enregistre plusieurs révisions, elles pourraient être stockées comme :

/.DocumentRevisions-V100/PerUID/501/1/com.apple.documentVersions/0787B7C3-DE11-4065-9FD9-61870212011D.rtf
/.DocumentRevisions-V100/PerUID/501/1/com.apple.documentVersions/D533CF36-0D49-4910-B0EB-C92395C05726.rtf

Si j'ouvrais ensuite un autre fichier rtf et que j'en enregistrais une version, il pourrait être nommé :

/.DocumentRevisions-V100/PerUID/501/2/com.apple.documentVersions/74A6EF6E-A22A-4196-B560-40ABDBF46DF4.rtf

Si je l'enregistrais sur mon image SecretDocs (montée avec propriété ignorée), les versions seraient stockées comme suit :

/Volumes/SecretDocs/.DocumentRevisions-V100/AllUIDs/1/com.apple.documentVersions/2ED4DAFD-9BCF-4158-BFDB-F9EEC631E44A.rtf

BTW, les permissions sur les fichiers de version semblent être clonées à partir des fichiers originaux. Les permissions sur les dossiers environnants ont tendance à n'autoriser que l'exécution (c'est-à-dire que vous ne pouvez pas voir les noms de fichiers, mais si vous connaissez le nom du fichier, vous pouvez y accéder). Par exemple, PerUID/501 est configuré pour n'autoriser l'exécution que pour l'utilisateur 501, aucun accès pour les autres. Le dossier db-v1 n'autorise que l'accès Root. Sans examiner en détail, il semble que le système soit assez verrouillé.

Maintenant, à propos de cette autre fuite avec laquelle je vous ai menacé : Les applications Lion ont tendance à sauvegarder leur état lorsque vous quittez, donc si vous avez un document confidentiel ouvert lorsque vous quittez, certaines de ses informations (comme, je pense, une capture d'écran) peuvent être stockées dans ~/Library/Saved Application State/someappid.savedState. Tant que vous fermez avant d'enregistrer I pensez à vous êtes en sécurité ici.

Une excellente question de la part de Phil M. !

Les données relatives aux versions d'Apple ne sont parfois pas limitées à /.DocumentRevisions-V100

Je vais être aussi bref que possible. Concepts clés :

• Cycle de vie transparent des applications (TAL) - sauvegarde automatique, reprise des versions
• Les systèmes de fichiers prennent en charge le stockage permanent des versions.

Dans certaines circonstances,

Dans 10.7 (Build 11A511) : les sous-répertoires de ~/Library sont utilisés, l'accès n'étant pas limité à l'utilisateur racine.

-  https://discussions.apple.com/message/15739595#15739595 (2011-07-25)

Aussi, légèrement adapté de https://discussions.apple.com/message/15741724#15741724

Dans mon test le plus récent avec le même serveur AFP, les versions pour une capture d'écran .png à distance :

• sont local et à l'intérieur de l'espace bien caché ~/Library veuillez voir Sauvegarde automatique, versions, reprise et cycle de vie transparent des applications (TAL) : informations techniques émergentes

• sont pas localement à /.DocumentRevisions-V100

• sont pas à distance à /.DocumentRevisions-V100

  reunion:~ centrimadmin$ ls -ld /.DocumentRevisions-V100 ls: /.DocumentRevisions-V100: No such file or directory

Au niveau local, il pourrait y avoir un peu de les données correspondantes à l'adresse /.DocumentRevisions-V100 mais dans ce cas, les versions du fichier distant sont locales, et ne sont pas limitées à l'utilisateur Root. Voir par exemple la capture d'écran 001 à http://www.wuala.com/grahamperrin/public/2011/07/25/e/?mode=gallery démontrant les versions locales du fichier distant, ouvertes après la déconnexion du serveur de fichiers.

Retour à la question d'ouverture de Ask Different images .sparsebundle cryptées, sécurité. Considérez ceci :

Dans le contexte d'une image disque chiffrée de type "sparse bundle", les utilisateurs sont plus enclins à utiliser JHFS+ (qui prend en charge le stockage de la version permanente) que MS-DOS (qui ne le prend pas en charge).

Cependant, quelqu'un devrait vérifier si les versions non cryptées restent dans le répertoire personnel de l'utilisateur - qui peut être non crypté - après le démontage d'un tel volume.

Personnellement, je trouve fseventer le plus utile dans des situations de test comme celle-ci. YMMV.

Séparation

Une partie de cette réponse peut soulever des questions qui ne sont pas spécifiques au cryptage, ni aux images de disque à liasses éparses, ni à la sécurité. Il s'agit de sujets potentiellement complexes, alors s'il vous plaît, plutôt que de poser des questions dans les commentaires sous cette réponse, je devrais probablement encourager chaque membre de l'équipe à répondre à ces questions. question à demander séparément.

J'ai vérifié La documentation pour développeurs d'Apple sur la fonctionnalité des versions et il semble indiquer que les versions précédentes d'un document sont stockées au même "endroit" (c'est-à-dire soit le même fichier, soit le même dossier) que la version actuelle du document ; mais la documentation est peu détaillée.

Il y a aussi l'article d'AppleInsider intitulé "Dans Mac OS X 10.7 Lion : Sauvegarde automatique, versions de fichiers et Time Machine ". qui dit :

Contrairement à Time Machine, Versions ajoute tous les instantanés de modification dans le fichier de document local, évitant ainsi un désordre dans le système de fichiers et la nécessité d'accéder aux sauvegardes à partir d'une Time Capsule ou d'un autre disque externe juste pour revenir aux versions précédentes créées au cours des dernières heures.

Je n'ai pas encore trouvé de description plus détaillée du fonctionnement de la fonction "Versions".

Gordon, c'est une bonne nouvelle pour tout le monde, ainsi que pour les développeurs des logiciels Knox et Espionage (j'utilise ces deux applications).

Voici cependant un scénario auquel les utilisateurs doivent faire attention. Si vous accédez à un fichier dans une image disque chiffrée montée sur un lecteur externe, les fichiers de version existeront probablement sur le lecteur système de l'utilisateur sous une forme non chiffrée. Une solution de contournement serait de copier le .sparsebundle sur le lecteur système avant de le monter.

Un autre scénario est que le .sparsebundle se trouve sur un autre Mac Snow Leopard sur le même réseau et que l'image est partagée sur le réseau, ce qui permet de la monter sur un Mac Lion en y accédant par le Finder. (Je le fais parfois.) Cela aurait pour conséquence de placer tous les fichiers de version sur le disque système de l'utilisateur en clair. Une solution serait d'utiliser le partage d'écran pour contrôler le Mac Snow Leopard, puis de monter et de travailler sur l'image sur ce Mac.

En fin de compte, dans Lion, les gens doivent comprendre davantage et être plus prudents que jamais lorsqu'ils utilisent des images de disque cryptées si les images ne sont pas situées sur le lecteur système. J'espère que les développeurs de Knox et d'Espionage mettront en garde leurs clients contre ces problèmes.

EDIT : La réponse de Graham semble confirmer la plupart de mes hypothèses.