From 6b5206db855df529e73363db807b74c680e75f78 Mon Sep 17 00:00:00 2001 From: matrss Date: Mon, 27 Jan 2025 15:08:57 +0000 Subject: [PATCH 1/3] Added a comment --- .../comment_3_a53bfbd63b3ec5834286167a61d5c4ba._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_3_a53bfbd63b3ec5834286167a61d5c4ba._comment diff --git a/doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_3_a53bfbd63b3ec5834286167a61d5c4ba._comment b/doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_3_a53bfbd63b3ec5834286167a61d5c4ba._comment new file mode 100644 index 0000000000..ec4fbe5cf7 --- /dev/null +++ b/doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_3_a53bfbd63b3ec5834286167a61d5c4ba._comment @@ -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... +"""]] From cb258ca480d460e571051e0f4bb4ba70f635c88e Mon Sep 17 00:00:00 2001 From: matrss Date: Mon, 27 Jan 2025 15:14:44 +0000 Subject: [PATCH 2/3] Added a comment --- .../comment_4_58ddd2578f115af22e995bd09c2bcea2._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_4_58ddd2578f115af22e995bd09c2bcea2._comment diff --git a/doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_4_58ddd2578f115af22e995bd09c2bcea2._comment b/doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_4_58ddd2578f115af22e995bd09c2bcea2._comment new file mode 100644 index 0000000000..bd64c6c224 --- /dev/null +++ b/doc/bugs/git_annex_checkpresentkey_removes_git_credentials/comment_4_58ddd2578f115af22e995bd09c2bcea2._comment @@ -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. +"""]] From 7adf1f45fa24534e84cf891242043af59d0fd7c8 Mon Sep 17 00:00:00 2001 From: matrss Date: Mon, 27 Jan 2025 15:26:15 +0000 Subject: [PATCH 3/3] Added a comment --- ...ent_6_4641d3ad4a8a8f17f8df47e02555dfa2._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/todo/generic_p2p_socket_transport/comment_6_4641d3ad4a8a8f17f8df47e02555dfa2._comment diff --git a/doc/todo/generic_p2p_socket_transport/comment_6_4641d3ad4a8a8f17f8df47e02555dfa2._comment b/doc/todo/generic_p2p_socket_transport/comment_6_4641d3ad4a8a8f17f8df47e02555dfa2._comment new file mode 100644 index 0000000000..ce9a361d40 --- /dev/null +++ b/doc/todo/generic_p2p_socket_transport/comment_6_4641d3ad4a8a8f17f8df47e02555dfa2._comment @@ -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. +"""]]