From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 573513858412 for ; Tue, 26 Jul 2022 22:51:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 573513858412 Received: by mail-ed1-x52f.google.com with SMTP id m8so19322486edd.9 for ; Tue, 26 Jul 2022 15:51:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=36uh3SUjS9VFdAfIg/UuunAImjBjvKVUi8ihk5HQrv0=; b=1gqV7nQ2v2ce3PbuHPU6ajhq4VT2NS64heB9RW4mk98MrliNH5fZaMS5N27LJT6ZVV MuShcsjfsURz6l1VodkGVP21A82F11qE0qSK0HbJ0dh0heTzQDCi7IfTIDeE99wKHP9w S5/L9madbrqMwAltr02ZZsbqFHhFAhu559u+Ofb84b03KYRkFz4HQ/dSc0f1K41MQJxZ Ahs8QYhYAtR0TEz5CR3NJlWtV7VHezpH/NsP+SolQx3wAJtHNO0KnvBqMLH59L8CsrgI khT6BZCBOHOmWi+u3vKoL/tO1SVxS+KXNnpDdYKHMuSote2qONLuyIa2UIc9+QQ6nJSR CG1A== X-Gm-Message-State: AJIora8Bm0+6i2GmM2vtWdBZ4KV3jvJvkeCkOZ5ZC5QeUiYLeFvarL2a ZFW1K2fz9PIhb4GotvoF327akMgjx9VSCxSLp9B/i1IU5IOoDw== X-Google-Smtp-Source: AGRyM1uVZRuDwUWDldyaOHpakZql1tBetHMQ6CRTyMcQYHlua6v7o0oocy7ue8vI4Vh1L9SPZIYpRblxrp/sm0eiGTk= X-Received: by 2002:a05:6402:b7b:b0:43c:90c0:86cc with SMTP id cb27-20020a0564020b7b00b0043c90c086ccmr2517153edb.247.1658875859771; Tue, 26 Jul 2022 15:50:59 -0700 (PDT) MIME-Version: 1.0 From: Daniel Thornburgh Date: Tue, 26 Jul 2022 15:50:48 -0700 Message-ID: Subject: debuginfod Credential Helper RFC To: elfutils-devel@sourceware.org X-Spam-Status: No, score=-17.1 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, HTML_OBFUSCATE_05_10, 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" Content-Transfer-Encoding: quoted-printable 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: Tue, 26 Jul 2022 22:51:05 -0000 Hello elfutils-devel@ I'm working on a use case for debuginfod (in LLVM) that needs a solution for authentication and authorization of users when accessing source and debug information. I've put together a short RFC for how this might work, based on how git and Docker CLIs handle credentials. It should be fairly straightforward to implement and to generalize to new credential types. Please take a look; it'd be good to have a consensus on how this should work across interested debuginfod implementations before moving forward towards implementation. --=20 debuginfod Credential Helper RFCBackground debuginfod is a simple HTTP-based protocol allowing clients to obtain debug information from servers. The de-facto standard includes environment variables for pointing clients at available debuginfod servers, but it includes no mechanism to provide credentials. This approach works well for fully open-source projects, but debuginfod is also particuarly useful for the highly-stripped binaries and constrained environments found in the embedded space. There, it=E2=80=99s common for li= censing constraints to require access to source and debug information to be restricted to specific users. Proposal debuginfod clients could support a new DEBUGINFOD_CREDENTIAL_HELPER environ= ment variable. This would provide a command that a debuginfod client could run to obtain credentials to supply to the server, much like Git or Docker credential helpers do. No modifications are proposed to generic debuginfod server implementations, since specific authentication and authorization decisions are usually quite domain-specific, and it=E2=80=99s fairly easy to write or configure a custo= m debuginfod server to make them. The proposal also omits any mechanism for the client to interactively prompt the user for their credentials or to retrieve them from storage; this is left to the credential helper. Protocol The behavior of the credential helpers broadly follows the example set by Git and Docker. The DEBUGINFOD_CREDENTIAL_HELPER environment variable contains a string indicating the command to run. If the string begins with an absolute path, the command is the verbatim string. Otherwise, the command is the string prepended with debuginfod-credential-. Once interpreted, the given command is executed in the shell with one additional argument to indicate the operation type. This is always get. The helper reads a description of the requested credential from stdin and writes a description of the found credential to stdout. Errors may be reported to stderr. Credential Format Credential requests and found credentials are both broadly described using Git credential helpers=E2=80=99 input/output format , with some modifications. Only the http and https protocols are supported, since debuginfod only operates over HTTP(S). The url attribute is unsupported; URL components must instead be passed separately. An added bearer attribute can supply OAuth2 bearer tokens in Base64 . This attribute is mutually exclusive with username and password. Daniel Thornburgh | dthorn@google.com