On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com wrote:
The alternatives for someone writing a parser are:
a. Store the original pkt-line framing.
Or obviously, a2. Frame in some other way, e.g. JSON array of strings
(complete straw man, not seriously proposing this).
--
To
Shawn Pearce spea...@spearce.org writes:
push cert format is like commit or tag format. You need those LFs. We
can't just go declare them optional because of the way pkt-line read
function is implemented in git-core.
As I said, I view each of the packets between push-cert and
push-cert-end
Shawn Pearce spea...@spearce.org writes:
push cert format is like commit or tag format. You need those LFs. We
can't just go declare them optional because of the way pkt-line read
function is implemented in git-core.
As I said, I view each of the packets between push-cert and
push-cert-end
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions is, I was
assuming pkt-line framing was the same thing as pkt-line header.
You seem to be saying the definition of pkt-line framing is header,
and optional trailing newline.
Yes. I thought
Dave Borowitz dborow...@google.com writes:
That existing implementations of the receivers treat an empty packet
(i.e. 0004)
or 0005\n ;)
Is that true? I think
len = pkt_line();
if (!len)
break; /* flush */
would give you len == 1 and would not confuse it
On Mon, Jul 6, 2015 at 2:06 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions is,
Dave Borowitz dborow...@google.com writes:
Unfortunately, optional LFs still make the stored certs for later
auditing and parsing a bit illegible. This is one way in which push
certs are fundamentally different from the rest of the wire protocol,
which is not intended to be persisted.
Hmm, I
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
The server can munge pkt-lines and reinsert LFs, but it _must_ have
some way of reconstructing the payload that the client signed in order
to verify the signature. If we just
On Mon, Jul 6, 2015 at 1:30 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I think I understand the confusion now. I think you and I are working
from different assumptions about the client behavior.
I agree that we now both understand where we come
On Mon, Jul 6, 2015 at 1:11 PM, Dave Borowitz dborow...@google.com wrote:
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
The server can munge pkt-lines and reinsert LFs, but it _must_ have
some way of reconstructing the
Dave Borowitz dborow...@google.com writes:
The server can munge pkt-lines and reinsert LFs, but it _must_ have
some way of reconstructing the payload that the client signed in order
to verify the signature. If we just naively insert LFs where missing,
we lose the ability to verify the
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions is, I was
assuming pkt-line framing was the same thing as pkt-line header.
You seem to be saying the definition of
Dave Borowitz dborow...@google.com writes:
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions is, I was
assuming pkt-line framing was the same thing as pkt-line header.
On Mon, Jul 6, 2015 at 12:28 PM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
push cert format is like commit or tag format. You need those LFs. We
can't just go declare them optional because of the way pkt-line read
function is implemented in git-core.
Dave Borowitz dborow...@google.com writes:
I think I understand the confusion now. I think you and I are working
from different assumptions about the client behavior.
I agree that we now both understand where we come from ;-)
And sorry for not being clear when I did the push-cert originally
Junio C Hamano gits...@pobox.com writes:
By clarifying that sender SHOULD terminate with LF, receiver MUST
NOT require it is the rule (and fixing the existing implementations
at places where they violate the MUST NOT part, which I think are
very small number of places), I think we can drop
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the implementation?
I'm not sure I understand your suggestion. Are you saying, you would
On Wed, Jul 1, 2015 at 1:49 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the implementation?
I'm not sure I understand your suggestion. Are you saying, you would
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com wrote:
b. Write a parser in some other clever way, e.g. parsing the entire
cert in reverse might work.
...as long as is illegal in nonce and pushee values, which it may
be but is not explicitly documented. I still have no
On Mon, Jul 6, 2015 at 11:27 AM, Dave Borowitz dborow...@google.com wrote:
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com wrote:
b. Write a parser in some other clever way, e.g. parsing the entire
cert in reverse might work.
...as long as is illegal in nonce and pushee
On Mon, Jul 6, 2015 at 10:46 AM, Dave Borowitz dborow...@google.com wrote:
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the
On Fri, Jul 3, 2015 at 11:07 AM, Jeff King p...@peff.net wrote:
I wondered briefly whether this impacted the keepalives we added to
`upload-pack` in 05e9515; those are implemented as 0-byte data packets,
which we send during the potentially long counting/delta-compression
phase before we send
Jeff King p...@peff.net writes:
On Wed, Jul 01, 2015 at 01:39:49PM -0700, Junio C Hamano wrote:
There is a slight complication on sending an empty line without any
termination, though ;-) The reader that calls packet_read() cannot
tell such a payload from a flush packet, I think.
*That*
On Fri, Jul 03, 2015 at 11:43:33AM -0700, Shawn Pearce wrote:
For (2), hopefully we can implement it in the same way, and rely on
empty sideband-0 packets. I haven't tested it in practice, though (I
have some very rough patches for (1) already).
sideband-0 is not going to work for JGit
On Fri, Jul 03, 2015 at 10:45:59AM -0700, Junio C Hamano wrote:
Usually flush packets are , and an empty data packet
is 0004. Or are you talking about some kind of flush inside the
pkt-data stream?
Neither. At the wire level there is a difference, but the callers
of most often used
On Wed, Jul 01, 2015 at 01:39:49PM -0700, Junio C Hamano wrote:
There is a slight complication on sending an empty line without any
termination, though ;-) The reader that calls packet_read() cannot
tell such a payload from a flush packet, I think.
*That* may be something we want to
Dave Borowitz dborow...@google.com writes:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index
Dave Borowitz dborow...@google.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the implementation?
I'm not sure I understand your suggestion. Are you saying, you would
prefer to make LFs optional in the push cert, for consistency with LFs
Junio C Hamano gits...@pobox.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix the implementation?
I think that something like this should be sufficient. As the
receiving end, we must not complain if there is no terminator.
...
And the change
Junio C Hamano gits...@pobox.com writes:
Dave Borowitz dborow...@google.com writes:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/technical/pack-protocol.txt
On Wed, Jul 1, 2015 at 1:00 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
31 matches
Mail list logo
