mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2023-01-01 18:11:09 -04:00
commit 9ce6309e4a
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 84 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

14
doc/forum/Way_to_add_file_in_other_directory_without_change__63__.mdwn Normal file
View file

@ -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.

8
doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_1c324fdc46fe9db3778bf21d9fbdd021._comment Normal file
View file

@ -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.
"""]]

20
doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_9d18e0752ae4b1ded9611759fbe2eeec._comment Normal file
View file

@ -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.
"""]]

21
doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_3_61841267c85651158652b20b137fb5fb._comment Normal file
View file

@ -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)
"""]]

21
doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment Normal file
View file

@ -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? 🤔
"""]]