ainst, and the commit data is non-trivial
to construct (requires mangling raw data anyway), maybe you could either
add another placeholder to get the data for signature verification, or
(alternatively or simultaneously) add a placeholder that prints both
data and signature in the OpenPGP message format (i.e. something you can
pass straight to 'gpg --verify').
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
On Fri, 2018-12-14 at 11:07 -0500, John Passaro wrote:
> On Thu, Dec 13, 2018 at 11:12 PM Michał Górny wrote:
> >
> > On Thu, 2018-12-13 at 16:22 -0500, John Passaro wrote:
> > > Currently, users who do not have GPG installed have no way to discern
> > > sig
e can do to reconcile the two requests
> (commit encoding vs output encoding) so seems reasonable to treat it
> as fatal.
>
> Updated patch coming as soon as I work out Peff's aforementioned "few
> hoops" to get properly encoded data -- and also how to test success
> and failure!
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
reject them at the moment.
Signed-off-by: Michał Górny
---
gpg-interface.c | 90 +++-
t/t7510-signed-commit.sh | 26
2 files changed, 87 insertions(+), 29 deletions(-)
Changes in v4:
* switched to using skip_prefix(),
* renamed the variable
On Sun, 2018-10-21 at 08:57 +0900, Junio C Hamano wrote:
> Michał Górny writes:
>
> > GnuPG supports creating signatures consisting of multiple signature
> > packets. If such a signature is verified, it outputs all the status
> > messages for each signature separately.
Dnia October 20, 2018 11:57:36 PM UTC, Junio C Hamano
napisał(a):
>Michał Górny writes:
>
>> GnuPG supports creating signatures consisting of multiple signature
>> packets. If such a signature is verified, it outputs all the status
>> messages for each signature s
On Mon, 2018-10-22 at 08:04 +, Michał Górny wrote:
> Dnia October 20, 2018 11:57:36 PM UTC, Junio C Hamano
> napisał(a):
> > Michał Górny writes:
> >
> > > GnuPG supports creating signatures consisting of multiple signature
> > > packets. If such a s
Obtain the primary key fingerprint off VALIDSIG status message,
and expose it via %GP format.
Signed-off-by: Michał Górny
---
Documentation/pretty-formats.txt | 2 ++
gpg-interface.c | 16 +++-
gpg-interface.h | 1 +
pretty.c
fingerprint rather than short/long identifier provided by %GK.
Signed-off-by: Michał Górny
---
Documentation/pretty-formats.txt | 1 +
gpg-interface.c | 14 +-
gpg-interface.h | 1 +
pretty.c | 4
t/t7510-signed-commit.sh
Replace the logic used to determine whether key and signer information
is present to use explicit flags in sigcheck_gpg_status[] array. This
is more future-proof, since it makes it possible to add additional
statuses without having to explicitly update the conditions.
Signed-off-by: Michał Górny
721698EC54E8713B6F51ECDDE430D
> EOF
> - git log -1 --format="%G?%n%GK%n%GS%n%GF" sixth-signed >actual &&
> + git log -1 --format="%G?%n%GK%n%GS%n%GF%n%GP" sixth-signed >actual &&
> test_cmp expect actual
> '
>
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
On Sat, 2018-11-03 at 16:17 +0100, Duy Nguyen wrote:
> On Sat, Oct 20, 2018 at 9:31 PM Michał Górny wrote:
> > +test_expect_success GPG 'detect fudged commit with double signature' '
> > + sed -e "/gpgsig/,/END PGP/d" forged1 >double-base &a
On Sat, 2018-11-03 at 16:36 +0100, Duy Nguyen wrote:
> On Sat, Nov 3, 2018 at 4:32 PM Michał Górny wrote:
> > > Perhaps my gpg is too old?
> > >
> > > $ gpg --version
> > > gpg (GnuPG) 2.1.15
> > > libgcrypt 1.7.3
> > > Copyright (C) 2016
On Sat, 2018-11-03 at 19:03 +0900, Junio C Hamano wrote:
> Michał Górny writes:
>
> > As for how involved... we'd just have to use a key that has split
> > signing subkey. Would it be fine to add the subkey to the existing key?
> > It would imply updating k
Test %GP in addition to %GF in custom format checks. With current
keyring, both have the same value.
Signed-off-by: Michał Górny
---
t/t7510-signed-commit.sh | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed
Add a dedicated signing subkey to the key identified as 'Eris
Discordia', and update tests appropriately. GnuPG will now sign commits
using the dedicated signing subkey, changing the value of %GK and %GF,
and effectively creating a test case for %GF!=%GP.
Signed-off-by: Michał Górny
On Sun, 2018-11-04 at 15:10 +, brian m. carlson wrote:
> On Sun, Nov 04, 2018 at 10:47:10AM +0100, Michał Górny wrote:
> > diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> > index e8377286d..86d3f93fa 100755
> > --- a/t/t7510-signed-commit.sh
>
On Mon, 2018-11-05 at 10:08 +0900, Junio C Hamano wrote:
> Michał Górny writes:
>
> > > It's my understanding that GnuPG will use the most recent subkey
> > > suitable for a particular purpose, and I think the test relies on that
> > > behavior. However,
On Fri, 2018-08-17 at 09:34 +0200, Michał Górny wrote:
> GnuPG supports creating signatures consisting of multiple signature
> packets. If such a signature is verified, it outputs all the status
> messages for each signature separately. However, git currently does not
> account for s
reject them at the moment.
Signed-off-by: Michał Górny
---
gpg-interface.c | 94 +++-
t/t7510-signed-commit.sh | 26 +++
2 files changed, 91 insertions(+), 29 deletions(-)
Changes in v3: reworked the whole loop to iterate over lines rather
than
On Mon, 2018-10-15 at 12:31 +0900, Junio C Hamano wrote:
> Michał Górny writes:
>
> > GnuPG supports creating signatures consisting of multiple signature
> > packets. If such a signature is verified, it outputs all the status
> > messages for each signature separately.
On Tue, 2018-08-14 at 22:35 -0700, Jonathan Nieder wrote:
> Hi,
>
> Michał Górny wrote:
>
> > I've been testing the git signature verification a bit and I've
> > discovered a troubling behavior when the commit object contains
> > multiple signatures.
&
On Wed, 2018-08-15 at 14:31 -0700, Jonathan Nieder wrote:
> Michał Górny wrote:
>
> > GnuPG supports creating signatures consisting of multiple signature
> > packets. If such a signature is verified, it outputs all the status
> > messages for each signature separately.
reject them at the moment.
Signed-off-by: Michał Górny
---
gpg-interface.c | 41
t/t7510-signed-commit.sh | 26 +
2 files changed, 59 insertions(+), 8 deletions(-)
Changes in v2:
* used generic 'flags' instead
o use,
even if there is no real need to account for that right now.
Signed-off-by: Michał Górny
---
gpg-interface.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/gpg-interface.c b/gpg-interface.c
index 35c25106a..9aedaf464 100644
--- a/gpg-interface.c
+
On Fri, 2018-08-17 at 05:28 -0400, Eric Sunshine wrote:
> On Fri, Aug 17, 2018 at 5:17 AM Michał Górny wrote:
> > Fix signature_check_clear() to free only values that are non-NULL. This
> > especially applies to 'key' and 'signer' members that can be NULL duri
s to be
the function used everywhere else in git and provided some MinGW
compatibility code.
Signed-off-by: Michał Górny
---
cache.h| 1 +
entry.c| 12 +++-
unpack-trees.c | 1 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
inde
W dniu śro, 25.04.2018 o godzinie 06∶58 +, użytkownik Robin H.
Johnson napisał:
> On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote:
> > --- a/entry.c
> > +++ b/entry.c
> > @@ -411,6 +411,7 @@ int checkout_entry(struct cache_entry *ce,
> > {
> &
e storing a lot of extra data. Rsync is not
very efficient at frequent updates, and has significant overhead
on every run. With all its disadvantages, git is still something that
lets our users fetch updates frequently with minimal network overhead.
So what did I do to deserve being called insane here? Is it because I
wanted to use the tools that work for us? Because I figured out that I
can improve our use case without really harming anyone in the process?
--
Best regards,
Michał Górny
ntire thing.)
>
>
> I just don't think the hook approach can completely solve the problem.
>
There's also the performance aspect. If we deal with checkouts that
include 1000+ files on a busy system (i.e. when mtimes really become
relevant), calling utime() instantly has a good chance of hitting warm
cache. On the other hand, post-checkout hook has a greater risk of
running cold cache, i.e. writing to all inodes twice.
--
Best regards,
Michał Górny
W dniu sob, 28.04.2018 o godzinie 16∶23 +0200, użytkownik Duy Nguyen
napisał:
> On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny wrote:
> > For the record, we're using this with ebuilds and respective cache files
> > (which are expensive to generate). We are using separate
31 matches
Mail list logo
