From: Junio C Hamano <gitster@pobox.com>
To: Ivan Frade <ifrade@google.com>
Cc: Ivan Frade via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH v4 1/2] fetch-pack: redact packfile urls in traces
Date: Thu, 28 Oct 2021 15:46:39 -0700 [thread overview]
Message-ID: <xmqqa6ispy28.fsf@gitster.g> (raw)
In-Reply-To: <CANQMx9WFKJAGF+7zti8+-b2je9sFuNxwOx-LCPtEoGCea54Mdw@mail.gmail.com> (Ivan Frade's message of "Thu, 28 Oct 2021 15:15:05 -0700")
Ivan Frade <ifrade@google.com> writes:
>> Hmph, the format we expect is "<hash> <uri>"; don't we need to
>> validate the leading <hash> followed by SP?
>
> I was trying to find a uri in a packet in general, not counting on the
> packfile-uri line format. That is probably an overgeneralization.
Ah, I see. This is merely a tracing, so we might benefit from a
generalized version of redactor, and from that point of view, the
use of strstr and stopping at the whitespace do make sort-of sense
to me, but then we lack any attempt to redact more than one instance
of URL in a packet, so the generalization may have quite a limited
usefulness.
> Next patch version follows these suggestions to look for a packfile-uri line.
Yeah, I think that is a good way to go, at least for now. When we
want a more general one, we can revisit it, but not now.
>> > - packet_trace(buffer, len, 0);
>> > + if (options & PACKET_READ_REDACT_URL_PATH &&
>> > + (url_path_start = find_url_path(buffer, &url_path_len))) {
>> > + const char *redacted = "<redacted>";
>> > + struct strbuf tracebuf = STRBUF_INIT;
>> > + strbuf_insert(&tracebuf, 0, buffer, len);
>> > + strbuf_splice(&tracebuf, url_path_start - buffer,
>> > + url_path_len, redacted, strlen(redacted));
>> > + packet_trace(tracebuf.buf, tracebuf.len, 0);
>> > + strbuf_release(&tracebuf);
>>
>> I briefly wondered if the repeated allocation (and more
>> fundamentally, preparing the redacted copy of packet whether we are
>> actually tracing the packet in the first place) is blindly wasting
>> the resources too much, but this only happens in the protocol header
>> part, so it might be OK.
>
> We only allocate and redact if it looks like a packfile-uri line, so
> it shouldn't happen too frequently.
I was mostly wondering about the cost of determining "if it looks
like?". But we do this only for the protocol header part, so we
won't have thousands of attempts to match, I guess. Oh, or if we
also do this for the ref advertisement packets, then we might have
quite a many. Hmph.
> I move the set/unset of the redacting flag to the FETCH_GET_PACK
> around the "packfile-uris" section.
> There is no need to check every incoming packet for a packfile-uri
> line, we know when they should come.
Yeah, that is quite a wise design decision, I would think.
Thanks.
next prev parent reply other threads:[~2021-10-28 22:46 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-08 16:03 [PATCH 0/2] fetch-pack: redact packfile urls in traces Ivan Frade via GitGitGadget
2021-10-08 16:03 ` [PATCH 1/2] " Ivan Frade via GitGitGadget
2021-10-08 19:36 ` Ævar Arnfjörð Bjarmason
2021-10-08 23:15 ` Ivan Frade
2021-10-08 16:03 ` [PATCH 2/2] Documentation: packfile-uri hash can be longer than 40 hex chars Ivan Frade via GitGitGadget
2021-10-08 19:43 ` Ævar Arnfjörð Bjarmason
2021-10-09 2:20 ` [PATCH v2] fetch-pack: redact packfile urls in traces Ivan Frade via GitGitGadget
2021-10-11 20:39 ` Junio C Hamano
2021-10-26 19:32 ` Ivan Frade
2021-10-19 22:57 ` [PATCH v3] " Ivan Frade via GitGitGadget
2021-10-20 11:41 ` Ævar Arnfjörð Bjarmason
2021-10-26 22:49 ` [PATCH v4 0/2] " Ivan Frade via GitGitGadget
2021-10-26 22:49 ` [PATCH v4 1/2] " Ivan Frade via GitGitGadget
2021-10-28 1:01 ` Junio C Hamano
2021-10-28 22:15 ` Ivan Frade
2021-10-28 22:46 ` Junio C Hamano [this message]
2021-10-26 22:49 ` [PATCH v4 2/2] http-fetch: redact url on die() message Ivan Frade via GitGitGadget
2021-10-28 16:39 ` Ævar Arnfjörð Bjarmason
2021-10-28 17:25 ` Eric Sunshine
2021-10-28 22:44 ` Ivan Frade
2021-10-28 22:41 ` Ivan Frade
2021-10-29 23:18 ` Junio C Hamano
2021-11-09 1:54 ` Ævar Arnfjörð Bjarmason
2021-10-28 22:51 ` [PATCH v5 0/2] fetch-pack: redact packfile urls in traces Ivan Frade via GitGitGadget
2021-10-28 22:51 ` [PATCH v5 1/2] " Ivan Frade via GitGitGadget
2021-10-28 23:21 ` Junio C Hamano
2021-10-29 18:42 ` Ivan Frade
2021-10-29 19:59 ` Junio C Hamano
2021-11-08 22:43 ` Jonathan Tan
2021-10-28 22:51 ` [PATCH v5 2/2] http-fetch: redact url on die() message Ivan Frade via GitGitGadget
2021-10-29 18:42 ` [PATCH v6 0/2] fetch-pack: redact packfile urls in traces Ivan Frade via GitGitGadget
2021-10-29 18:42 ` [PATCH v6 1/2] " Ivan Frade via GitGitGadget
2021-11-08 23:01 ` Jonathan Tan
2021-11-09 1:36 ` Ævar Arnfjörð Bjarmason
2021-11-10 23:44 ` Ivan Frade
2021-11-11 0:01 ` Ævar Arnfjörð Bjarmason
2021-11-10 21:18 ` Ivan Frade
2021-10-29 18:42 ` [PATCH v6 2/2] http-fetch: redact url on die() message Ivan Frade via GitGitGadget
2021-11-08 23:06 ` Jonathan Tan
2021-11-10 23:51 ` [PATCH v7 0/2] fetch-pack: redact packfile urls in traces Ivan Frade via GitGitGadget
2021-11-10 23:51 ` [PATCH v7 1/2] " Ivan Frade via GitGitGadget
2021-11-10 23:51 ` [PATCH v7 2/2] http-fetch: redact url on die() message Ivan Frade via GitGitGadget
2021-11-12 4:43 ` [PATCH v7 0/2] fetch-pack: redact packfile urls in traces Junio C Hamano
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=xmqqa6ispy28.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=ifrade@google.com \
--cc=jonathantanmy@google.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).