On Mon, Apr 04, 2016 at 09:39:29PM -0400, Eric Sunshine wrote:
> On Mon, Apr 4, 2016 at 6:22 PM, wrote:
> > Instead of running the verify-tag plumbing command, we use the
> > pgp_verify_tag(). This avoids the usage of an extra fork call. To do
> > this, we extend the number of parameters that tag
On Mon, Apr 04, 2016 at 09:38:54AM -0400, Jeff King wrote:
> On Mon, Apr 04, 2016 at 12:12:04AM -0400, Santiago Torres wrote:
>
> > > As a side note, it might actually be an improvement for pgp_verify_tag
> > > to take a sha1 (so that git-tag is sure that it is verifyi
> > diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c
> > index f776778..8abc357 100644
> > --- a/builtin/verify-tag.c
> > +++ b/builtin/verify-tag.c
> > @@ -30,6 +30,8 @@ int cmd_verify_tag(int argc, const char **argv, const
> > char *prefix)
> > {
> > int i = 1, verbose = 0, had_erro
On Sun, Apr 03, 2016 at 09:07:25AM -0400, Jeff King wrote:
> On Sun, Apr 03, 2016 at 03:59:46AM -0400, Eric Sunshine wrote:
>
> > On Sun, Apr 3, 2016 at 12:40 AM, Jeff King wrote:
> > > In fact, I suspect you could replace the "GOODSIG" check as well by
> > > doing something like:
> > >
> > > #
ify_tag() function to pgp_verify_tag() to avoid
> > conflicts with the mktag.c function.
> >
> > Signed-off-by: Santiago Torres
> > ---
> > - len = parse_signature(buf, size);
> > -
> > - if (size == len) {
> > - if (flags &
On Sun, Apr 03, 2016 at 08:50:27AM +0200, Johannes Sixt wrote:
> Am 03.04.2016 um 01:16 schrieb santi...@nyu.edu:
> > From: Santiago Torres
> >
> > The verify_signed_buffer comand might cause a SIGPIPE signal when the
> > gpg child process terminates early (due to a
> > if (cmdmode == 'v')
> > - return for_each_tag_name(argv, verify_tag);
> > + return for_each_tag_name(argv, pgp_verify_tag,
> > + GPG_VERIFY_VERBOSE);
>
> but I think that is coupling too closely. What happens later when the
> public, multi-file
> > - signal(SIGPIPE, SIG_IGN);
> > while (i < argc)
> > - if (verify_tag(argv[i++], flags))
> > + name = argv[i++];
> > + if (get_sha1(name, sha1))
> > + return error("tag '%s' not found.", name);
> > +
> > +
> > This is my first stab at this, in the dumbest/simplest way imaginable. I
> > don't like that there is no code reuse (the run_gpg_verify function is
> > repeated here and in the plumbing command). I would appreciate pointers
> > on what would be the best way to avoid this.
>
> It looks to me li
> I know you are just copying this from the one in builtin/verify-tag.c,
> but I find the use of "size" and "len" for two different purposes
> confusing. Those words are synonyms, so how do the variables differ?
>
> Perhaps "payload_size", or "signature_offset" would be a better term for
> "len".
don't see any explicit SIGPIPE trickery here. Any pointers?
Thanks!
-Santiago.
On Thu, Mar 24, 2016 at 05:39:20PM -0400, santi...@nyu.edu wrote:
> From: Santiago Torres
>
> The verify tag function is just a thin wrapper around the verify-tag
> command. We can avoid one fork
eb 27, 2016 at 01:31:33PM -0500, Jeff King wrote:
> On Sat, Feb 27, 2016 at 12:45:24PM -0500, Santiago Torres wrote:
>
> > > A much more interesting change in this area, I think, would be to skip
> > > verify-tag entirely. Once upon a time it had a lot of logic itsel
Hello Jeff, thanks for going through the patch.
> > diff --git a/builtin/tag.c b/builtin/tag.c
> > index 1705c94..5de1161 100644
> > --- a/builtin/tag.c
> > +++ b/builtin/tag.c
> > @@ -105,8 +105,7 @@ static int verify_tag(const char *name, const char *ref,
> > const u
On Tue, Jan 26, 2016 at 01:13:16PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
> >
> >> > If you cannot trust those with write access to a repo that you are
> >> > pulling and
Hello, sorry for being MIA yesterday among all this movement...
On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
> Jeff King venit, vidit, dixit 27.01.2016 08:33:
> > On Wed, Jan 27, 2016 at 08:23:02AM +0100, Michael J Gruber wrote:
> >
> >>> Tag objects already have a "tag" head
On Tue, Jan 26, 2016 at 03:26:51PM -0500, Jeff King wrote:
> On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
>
> > > If you cannot trust those with write access to a repo that you are
> > > pulling and installing from you might want to re-check where
On Tue, Jan 26, 2016 at 10:35:34AM +0100, Michael J Gruber wrote:
> Santiago Torres venit, vidit, dixit 25.01.2016 22:22:
> > Hello everyone.
> >
> > I've done some further research on the security properties of git
> > metadata and I think I've ide
Hello everyone.
I've done some further research on the security properties of git
metadata and I think I've identified something that might be worth
discussing. In this case, The issue is related to the refs that point to
git tag objects. Specifically, the "loose" nature of tag refs might
possibly
On Thu, Jan 14, 2016 at 09:21:28AM -0800, Stefan Beller wrote:
> On Thu, Jan 14, 2016 at 9:16 AM, Santiago Torres wrote:
> > Hello Stefan, thanks for your feedback again.
> >
> >> This is what push certs ought to solve already?
> >
> > Yes, they aim to solve
On Fri, Jan 22, 2016 at 05:22:16PM +, Draggs, Tori wrote:
> I apologize, however my intent in reaching out was not to seek free of cost
> help desk services.
Don't worry, just use reply to all so everyone can see and chime in if
they can help.
> > Hi. I am able to pull up Visual Studio Code
> I assume you are assuming here that the "push to upstream" doesn't
> involve some kind of human verification? If someone tried pushing
> something like this to Linus, he would be checking the git diff stats
> and git commit structure for things that might look like "developer
> negligence". He'
Hi Stefan, thanks for the insight.
> This is what push certificates ought to solve.
> The server records all pushes and its signed certificates of pushes
> and by the difference of the
> refs (either in packed refs or as a loose ref) to the push certificate
> this tampering of
> the server can be
Hello everyone,
I'm Santiago, a PhD student at NYU doing research about secure software
development pipelines. We've been studying different aspects of Git
lately, (as it is an integral part of many projects) and we believe
we've found a vulnerabilty in the way Git structures/signs metadata.
An
101 - 123 of 123 matches
Mail list logo
