Re: [PATCH v2] gpg-interface.c: detect and reject multiple signatures on commits

[Tacitus Aedifex]

I think that there is a more simple way to catch multiple signatures see below.  
Other than that, I like this patch.


Signed-off-by: Tacitus Aedifex 
---
gpg-interface.c | 18 ++
1 file changed, 18 insertions(+)

diff --git a/gpg-interface.c b/gpg-interface.c
index db17d65f8..a4dba3361 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -93,6 +93,7 @@ static void parse_gpg_output(struct signature_check *sigc)
{
const char *buf = sigc->gpg_status;
int i;
+   int multi_sig = 0;

/* Iterate over all search strings */
for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
@@ -115,6 +116,23 @@ static void parse_gpg_output(struct signature_check *sigc)
next = strchrnul(found, '\n');
sigc->signer = xmemdupz(found, next - found);
}
+		} else 
+			multi_sig++;

+
+   /*
+* GOODSIG, BADSIG, etc. can occure only once for each 
signature.
+* Therefore, if we had more than one then we're dealing with
+* multiple signatures. We don't support them currently and 
they are
+* rather hard to create, so something is likely probably not 
right
+* and we should reject them altogether.
+*/
+   if (multi_sig > 1) {
+   sigc->result = 'E';
+   /* clear partial data to avoid confusion */
+   if (sigc->signer)
+   FREE_AND_NULL(sigc->signer);
+   if (sigc->key)
+   FREE_AND_NULL(sigc->key);
}
}
}
--
2.18.0.129.ge333175
--

Re: Fixing constant preference prompts during tests

[Tacitus Aedifex]

On Wed, Sep 26, 2018 at 02:48:49PM -0700, Junio C Hamano wrote:

We do not want your choice of gpg.program or what kind of
trust you have personally recorded in your ~/.gnupg/ affect how gpg
invoked inside our tests work.


This makes sense to me now. I get what you are saying. The gpg binary installed 
on my system is fairly new:


gpg --version
gpg (GnuPG) 2.2.8
libgcrypt 1.8.3
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/user/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
   CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed

I'm not sure if that has anything to do with it. I'm going to have to 
investigate further to figure out what is being executed and with what 
parameters that leads to the prerefences prompt. While working with GPG on 
another project I noticed that GPG doesn't like to work with keyrings other 
than the default ones. I tried a bunch of different combinations of 
--no-default-keyrings, --homedir, --default-key, etc to try to get GPG to never 
touch ~/.gnupg and I couldn't figure it out. It would always re-create ~/.gnupg 
and default keyrings and even read gpg.conf when explicitly told not to. I 
suspect that is what is going on here.


//tæ

Re: GPG signing is bent on WIndows

[Tacitus Aedifex]

On Wed, Sep 26, 2018 at 04:05:02PM -0400, Jeffrey Walton wrote:

I got to look at it today. On Windows:

$ cat ~/.gnupg/gpg-agent.conf
pinentry-program
/usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac


Do you have this app on your system? That path looks like one for a mac 
pinentry program and won't work on Windows. There are several tutorials on the 
web that explain how to get GPG working on windows. I suggest starting there.  
Get so that you can sign normal files from the command line on Windows and then 
try again.


//tæ

Re: Fixing constant preference prompts during tests

[Tacitus Aedifex]

On Wed, Sep 26, 2018 at 10:15:06AM -0700, Junio C Hamano wrote:

Nobody raised this so far as far as I recall; thanks for the first
one to do so, as it is a sign that you are doing something unusual
(e.g. have newer or different version of GPG than most other people)
and others will hit by the same symptom later when whatever thing
you are using as a minority right now becomes more prevalent.


Indeed I am. I use Qubes OS with a split GPG setup. I have a virtual machine 
dedicated to handling my crypto keys and I use the qubes GPG wrapper to 
interact with the signing VM through the Xen hypervisor. I think the only thing 
that needs to change is that the tests respect gpg.program setting in 
.gitconfig. Signing and verifying commits and tags works perfectly but the 
tests don't allow me to override which program is used.


It may be a little more complicated than this because looking at the tests it 
seems like they set up their own dummy user with dummy keys and use gpg 
directly. I have gpg installed on my client VM so in theory it should work. I 
can't tell exctly where the prompt is coming from.


//tæ

Fixing constant preference prompts during tests

[Tacitus Aedifex]

I keep getting prompted for my algorithm preferences while running all of the 
git test suite:


Set preference list to:
Cipher: AES256, AES192, AES, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: Uncompressed
Features: MDC, Keyserver no-modify

What is the best way to prevent this from happening? I want to run the entire 
test suite unattended and have it complete on its own.


//tæ

avoid "Set preference list" during make test?

[Tacitus Aedifex]

While running `make test` on the git source tree I keep getting asked:

 Set preference list to:
   Cipher: ...
   Digest: ...
   etc...

Is there any way to turn that prompt off so that `make test` completes without 
any keyboard input?


//tæ

Re: git-bug: Distributed bug tracker embedded in git

[Tacitus Aedifex]

I really like this idea. I've often wanted an integrated bug database like 
this. My solution has always been to have a subrepo storing bug reports and 
coments in .txt files and then using bash porcelain scripts to make a git-like 
interface. I think I like this better. My only nit is Go. That makes me sad.  
Someone should re-implement this in C or Rust.


//t??

Re: abstracting commit signing/verify to support other signing schemes

[Tacitus Aedifex]

On Fri, Aug 03, 2018 at 06:07:46PM -0400, Jeff King wrote:

There's been some work on this lately. See this patch and the response
thread:

 https://public-inbox.org/git/20180409204129.43537-9-mastahy...@gmail.com/

The more recent work focused on just doing the minimum to provide
gpg/gpgsm variants:

 https://public-inbox.org/git/cover.1531831244.git.henning.sch...@siemens.com/

That replaces the earlier patch series, and is currently merged to the
'next' branch and is on track to get merged to 'master' before Git 2.19
is released.


thank you for setting the context. it looks like both patch sets are going in 
the same direction that i suggested, at least with the config variables.  
personally, i prefer the 'signingtool.' approach in the older patch set 
over the 'gpg.' approach in the newer patch set since my goal is to get 
away from assuming gpg.


the older patch set suggested the idea of using PEM strings to match up the 
signature payload with a certain signing tool.  i can't tell if they mean the 
'pre-ecapsulation boundary' (e.g. '-BEGIN FOO-') or if they mean the 
encapsulated headers; both as defined in RFC 1421 [0].


the newer patch set looks specifically at the pre-encapsulation boundary to 
switch behaviors. that works assuming that the signing tools all understand 
PEM. in the case of signify, it doesn't, so the driver code in git will have to 
translate to/from PEM.


i suggest that we switch to a standard format for all signatures that is 
similar to the commit message format with colon ':' separated fields followed 
by a payload.  the colon separated fields would specify the signing tool used 
to generate the signature and the tool specific data followed by the signature 
blob like so:


 signing-tool: gpg
 gpg-keyid: 0123456789ABCDEF
 
 -BEGIN PGP SIGNATURE-

 
 -END PGP SIGNATURE-

by adopting this format, git will be fully abstracted from the underlying 
signing tool and the user can specify multiple signing tools in their config 
and git will be able to map the signature to the tool when verifying (e.g. git 
log --show-signature).


a signify signature would look something like this:

 signing-tool: signify
 signify-public-key: 
 
 


i hope we adopt a more generic approach like this.


One of the downsides there is that if we eventually move to a generic
signing-tool config, we'd have to support two layers of historical
abstraction (the original "gpg.program" config, and the new
"gpg..*" config).


i like the idea of aliasing all of the old config variables to their equivilent 
and outputting a deprecation warning when we get plan on removing the aliases 
altogether in the future.



So _if_ we knew what it would take to support signify, we could
potentially adjust what's going into 2.19 in order to skip straight to
the more generic interface. But on the OTOH, it may not be worth
rushing, and there is already a vague plan of how the gpg..*
config would interact with a more generic config.


there's no rush, but i would prefer that the newer patch set get changed to use 
the more generic 'signingtool..*' instead of 'gpg..*'. if you all 
agree, i'll follow up with a patch to change that part of what is going into 
2.19.


then round two will be to experiment with a new, standard signature format that 
doesn't assume anything about the underlying signing tool.


//t??

[0] https://tools.ietf.org/html/rfc1421

abstracting commit signing/verify to support other signing schemes

[Tacitus Aedifex]

I'm looking at the existing commit signing and verification
integration and it is all GPG specific. I'm interested in refactoring
the code to have a generic signing/verifying interface so that "drivers"
for other signing tools can be created and other signing tools can be
used (e.g. OpenBSD signify).

The existing interface defined in gpg-interface.h is already fairly
generic. It looks like the only things that would need to be fixed
are the names of some members in the signature_check struct and the GPG
specific constants.

I propose to rename the gpg-interface.h file to signature-interface.h.
There are several different ways to do the "polymorphism" needed to have
a base signature_check struct with a tool-specific part for storing the
tool-specific data (e.g. gpg_output, gpg_status, result). I'm looking
for suggestions on the way this has been done in other places in the Git
code so I can do it the same way. My initial impulse it to have a union
of tool-specific structs inside of the signature_check struct.

The plan for changing the signing behavior is to change the code looking
for commit.gpgsign in sequencer.c to instead look for commit.signtool.
The string value will define which signing tool to use. The default will
be null which is the equivilent to gpgsign=false. To get GPG
signing the user would set it to "gpg". To maintain backwards
compatibility, the code will continue to check for commit.gpgsign and
translate that to commit.signtool=gpg and output a warning.

I also think that it makes sense to move the user.signingkey to be
gpg.signingkey since that only makes sense in the context of GPG.

The real trick here is how to handle signatures from different tools in
a given project. I think the answer is to store the value of
commit.signtool along with the signature blob associted with each signed
commit. That way the signature verification code can know which tool to
use to verify the signature. If a commit has a signture but no tool
selector, the default will be to assume GPG to preserve backwards
compatibility.

Any other thoughts and/or suggestions?

//t??