]> dgit.raspbian.org Git - git-annex.git/commitdiff
comment
authorJoey Hess <joeyh@joeyh.name>
Tue, 11 Jan 2022 17:07:51 +0000 (13:07 -0400)
committerJoey Hess <joeyh@joeyh.name>
Tue, 11 Jan 2022 17:07:51 +0000 (13:07 -0400)
doc/tips/using_signed_git_commits/comment_4_5ad0596373cc363ec9bc0b69efbac03c._comment [new file with mode: 0644]

diff --git a/doc/tips/using_signed_git_commits/comment_4_5ad0596373cc363ec9bc0b69efbac03c._comment b/doc/tips/using_signed_git_commits/comment_4_5ad0596373cc363ec9bc0b69efbac03c._comment
new file mode 100644 (file)
index 0000000..7ac72d4
--- /dev/null
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-01-11T17:02:59Z"
+ content="""
+Are we still concerned about this? Well, git has a workaround for SHA1's
+insecurity and will eventually change hashes. There are plenty of other
+reasons to want to sign git commits, certianly.
+
+The webapp bypasses gpg signing because it commits automatically and
+potentially frequently, and depending on how gpg handles password
+prompting, that could flood the user with repeated password prompts.
+But you can change this default with the `annex.allowsign` configuration.
+
+(Commits to the git-annex branch are also not signed by default, for similar
+reasons. Also, the risks of SHA1 collisions involving the git-annex branch
+seem small to nonexistant, since that branch only records bookeeping
+information git-annex cares about, and a small amount of configuration.
+git-annex does not use data from that branch in any way that would let
+an untrusted person who modified the branch do anything malicious.)
+"""]]