From 0c216a7cb8535a90801f378dedb9374b77e38b26 Mon Sep 17 00:00:00 2001 From: username Date: Mon, 18 Oct 2021 19:54:29 +0000 Subject: [PATCH 1/3] Added a comment --- ..._679ad639cbba7f9a4d28131219d20178._comment | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment new file mode 100644 index 0000000000..fdf131035d --- /dev/null +++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment @@ -0,0 +1,25 @@ +[[!comment format=mdwn + username="username" + avatar="http://cdn.libravatar.org/avatar/3c17ce77d299219a458fc2eff973239a" + subject="comment 18" + date="2021-10-18T19:54:29Z" + content=""" +I wasn't clear enough, or maybe I did something wrong when testing the directory special remote. + +When using standard git-annex repositories for everything as explained in comment 14 I get this: + +``` +$ git log --graph --oneline +* 5555555555 (HEAD -> master) amended commit 2 +|\ +| * 4444444444 (DVD1) DVD1 +* 3333333333 amended commit 1 +|\ +| * 2222222222 (CD1) CD1 +* 1111111111 init +``` + +The master branch tracks only the contents of my local HDD (note that in step 4 I edit the working directory to my liking and amend the automatic ```git-annex sync``` commit), and the CD1 branch contains only what's in that disc and nothing else, such that ```git checkout 2222222222``` or ```git checkout CD1``` replaces everything in the working directory with the contents of CD1, similar to mounting the physical disc and browsing its filesystem. + +Using the directory special remote, the contents of my master branch are combined with the contents of the special remote, so the same ```git checkout CD1``` command wouldn't replicate exactly what's on CD1, the master branch directory tree would still be present after the branch switch. +"""]] From 8626f35898eb42e50f8ab1ff6e57ba1d1a314cd2 Mon Sep 17 00:00:00 2001 From: Atemu Date: Tue, 19 Oct 2021 12:26:33 +0000 Subject: [PATCH 2/3] Added a comment --- ..._60b54e6bbb37464697b4f5c4ebe561da._comment | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment diff --git a/doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment b/doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment new file mode 100644 index 0000000000..6c43e974c1 --- /dev/null +++ b/doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment @@ -0,0 +1,23 @@ +[[!comment format=mdwn + username="Atemu" + avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a" + subject="comment 2" + date="2021-10-19T12:26:33Z" + content=""" +> Since this was posted, fsck has stopped complaining about files dropped with `dropunused`. + +Thank you! + +> I could imagine formalizing this ad-hoc tag into something standard in git-annex. + +This is the best option I think; some sort of flag you can set on a key that marks it as unwanted and propagates via the git-annex branch. +The actual deletions could then be carried out on the individual repos by using a dedicated command (`dropdeleted`?), by the assistant or perhaps even using `sync --content`. + +The important bit is that it shouldn't be synchronous or depend on the repository being reachable directly though; it should be recorded and propagated asynchronously. +E.g. in any tree of repos with assistants running (so, no transitive connections), marking a key as deleted in any one of them should result in the key being deleted from all of them. + +> But one problem with it is it may not play well in multiuser environments where people have different ideas about what files they want to delete all copies of. + +Ah, I didn't consider that. A recycle bin with tracked files is likely infeasible but an untracked one could still be valuable. That's a topic for another issue though. + +"""]] From 6824a56d096a608920bd0df593f5ad898893b301 Mon Sep 17 00:00:00 2001 From: Atemu Date: Tue, 19 Oct 2021 13:05:50 +0000 Subject: [PATCH 3/3] Added a comment --- ..._09b89df28a3a3dab2f0fbf2f56feafe1._comment | 36 +++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment new file mode 100644 index 0000000000..e6946ee5f6 --- /dev/null +++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment @@ -0,0 +1,36 @@ +[[!comment format=mdwn + username="Atemu" + avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a" + subject="comment 3" + date="2021-10-19T13:05:50Z" + content=""" +> Mostly people pick on gpg's public key crypto implementation, and mostly I think, because public key crypto is easy to pick at. I have not seen many such arguments about gpg that seem very convincing to me. + +Ah, this is not about the underlying algorithms and theories. Those are more than sufficient in our pre-quantum world and, as you said, AGE isn't fundamentally different here. + +What I'm mostly concerned about is the quality of the implementation; especially the non-functional aspects like speed, UI and simplicity (some of which also have security implications). + +> The way git-annex uses gpg for encryption=shared does not involve public key crypto at all, but uses AES-128, which is about as close as there is to a standard for encrypting things. + +The actual encryption is done symmetrically but the encryption of the symmetric key is done asymmetrically if I'm not mistaken. + +This is not what age aims to replace though, it functions the exact same from a high level AFAIK; just with a different implementation that satisfies different goals from GPG. + +> git-annex already links to an AES implementation for other purposes and could probably bypass gpg and use that, but that smells of implementing your own crypto. + +That definitely smells of homebrewed crypto. This is why I would love to see something like age used: It's a pre-made, (supposedly) secure, standardised crypto system/library that you can feed files into and it simply gives you encrypted files back. No faffing about with complex key setups or other brilliant UX anno 1999. + +> AGE does not seem to expose any non-public key encryption, so it could not be used for encryption=shared, I think. (Unless perhaps the public/private key pair were stored in the repo as the shared cipher?) + +I'm not sure I follow, couldn't you just generate an age keypair and simply store that in the repo? + +Does the current gpg-based implementation not do it just like that? + +> I don't like the idea of git-annex supporting more than 2 encryption programs, and even 2 seems like 1 too many. Every one will be an ongoing cost. It's not clear to me that there's enough of a benefit to support AGE, or that it would be the best choice for a +1. + +Me neither and I understand your point but the problem with that approach is that it leaves absolutely no way to migrate away from GPG. + +GPG is a complex beast that will likely need replacement within the next decade and age seems like the most obvious alternative for use-cases like git-annex. +Only time can tell whether it actually becomes the new file encryption standard but it seems like the most likely candidate right now. + +"""]]