On Sun, 2016-10-30 at 01:16 -0700, Junio C Hamano wrote:
> Jon Loeliger writes:
>
> >
> > Is there an existing protocol provision, or an extension to
> > the protocol that would allow a distrustful client to say to
> > the server, "Really, you have Y2? Prove it."
>
> There is not, but I do not
On Sun, 2016-10-30 at 01:03 -0700, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >
> > On Fri, 2016-10-28 at 22:31 -0700, Junio C Hamano wrote:
> > >
> > > Not sending to the list, where mails from Gmail/phone is known to
> > > get
> > > rejected.
> >
> > [I guess I can go ahead and quote
Jon Loeliger writes:
> Is there an existing protocol provision, or an extension to
> the protocol that would allow a distrustful client to say to
> the server, "Really, you have Y2? Prove it."
There is not, but I do not think it would be an effective solution.
The issue is not the lack of prot
Matt McCutchen writes:
> On Fri, 2016-10-28 at 22:31 -0700, Junio C Hamano wrote:
>> Not sending to the list, where mails from Gmail/phone is known to get
>> rejected.
>
> [I guess I can go ahead and quote this to the list.]
>
>> No. I'm saying that the scenario you gave is bad and people should
Jeff King writes:
> ... It is not thinking about what secret things are hitting the
> master that you are pushing, no matter how they got there.
>
> I agree there is a potential workflow (that you have laid out) where
> such lying can cause an innocent-looking sequence of events to disclose
> the
On Sat, Oct 29, 2016 at 12:08:31PM -0400, Matt McCutchen wrote:
> Let's focus on the first scenario. There the user is just pulling and
> pushing a master branch. Are you saying that each time the user pulls,
> they need to look over all the commits they pulled before pushing them
> back? I thi
So, like, Junio C Hamano said:
> Matt McCutchen writes:
>
> > Then the server generates a commit X3 that lists Y2 as a parent, even
> > though it doesn't have Y2, and advances 'x' to X3. The victim fetches
> > 'x':
> >
> >victim server
> >
> > Y1---Y2---
On Sat, 2016-10-29 at 09:39 -0400, Jeff King wrote:
> I'm not sure I understand how connecting to a remote server to fetch is
> a big problem. The server may learn about the existence of particular
> sha1s in your repository, but cannot get their content.
>
> It's the subsequent push that is a pro
On Fri, 2016-10-28 at 22:31 -0700, Junio C Hamano wrote:
> Not sending to the list, where mails from Gmail/phone is known to get
> rejected.
[I guess I can go ahead and quote this to the list.]
> No. I'm saying that the scenario you gave is bad and people should be
> taught not to connect to untr
On Fri, Oct 28, 2016 at 11:33:49PM -0400, Matt McCutchen wrote:
> On Fri, 2016-10-28 at 18:11 -0700, Junio C Hamano wrote:
> > Ah, I see. My immediate reaction is that you can do worse things in
> > the reverse direction compared to this, but your scenario does sound
> > bad already.
>
> Are you
On Fri, 2016-10-28 at 18:11 -0700, Junio C Hamano wrote:
> Ah, I see. My immediate reaction is that you can do worse things in
> the reverse direction compared to this, but your scenario does sound
> bad already.
Are you saying that clients connecting to untrusted servers already
face worse risks
Matt McCutchen writes:
> Then the server generates a commit X3 that lists Y2 as a parent, even
> though it doesn't have Y2, and advances 'x' to X3. The victim fetches
> 'x':
>
>victim server
>
> Y1---Y2 (Y2)
> /
On Fri, 2016-10-28 at 15:00 -0700, Junio C Hamano wrote:
> Let me see if I understood your scenario correctly.
>
> Suppose we start from this history where 'O' are common, your victim
> has a 'Y' branch with two commits that are private to it, as well as
> a 'X' branch on which it has X1 that it p
Matt McCutchen writes:
> I was studying the fetch protocol and I realized that in a scenario in
> which a client regularly fetches a set of refs from a server and pushes
> them back without careful scrutiny, the server can steal the targets of
> unrelated refs from the client repository by fabric
I was studying the fetch protocol and I realized that in a scenario in
which a client regularly fetches a set of refs from a server and pushes
them back without careful scrutiny, the server can steal the targets of
unrelated refs from the client repository by fabricating its own refs
to the "have"
15 matches
Mail list logo
