From: Joey Hess Date: Tue, 19 Oct 2021 16:43:08 +0000 (-0400) Subject: comment X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~79^2~125 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=67a67d740b4245c310c5869e767738a023654c5d;p=git-annex.git comment --- diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_b9de19ba8382225ac8c65ee1ad8110a8._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_b9de19ba8382225ac8c65ee1ad8110a8._comment deleted file mode 100644 index 051cfb4d25..0000000000 --- a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_b9de19ba8382225ac8c65ee1ad8110a8._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2021-10-19T13:58:24Z" - content=""" -Sequoia-PGP could be another contender (OpenPGP in rust). There is a sq -command line interface that is equivilant to gpg. - -It should be able to decrypt objects in repositories encrypted using gpg. -If that works well, git-annex could support it in parallel with gpg for -some time, then deprecate the gpg support and eventually remove it. This is -a more appealing path than supporting multiple encryption tools -indefinitely. - -This issue is a pre-requisite for using sq, although presumably the -low-level library could be used directly to avoid the issue. - -"""]] diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_4_b9de19ba8382225ac8c65ee1ad8110a8._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_4_b9de19ba8382225ac8c65ee1ad8110a8._comment new file mode 100644 index 0000000000..3bb4de0e27 --- /dev/null +++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_4_b9de19ba8382225ac8c65ee1ad8110a8._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2021-10-19T13:58:24Z" + content=""" +Sequoia-PGP could be another contender (OpenPGP in rust). There is a sq +command line interface that is equivilant to gpg. + +It should be able to decrypt objects in repositories encrypted using gpg. +If that works well, git-annex could support it in parallel with gpg for +some time, then deprecate the gpg support and eventually remove it. This is +a more appealing path than supporting multiple encryption tools +indefinitely. + +This issue is a pre-requisite for using sq, although presumably the +low-level library could be used directly to avoid the issue. + +"""]] diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_5_c81d61a221fd93eb25765998b67bbde7._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_5_c81d61a221fd93eb25765998b67bbde7._comment new file mode 100644 index 0000000000..d3aee173b4 --- /dev/null +++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_5_c81d61a221fd93eb25765998b67bbde7._comment @@ -0,0 +1,32 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 5""" + date="2021-10-19T16:33:01Z" + content=""" +> I'm not sure I follow, couldn't you just generate an age keypair and simply store that in the repo? +> +> Does the current gpg-based implementation not do it just like that? + +No, it uses gpg --symmetric which is much simpler and also likely more +secure. + +As far as gpg's UI complexity, it's a problem to some extent (although every +one of those options presumably has a user), but notice that a git-annex user +who uses encryption=shared never has to touch gpg's interface at all. +This is by design. It's only with encryption=hybrid and pubkey that the user +is exposed to the complexities of public key crypto, and I expect that mostly +users who already are familiar with that and need the inherent complexity of it +will use those. + +> age seems like the most obvious alternative for use-cases like +> git-annex. Only time can tell whether it actually becomes the new file encryption +> standard but it seems like the most likely candidate right now. + +I don't follow this reasoning; the openpgp standard is a well-established +standard with many implementations, and so it seems likely that an implementation +of that standard will be what replaces gpg, if anything. + +(It also is possible that gpg eventually ends up being reimplemented using +something like Sequoia-PGP under the hood to gain the protections from C-level +security holes, which are certainly a real concern.) +"""]]