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 <[email protected]> wrote: > > Hi Peter, > > Lo Peter <[email protected]> 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 <[email protected]> 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
