[bug#52866] maintenance: Add a crash dump service.

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> Or, dump.guix.gnu.org could relay everything as-is to bug-guix@gnu.org
>> *if* we know users are aware of what data is being reported.
>
> That's something that also crossed my mind, but I chose instead to make
> the web-server publish the bug reports here: https://dump.guix.gnu.org.
> They can then be downloaded with this URL:
> https://dump.guix.gnu.org/download/<id>.
>
> Of course the next step it to use this API in a command line tool or
> so. I don't feel like working on another web interface.

OK (I didn’t know it was already deployed!).  What if we just put the
uploaded file in a directory and let nginx provide a directory index and
all?  Anyway, given the target audience, it doesn’t have to be fancy.
:-)

> Regarding the installer integration, you can have a look to:
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-harden-installer&id=22158d407af89d2f3df3abd8005ec2321df45c74.

At first sight it LGTM.  The key thing is that the crash dump code must
be programmed “defensively” so that it never crashes itself; it should
gracefully handle transient network errors, TLS certificate issues, bad
HTTP responses, etc., and just say it when it failed to upload the
report.

> There's already a window asking before uploading the crash dump. I think
> that if we make the warning message even more explicit it could be fine.

The message should allow for informed consent.  Thus it should explain
what the risks are (“Logs may contain sensitive information such as …”,
“Logs are eventually publicly visible, but IP addresses are not logged”,
etc.) and/or it should let users screen all the logs.

Josselin Poiret <dev@jpoiret.xyz> skribis:

> While looking at the code for the crash dump page in the installer, I
> didn't see any special handling of user and root passwords.  I've just
> tested it at https://dump.guix.gnu.org/download/installer-dump-c9deb88f,
> and you can see that the passwords end up in the results at the end
> (both are `TEST` in capitals in my case).  I think this might require
> more thought.  I'm not sure we have to include the result alist in the
> dump report, as the installer log should provide enough information in
> the case of a failure.

As discussed the other day on IRC, to make sure the backtrace does not
contain passwords, we could define a record type for “secrets”, which
would basically just “box” strings such as passwords.  That record
type’s printer would just print #<secret 0123abcd>.  See
<file-system-label> for an example.

> Concerning Ludo's objection to syslog being in the dump, this was one of
> the reasons behind the new logging facilities at [1], which provide a
> clean installer-only log file.  We could add some checkboxes to choose
> which files to include, eg:
>
> [X] Installer log
> [ ] Syslog
> [ ] Dmesg
>
> Along with an option to view them in a pager.

Problem is that users, even advanced users, cannot necessarily tell what
sensitive info each of these might contain, nor whether withdrawing them
from the report would impede debugging.  So it’s probably a choice we
have to make ourselves.

Since the installer uses syslog, we could add a syslog rule that
redirects installer logging to a separate file.  We still need kernel
output to see info about devices, but perhaps that too could go to a
separate file?

Thanks,
Ludo’.