mbox series

[0/3] fast-export, fast-import: implement signed-commits

Message ID 20210419225441.3139048-1-lukeshu@lukeshu.com (mailing list archive)
Headers show
Series fast-export, fast-import: implement signed-commits | expand

Message

Luke Shumaker April 19, 2021, 10:54 p.m. UTC
From: Luke Shumaker <lukeshu@datawire.io>

fast-export has an existing --signed-tags= flag that controls how to
handle tag signatures.  However, there is no equivalent for commit
signatures; it just silently strips the signature out of the commit
(analogously to --signed-tags=strip).

So implement a --signed-commits= flag in fast-export, and implement
the receiving side of it in fast-import.

Luke Shumaker (3):
  git-fast-import.txt: add missing LF in the BNF
  fast-export: rename --signed-tags='warn' to 'warn-verbatim'
  fast-export, fast-import: implement signed-commits

 Documentation/git-fast-export.txt | 18 +++++--
 Documentation/git-fast-import.txt |  9 +++-
 builtin/fast-export.c             | 88 +++++++++++++++++++++++++------
 builtin/fast-import.c             | 15 ++++++
 t/t9350-fast-export.sh            | 82 ++++++++++++++++++++++++++++
 5 files changed, 191 insertions(+), 21 deletions(-)

Comments

Elijah Newren April 21, 2021, 6:12 p.m. UTC | #1
On Mon, Apr 19, 2021 at 3:54 PM Luke Shumaker <lukeshu@lukeshu.com> wrote:
>
> From: Luke Shumaker <lukeshu@datawire.io>
>
> fast-export has an existing --signed-tags= flag that controls how to
> handle tag signatures.  However, there is no equivalent for commit
> signatures; it just silently strips the signature out of the commit
> (analogously to --signed-tags=strip).
>
> So implement a --signed-commits= flag in fast-export, and implement
> the receiving side of it in fast-import.

I understand adding an option to fast-export, but shouldn't there also
be one for fast-import?  In particular, I can see users wanting any of
the following:

* I want these signatures exported and imported because I know I won't
tweak them and they'll still be valid.
* I want these signatures even though they'll be invalid.  Whatever,
I'll just deal with it.
* I want the signatures exported and imported *when they will remain
valid*.  Always exporting them makes sense, because fast-export
doesn't know about tweaks I'll be making to its output before feeding
it to fast-import.  But fast-import should have options to
strip-if-invalid/warn-if-invalid/error-if-invalid/import-without-warning
for these tags (though they don't have to use these exact names).

I know fast-import doesn't do anything of the sort for signed tags,
but fast-import also doesn't support signed tags as per this comment
in the documentation:

"""
Signing annotated tags during import from within fast-import is not
supported.  Trying to include your own PGP/GPG signature is not
recommended, as the frontend does not (easily) have access to the
complete set of bytes which normally goes into such a signature.
If signing is required, create lightweight tags from within fast-import with
`reset`, then create the annotated versions of those tags offline
with the standard 'git tag' process.
"""

it just happens to "work" since the signature is part of the
annotation and fast-import doesn't attempt to read or validate the
annotation in any way, treating it as free-from text.  I'd say users
relying on this are on somewhat shaky ground.

But here you're adding explicit fast-import directives to the language
for signatures of commits, so you clearly do need to care.  And I
suspect fast-import's default should be error-if-invalid rather than
import-without-warning.

> Luke Shumaker (3):
>   git-fast-import.txt: add missing LF in the BNF
>   fast-export: rename --signed-tags='warn' to 'warn-verbatim'
>   fast-export, fast-import: implement signed-commits
>
>  Documentation/git-fast-export.txt | 18 +++++--
>  Documentation/git-fast-import.txt |  9 +++-
>  builtin/fast-export.c             | 88 +++++++++++++++++++++++++------
>  builtin/fast-import.c             | 15 ++++++
>  t/t9350-fast-export.sh            | 82 ++++++++++++++++++++++++++++
>  5 files changed, 191 insertions(+), 21 deletions(-)
>
> --
> 2.31.1
>
> Happy hacking,
> ~ Luke Shumaker
Luke Shumaker April 21, 2021, 7:28 p.m. UTC | #2
On Wed, 21 Apr 2021 12:12:40 -0600,
Elijah Newren wrote:
> 
> On Mon, Apr 19, 2021 at 3:54 PM Luke Shumaker <lukeshu@lukeshu.com> wrote:
> >
> > From: Luke Shumaker <lukeshu@datawire.io>
> >
> > fast-export has an existing --signed-tags= flag that controls how to
> > handle tag signatures.  However, there is no equivalent for commit
> > signatures; it just silently strips the signature out of the commit
> > (analogously to --signed-tags=strip).
> >
> > So implement a --signed-commits= flag in fast-export, and implement
> > the receiving side of it in fast-import.
> 
> I understand adding an option to fast-export, but shouldn't there also
> be one for fast-import?  In particular, I can see users wanting any of
> the following:
> 
> * I want these signatures exported and imported because I know I won't
> tweak them and they'll still be valid.
> * I want these signatures even though they'll be invalid.  Whatever,
> I'll just deal with it.
> * I want the signatures exported and imported *when they will remain
> valid*.  Always exporting them makes sense, because fast-export
> doesn't know about tweaks I'll be making to its output before feeding
> it to fast-import.  But fast-import should have options to
> strip-if-invalid/warn-if-invalid/error-if-invalid/import-without-warning
> for these tags (though they don't have to use these exact names).
> 
> I know fast-import doesn't do anything of the sort for signed tags,
> but fast-import also doesn't support signed tags as per this comment
> in the documentation:
> 
> """
> Signing annotated tags during import from within fast-import is not
> supported.  Trying to include your own PGP/GPG signature is not
> recommended, as the frontend does not (easily) have access to the
> complete set of bytes which normally goes into such a signature.
> If signing is required, create lightweight tags from within fast-import with
> `reset`, then create the annotated versions of those tags offline
> with the standard 'git tag' process.
> """
> 
> it just happens to "work" since the signature is part of the
> annotation and fast-import doesn't attempt to read or validate the
> annotation in any way, treating it as free-from text.  I'd say users
> relying on this are on somewhat shaky ground.
> 
> But here you're adding explicit fast-import directives to the language
> for signatures of commits, so you clearly do need to care.  And I
> suspect fast-import's default should be error-if-invalid rather than
> import-without-warning.

I agree that this would be a good and useful flag to add to
fast-import.  However, I don't think that it's a necessary thing to
add for this work, and I think that it's beyond the scope of what I am
willing to implement.

I see where you're coming from when you say that tags and commits are
different in this regard, but I don't agree.  The signed tags
situation does look like shakey ground, but IMO once fast-export
gained the --signed-tags option, that was saying "this is the correct
and stable way of encoding a tag signature in a fast-import stream".
The fact that it is wonky in that it is shoved in to the message is an
accident of implementation history, and to me doesn't say anything
about the nature of the thing.

I think that such a flag in fast-import is just as worthy of existing
for tags as it is worthy of existing for commits.

Actually, I'm not sure I think such flags belong in fast-import
itself, I think it may make good sense to have such a filter
implemented as an external tool.  Fast-export and fast-import seem to
avoid using the many parts of standard git library functions,
apparently (to me) to avoid allocations because "fast".  Given that
trouble gone to just to avoid allocations, calling out to GPG seems
prohibitively slow by comparison.  But I agree such functionality
would be good and useful, regardless of whether I think it belongs in
fast-import itself.