Hi Peter,

Lo Peter <peterloleungyau@gmail.com> 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 <leo.prikler@student.tugraz.at> 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