From: Stefan Beller <stefanbeller@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 00/18] Signed push
Date: Sat, 23 Aug 2014 00:51:29 +0200 [thread overview]
Message-ID: <53F7C971.7080100@gmail.com> (raw)
In-Reply-To: <xmqqa96wnoj1.fsf@gitster.dls.corp.google.com>
On 23.08.2014 00:32, Junio C Hamano wrote:
> Stefan Beller <stefanbeller@gmail.com> writes:
>
>> On 22.08.2014 22:33, Junio C Hamano wrote:
>>> Stefan Beller <stefanbeller@gmail.com> writes:
>>>
>>>> On 22.08.2014 22:03, Junio C Hamano wrote:
>>>>> Stefan Beller <stefanbeller@gmail.com> writes:
>>>>>
>>>>>> So there would be tags like:
>>>>>> master_2014_08_21
>>>>>> master_2014_08_22
>>>>>> ...
>>>>>> maint_2014_08_13
>>>>>> maint_2014_08_21
>>>>>> and so on. Whenever there is no tag at the tip of the branch, we'd
>>>>>> know there is something wrong.
>>>>>
>>>>> Who creates that tag?
>>>>>
>>>>
>>>>> My guess would be usability as tagging so many branches is cumbersome
>>>> for a maintainer?
>>>
>>> Did you answer my question? Who creates these tags?
>>>
>>
>> It would be up to the one who pushes, the user, or in our case you!
>> ...
>> As I wrote in the first email, I made up this workaround and wanted to
>> see, what's so bad about that workaround and how to overcome the
>> problems. And all I could find was a burden on the maintainer/user.
>
> "burden" is not an issue, as I'll be signing the push certificate
> anyway when I push. A signed tag or a signed commit and signed push
> certificate solves two completely separate and orthogonal issues.
>
> What happens if you break into GitHub or k.org and did
>
> $ git tag maint_2014_08_22 master_2014_08_22
Ok, I personally haven't used tags a lot.
I just tried to
git tag -s testbreaktag v2.1.0
git show testbreaktag
# However it would still read:
tag v2.1.0
Tagger: Junio C Hamano <gitster@pobox.com>
Date: Fri Aug 15 15:09:28 2014 -0700
So as I do not posess your private key I could not create signed tags
even if I were to break into github/k.org
>
> to create an extra tag out of the tag signed by me? If you want,
> you could also remove the original while at it.
Considering I'm in the hosting server,
could I delete the push cert as well?
Now that I deleted the push certificate,
I could pretend "Junio just forgot to sign the push cert today"
and we're back at the tag solution?
Ah wait! the subsequent push certs would not match,
I'd need to delete them as well.
> The goal is to let
> us validate without having to trust the hosting site, its management
> and its software, which is what creates the tag there, controls
> where the tag sits in refs/ hierarchy and how it is shown to the
> outside world.
>
Ok, I got the goal. :)
Thanks for your patience,
Stefan
next prev parent reply other threads:[~2014-08-22 22:51 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-19 22:06 [PATCH 00/18] Signed push Junio C Hamano
2014-08-19 22:06 ` [PATCH 01/18] receive-pack: do not overallocate command structure Junio C Hamano
2014-08-19 22:06 ` [PATCH 02/18] receive-pack: parse feature request a bit earlier Junio C Hamano
2014-08-19 22:31 ` Junio C Hamano
2014-08-19 22:06 ` [PATCH 03/18] receive-pack: do not reuse old_sha1[] to other things Junio C Hamano
2014-08-19 22:32 ` Junio C Hamano
2014-08-19 22:06 ` [PATCH 04/18] receive-pack: factor out queueing of command Junio C Hamano
2014-08-19 22:06 ` [PATCH 05/18] send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher Junio C Hamano
2014-08-19 22:06 ` [PATCH 06/18] send-pack: refactor decision to send update per ref Junio C Hamano
2014-08-19 22:06 ` [PATCH 07/18] send-pack: always send capabilities Junio C Hamano
2014-08-19 22:06 ` [PATCH 08/18] send-pack: factor out capability string generation Junio C Hamano
2014-08-19 22:06 ` [PATCH 09/18] send-pack: rename "new_refs" to "need_pack_data" Junio C Hamano
2014-08-19 22:06 ` [PATCH 10/18] send-pack: refactor inspecting and resetting status and sending commands Junio C Hamano
2014-08-19 22:06 ` [PATCH 11/18] send-pack: clarify that cmds_sent is a boolean Junio C Hamano
2014-08-19 22:06 ` [PATCH 12/18] gpg-interface: move parse_gpg_output() to where it should be Junio C Hamano
2014-08-19 22:06 ` [PATCH 13/18] gpg-interface: move parse_signature() " Junio C Hamano
2014-08-19 22:06 ` [PATCH 14/18] pack-protocol doc: typofix for PKT-LINE Junio C Hamano
2014-08-19 22:06 ` [PATCH 15/18] the beginning of the signed push Junio C Hamano
2014-08-20 2:48 ` brian m. carlson
2014-08-20 6:57 ` Bert Wesarg
2014-08-20 23:41 ` Junio C Hamano
2014-08-19 22:06 ` [PATCH 16/18] receive-pack: GPG-validate push certificates Junio C Hamano
2014-08-20 16:56 ` David Turner
2014-08-20 17:29 ` Junio C Hamano
2014-08-20 17:56 ` David Turner
2014-08-20 19:38 ` Junio C Hamano
2014-08-21 23:59 ` David Turner
2014-08-22 0:11 ` Junio C Hamano
2014-08-19 22:06 ` [PATCH 17/18] send-pack: send feature request on push-cert packet Junio C Hamano
2014-08-19 22:06 ` [PATCH 18/18] signed push: final protocol update Junio C Hamano
2014-08-21 19:28 ` Shawn Pearce
2014-08-21 23:40 ` Junio C Hamano
2014-08-22 3:06 ` Kyle J. McKay
2014-08-22 17:59 ` Junio C Hamano
2014-08-22 23:54 ` Shawn Pearce
2014-08-25 17:59 ` Junio C Hamano
2014-08-26 17:33 ` Shawn Pearce
2014-08-26 19:38 ` Junio C Hamano
2014-08-26 19:52 ` Junio C Hamano
2014-09-04 23:57 ` Junio C Hamano
2014-09-05 2:41 ` Shawn Pearce
2014-08-22 4:20 ` Junio C Hamano
2014-08-22 0:22 ` David Turner
2014-08-19 23:07 ` [PATCH 00/18] Signed push Duy Nguyen
2014-08-19 23:29 ` Junio C Hamano
2014-08-20 1:19 ` Nico Williams
2014-08-20 2:54 ` Junio C Hamano
2014-08-20 5:57 ` Junio C Hamano
2014-08-20 2:39 ` Junio C Hamano
2014-08-20 6:28 ` Nico Williams
2014-08-22 19:59 ` Stefan Beller
2014-08-22 20:03 ` Junio C Hamano
2014-08-22 20:22 ` Stefan Beller
2014-08-22 20:33 ` Junio C Hamano
2014-08-22 20:38 ` Stefan Beller
2014-08-22 22:32 ` Junio C Hamano
2014-08-22 22:51 ` Stefan Beller [this message]
2014-08-25 17:54 ` Junio C Hamano
2014-08-25 18:38 ` Jason Pyeron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53F7C971.7080100@gmail.com \
--to=stefanbeller@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).