From: Emily Shaffer <emilyshaffer@google.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 4/9] bugreport: add config values from whitelist
Date: Wed, 11 Dec 2019 12:48:11 -0800 [thread overview]
Message-ID: <20191211204811.GC107889@google.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1910281506040.46@tvgsbejvaqbjf.bet>
On Mon, Oct 28, 2019 at 03:14:35PM +0100, Johannes Schindelin wrote:
> Hi Emily,
Sorry for the delay in replying. This work has been backburnered and
this mail slipped through the cracks.
>
> On Thu, 24 Oct 2019, Emily Shaffer wrote:
>
> > Teach bugreport to gather the values of config options which are present
> > in 'git-bugreport-config-whitelist'.
> >
> > Many config options are sensitive, and many Git add-ons use config
> > options which git-core does not know about; it is better only to gather
> > config options which we know to be safe, rather than excluding options
> > which we know to be unsafe.
>
> Should we still have the `// bugreport-exclude` comments, then?
They were optional (useless) before too. I can remove them if you want;
I suppose I like the idea of having precedent if someone wants to build
their own internal version with opt-out configs rather than opt-in. I
can remove them if we want; it doesn't matter very much to me either
way.
>
> >
> > Reading the whitelist into memory and sorting it saves us time -
> > since git_config_bugreport() is called for every option the user has
> > configured, limiting the file IO to one open/read/close and performing
> > option lookup in sublinear time is a useful optimization.
>
> Maybe we even want a hashmap? That would reduce the time complexity even
> further.
Sure, we can do it. I'll make that change.
>
> > diff --git a/bugreport.c b/bugreport.c
> > index ada54fe583..afa4836ab1 100644
> > --- a/bugreport.c
> > +++ b/bugreport.c
> > @@ -1,10 +1,24 @@
> > #include "cache.h"
> >
> > #include "bugreport.h"
> > +#include "config.h"
> > +#include "exec-cmd.h"
> > #include "help.h"
> > #include "run-command.h"
> > #include "version.h"
> >
> > +/**
> > + * A sorted list of config options which we will add to the bugreport. Managed
> > + * by 'gather_whitelist(...)'.
> > + */
> > +struct string_list whitelist = STRING_LIST_INIT_DUP;
> > +struct strbuf configs_and_values = STRBUF_INIT;
> > +
> > +// git version --build-options
> > +// uname -a
> > +// curl-config --version
> > +// ldd --version
> > +// echo $SHELL
>
> These comments probably want to move to a single, C style comment, and
> they probably want to be introduced together with `get_system_info()`.
Yeah, it's stale and has been removed now. It was less commentary and
more todo list for author ;)
>
> I also have to admit that I might have missed where `$SHELL` was added
> to the output...
I skipped it entirely since bugreport doesn't run in shell anymore. If
you have advice for gathering the user's shell I can try to add it; is
there such a difference between, say, a Debian user using bash and a
Debian user using zsh? I suppose it could be useful if someone has an
issue with GIT_PS1, or with autocompletion. I'll look into gathering it.
>
> > void get_system_info(struct strbuf *sys_info)
> > {
> > struct child_process cp = CHILD_PROCESS_INIT;
> > @@ -53,3 +67,39 @@ void get_system_info(struct strbuf *sys_info)
> > argv_array_clear(&cp.args);
> > strbuf_reset(&std_out);
> > }
> > +
> > +void gather_whitelist(struct strbuf *path)
> > +{
> > + struct strbuf tmp = STRBUF_INIT;
> > + strbuf_read_file(&tmp, path->buf, 0);
> > + string_list_init(&whitelist, 1);
> > + string_list_split(&whitelist, tmp.buf, '\n', -1);
> > + string_list_sort(&whitelist);
> > +}
> > +
> > +int git_config_bugreport(const char *var, const char *value, void *cb)
> > +{
> > + if (string_list_has_string(&whitelist, var)) {
> > + strbuf_addf(&configs_and_values,
> > + "%s : %s\n",
> > + var, value);
>
> A quite useful piece of information would be the config source. Not sure
> whether we can do that outside of `config.c` yet...
It's possible. I can add it.
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +void get_whitelisted_config(struct strbuf *config_info)
> > +{
> > + struct strbuf path = STRBUF_INIT;
> > +
> > + strbuf_addstr(&path, git_exec_path());
> > + strbuf_addstr(&path, "/git-bugreport-config-whitelist");
>
> Hmm. I would have expected this patch to come directly after the patch
> 2/9 that generates that white-list, and I would also have expected that
> to be pre-sorted, and compiled in.
>
> Do you want users to _edit_ the file in the exec path? In general, that
> path will be write-protected, though. A better alternative would
> probably be to compile in a hard-coded list, and to allow including more
> values e.g. by offering command-line options to specify config setting
> patterns. But if we allow patterns, we might actually want to have those
> exclusions to prevent sensitive data from being included.
Hm, interesting. Do we have precedent for compiling in a header
generated during the build process? I think I saw one when I was adding
this script - I'll take a look.
>
> > +
> > + gather_whitelist(&path);
> > + strbuf_init(&configs_and_values, whitelist.nr);
> > +
> > + git_config(git_config_bugreport, NULL);
> > +
> > + strbuf_reset(config_info);
> > + strbuf_addbuf(config_info, &configs_and_values);
> > +}
> > diff --git a/bugreport.h b/bugreport.h
> > index ba216acf3f..7413e7e1be 100644
> > --- a/bugreport.h
> > +++ b/bugreport.h
> > @@ -5,3 +5,10 @@
> > * The previous contents of sys_info will be discarded.
> > */
> > void get_system_info(struct strbuf *sys_info);
> > +
> > +/**
>
> I also frequently use JavaDoc-style `/**`, but I am not sure that this
> is actually desired in Git's source code ;-)
>
> > + * Adds the values of the config items listed in
> > + * 'git-bugreport-config-whitelist' to config_info. The previous contents of
> > + * config_info will be discarded.
> > + */
> > +void get_whitelisted_config(struct strbuf *sys_info);
> > diff --git a/builtin/bugreport.c b/builtin/bugreport.c
> > index 7232d31be7..70fe0d2b85 100644
> > --- a/builtin/bugreport.c
> > +++ b/builtin/bugreport.c
> > @@ -56,6 +56,10 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
> > get_system_info(&buffer);
> > strbuf_write(&buffer, report);
> >
> > + add_header(report, "Whitelisted Config");
>
> Quite honestly, I would like to avoid the term "whitelist" for good. How
> about "Selected config settings" instead?
Will do - thanks for the callout.
>
> Thanks,
> Dscho
>
> > + get_whitelisted_config(&buffer);
> > + strbuf_write(&buffer, report);
> > +
> > fclose(report);
> >
> > launch_editor(report_path.buf, NULL, NULL);
> > --
> > 2.24.0.rc0.303.g954a862665-goog
> >
> >
next prev parent reply other threads:[~2019-12-11 20:48 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 2:34 [PATCH] bugreport: add tool to generate debugging info Emily Shaffer
2019-08-15 14:15 ` Derrick Stolee
2019-08-15 14:36 ` Junio C Hamano
2019-08-15 22:52 ` Emily Shaffer
2019-08-15 23:40 ` Junio C Hamano
2019-08-16 1:25 ` Emily Shaffer
2019-08-16 16:41 ` Junio C Hamano
2019-08-16 19:08 ` Emily Shaffer
2019-08-15 20:07 ` Johannes Schindelin
2019-08-15 22:24 ` Emily Shaffer
2019-08-16 20:19 ` Johannes Schindelin
2019-08-15 20:13 ` Emily Shaffer
2019-08-15 18:10 ` Junio C Hamano
2019-08-15 21:52 ` Emily Shaffer
2019-08-15 22:29 ` Junio C Hamano
2019-08-15 22:54 ` Emily Shaffer
2019-08-17 0:39 ` [PATCH v2 0/2] add git-bugreport tool Emily Shaffer
2019-08-17 0:39 ` [PATCH v2 1/2] bugreport: add tool to generate debugging info Emily Shaffer
2019-08-17 0:39 ` [PATCH v2 2/2] bugreport: generate config whitelist based on docs Emily Shaffer
2019-08-17 20:38 ` Martin Ågren
2019-08-21 17:40 ` Emily Shaffer
2019-10-25 2:51 ` [PATCH v3 0/9] add git-bugreport tool Emily Shaffer
2019-10-25 2:51 ` [PATCH v3 1/9] bugreport: add tool to generate debugging info Emily Shaffer
2019-10-29 20:29 ` Josh Steadmon
2019-11-16 3:11 ` Junio C Hamano
2019-11-19 20:25 ` Emily Shaffer
2019-11-19 23:24 ` Johannes Schindelin
2019-11-20 0:37 ` Junio C Hamano
2019-11-20 10:51 ` Johannes Schindelin
2019-11-19 23:31 ` Johannes Schindelin
2019-11-20 0:39 ` Junio C Hamano
2019-11-20 2:09 ` Emily Shaffer
2019-11-20 0:32 ` Junio C Hamano
2019-10-25 2:51 ` [PATCH v3 2/9] bugreport: generate config whitelist based on docs Emily Shaffer
2019-10-28 13:27 ` Johannes Schindelin
2019-10-25 2:51 ` [PATCH v3 3/9] bugreport: add version and system information Emily Shaffer
2019-10-28 13:49 ` Johannes Schindelin
2019-11-08 21:48 ` Emily Shaffer
2019-11-11 13:48 ` Johannes Schindelin
2019-11-14 21:42 ` Emily Shaffer
2019-10-29 20:43 ` Josh Steadmon
2019-10-25 2:51 ` [PATCH v3 4/9] bugreport: add config values from whitelist Emily Shaffer
2019-10-28 14:14 ` Johannes Schindelin
2019-12-11 20:48 ` Emily Shaffer [this message]
2019-12-15 17:30 ` Johannes Schindelin
2019-10-29 20:58 ` Josh Steadmon
2019-10-30 1:37 ` Junio C Hamano
2019-11-14 21:55 ` Emily Shaffer
2019-10-25 2:51 ` [PATCH v3 5/9] bugreport: collect list of populated hooks Emily Shaffer
2019-10-28 14:31 ` Johannes Schindelin
2019-12-11 20:51 ` Emily Shaffer
2019-12-15 17:40 ` Johannes Schindelin
2019-10-25 2:51 ` [PATCH v3 6/9] bugreport: count loose objects Emily Shaffer
2019-10-28 15:07 ` Johannes Schindelin
2019-12-10 22:34 ` Emily Shaffer
2019-10-29 21:18 ` Josh Steadmon
2019-10-25 2:51 ` [PATCH v3 7/9] bugreport: add packed object summary Emily Shaffer
2019-10-28 15:43 ` Johannes Schindelin
2019-12-11 0:29 ` Emily Shaffer
2019-12-11 13:37 ` Johannes Schindelin
2019-12-11 20:52 ` Emily Shaffer
2019-10-25 2:51 ` [PATCH v3 8/9] bugreport: list contents of $OBJDIR/info Emily Shaffer
2019-10-28 15:51 ` Johannes Schindelin
2019-10-25 2:51 ` [PATCH v3 9/9] bugreport: print contents of alternates file Emily Shaffer
2019-10-28 15:57 ` Johannes Schindelin
2019-11-19 20:40 ` Emily Shaffer
2019-10-29 1:54 ` [PATCH v3 0/9] add git-bugreport tool Junio C Hamano
2019-10-29 11:13 ` Johannes Schindelin
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=20191211204811.GC107889@google.com \
--to=emilyshaffer@google.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.