public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Noah Sanci <nsanci@redhat.com>, elfutils-devel@sourceware.org
Subject: Re: [Bug debuginfod/27277] Describe retrieved files when verbose
Date: Thu, 5 Aug 2021 12:54:02 -0400	[thread overview]
Message-ID: <20210805165402.GD4195@redhat.com> (raw)
In-Reply-To: <b58851f417995647f800e35227284d933433fa5e.camel@klomp.org>

Hi -

> I like the verbose http header output, but wish it was done earlier
> instead of after the download. Maybe when we commit to an url, if the
> info is available then.

What do you mean "done"?  Printed?

> The new X-FILE and X-ARCHIVE headers also seem useful.
> One question about X-FILE, if it doesn't come from an archive, does it
> leak a file system path that might be "secret" on the server?

Perhaps kind of sort of ... but since source files for such buildids
are resolved only against the host filesystem, those same names will
be there in all their glory in the DWARF.  My guess is that public
servers that care about such configuration privacy will be exclusively
archive based.

> Why is X-FILE-SIZE != Content-Length ?

Because Content-Length can be shorter due to compression
transfer-encoding.  It's the file size that governs local storage &
DEBUGINFOD_MAXSIZE interaction.

> I am less enthusiastic about the new debuginfod_get_response_headers
> interface. It seems not as useful since it only works if we haven't
> already (negatively) cached the file and it is very free-form, do we
> guarantee any headers are there? 

Naturally we can't guarantee any headers, because they are at the
pleasure of the server.

> Could you provide a user story where this is used?

Not really, beyond just printing the things for information purposes,
but not wanting the whole DEBUGINFOD_VERBOSE=1 firehose.  In the mid
term, it could help systemd-coredumpctl type tools map buildids to
actual distro artifact names, and enable paranoid
federation/buildtree/checking type measures (where we may want to
spot-check servers that buildids haven't been hijacked).  Vague but I
think there's something there.

> Maybe this interface is more useful if it was done as a new active
> query type (the HEAD query you mention in the commit message)?

That in turn would require THREE new API functions or a stateful
set_HEAD_mode_and_return_dev_null one and modifying the three main
lookup functions.

- FChE


  reply	other threads:[~2021-08-05 16:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04 18:54 Noah Sanci
2021-08-05 15:13 ` Mark Wielaard
2021-08-05 16:54   ` Frank Ch. Eigler [this message]
2021-08-06 10:04     ` Mark Wielaard
2021-08-06 18:54       ` Frank Ch. Eigler
2021-08-09  9:25         ` Mark Wielaard
2021-08-23 15:11           ` Noah Sanci
2021-08-24  8:18             ` Mark Wielaard
2021-08-27 18:38               ` Noah Sanci
2021-09-08 20:56                 ` Mark Wielaard
2021-09-10 18:22                   ` Noah Sanci
2021-09-12 19:08                     ` Mark Wielaard
2021-09-13 20:07                       ` Noah Sanci
2021-09-16 10:50                         ` Mark Wielaard
2021-09-22 20:33           ` Frank Ch. Eigler
2021-09-29 14:55             ` Mark Wielaard
2021-09-29 21:28               ` Frank Ch. Eigler
2021-10-05 14:28                 ` Mark Wielaard
2022-07-14 15:32                   ` Noah Sanci
2022-08-04 13:12                     ` Mark Wielaard
     [not found]                       ` <CAJXA7qg09YkxK-NRQ31Hem0+54Us=jYC5+1siPSbHangx=SCow@mail.gmail.com>
2022-08-08 14:35                         ` Mark Wielaard
2021-08-25 18:08 Noah Sanci
2021-09-08 15:01 ` Mark Wielaard

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=20210805165402.GD4195@redhat.com \
    --to=fche@redhat.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.org \
    --cc=nsanci@redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).