diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__.mdwn b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__.mdwn new file mode 100644 index 0000000000..33b4165131 --- /dev/null +++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__.mdwn @@ -0,0 +1,14 @@ +Hi, +I am trying to use annex, but couldn't find a way. It will be very +helpful if anyone can help. + +I have NAS mounted on specific directory /mnt/nas/ +Suppose whole directory in it is READ-ONLY and keep the file, structure as it is now. + +I want to "annex add" files in that directory like +git annex addurl file:///mnt/nas/a.mp4 + +But it seems addurl is only for http/https and "directory special remote" have to change the whole structure of the directory. +Is there any alternative I can try? + +Thanks. diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_1c324fdc46fe9db3778bf21d9fbdd021._comment b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_1c324fdc46fe9db3778bf21d9fbdd021._comment new file mode 100644 index 0000000000..6096d7abf3 --- /dev/null +++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_1c324fdc46fe9db3778bf21d9fbdd021._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="strmd" + avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3" + subject="comment 2" + date="2023-01-01T13:28:46Z" + content=""" +Hi! Take a look at `git annex import` and its various options, it sounds like that's what you're after. +"""]] diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_9d18e0752ae4b1ded9611759fbe2eeec._comment b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_9d18e0752ae4b1ded9611759fbe2eeec._comment new file mode 100644 index 0000000000..4e9ce6695f --- /dev/null +++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_9d18e0752ae4b1ded9611759fbe2eeec._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="acadx0@9d7ca00c5a85a700a7209ab4fc2505189ded1aa3" + nickname="acadx0" + avatar="http://cdn.libravatar.org/avatar/b108d0f7ce179702be9003ca890a0131" + subject="try 2" + date="2023-01-01T04:00:54Z" + content=""" +Okay I got git annex addurl file:/// working with this config. + +``` +[annex \"security\"] + allowed-url-schemes = http https file + allowed-http-addresses = all +``` + +But it copies the file to local directory, is there a way to make it +just calculate checksum without copying(downloading) it? + +Or if there's just alternative way please let me know. +"""]] diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_3_61841267c85651158652b20b137fb5fb._comment b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_3_61841267c85651158652b20b137fb5fb._comment new file mode 100644 index 0000000000..7ccf9c0c34 --- /dev/null +++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_3_61841267c85651158652b20b137fb5fb._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="acadx0@9d7ca00c5a85a700a7209ab4fc2505189ded1aa3" + nickname="acadx0" + avatar="http://cdn.libravatar.org/avatar/b108d0f7ce179702be9003ca890a0131" + subject="hmm" + date="2023-01-01T16:49:37Z" + content=""" +thanks, but It seems git annex import is just same as + +``` +cd ~/annex/ +cp /mnt/nas/FILE FILE +git annex add FILE + +or + +git annex addurl file:///mnt/nas/FILE +``` + +Is there a way to avoid copying file when trying to add file in annex repository, but do all the required operations like checksum calculation (as it is already accessible in local filesystem through nas) +"""]] diff --git a/doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment b/doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment new file mode 100644 index 0000000000..2455fcf1b0 --- /dev/null +++ b/doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="nobodyinperson" + avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5" + subject="comment 3" + date="2022-12-29T10:49:27Z" + content=""" +> But... If the attacker only cares about a single file, they only have to run scrypt **once.** + +Well, the attacker would still need to run scrypt many times to brute-force the actual content, IIUC. + +I understand it like this (might be wrong, I'm no security expert): + +- scrypt is an arbitrarily-slow key derivation function taking an input (the „password” - or for us: the file content) and some parameters (salt, n, r, p) +- knowing the parameters (salt, n, r, p) is necessary to verify file integrity so storing those in an easily accessible way (e.g. directly in the key) would simplify things and we wouldn't need to teach git-annex much more to handle this. +- A (public) git-annex repo that has some files „scrypt”-ed like this then contains the scrypt hash and the parameters used to generate that hash. So this is equivalent to a database breach where user credentials were secured with scrypt. (right?) +- An attacker thus now still has to brute-force the content of the desired file. With little information about how that file looks in detail („how exactly is that YAML containing the password structured? How big is it even? What key order? Are there comments? That comment could even contain a random salt itself...”), this brute-forcing should be pretty infeasible if the scrypt parameters are tuned to hash *ridiculously* slow (like multiple seconds even on a beefy machine with much RAM - doesn't bother us if `git annex fsck` is slow on that one file. Big files hash slowly anyway as well...). It should definitely be harder than cracking a breached password database where it is clear that the passwords don't contain newlines and there most likely is a size limit, etc. + +If my above assumptions are correct, an `scrypt` key backend for git-annex should make for a nice way of hiding the content of *some* files in a public repo, right? + +P.S: Thinking about the 'that secured file could contain potentially large random comments acting as a salt next to the actual secret' together with removing the size from the key ([`git annex migrate --remove-size`](https://git-annex.branchable.com/git-annex-migrate/)) should already be pretty safe with the default SHA256-backend, right? 🤔 +"""]]