Re: [PATCH 1/1] verify-tag/verify-commit should exit unsuccessfully when signature is not trusted

> > disable fetching keys from hkp servers. This way signature verification > > should fail. > > > > Thanks, > > -Santiago. > > This is not a deviation. GPG correctly recognizes difference between trusted, > untrusted and unknown levels. git on the other hand does not. Well it did > until > the

Re: [PATCH 1/1] verify-tag/verify-commit should exit unsuccessfully when signature is not trusted

On Wed, Aug 01, 2018 at 12:19:42AM +, brian m. carlson wrote: > On Tue, Jul 31, 2018 at 10:05:22PM +0200, Vojtech Myslivec wrote: > > Hello, > > > > me and my colleague are struggling with automation of verifying git > > repositories and we have encountered that git verify-commit and > >

Re: does a new repo actually *need* default template content?

On Fri, Jun 01, 2018 at 03:06:10AM -0400, Jeff King wrote: > On Mon, May 28, 2018 at 07:56:12PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > > > On Mon, May 28 2018, Robert P. J. Day wrote: > > > > > (apologies for more pedantic nitpickery, just little things i'm > > > running across in my

Re: GIT 2.3.1 - Code Execution Vulnerability

Hi, Christian. They are probably talking about one of these[1][2]. I don't have access to a solaris machine right now, so I don't know which is the latest version they ship, but they probably backported patches. Here we can't do much more about it, given that the packagers for your solaris

Re: upstreaming https://github.com/cgwalters/git-evtag ?

> > push for hash-agnosticity. I don't know if git-evtag is hash agnostic, > > but if it is not, then we have two transition plans to think about. > > I don't think there's even a question here: Git has to transition off > of SHA-1. > > In that context, Stefan's comment is a welcome one: once

Re: upstreaming https://github.com/cgwalters/git-evtag ?

> > See Documentation/technical/hash-function-transition.txt > > for how to do it. > > evtag took me a day or two to write initially and doesn't > impose any requirements on users except a small additional > bit of software. I agree that, in nature it shouldn't be difficult, but I also think

Re: upstreaming https://github.com/cgwalters/git-evtag ?

> Personally I'd dislike to include ev-tags as it might send a signal > of "papering over sha1 issues instead of fixing it". +1. I probably didn't convey it well, but this is what I was hoping for. I think git has enough building blocks to provide something akin to git evtags already. Thanks,

Re: upstreaming https://github.com/cgwalters/git-evtag ?

/ On Mon, Jan 08, 2018 at 03:42:33PM -0500, Colin Walters wrote: > > > On Mon, Jan 8, 2018, at 3:40 PM, Santiago Torres wrote: > > Hi, > > > > I personally like the idea of git-evtags, but I feel that they could be > > made so that push certificates (and being ha

Re: upstreaming https://github.com/cgwalters/git-evtag ?

Hi, I personally like the idea of git-evtags, but I feel that they could be made so that push certificates (and being hash-algorithm agnostic) should provide the same functionality with less code. To me, a git evtag is basically a signed tag + a data structure similar to a push certificate

Re: git status always modifies index?

Ah, my bad. I missed this patch... Good luck! -Santiago. signature.asc Description: PGP signature

Re: git status always modifies index?

On Wed, Nov 22, 2017 at 09:37:09AM -0600, Nathan Neulinger wrote: > What I'm meaning is - why does it need to write the index back out to disk? > > From looking at the code in builtin/commit.c it looks like it takes a lock > on the index, collects the status, and then unconditionally rewrites the

Re: git status always modifies index?

Hi Nathan. Do you mean git-status writing an index file? What would you suggest for git-status to compute which files have changed without modifying an index-file? Or are you suggesting git-status to fail if the index file doesn't belong to the user-id who invoked the command... Thanks,

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

> If it's a small range of gnupg versions which fail badly when the GNUPGHOME > dir is removed, then there's far less reason for git to do much more than > make an effort to kill the agent. > Yeah. FWIW, it may be reasonable to consider dropping the patch once we are certain distros don't ship

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Quick followup. The version that triggers this is at least 2.1.21[1]. I recall there was some wiggle room on minor versions before it. Thanks! -Santiago. [1] https://dev.gnupg.org/T3218 On Mon, Nov 13, 2017 at 06:02:02PM -0500, Santiago Torres wrote: > > > Were the ENOENT e

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

> Were the ENOENT errors you encountered in running the tests multiple times > easy to reproduce? If you had the right gpg2, it should be easy to repro with just re-running. > If so, I can certainly try to reproduce them and then > run the tests with --reload in place of --kill to gpgconf.

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

> Of course, beyond getting stderr to /dev/null, there is the fact that on > versions of gnupg < 2.1, gpgconf --kill is not available. I noticed this with > gnupg-2.0.14 on CentOS 6. It also occurs on CentOS 7, which provides > gnupg-2.0.22. > > I don't know if there's much value in trying to

Re: Unable to use --patch with git add

It'd be helpful to know: - What did you do? - What did you expect to happen? - What happened instead? I suspect you are using --patch with a new file, so you probably need to first add it with -N or so. This is just a shot in the dark though... Thanks, -Santiago. On Wed, Oct 11, 2017 at

Re: git ls-tree -d doesn't work if the specified path is the repository root?

> Is there some reason for this? This behavior seems like a bug to me: > it means that prior to calling ls-tree I need to check if the > referenced path happens to be the root, and if so, find some other > means (rev-parse?) of converting it to a treehash. Hmm, interesting. I see these four

Re: [RFC PATCH 0/2] Add named reference to latest push cert

Hello, everyone. Sorry for being late in this thread, I was making sure I didn't say anything outrageously wrong. > That's Stefan; I wouldn't have suggested any approach that uses the > blob whose sole purpose is to serve as a temporary storage area to > pass the information to the hook as part

Re: signing commits using gpg2

On Sat, Sep 02, 2017 at 05:11:50PM -0400, shawn wilson wrote: > tl;dr - how do I get git to use gpg2 to sign things? > > I'm using gpg2 (so no agent options are configured but an agent is > running) which is configured w/ a Nitrokey (Pro if it matters): > > % git commit -m "Initial." > >

Re: t5551 hangs ?

> No concurrency. > That's what I do: ./t5551-http-fetch-smart.sh Oh ok! I was just trying to weed out what could out of place. Just to make sure, your old compute is also running debian 8 latest? > > > - You probably want to see the version of apache this is running/etc. > > The one that

Re: t5551 hangs ?

Hello, Torsten. On Tue, Aug 22, 2017 at 07:10:59AM +0200, Torsten Bögershausen wrote: > Hej, > I found 2 threads about hanging t5551, one in 2016, and one question > from Junio somewhen in 2017. > I have it reproducable here: > - Debian 8, 64 bit > - SSD > - Half-modern processor ;-) I don't

Re: [PATCH] t: lib-gpg: flush gpg agent on startup

> With that "run it but ignore the outcome even if we failed to.", we > do not have to worry about any of that ;-) Oh right! thanks for the suggestion! Let me re-roll... Thanks, -Santiago. signature.asc Description: PGP signature

Re: [PATCH] t: lib-gpg: flush gpg agent on startup

opefully gpgconf goes nowhere by then). I was able to test this on debian oldstable/stable and arch. Cheers! -Santiago. [1] https://public-inbox.org/git/xmqqvampmnmv@gitster.mtv.corp.google.com/ On Thu, Jul 20, 2017 at 12:58:14PM -0400, santi...@nyu.edu wrote: > From: Santiago To

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

c124ad5a2462a460d4e3 Mon Sep 17 00:00:00 2001 From: Santiago Torres <santi...@nyu.edu> Date: Tue, 18 Jul 2017 13:16:11 -0400 Subject: [RFC/PATCH] t: lib-gpg: flush gpg agent on startup When running gpg-relevant tests, a gpg-daemon is spawned for each GNUPGHOME used. This daemon may stay

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

d > documented. I double checked the patch/solutions/causes just to be sure I'm not doing anything crazy. Here's a v2 of the patch that kills the agent upon cleanup rather than startup. Thanks! -Santiago. From 20491890b804d13f9edb0205c1cc21d080beffe2 Mon Sep 17 00:00:00 2001 From: Santiago

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

> > I'll dig into this. This sounds a way more reasonable approach. > > Thanks. Another thing that may help, if it turns out that we do > want to let agent run when it wants to I did some digging on the reason as to why this was happening. It turns out there is a bug on gnupg. As of gpg 2.1.21,

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

Hi, Junio. Thanks for replying. > I postponed it when I saw it the first time to see if anybody > comments on it, and then it turns out nobody was interested, and it > remained uninteresting to the list to this day. > True, that's what I was afraid of, but I wanted to give it some closure. >

Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

> Here are the topics that have been cooking. Hi, I sent (a patch almost a week ago) that would probably[1] be labeled as "uninteresting" (as per the notes from the maintainer), but I wanted to make sure it wasn't lost in the noise -- I see that theres a lot of active development lately. I

Re: [RFC PATCH] t: lib-gpg: flush agent sockets on startup

Hello all, I don't know if this is a desired feature, but I noticed that, one some versions of gpg, gpg tests are skipped when I run a test suite multiple times. Cheers! -Santiago. On Fri, Jul 07, 2017 at 06:01:59PM -0400, santi...@nyu.edu wrote: > From: Santiago Torres <santi...@n

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote: > Santiago Torres <santi...@nyu.edu> writes: > OK, so has everybody agreed what the next step would be? I believe it is, although I imagine getting a confirmation from Peff would be adequate. > Is the patch bel

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

On Wed, Mar 22, 2017 at 06:41:24PM -0400, Jeff King wrote: > > In that case, something like this would be closer to the desired > > behavior? > > Yes, though you can spell: > > cat >expect <<-\EOF > EOF > > as just: > > >expect Ah, that sounds like a better way to fix this with a

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

> I worked up the patch to do that (see below), but I got stumped trying > to write the commit message. Perhaps that is what the test intended, but > I don't think tag's --format understands "%G" codes at all. So you > cannot tell from the output if a tag was valid or not; you have to check > the

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

On Wed, Mar 22, 2017 at 03:04:32PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Wed, Mar 22, 2017 at 01:08:05PM -0700, Junio C Hamano wrote: > > > >> From: Jan Palus > >> > >> These all came as part of an earlier st/verify-tag topic that was >

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

On Wed, Mar 22, 2017 at 05:10:03PM -0400, Jeff King wrote: > On Wed, Mar 22, 2017 at 01:08:05PM -0700, Junio C Hamano wrote: > > > From: Jan Palus > > > > These all came as part of an earlier st/verify-tag topic that was > > merged to 2.12. > > > > Signed-off-by: Junio C

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > I have just read on ArsTechnica[1] that while Git repository could be > corrupted (though this would require attackers to spend great amount > of resources creating their own collision, while as said elsewhere > in this thread

SHAttered (the first practical SHA1 attack)

Hello all, I ran into this website presenting the "first practical attack on sha1"[1]. I don't recall seeing this on the ML, so I'm sharing this just in case. I know there are proposals to move out of sha1 already. I wonder if this affects the timeline for their adoption? Thanks, -Santiago. [1]

Re: idea: light-weight pull requests

Hello, pabs. IMHO, the notion of a PR/MR is more specific to Git repository management tools (e.g., GitHub, GitLab). They all have specific concepts/ways to manage the way how their hosted repositories behave --- and I believe this flexibility is one of the beauties in Git . I could see how this

Re: git clone problem

Hello, Jordi. Hmm, it should've cloned in the "whatever" directory. Can you post your git version/configs and maybe the output verbatim of the command when you run it? If you can reproduce in an empty dictionary that'd be better $ mkdir test && cd test $ git clone --recursive

Re: [PATCH v6 4/6] builtin/tag: add --format argument for tag -v

On Wed, Jan 18, 2017 at 10:44:03AM -0800, Junio C Hamano wrote: > Santiago Torres <santi...@nyu.edu> writes: > Was: Thanks! Would you want me to re-roll really quick? or would you rather apply this on your side? Thanks, -Santiago. > > Eric, I've noticed that this mess

Re: [PATCH v6 4/6] builtin/tag: add --format argument for tag -v

On Wed, Jan 18, 2017 at 10:25:59AM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > santi...@nyu.edu writes: > > > >> @@ -428,9 +443,12 @@ int cmd_tag(int argc, const char **argv, const char > >> *prefix) > >>if (filter.merge_commit) > >>

Re: [PATCH v5 5/7] builtin/tag: add --format argument for tag -v

> VERBOSE|QUIET _does_ have a meaning, which is "show the payload, but do > not print the signature buffer". Perhaps just renaming QUIET to > OMIT_STATUS or something would make it more clear. > Let me give this a go too. OMIT_STATUS does sound less confusing. Thanks, -Santiago. > -Peff

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

Yeah, this actually looks more cleaner. Let me give it a go. Thanks! -Santiago. On Tue, Jan 17, 2017 at 12:30:04PM -0500, Jeff King wrote: > On Tue, Jan 17, 2017 at 12:25:31PM -0500, Jeff King wrote: > > > Actually, looking at the callsites, I think they are fine to just call > >

Re: [PATCH v5 5/7] builtin/tag: add --format argument for tag -v

> > { > > - return verify_and_format_tag(sha1, name, NULL, GPG_VERIFY_VERBOSE); > > + int flags; > > + char *fmt_pretty = cb_data; > > + flags = GPG_VERIFY_VERBOSE; > > + > > + if (fmt_pretty) > > + flags = GPG_VERIFY_QUIET; > > + > > + return verify_and_format_tag(sha1,

Re: [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag

> > Hrm. Maybe I am missing something, but what does: > > > > verify_and_format_tag(sha1, name, fmt, flags); > > > > get you over: > > > > gpg_verify_tag(sha1, name, flags); > > pretty_print_ref(name, sha1, fmt); > > > > ? The latter seems much more flexible, and I do not see how the > >

Re: [PATCH 2/2] tag: send fully qualified refnames to verify_tag_and_format

On Wed, Oct 19, 2016 at 04:39:44PM -0400, Jeff King wrote: > The ref-filter code generally expects to see fully qualified > refs, so that things like "%(refname)" and "%(refname:short)" > work as expected. We can do so easily from git-tag, which > always works with refnames in the refs/tags

Re: [PATCH v4 2/7] ref-filter: add function to print single ref_array_item

On Wed, Oct 19, 2016 at 05:16:42AM -0400, Jeff King wrote: > On Wed, Oct 19, 2016 at 04:55:43AM -0400, Jeff King wrote: > > > > diff --git a/ref-filter.h b/ref-filter.h > > > index 14d435e..3d23090 100644 > > > --- a/ref-filter.h > > > +++ b/ref-filter.h > > > @@ -107,4 +107,7 @@ struct

Re: What's cooking in git.git (Oct 2016, #03; Tue, 11)

> * st/verify-tag (2016-10-10) 7 commits > - t/t7004-tag: Add --format specifier tests > - t/t7030-verify-tag: Add --format specifier tests > - builtin/tag: add --format argument for tag -v > - builtin/verify-tag: add --format to verify-tag > - tag: add format specifier to gpg_verify_tag > -

Re: [PATCH v4 0/7] Add --format to tag verification

Hi, I noticed there were no replies for this thread. I was curious if it got buried because I sent it on the Friday evening before a long weekend. I don't mean to pressure or anything. Thanks! -Santiago. On Fri, Oct 07, 2016 at 05:07:14PM -0400, santi...@nyu.edu wrote: > From: Santiago Tor

Re: [PATCH v3 0/5] Add --format to tag verification

Hi, Junio. > I however notice that there is no new tests to protect these two new > features from future breakages. Perhaps you want to add some in > [6/5]? I'll be working on this. I spent some time looking around for example tests for format. Are there any that I should pay special attention

Re: [PATCH v2 4/5] builtin/verify-tag: add --format to verify-tag

> > static const char * const verify_tag_usage[] = { > > - N_("git verify-tag [-v | --verbose] ..."), > > + N_("git verify-tag [-v | --verbose] [--format=] ..."), > > Does this require a corresponding documentation change? (also 5/5) > Yes, I'll work on this while I wait for more reviews.

Re: [PATCH 4/6] tag: add format specifier to gpg_verify_tag

On Thu, Sep 22, 2016 at 01:58:06PM -0700, Junio C Hamano wrote: > santi...@nyu.edu writes: > > > Calling functions for gpg_verify_tag() may desire to print relevant > > information about the header for further verification. Add an optional > > format argument to print any desired information

Re: [PATCH 5/6] builtin/verify-tag: Add --format to verify-tag

On Thu, Sep 22, 2016 at 02:16:21PM -0700, Junio C Hamano wrote: > santi...@nyu.edu writes: > > > From: Santiago Torres <santi...@nyu.edu> > > > > Callers of verify-tag may want to cross-check the tagname from refs/tags > > with the tagname from the tag

Re: [PATCH 6/6] builtin/tag: add --format argument for tag -v

> OK, you said something about for_each_ref() in an earlier commit, > but what you meant was this one, which takes each_tag_name_fn. Oh yeah, sorry for the confusion. > > The function for_each_tag_name(), the type each_tag_name_fn, and the > function of that type verify_tag(), are ALL

Re: Bug

Hi, Michael. It would be helpful to get more context on what triggered this bug. I'm not a 'core' dev, so there may be a better way to send this. In general, you want to state the following: 0) Information about your git installation, host system, etc. 1) Information about your repo (was it

Re: [OT] USENIX paper on Git

On Wed, Aug 03, 2016 at 01:58:54PM -0400, Jeff King wrote: > On Wed, Aug 03, 2016 at 01:45:00PM -0400, Santiago Torres wrote: > > > > - if there is a chain of signatures, the attacker must follow the > > > chain, but they can always withhold links

Re: [OT] USENIX paper on Git

On Wed, Aug 03, 2016 at 10:35:39AM -0700, Stefan Beller wrote: > On Wed, Aug 3, 2016 at 10:22 AM, Santiago Torres <santi...@nyu.edu> wrote: > > On Wed, Aug 03, 2016 at 10:14:21AM -0700, Stefan Beller wrote: > >> On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torres

Re: [OT] USENIX paper on Git

On Wed, Aug 03, 2016 at 10:35:54AM -0700, Junio C Hamano wrote: > Santiago Torres <santi...@nyu.edu> writes: > > >> Submodules actually track commits, not tags or branches. > >> > >> This is confusing for some users, e.g. the user intended to track a >

Re: [OT] USENIX paper on Git

Hello, > Here are my comments on the work itself. They're critical, but meant in > a friendly way. :) > Thanks! If anything, the community here has been incredibly helpful in helping me understand everything. > As far as the attack goes, I'm still not convinced this is all that > _interesting_

Re: [OT] USENIX paper on Git

On Wed, Aug 03, 2016 at 10:14:21AM -0700, Stefan Beller wrote: > On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torres <santi...@nyu.edu> wrote: > > > share things before they are published. Thankfully, this is OK in > >> > USENIX's book. Here's the link: > >>

Re: [OT] USENIX paper on Git

> share things before they are published. Thankfully, this is OK in > > USENIX's book. Here's the link: > > http://i2.cdn.turner.com/cnnnext/dam/assets/160730192650-14new-week-in-politics-super-169.jpg > > While I had a good laugh, I am wondering whether this is the correct link? Oh my god,

[OT] USENIX paper on Git

Hello everyone, I will be presenting a paper regarding the Git metadata issues that we discussed at the beginning on the year on USENIX '16. I'm writing To make everyone in this ML aware that this work exists and to bring everyone into the loop. I'm open for feedback and corrections. If anything

Re: Commits are no longer gpg-signed in 2.9.0 when "commit.gpgsign" is enabled

On Mon, Jul 11, 2016 at 06:27:57PM +0200, Nils Fenner wrote: > Hi Santiago, > > repeated your test here and actually found something interesting. When > committing via 'git gui', commits are not being gpg-signed, while firing > a 'git commit' shows the passphrase dialog and signs the commit

Re: Commits are no longer gpg-signed in 2.9.0 when "commit.gpgsign" is enabled

Jul 2016 10:40:41 AM EDT using RSA key ID 468F122CE8162295 gpg: Good signature from "Santiago Torres <torresari...@gmail.com>" [ultimate] gpg: aka "Santiago Torres-Arias <santi...@nyu.edu>" [ultimate] Author: Santiago Torres <torresar

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 03:35:07PM -0700, Junio C Hamano wrote: > On Tue, Jun 7, 2016 at 3:29 PM, Jeff King wrote: > > or even: > > > > git tag --show-tag-name foo/v1.0 > > > > when refs/remotes/foo/v1.0 exists? > > > > The rule right now is generally that "git tag" takes actual

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 06:13:25PM -0400, Jeff King wrote: > On Tue, Jun 07, 2016 at 03:11:47PM -0700, Junio C Hamano wrote: > > > On Tue, Jun 7, 2016 at 3:07 PM, Jeff King wrote: > > >> > > >> Puzzled. I didn't even use --format=%(tagname) in the above. > > > > > > No, but you

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 05:08:56PM -0400, Jeff King wrote: > On Tue, Jun 07, 2016 at 03:56:08PM -0400, santi...@nyu.edu wrote: > > > diff --git a/tag.c b/tag.c > > index d1dcd18..591b31e 100644 > > --- a/tag.c > > +++ b/tag.c > > @@ -55,6 +55,14 @@ int gpg_verify_tag(const unsigned char *sha1,

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 05:17:07PM -0400, Jeff King wrote: > That is much more flexible, as they could even do some more complicated > matching than a single string (though in practice, for security things, > I think simpler is better). > > I think this option is going to become a blueprint for

Re: [RFC/PATCH] verify-tag: add --check-name flag

On Tue, Jun 07, 2016 at 02:05:20PM -0700, Junio C Hamano wrote: > santi...@nyu.edu writes: > > > 1.- Using a tag ref as a check-out mechanism is pretty common by package > > managers and other tools. Verifying the tag signature provides > > authentication guarantees, but there is no

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

On Thu, Apr 21, 2016 at 03:20:39PM -0700, Junio C Hamano wrote: > * st/verify-tag (2016-04-19) 6 commits > - tag -v: verfy directly rather than exec-ing verify-tag > - verify-tag: move tag verification code to tag.c > - verify-tag: prepare verify_tag for libification > - verify-tag: update

Re: [PATCH] tag.c: remove extern keyword from function definition

On Wed, Apr 20, 2016 at 04:34:25PM +0100, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > > Hi Santiago, > > If you need to re-roll your 'st/verify-tag' branch, could you > please squash this into the relevant patch (commit c5213b40, > "verify-tag: move

Re: [PATCH v5 2/6] t7030-verify-tag: Adds validation for multiple tags

On Sun, Apr 17, 2016 at 02:19:00PM -0400, Eric Sunshine wrote: > On Sun, Apr 17, 2016 at 1:31 PM, Santiago Torres <santi...@nyu.edu> wrote: > >> + grep "^.GNUPG" expect.stderr && > >> > >> Hmm, is there a reason you didn'

Re: [PATCH v5 0/6] tag: move PGP verification code to tag.c

On Thu, Apr 07, 2016 at 12:19:37PM -0400, Eric Sunshine wrote: > On Wed, Apr 6, 2016 at 11:40 PM, Santiago Torres <santi...@nyu.edu> wrote: > >> > v5 (this): > >> > Added helpful feedback by Eric > >> > > >> > * Reordering of the patches,

Re: [PATCH v5 2/6] t7030-verify-tag: Adds validation for multiple tags

Sorry for the delay! I just realized I had missed the second comment. > + grep "^.GNUPG" expect.stderr && > > Hmm, is there a reason you didn't stick with the more strict regex > Peff suggested? > > ^.GNUPG:. > > (Genuine question: I'm not saying your choice is wrong, I'm just >

Re: [PATCH v5 0/6] tag: move PGP verification code to tag.c

> > v5 (this): > > Added helpful feedback by Eric > > > > * Reordering of the patches, to avoid temporal inclusion of a regression > > * Fix typos here and there. > > * Review commit messages, as some weren't representative of what the > > patches > >were doing anymore. > > * Updated

Re: [PATCH v5 4/6] builtin/verify-tag: replace name argument with sha1

> > type = sha1_object_info(sha1, NULL); > > if (type != OBJ_TAG) > > return error("%s: cannot verify a non-tag object of type %s.", > > - name, typename(type)); > > + hex_sha1, typename(type)); > > So, if I said > > $

Re: [PATCH v5 0/6] tag: move PGP verification code to tag.c

Thanks for the reviews! I'll update the commit messages. It appears that I there's a lot to learn on my side on the art of writing good commit messages. -Santiago. On Wed, Apr 06, 2016 at 09:39:39AM -0700, Junio C Hamano wrote: > The first three looked almost good. I do not fully agree with

Re: [PATCH v5 0/6] tag: move PGP verification code to tag.c

Sorry, forgot to add, this is a follow on to [1]. Thanks, -Santiago. [1]: http://git.661346.n2.nabble.com/PATCH-v4-0-6-tag-move-PGP-verification-code-to-tag-c-td7652451.html On Tue, Apr 05, 2016 at 12:07:23PM -0400, santi...@nyu.edu wrote: > From: Santiago Torres <santi...@nyu.edu>

Re: [PATCH v4 6/6] tag.c: Change gpg_verify_tag argument to sha1

iption leaves me fairly clueless about why this change is > being made since justification seems to be lacking. More about this > below... > > > Signed-off-by: Santiago Torres <santi...@nyu.edu> > > --- > > diff --git a/builtin/tag.c b/builtin/tag.c > > @@ -104,7

Re: [PATCH v4 2/6] t/t7030-verify-tag.sh: Adds validation for multiple tags

> > The bulk of this description is merely repeating what the patch itself > already says, thus is redundant. The entire commit message could > probably be collapsed to: > > t7030: test verify-tag with multiple tags > > git-verify-tag accepts multiple tags as arguments, however, >

Re: [PATCH v4 5/6] tag: use pgp_verify_function in tag -v call

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

Re: [PATCH v3 4/4] tag: use pgp_verify_function in tag -v call

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

Re: [PATCH v3 4/4] tag: use pgp_verify_function in tag -v call

> > 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,

Re: [PATCH v3 2/4] t/t7030-verify-tag.sh: Adds validation for multiple tags

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:

Re: [PATCH v3 3/4] builtin/verify-tag: move verification code to tag.c

c > > code. We rename the verify_tag() function to pgp_verify_tag() to avoid > > conflicts with the mktag.c function. > > > > Signed-off-by: Santiago Torres <santi...@nyu.edu> > > --- > > - len = parse_signature(buf, size); > > - > > -

Re: [PATCH v3 1/4] builtin/verify-tag.c: Ignore SIGPIPE on gpg-interface

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 <santi...@nyu.edu> > > > > The verify_signed_buffer comand might cause a SIGPIPE signal when the > > gpg child process ter

Re: [PATCH v3 4/4] tag: use pgp_verify_function in tag -v call

> > 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,

Re: [PATCH] tag.c: move PGP verification code from plumbing

> > - 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); > > + > > +

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

> > 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

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

> 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".

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

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 <torresari...@gmail.com> > > The verify tag function is just a thin wrapper around the verify-tag > command.

Re: [PATCH/RFC] builtin/tag: Changes argument format for verify

-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 itself, but > > > the

Re: [PATCH/RFC] builtin/tag: Changes argument format for verify

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

Re: [RFC] tag-ref and tag object binding

On Tue, Jan 26, 2016 at 01:13:16PM -0800, Junio C Hamano wrote: > Jeff King <p...@peff.net> 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 > >

Re: [RFC] tag-ref and tag object binding

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"

Re: [RFC] tag-ref and tag object binding

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 identified so

Re: [RFC] tag-ref and tag object binding

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 whe

[RFC] tag-ref and tag object binding

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

Re: [RFC] Malicously tampering git metadata?

On Thu, Jan 14, 2016 at 09:21:28AM -0800, Stefan Beller wrote: > On Thu, Jan 14, 2016 at 9:16 AM, Santiago Torres <santi...@nyu.edu> wrote: > > Hello Stefan, thanks for your feedback again. > > > >> This is what push certs ought to solve already? > > >

Re: GIT Question

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

  1   2   >