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 2025-01-27 12:23:13 -04:00
commit 0529f9a84a
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 30 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_3_a53bfbd63b3ec5834286167a61d5c4ba._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="matrss"
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
subject="comment 3"
date="2025-01-27T15:08:57Z"
content="""
I can still reproduce this issue with 10.20250115, but in my testing it seems like it only happens against a forgejo-aneksajo instance on localhost without TLS, not against a different remote instance. This setup required `git config annex.security.allowed-ip-addresses 127.0.0.1`, maybe it has something to do with that or TLS...
"""]]

8
doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_4_58ddd2578f115af22e995bd09c2bcea2._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="matrss"
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
subject="comment 4"
date="2025-01-27T15:14:44Z"
content="""
It definitely takes a different code path somehow, as I don't see the `Utility.Url` debug messages when the remote is not on localhost.
"""]]

14
doc/todo/generic_p2p_socket_transport/comment_6_4641d3ad4a8a8f17f8df47e02555dfa2._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="matrss"
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
subject="comment 6"
date="2025-01-27T15:26:15Z"
content="""
> > If the PSK were fully contained in the remote string then a third-party getting hold of that string could pretend to be the server
> I agree this would be a problem, but how would a third-party get ahold of the string though? Remote urls don't usually get stored in the git repository, perhaps you were thinking of some other way.
My thinking was that git remote URLs usually aren't sensitive information that inherently grant access to a repository, so a construct where the remote URL contains the credentials is just unexpected. A careless user might e.g. put it into a `type=git` special remote or treat it in some other way in which one wouldn't treat a password, without considering the implications. I am not aware of a way in which they could be leaked without user intervention, though.
Having separate credentials explicitly named as such just seems safer. But in the end this would be the responsibility of the one implementing the p2p transport, anyway.
"""]]