From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 718C1385AC19 for ; Thu, 4 Aug 2022 18:05:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 718C1385AC19 Received: by mail-ed1-x533.google.com with SMTP id a89so647965edf.5 for ; Thu, 04 Aug 2022 11:05:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=YHeDra8+B7F6doWVCMQbsHFihdSfKkcvdmTXYYEaFGo=; b=Wxjnv188CaOfH8CEtvIkd72I8FDtwDitgN1sYjTNjt8pN4pmrTiN7qdJQZ2XVKnY40 XPxr3DWDZpRCMiRu7tAPJeSt557i0ERasTNBLOl/RmSRRlyLGFfWAilaXsNyasJTW5Hp b423SEdPWz3+dNGNYhb3Mz68YzNemu0L671qRygGjWaG3xbTLz999aVt1m4X9VTQ1Bn/ BlcteyUmAV6WsS4xx5Ruaiul3mcrOjDN4js3oGGXBOk6WeR/MeeAvejZ0Nh+B1XoAZya 44x3ryQxB+zuoJ26iGjNot3XtpiNCS8NIguP47uHx7ZhkCwOOO3IKmP4qOGNAEOHpSv4 EdoQ== X-Gm-Message-State: ACgBeo112xuS3sNGTqDc4ExWoz7o/aXFjoWKbL0BXjNaxMHiDqJWI0BG bBp4M07hVCYsnjd2mJCM59eSdplKqxEL0KjGBsQuj37kLGk= X-Google-Smtp-Source: AA6agR50lZKi5rZ09QcU7uvNOeU+6KLWL+lTmUwJL1qnc97zt5Ezg2zGsp9dnelpb7XAkkOEF23xjTZ93phMHuKWGKc= X-Received: by 2002:aa7:d653:0:b0:43d:151b:5939 with SMTP id v19-20020aa7d653000000b0043d151b5939mr3157708edr.278.1659636306140; Thu, 04 Aug 2022 11:05:06 -0700 (PDT) MIME-Version: 1.0 References: <7e442ae6d3be28043d3c3ecd8a66af011b8dd573.camel@klomp.org> <259802b4c23d488bbd68a5f50898f44e4258c530.camel@klomp.org> <025de8a2c25112e902cc330199b9d0ebb61fbaf6.camel@klomp.org> In-Reply-To: <025de8a2c25112e902cc330199b9d0ebb61fbaf6.camel@klomp.org> From: Daniel Thornburgh Date: Thu, 4 Aug 2022 11:04:54 -0700 Message-ID: Subject: Re: debuginfod Credential Helper RFC To: Mark Wielaard Cc: elfutils-devel@sourceware.org X-Spam-Status: No, score=-17.0 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 04 Aug 2022 18:05:10 -0000 On Thu, Aug 4, 2022 at 10:02 AM Mark Wielaard wrote: > I wonder if we should generalize that for other DEBUGINFOD_envs. But > instead of adding more environment variables have a debuginfod control > file like we already have for cache_clean_interval, max_unused_age and > cache_miss. > > So as an alternative to setting any of the DEBUGINFOD_frob environment > variables you could put an urls, cache_path, progress, verbose > retry_limit, timeout, maxtime, maxsize or headers file under > XDG_CONFIG_HOME (~/.config) debuginfod_client that would be used if the > corresponding environment variable isn't set. > > The downside of course is that it would cause more file stats when > creating a debuginfod_client handle, but the overhead is probably > minimal especially if programs just reuse the debuginfod_client > objects. > > Or maybe it should just be one control file that can have entries for > all of the variables. > Generalizing our use case, configuration files help when you're looking to put permissions on part of the debuginfod configuration. Not sure if that generalizes beyond supplying headers, but maybe in the future? I could also see file-based config being useful if some aspect of the debuginfod configuration can change from moment-to-moment. Environment variables could be used for that, but it would require either changing those variables in the calling shell or wrapping each debuginfod client utility. Or maybe just if the number of environment variables grows unwieldy. For the permissions and mutable configuration cases, it would be desirable to point debuginfod at different paths, so that these could be kept in e.g. tmpfs. These might be machine generated, which also means there may be multiple sources of such files. So, something like a DEBUGINFOD_CONFIG_FILES list might work well there; each file could contain, say, a list of environment_variable=value pairs, (or a more debuginfod-specific format), and all the files in the list could be concatenated together. Then, a service set up in bashrc could append or prepend its moment-to-moment configuration runfile to the list of config files. You could also do this more granularly: DEBUGINFOD_HEADERS_FILES would work for us, and other lists could be created for other dynamically controllable aspects of the system. This wouldn't compose as well if you needed to do hackery to say, remove a source of config from the list, though, as then you'd have to find and remove n sources of config from n lists. -- Daniel Thornburgh | dthorn@google.com