GNU bug report logs - #31284
[PATCH 0/1] guix: Add git-fetch/impure.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31284 in the body.
You can then email your comments to 31284 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Chris Marusich <cmmarusich <at> gmail.com>
To: bug-guix <at> gnu.org
Cc: Chris Marusich <cmmarusich <at> gmail.com>
Subject: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Fri, 27 Apr 2018 01:12:17 -0700

Hi Guix!

Sometimes, a Git repository may only be available via an authenticated
SSH connection.  Even in the case of repositories that only contain
free software, this situation can arise for administrative or
compliance-related reasons.  How can one define a package in such a
situation?

This patch adds a new origin method, git-fetch/impure, which solves
that problem.  Specifically, git-fetch/impure creates a fixed-output
derivation that fetches the Git repository outside of a derivation, in
the environment of the invoking user.  In particular, this enables SSH
to communicate with the user's SSH agent, which in turn allows Git to
fetch the repository over an authenticated SSH connection.  In
addition, because it is a fixed-output derivation, the output of a
successful git-fetch/impure is guaranteed to be identical to the
output of a pure git-fetch for any given commit.

Here's a simple example:

(define-public guix-over-ssh
  (package
    (inherit guix)
    (name "guix-over-ssh")
    (source
     (origin
       (inherit (package-source guix))
       (method git-fetch/impure)
       (uri
        (git-reference
         (inherit (origin-uri (package-source guix)))
         (url "ssh://marusich <at> git.sv.gnu.org:/srv/git/guix.git")))))))

In this particular example, my username appears in the package
definition, but there is no reason why that has to be so.  In many
systems, it is possible to grant access to multiple users with
different SSH keys under a single shared user name.  And in other
systems, an automated build system might need to fetch sources using
its own unique system user name and SSH key.

All in all, I think this is pretty useful.  It enables developers to
define packages in environments where authenticated access to Git
repositories is required.  Please let me know what you think!

Chris Marusich (1):
  guix: Add git-fetch/impure.

 doc/guix.texi         |  24 +++++++
 guix/git-download.scm | 150 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 174 insertions(+)

-- 
2.17.0

Message #10 received at 31284-done <at> debbugs.gnu.org (full text, mbox):

From: Chris Marusich <cmmarusich <at> gmail.com>
To: 31284-done <at> debbugs.gnu.org
Subject: Re: Status: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Fri, 27 Apr 2018 01:19:21 -0700

[Message part 1 (text/plain, inline)]

Hi,

Please ignore this bug report.  I intended to submit it to
guix-patches <at> gnu.org, but I entered the wrong email address.

-- 
Chris

[signature.asc (application/pgp-signature, inline)]

Message #13 received at 31284 <at> debbugs.gnu.org (full text, mbox):

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: 31284 <at> debbugs.gnu.org
Subject: Re: bug#31284: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Fri, 27 Apr 2018 09:05:37 -0400

Hi Chris,

On Fri, Apr 27, 2018 at 4:12 AM, Chris Marusich <cmmarusich <at> gmail.com> wrote:
> Hi Guix!
>
> Sometimes, a Git repository may only be available via an authenticated
> SSH connection.  Even in the case of repositories that only contain
> free software, this situation can arise for administrative or
> compliance-related reasons.  How can one define a package in such a
> situation?
>
> This patch adds a new origin method, git-fetch/impure, which solves
> that problem.  Specifically, git-fetch/impure creates a fixed-output
> derivation that fetches the Git repository outside of a derivation, in
> the environment of the invoking user.  In particular, this enables SSH
> to communicate with the user's SSH agent, which in turn allows Git to
> fetch the repository over an authenticated SSH connection.  In
> addition, because it is a fixed-output derivation, the output of a
> successful git-fetch/impure is guaranteed to be identical to the
> output of a pure git-fetch for any given commit.

In general I'm opposed to including such things in Guix. When I
encountered a similar situation at work I opted to use https cloning
with a password token in the url. Then there was no external state
(like an rsa key) needed.

I understand the motivation behind asking for something like this, but
I don't think Guix proper should include it.

- Dave

Message #16 received at 31284 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: 31284 <at> debbugs.gnu.org
Subject: Re: bug#31284: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Fri, 27 Apr 2018 17:37:34 -0400

Hi Chris,

Chris Marusich <cmmarusich <at> gmail.com> writes:

> Sometimes, a Git repository may only be available via an authenticated
> SSH connection.  Even in the case of repositories that only contain
> free software, this situation can arise for administrative or
> compliance-related reasons.  How can one define a package in such a
> situation?
>
> This patch adds a new origin method, git-fetch/impure, which solves
> that problem.  Specifically, git-fetch/impure creates a fixed-output
> derivation that fetches the Git repository outside of a derivation, in
> the environment of the invoking user.  In particular, this enables SSH
> to communicate with the user's SSH agent, which in turn allows Git to
> fetch the repository over an authenticated SSH connection.

I agree with David that I'd prefer not to have something like this in
Guix.  However, I can offer another method that I've sometimes used to
build a package based on a git checkout that's not publicly available on
the network.

My hacky approach has been to manually add a tarball of the desired
sources using "guix download file:///home/mhw/foo.tar.gz" and then to
add a bogus origin but with the correct hash.  If a file with a matching
hash is already in the store, then it will be used, and the other fields
of the 'origin' will effectively be ignored.

      Mark

Message #19 received at 31284 <at> debbugs.gnu.org (full text, mbox):

From: Chris Marusich <cmmarusich <at> gmail.com>
To: "Thompson\, David" <dthompson2 <at> worcester.edu>
Cc: 31284 <at> debbugs.gnu.org
Subject: Re: bug#31284: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Fri, 27 Apr 2018 21:45:04 -0700

[Message part 1 (text/plain, inline)]

Hi David and Mark,

Thank you both for taking a look at this!

"Thompson, David" <dthompson2 <at> worcester.edu> writes:

> When I encountered a similar situation at work I opted to use https
> cloning with a password token in the url. Then there was no external
> state (like an rsa key) needed.

This is good to know!  I hadn't considered putting the secret into the
URL.  I can see how that might be a simple and appropriate solution in
some situations.  However, it would also be nice if Guix could fetch Git
repositories over SSH using public key authentication.  In some
situations, SSH public key authentication may be the only option.

Mark H Weaver <mhw <at> netris.org> writes:

> My hacky approach has been to manually add a tarball of the desired
> sources using "guix download file:///home/mhw/foo.tar.gz" and then to
> add a bogus origin but with the correct hash.  If a file with a matching
> hash is already in the store, then it will be used, and the other fields
> of the 'origin' will effectively be ignored.

That's a neat trick!  It looks like it would work well for ad-hoc
hacking.  But how does it scale?  Imagine if you wanted to do this for
10 packages, or 100.  The manual upkeep could become quite painful.  It
would be so much nicer if Guix could just download the source
automatically, as usual!

You've both said that you would prefer not to add git-fetch/impure to
Guix.  Can you help me to understand why you feel that way?  I really
think it would be nice if Guix could fetch Git repositories over SSH
using public key authentication, so I'm hoping that we can talk about it
and figure out an acceptable way to implement it.

-- 
Chris

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 31284 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: 31284 <at> debbugs.gnu.org, "Thompson, David" <dthompson2 <at> worcester.edu>
Subject: Re: bug#31284: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Sun, 29 Apr 2018 19:21:08 +0200

Hello,

Chris Marusich <cmmarusich <at> gmail.com> skribis:

> You've both said that you would prefer not to add git-fetch/impure to
> Guix.  Can you help me to understand why you feel that way?  I really
> think it would be nice if Guix could fetch Git repositories over SSH
> using public key authentication, so I'm hoping that we can talk about it
> and figure out an acceptable way to implement it.

One argument against it would be that it encourages people (or at least
makes it very easy) to write origins that depend on external state, and
thus may be non-reproducible by others, and that Guix itself should
provide tools for writing reproducible build definitions.

Ludo’.

Message #25 received at 31284 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: 31284 <at> debbugs.gnu.org, "Thompson, David" <dthompson2 <at> worcester.edu>
Subject: Re: bug#31284: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Sun, 29 Apr 2018 13:28:13 -0400

Hi Chris,

Chris Marusich <cmmarusich <at> gmail.com> writes:

> You've both said that you would prefer not to add git-fetch/impure to
> Guix.  Can you help me to understand why you feel that way?  I really
> think it would be nice if Guix could fetch Git repositories over SSH
> using public key authentication, so I'm hoping that we can talk about it
> and figure out an acceptable way to implement it.

I thought about it some more, and found that I cannot really justify my
position on this, so I hereby drop my objection.  It's obviously not
useful for packages that will be included in Guix itself, which is our
primary focus, but I suppose it could be useful for private package
definitions.

What do you think, David?  It seems to me that password tokens in URLs
raise possible security risks, whereas public-key authentication is
generally better practice.

       Mark

Message #28 received at 31284 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: 31284 <at> debbugs.gnu.org
Subject: Re: bug#31284: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Sun, 29 Apr 2018 13:39:43 -0400

Hi Chris,

I don't see your patch anywhere in <https://bugs.gnu.org/31284>.
Can you resend it?

I'm curious how you arrange for a build process launched by guix-daemon
to have access to your 'ssh-agent'.  Although I've dropped my objection
to this idea in principle, I have yet to review the technical details of
how this actually works.  It might be that the details will raise
further alarm bells in my head :)

      Mark

Message #31 received at 31284 <at> debbugs.gnu.org (full text, mbox):

From: Chris Marusich <cmmarusich <at> gmail.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 31284 <at> debbugs.gnu.org
Subject: Re: bug#31284: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Sun, 29 Apr 2018 17:18:58 -0700

[Message part 1 (text/plain, inline)]

Mark H Weaver <mhw <at> netris.org> writes:

> Hi Chris,
>
> I don't see your patch anywhere in <https://bugs.gnu.org/31284>.
> Can you resend it?
>
> I'm curious how you arrange for a build process launched by guix-daemon
> to have access to your 'ssh-agent'.  Although I've dropped my objection
> to this idea in principle, I have yet to review the technical details of
> how this actually works.  It might be that the details will raise
> further alarm bells in my head :)

The patch can be found here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31285

I accidentally sent the cover letter to bug-guix <at> gnu.org instead of
guix-patches <at> gnu.org, which is why this bogus bug report (31284) was
opened.  I've closed this bug report in favor of the "guix-patches" one.
Sorry for the confusion!

-- 
Chris

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 31284 <at> debbugs.gnu.org (full text, mbox):

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 31284 <at> debbugs.gnu.org, Chris Marusich <cmmarusich <at> gmail.com>
Subject: Re: bug#31284: [PATCH 0/1] guix: Add git-fetch/impure.
Date: Mon, 30 Apr 2018 09:59:04 -0400

On Sun, Apr 29, 2018 at 1:28 PM, Mark H Weaver <mhw <at> netris.org> wrote:
> Hi Chris,
>
> Chris Marusich <cmmarusich <at> gmail.com> writes:
>
>> You've both said that you would prefer not to add git-fetch/impure to
>> Guix.  Can you help me to understand why you feel that way?  I really
>> think it would be nice if Guix could fetch Git repositories over SSH
>> using public key authentication, so I'm hoping that we can talk about it
>> and figure out an acceptable way to implement it.
>
> I thought about it some more, and found that I cannot really justify my
> position on this, so I hereby drop my objection.  It's obviously not
> useful for packages that will be included in Guix itself, which is our
> primary focus, but I suppose it could be useful for private package
> definitions.
>
> What do you think, David?  It seems to me that password tokens in URLs
> raise possible security risks, whereas public-key authentication is
> generally better practice.

If I'm outvoted here then I'm OK with accepting this change. Just to
clarify, I advocate the use of password tokens in URLs for private
repositories only. I do this for non-Guix things as well in order to
improve reproducibility of internal builds.

- Dave

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.