From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id EDnXLx267mBUbQEAgWs5BA (envelope-from ) for ; Wed, 14 Jul 2021 12:19:09 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id GIOdKx267mACYgAA1q6Kng (envelope-from ) for ; Wed, 14 Jul 2021 10:19:09 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E0E531461E for ; Wed, 14 Jul 2021 12:19:08 +0200 (CEST) Received: from localhost ([::1]:53490 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3byt-0006md-4c for larch@yhetil.org; Wed, 14 Jul 2021 06:19:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43470) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3bt4-0006Qy-2Y for help-guix@gnu.org; Wed, 14 Jul 2021 06:13:06 -0400 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:43708) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m3bt0-0003M3-Gc for help-guix@gnu.org; Wed, 14 Jul 2021 06:13:05 -0400 Received: by mail-ot1-x32e.google.com with SMTP id i12-20020a05683033ecb02903346fa0f74dso1893454otu.10 for ; Wed, 14 Jul 2021 03:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/qLswTL1wId/wGrFfbU6UPgKz+BK9A4H/nhiyZFrsEo=; b=g2ReItaz6tpvVKj66BXl7zF59jZX2WMuom3fMJ3KyiDfgVT6wTZmUnmejojAWm3bFZ xbcNvqiar3lRR2aOdrmSB8FKqbOFs+dKe/CnQybotIevE99vzs4elui0FFqsPuDIrBcN xB0xKMHsC8JMk6sXlCvXCVs6Totnh78imJeIgj8InaT1N17GUytXNQyWifQ271UHHlUN 9qfe50Ei6XQp40QCXVZlLA1I50omYqG/92pSRRlhGMWZPNz6ITNZ19i/RRqiM37rAb95 HCYMTjd0TUjpaccVfwmdnN6Vpl5yEXZpeKhbqWAhDHbZlVtVrIafWF6NFLcdgEeewR3F ixMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/qLswTL1wId/wGrFfbU6UPgKz+BK9A4H/nhiyZFrsEo=; b=O6LrWqd1j9hF6vzqYdKjxg5TPBcUl4jCGUg3h1EWmC2dmSr2CSkjBnPAR0ZPPUX2ee My/h0x5Sacq5fLqPwj6GohL//SkSGShRJx72bViBTTPb1ZzKin2dskzgL0hP/JpmqKWY Z03WHzYtoguUjRD2dAIm1369ZD3NXAqvF8OfhaP29VpamyiETU9TC/18a2mLxQRLvw52 jWHs3p2/awWEDjUMFNiXetC7wP2Ks5amS0KeDw1oxEjnlkao40z5lT2BOmPiIyT1oy3g gaIYEenSrtW0Xf+YyOU9IK3VyQL0O2/4/sAnl7/Pg2LwU8MYEVpz3Aaak/Iznsbs7Qi7 eBHg== X-Gm-Message-State: AOAM5305tTiEU2TmDNtfvLhhA2nL9yahXKGGid3QFur8lexaCf6e/shp 6cCyg2j8QZmxitUCRLlytKQZCeF+bEmab8SC/KU= X-Google-Smtp-Source: ABdhPJxRnzO5ilZxSScsxf71gBi4ZciFmvnBd5HUq153wKuDlTiqGTF7d1cdbnDXMcyCIsPot/gNcp2I3tO2W9YlOFU= X-Received: by 2002:a05:6830:11d0:: with SMTP id v16mr7280623otq.273.1626257581394; Wed, 14 Jul 2021 03:13:01 -0700 (PDT) MIME-Version: 1.0 References: <87zgupz225.fsf@gmail.com> In-Reply-To: <87zgupz225.fsf@gmail.com> From: Lo Peter Date: Wed, 14 Jul 2021 18:12:50 +0800 Message-ID: Subject: Re: Fwd: SSH in git-fetch To: Chris Marusich Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::32e; envelope-from=peterloleungyau@gmail.com; helo=mail-ot1-x32e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: help-guix Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1626257949; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=/qLswTL1wId/wGrFfbU6UPgKz+BK9A4H/nhiyZFrsEo=; b=bKFzG68Pn5tRvVubYmA3Eb00UmTsG1Rhqy72NqrzNEyYhQg+AgFzt7mSuEfx3133ktntys sedWErcD0aiRyV6ONCN3DWOYQrxHealNfV9P/4SPojUn41iZL+2i8T04MM8ZuMxMxxOBuK 4T7iUAi/fn1J7Qy1WqhaSvcxJgu+/dys5NLpuCAbrBfd3mEWfMSHrq1tNkr3XWGo3P4Cso 4JRIZ82bXSNoPdgFqkYbbO0v5LUkKfh4gp1yY0UScp95ovv5n9qDN5WuxZjVPY4GQpidNe dXDZD9XqLVx1Tyob655cFjiW6nBPliorKgZ4xZGJ3RO0VZo5wSDGmAYsQ5mpnQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1626257949; a=rsa-sha256; cv=none; b=kdRmw9/ObJGT5Pd0qFqp9zBEPMUYfaZzlqlMV2VSupR1sdCHypiKqUOWXH7Q0h1l8k2sca 16WhT9ndilQZZqY2evGaVP0JK4geH3U61g90vptZ4/VcWjlhHwtsiaqdkrYPxmoCyOqZyA BEnRajfbaAwgzUBelx6KL4lTGSz6m3ItL0BcHNPT4b5s6iRS8Kx06iErDMmjJP++t7Pwgn BZZNs9cZZ4Fvs5VvT9geJsYoE31YgtKCf+fOL4AavJivUIwbLtcKT0wRm+tuFWwiUe2Fyo H/EHSjT2WQICNW8DC9Hkx/V+P0IeRI/ivfbASZZ8y58iTyPTPh0tRK5dpRn9tg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=g2ReItaz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Migadu-Spam-Score: -3.10 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=g2ReItaz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Migadu-Queue-Id: E0E531461E X-Spam-Score: -3.10 X-Migadu-Scanner: scn0.migadu.com X-TUID: myiPt0PiUBu1 Dear Chris, Thanks for the suggestion. I have previously tested that fetching from private channel works (after a workaround of use a PEM format of SSH key, due to a bug in libssh2). And I have just tested Luis's suggested workaround and can confirm that it works. Although the private channel will be kept only without our organization, I think the security team will frown if there are passwords in the package definitions committed to the repo. So I think meanwhile I will use the workaround suggested by Luis. Regards, Peter Lo On Wed, Jul 14, 2021 at 5:18 PM Chris Marusich wrote: > > Hi Peter, > > Lo Peter writes: > > > Is it that git-fetch does not support fetching over SSH? > > As Luis mentioned, for a package, if you use "git-checkout" as the > origin and provide a Git SSH URL, it will work. I'm not sure if an > equivalent exists for other transmission methods, but I doubt it (e.g., > using Mercurial over SSH to check out a Mercurial repository, or using > SFTP to fetch a release tarball over the SSH File Transfer Protocol). > For channels, it will work if you just provide a Git SSH URL in your > channels.scm file. I tested this just now on my own machines, and it > definitely works. > > However, since Guix uses libgit2 under the hood, rather than invoking > the "ssh" command, as you noticed there may be subtle differences > between how a vanilla "ssh" command works vs. how Guix will handle the > SSH connection. In any case, running an SSH agent might prove useful. > In both the case of fetching a package via git-checkout and fetching a > channel, Guix will attempt to fetch the repository "outside" the build > environment, so if you are running an agent, it will try to use it. I'm > not sure if Guix will honor your SSH config, though. > > If you are not wedded to SSH, then another option that may be better for > reproducibility is to use HTTPS with the user and password encoded in > the URL. This is nice because it doesn't require a user to to configure > SSH correctly on their local machine or provision an authorized SSH key > just to fetch the channel or the packages. In some situations, > embedding a user name and password in the URL in the package definition > may be sufficient, but in other situations, it may not meet your > security requirements (the URLs will wind up in the store and thus be > visible to anyone else logged into the system); it's up to you to decide > what's appropriate for your situation. > > Leo Prikler writes: > > > Yes, git-fetch does not support fetching over SSH. "Cannot run ssh" is > > the error returned because the ssh program is missing at fetch time, > > but even if it existed, you'd get a different error, namely one of > > lacking keys. You'd have to set up Guix to authenticate itself as you > > for pulling the source and while that is in theory possible, there is a > > potential security risk attached to most ways of solving it and no > > clear path forward. > > > > Furthermore, such a feature, were it integrated in Guix, is likely only > > to be used for nonfree software and thus located closely to such > > software itself. > > It sounds like you're suggesting that Guix should avoid making it easy > to integrate with existing access control mechanisms because access > control is only useful for non-free software. I disagree with that. > Access control is useful, and it is often necessary for security or > compliance reasons, even in the world of free software. > > The issue of controlling access to a particular repository of software > is orthogonal to the question of whether that software is free software. > It is common for someone to want to maintain a local copy of free > software and also to control access to that copy. In many > organizations, it is a hard requirement that all software is securely > stored and can only be accessed by authorized entities. This is true > regardless of whether the software is free software. It is also easy to > imagine that some people or organizations might prefer or be required to > develop all software, even free software, privately within their own > secure network. If Guix makes it difficult for developers to use it in > an environment where access control is required, Guix is less likely to > be used in those environments, and I think that would be a missed > opportunity. > > I don't think it helps the free software movement to encourage the idea > that access control is somehow antithetical to free software. It isn't. > Even the FSF controls access to its software repositories via SSH. > Savannah's projects may be available anonymously via FTP or other means, > but the SSH URLs are only usable if you're an FSF associate member. > Similarly, great free software like Kallithea exists, which is a tool > for hosting source code repositories, restricting access to them, and > making it easy to collaborate with others. There are many, many free > software projects that integrate well with access control systems, and > it does not mean they are somehow not good members of the free software > community. > > In short, the need for access control is not unusual, and it does not go > against the spirit of free software. It should be easy to use Guix in > environments where access control is required. I'm glad that channels > and packages can be used over SSH and that we have a variety of options > besides SSH for controlling access, too. However, SSH is a very common > way to control access these days, and I think there are opportunities to > improve that support in Guix. > > >> I would like to prompt the use of Guix for per-project management in > >> my small team of data scientists, so we would need a private channel > >> for a few internal R packages. The above problem is a real blocker. > >> Any help is greatly appreciated. > > I don't think this has to necessarily be a blocker. You can point git- > > fetch to file:// URIs, so your channel could have file:///path/to/repo > > and it'd work under the assumption that your scientists run git pull on > > those repos frequently enough (you could automate that with a script, > > perhaps even one written in Guile/a handwritten Guix extension). If > > you have company/university intranet, you could also expose those > > internal package over that on a well-known address, that's not > > reachable from outside. > > These solutions can work, but because they require extra steps to > implement, they are probably less attractive than using Git over SSH. > > -- > Chris