Re: [PATCH 00/18] Signed push

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry, but I cannot answer, as the only thing that I recall when
I hear "branch object" was that I heard the phrase used but
without much substance.

I do not think I saw a clear explanation on what it is, how it is
represented, how it is presented to the end user, how it is
propagated across repositories (if it is to be propagated),
how it is stored (if it is to be stored), how it is to be used,
etc. and such crucial details necessary to judge the merit
of thinking about introducing one. Perhaps it was explained
in the old thread, but I don't recall, so I cannot judge how
useful it would be to solve the problem the push certificate is
trying to solve.


On Tue, Aug 19, 2014 at 6:19 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
> On Tue, Aug 19, 2014 at 03:06:09PM -0700, Junio C Hamano wrote:
>> While signed tags and commits assert that the objects thusly signed
>> came from you, who signed these objects, there is not a good way to
>> assert that you wanted to have a particular object at the tip of a
>> particular branch.  My signing v2.0.1 tag only means I want to call
>> the version v2.0.1, and it does not mean I want to push it out to my
>> 'master' branch---it is likely that I only want it in 'maint', so
>> the signature on the object alone is insufficient.
>>
>> [...]
>>
>> This series introduces a cryptographic assurance for ref updates
>> done by "git push" by introducing a mechanism that allows you to
>> sign a "push certificate" (for the lack of better name) every time
>> you push.  Think of it as working on an axis orthogonal to the
>> traditional "signed tags".
>
> Sounds a lot like the "branch object" concept I suggest earlier, where
> each push would also push a commit to a branch object describing the
> updates to the branch, including signing of the updates to the branch
> (hey, it's just a signed commit), groups of commits pushed together / to
> be backed out together, rebase history, ...  (What about pushing
> orphaned commits?)
>
> Code-wise, would that be more or less generic?
>
> Nico
> --
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]