From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97307 invoked by alias); 19 Nov 2019 15:41:58 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 97294 invoked by uid 89); 19 Nov 2019 15:41:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=services X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Nov 2019 15:41:56 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 22A0230003CD; Tue, 19 Nov 2019 16:41:53 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id D2E3D413CEAA; Tue, 19 Nov 2019 16:41:53 +0100 (CET) Message-ID: <52e9358695f8486af6e4e467660c971a1e97c02f.camel@klomp.org> Subject: Re: patch 2/2 debuginfod server etc. From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org, amerey@redhat.com Date: Tue, 19 Nov 2019 15:41:00 -0000 In-Reply-To: <20191118184108.GC2880@redhat.com> References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <20191028190726.GE14349@redhat.com> <8d0b26865cc18838c24ea57c09f4ee5af713af16.camel@klomp.org> <20191114122953.GC873@redhat.com> <20191118184108.GC2880@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00179.txt.bz2 Hi, On Mon, 2019-11-18 at 13:41 -0500, Frank Ch. Eigler wrote: > > > I see where you're going with it, it's a reasonable concern. For now, > > > we can consider it covered by the "debuginfod should be given > > > trustworthy binaries" general rule. > >=20 > > This does keep me slightly worried. Even "trustworthy binaries" could > > be produced by buggy compilers.=20 >=20 > Those would be untrustworthy binaries. But then every binary could be untrustworthy :) > > I really think we should have some way to restrict which files on > > the file system can be served up. IMHO the default should be that no > > files outside directories explicit given to debuginfod should be > > allowed to be provided to the client. So it makes sense providing > > any extra source dirs, so you can check that any references to > > source files are actually correct/intended. >=20 > It's not so easy. For build trees, source files can include > /usr/include/*, which do not contain executables and so don't need > indexing. The use of symlinks in some configury/build systems makes > filtering after the fact difficult too - the realpath of object files > and source trees need not even be near, or in a single place. The /usr/include/* thing is precisely why I think it is wrong to provide those files. Those just happen to be the versions of the include file installed on the machine the server is running on. They might be completely different. Some debug files might have references to (generated) files in /tmp. You wouldn't want to provide those, even if they existed on the file system. Yes, there might be source files outside the sources tree you provided, but that doesn't mean you want to just hand them out. In particular I believe that if we find source files under /usr/src/debug then we should only provide those source files, not any others on the file system. > Would you be satisfied if the -F / -R flags were restored, so that -F > would be required in order to start file-scanning threads (and similar > for -R)? Then all this does not arise, because people who don't trust > their compilers wouldn't run debuginfod in -F mode. That would be helpful, but then -F should not be used by default. And I don't think we should recommend people use it. > > > I was thinkinng [300s] it's about right for a developer's live build = tree. > >=20 > > OK, but those aren't included by default.=20 >=20 > A concern about the systemd service defaults can be addressed at the > systemd service / sysconfig level. Would you prefer a day for that? Something between an hour and a day seems appropriate for that. > > Which suggest to use it to polish by removing debuginfo-unrelated data. > > I am still not sure what that unrelated data is or when I really want > > to do this. It doesn't really list any quantifiable benefits. >=20 > OK, elaborating this point in the man page. Thanks. OK, so this is mainly about purging indexed source files that are never actually referenced. > > > The text says that debuginfod does not provide https service at all, > > > so this is not relevant. A front-end https reverse-proxy would have > > > to deal with this stuff. I plan to cover this in a blog post later > > > on, and probably in the form of software baked into a container image. > >=20 > > But debuginfod might use HTTPS services itself for fallback. I think it > > is important to describe how/if those https ssl/tls connections are > > authenticated. >=20 > OK, will add a blurb. Thanks. So we don't do any authentication right now even when using https? Is that deliberate? What would it take to let it use the system certs for authentication? Cheers, Mark