On Fri, Oct 18, 2019 at 12:03:43PM -0400, Konstantin Ryabitsev wrote:
> On Fri, Oct 18, 2019 at 11:54:09AM -0400, Santiago Torres Arias wrote:
> > > Seeing how large this signature is, I have to admit that I am partial to
> > > Konstantin's suggestion of using minisign.
> Seeing how large this signature is, I have to admit that I am partial to
> Konstantin's suggestion of using minisign. This seems like something
> that could be added to git as an alternative to gpg without too much
> trouble, I think.
>
>
I wonder how big the pgp payload would be with ed25519
On Fri, Oct 18, 2019 at 08:34:17AM +0200, Nicolas Belouin wrote:
> On 10/18/19 4:52 AM, Willy Tarreau wrote:
> > On Thu, Oct 17, 2019 at 09:54:47PM -0400, Konstantin Ryabitsev wrote:
> >> On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:
> It could only possibly work if nobody ever add
Hi Willy, Vegard.
On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:
> Hi Vegard,
>
> On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:
> > (cross-posted to git, LKML, and the kernel workflows mailing lists.)
> >
> > Hi all,
> >
> > I've been following Konstantin Ryabit
On Sun, Aug 18, 2019 at 08:14:15AM +0530, Dhaval Patel wrote:
> How to reproduce
>
> [snip]
> Suggested feature -
>
> when I press tab, git diff should autocomplete just like git add.
I think this is somewhat harder of a usecase, as git add generally takes
paths and diff can compare revisions *a
Hi,
I'm not completely sure if this is the best way to achieve this, but I
you could instruct a merge driver to mark all new files as unset.
Cheers!
-Santiago.
On Thu, Jul 25, 2019 at 04:42:48PM +0300, Ilya Kantor wrote:
> Hi,
>
> We're using Git to manage translations of an open-source book, a
> Now this one's VERBOSE handling is a bit interesting. Previously we'd
> set VERBOSE even if we were going to show a format. And then later we
> just set the OMIT_STATUS bit, leaving VERBOSE in place:
>
> > - flags |= GPG_VERIFY_OMIT_STATUS;
>
> That _usually_ didn't matter because wi
> So we're going to stop setting OMIT_STATUS ever, which makes sense.
>
> It took me a minute to figure out here that the behavior for VERBOSE is
> not changed, because we _overwrite_ flags, rather than just setting a
> single bit. But that's definitely the right thing to do when there's a
> forma
On Mon, Apr 22, 2019 at 11:07:01PM +, brian m. carlson wrote:
> On Mon, Apr 22, 2019 at 12:02:11PM -0400, Jeff King wrote:
> > On Mon, Apr 22, 2019 at 11:46:56AM -0400, Santiago Torres Arias wrote:
> >
> > > I think that would be great, as we could make it simpler for
On Mon, Apr 22, 2019 at 11:28:42AM -0400, Jeff King wrote:
> On Mon, Apr 22, 2019 at 10:52:38AM -0400, Santiago Torres Arias wrote:
> > Hi,
> >
> > This is the second what's cooking that's gone by without mention of the
> > RFC patch regarding verify_tag[1].
> However, I don't think this patch is quite right, as it causes us to
> dump the whole tag contents to stdout, as well. E.g.:
>
> [before]
> $ git tag -v --format='foo %(tag)' v2.21.0
> foo v2.21.0
>
> [after]
> $ git tag -v --format='foo %(tag)' v2.21.0
> object 8104ec994ea3849a968b
On Mon, Apr 22, 2019 at 03:10:30PM +0900, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branche
On Fri, Apr 12, 2019 at 04:14:32PM -0400, santi...@nyu.edu wrote:
> From: Santiago Torres
>
> On the git tag -v code, there is a guard to suppress gpg output if a
> pretty format is provided. The rationale for this is that the gpg output
> *and* the pretty formats together may con
Hi,
This has been known for a whlie now[1]. The consensus back then was that
this information was up to higher-level integrators to verify using
means like e.g., --format.
This is implemented in for example pacman/devtools here[2]. We published
a paper with a more thorough security model here[3],
That was proably my bad.
I still find it somewhat astounding that it compiles with a modern
toolchain after 15+ years. Many projects fail to do so (it's an
understandably high bar to have).
I'm glad this is possible and you were able to do so (maybe you want to
share your experiences about it so
lun, 04/03/2019 alle 15.10 -0500, Santiago Torres ha scritto:
> > This commit is about 14 years old:
> >
> > Date: Thu Apr 7 15:13:13 2005 -0700
> >
> > Unless you have a toolchain from around that time, I'd be very
> > surprised
> > i
This commit is about 14 years old:
Date: Thu Apr 7 15:13:13 2005 -0700
Unless you have a toolchain from around that time, I'd be very surprised
if things build. Notably, there you're having an issue with the symbols
that lssl is exposing (I suspect you're not even using the openssl 1.0.0
se
gt; > rebuild by clicking the 'hammer' icon, the message in the console
> > window says:
> > 20:04:07 Incremental Build of configuration Default for project
> > git
> > make all
> > SUBDIR git-gui
> > SUBDIR gitk-git
> > SUBDIR templat
It'd be difficult to debug without more context:
Do you mind sharing your build log and more informationa about your
setup? (e.g., what OS are you running, what packages are installed, how
did you get the git sources, etc.)
Thanks,
-Santiago.
On Sun, Feb 10, 2019 at 10:56:54PM +0100, Fabio Aiuto
Hi, Ralph.
This feels like an issue of how homebrew relays information rather than
with git:
santiago at ~ ✔ git clone nonexistent
fatal: repository 'nonexistent' does not exist
santiago at ~ ✗ git clone https://nonexistent.git
Cloning into 'nonexistent'...
fatal: unable to ac
> > 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
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
> > verif
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 trav
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 versi
> > 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 we'
> > 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 that
> 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,
-Sa
rverma.com/
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 certificate
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 embedd
Ah, my bad. I missed this patch...
Good luck!
-Santiago.
signature.asc
Description: PGP signature
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
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,
-Santiago
> 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 th
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
> 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. If
> 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
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 11:16:3
> 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 beh
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
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."
>
>
> 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 comes
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 thi
> 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
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 Torres
7a3a5c124ad5a2462a460d4e3 Mon Sep 17 00:00:00 2001
From: Santiago Torres
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 running after the tes
is clearly understood and
> 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
> > 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,
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.
>
> 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 che
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
>
> Wh
On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote:
> Santiago Torres 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 below a good first step (I stil
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 smaller
> 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 e
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
> >> merged to 2.12.
> >>
> >> Signed-o
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 Hamano
> > ---
> >
>
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 allege
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]
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 c
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 https://github.co
On Wed, Jan 18, 2017 at 10:44:03AM -0800, Junio C Hamano wrote:
> Santiago Torres 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 message
>
>
> h
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)
> >>die(_("--merged and --no-merged
> 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
signat
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
> > pretty_print_r
> > {
> > - 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, ref,
> > 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
> >
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 namespa
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 ref_sortin
> * 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
> -
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: Santiag
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 t
> > 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.
Thank
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 after
On Thu, Sep 22, 2016 at 02:16:21PM -0700, Junio C Hamano wrote:
> santi...@nyu.edu writes:
>
> > From: Santiago Torres
> >
> > Callers of verify-tag may want to cross-check the tagname from refs/tags
> > with the tagname from the tag object header upon GPG verifica
> 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 file-scope
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 GitHu
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 fr
On Wed, Aug 03, 2016 at 10:35:39AM -0700, Stefan Beller wrote:
> On Wed, Aug 3, 2016 at 10:22 AM, Santiago Torres 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 wrote:
> >> > > share
On Wed, Aug 03, 2016 at 10:35:54AM -0700, Junio C Hamano wrote:
> Santiago Torres writes:
>
> >> Submodules actually track commits, not tags or branches.
> >>
> >> This is confusing for some users, e.g. the user intended to track a
> >> library at v
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_
On Wed, Aug 03, 2016 at 10:14:21AM -0700, Stefan Beller wrote:
> On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torres wrote:
> > > share things before they are published. Thankfully, this is OK in
> >> > USENIX's book. Here's the link:
> >> > http://i2.
> 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, sorr
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
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 correc
gnature made Mon 11 Jul 2016 10:40:41 AM EDT using RSA key ID
468F122CE8162295
gpg: Good signature from "Santiago Torres "
[ultimate]
gpg: aka "Santiago Torres-Arias "
[ultimate]
Author: Santiago Torres
Date: Mon Jul 11 10:40:32 2016 -0400
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 tag names.
>
>
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 used --show-tagna
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, con
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 o
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 feedba
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 vari
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 tag verification code to tag.
On Sun, Apr 17, 2016 at 02:19:00PM -0400, Eric Sunshine wrote:
> On Sun, Apr 17, 2016 at 1:31 PM, Santiago Torres wrote:
> >> + grep "^.GNUPG" expect.stderr &&
> >>
> >> Hmm, is there a reason you didn't stick with the more st
On Thu, Apr 07, 2016 at 12:19:37PM -0400, Eric Sunshine wrote:
> On Wed, Apr 6, 2016 at 11:40 PM, Santiago Torres wrote:
> >> > v5 (this):
> >> > Added helpful feedback by Eric
> >> >
> >> > * Reordering of the patches, to avoid temporal inc
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
> inter
> > 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 t7030
> > 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
>
> $ gi
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 wha
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
>
> v5 (this):
airly clueless about why this change is
> being made since justification seems to be lacking. More about this
> below...
>
> > Signed-off-by: Santiago Torres
> > ---
> > diff --git a/builtin/tag.c b/builtin/tag.c
> > @@ -104,7 +104,7 @@ static int delete_tag(cons
>
> 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,
> ex
1 - 100 of 123 matches
Mail list logo
