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