From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 93B6E385C6D4 for ; Wed, 11 Oct 2023 14:50:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 93B6E385C6D4 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 r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 6D449300B302; Wed, 11 Oct 2023 16:50:52 +0200 (CEST) Received: by r6.localdomain (Postfix, from userid 1000) id 00AB63402EA; Wed, 11 Oct 2023 16:50:51 +0200 (CEST) Message-ID: Subject: Re: PATCH PR30962, debuginfod From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Date: Wed, 11 Oct 2023 16:50:51 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Spam-Status: No, score=-3029.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Frank, On Wed, 2023-10-11 at 10:22 -0400, Frank Ch. Eigler wrote: > > I think this makes sense, but it would be good to see an example of the > > paths this now exposes. >=20 > e.g: > % debuginfod-find -v debuginfo /bin/ls > [...] > x-debuginfod-size: 502024 > x-debuginfod-archive: /mnt/fedora_koji_prod/koji/packages/coreutils/9.3/4= .fc39/x86_64/coreutils-debuginfo-9.3-4.fc39.x86_64.rpm > x-debuginfod-file: /usr/lib/debug/usr/bin/ls-9.3-4.fc39.x86_64.debug > [...] Ah, right. Thanks. > > Does this include the temporary dir that a file is extracted in? >=20 > No. >=20 > > Does it really make sense to provide the full (absolute?) path of > > the archive a source file was found in? >=20 > As much sense as omitting the entire path information and returning > only the basename. Sometimes the path may matter, if e.g. the archive > file names are duplicate. And it turns out the archive paths were > already usually sent in their entirety, and the archived-file paths > were basename'd. Kinda the wrong way around. Anyway it's simplest to > do neither bit of elision at the tool level. OK. But I think you should add an explanation or example to "Front-end proxies can also elide sensitive path name components" paragraph. So the user is fully aware what those "sensitive path names" are. Maybe even add that debuginfod-find -v example so people can double check. Thanks, Mark