From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id A4D9F384C001 for ; Fri, 6 Aug 2021 10:04:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A4D9F384C001 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 376FB30291A9; Fri, 6 Aug 2021 12:04:47 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 99385413CC81; Fri, 6 Aug 2021 12:04:46 +0200 (CEST) Message-ID: <35f2073dfeed8f008d42a78bf60b7efcf13164eb.camel@klomp.org> Subject: Re: [Bug debuginfod/27277] Describe retrieved files when verbose From: Mark Wielaard To: "Frank Ch. Eigler" Cc: Noah Sanci , elfutils-devel@sourceware.org Date: Fri, 06 Aug 2021 12:04:46 +0200 In-Reply-To: <20210805165402.GD4195@redhat.com> References: <20210805165402.GD4195@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 10:04:50 -0000 Hi, On Thu, 2021-08-05 at 12:54 -0400, Frank Ch. Eigler wrote: > > 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. >=20 > What do you mean "done"? Printed? Yes, since the actual download might take a bit, it is nice to see the headers at the moment we commit to a server/download. aka here in the source: if (vfd >=3D 0 && !verbose_reported && committed_to >=3D 0) { bool pnl =3D (c->default_progressfn_printed_p && vfd =3D=3D STDERR_FI= LENO); dprintf (vfd, "%scommitted to url %d\n", pnl ? "\n" : "", committed_to); if (pnl) c->default_progressfn_printed_p =3D 0; verbose_reported =3D true; } Assuming we have the headers at that point of course. Otherwise right after that when they become available (this is inside the download loop). > > 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? >=20 > 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. Yeah, you are right, the DWARF debug files themselves already "expose" those paths. > > Why is X-FILE-SIZE !=3D Content-Length ? >=20 > Because Content-Length can be shorter due to compression > transfer-encoding. It's the file size that governs local storage & > DEBUGINFOD_MAXSIZE interaction. Ah, of course, then it is indeed useful to have both headers. > > 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?=20 >=20 > Naturally we can't guarantee any headers, because they are at the > pleasure of the server. >=20 > > Could you provide a user story where this is used? >=20 > Not really, beyond just printing the things for information purposes, > but not wanting the whole DEBUGINFOD_VERBOSE=3D1 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. Yes, I do think there is something there, but imho it is too vague and fragile to be useful as is, especially since it depends on what is in the cache. > > 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)? >=20 > 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. Yes, it definitely is more work. Cheers, Mark