[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: SSH in git-fetch
Re: Fwd: SSH in git-fetch
Wed, 14 Jul 2021 18:12:50 +0800
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.
On Wed, Jul 14, 2021 at 5:18 PM Chris Marusich <firstname.lastname@example.org> wrote:
> Hi Peter,
> Lo Peter <email@example.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 <firstname.lastname@example.org> 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
> 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
> 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.