unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Thompson, David" <dthompson2@worcester.edu>
To: Efraim Flashner <efraim@flashner.co.il>,
	"Thompson, David" <dthompson2@worcester.edu>,
	zimoun <zimon.toutoune@gmail.com>,
	25957@debbugs.gnu.org
Subject: bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks
Date: Fri, 2 Sep 2022 15:58:09 -0400	[thread overview]
Message-ID: <CAJ=RwfbPsTMdVPtUc0QeiPqYq3sFQPhGGvL+p2W7Dc0cicqf9w@mail.gmail.com> (raw)
In-Reply-To: <CAJ=RwfZKbTS5VAAorC8G4OVo=Rvs6PazqD1yTxOJ5-vWCc=Zcw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4148 bytes --]

On Fri, Sep 2, 2022 at 8:50 AM Thompson, David <dthompson2@worcester.edu> wrote:
>
> On Fri, Sep 2, 2022 at 8:44 AM Efraim Flashner <efraim@flashner.co.il> wrote:
> >
> > On Fri, Sep 02, 2022 at 07:11:54AM -0400, Thompson, David wrote:
> > > On Fri, Sep 2, 2022 at 3:00 AM Efraim Flashner <efraim@flashner.co.il> wrote:
> > > >
> > > > I took a look at the gitolite service finally and I hadn't realized
> > > > there wasn't a running daemon to containerize. I assumed we could do
> > > > something like:
> > > >
> > > > (start $~(make-forkexec-constructor/container
> > > >             (list ...)
> > > >             #:environment-variables
> > > >             '("PATH=...")
> > > >             #:mappings ...))
> > > >
> > > > Given that's not the case then I'd need to look at gitolite itself to
> > > > see how it calls the other binaries it expects to be available, and if
> > > > wrapping it would be enough or if we would need to just propagate the
> > > > other packages for functionality.
> > >
> > > Gitolite simply expects tools like git to be on $PATH.  It's a pretty
> > > naive system, there's nothing like a configure script that is
> > > determining the absolute file name of these tools and substituting
> > > those names into the built files.
> > >
> > > The executable is already wrapped so that coreutils, findutils, and
> > > git are on $PATH, but notably not openssh:
> > >
> > > (add-after 'install 'wrap-scripts
> > >                     (lambda* (#:key inputs outputs #:allow-other-keys)
> > >                       (let ((out (assoc-ref outputs "out"))
> > >                             (coreutils (assoc-ref inputs "coreutils"))
> > >                             (findutils (assoc-ref inputs "findutils"))
> > >                             (git (assoc-ref inputs "git")))
> > >                         (wrap-program (string-append out "/bin/gitolite")
> > >                           `("PATH" ":" prefix
> > >                             ,(map (lambda (dir)
> > >                                     (string-append dir "/bin"))
> > >                                   (list out coreutils findutils git)))))))
> > >
> > > However, git and openssh are still propagated inputs. I'm going to
> > > move the propagated inputs to regular inputs, potentially add openssh
> > > to the wrapper once I remind myself what gitolite does with those
> > > tools, and test it all out on my server using the gitolite service.
> > > If that all works, we have a good starting point for adding extension
> > > support in the service.
> >
> > I like it. Let us know how it goes.
>
> The problem is that gitolite generates git hooks for the repositories
> that it manages, and those hooks invoke git, so the only way those
> scripts will be able to work (without input propagation) is to find a
> way to inject the proper PATH or find a way to replace references to
> things like 'git diff' with '/gnu/store/.../git diff'.  I'm going to
> keep exploring and report back when I have something to show.

After several rounds of experimentation and breaking my git server a
few times, here's what I've found:

* Changing git and openssh to be regular inputs and wrapping both
gitolite and gitolite-shell with a $PATH that contains git works and
it's very little extra code.

* Trying to replace every invocation of a git command took a lot of
grepping and crafting of regexps to use for substitute* and I never
got to a point where the result wasn't buggy.  In particular,
gitolite-shell never worked properly so I couldn't push to my repos.

So, I think the simple wrapper approach is the way to go.  Patch
attached.  I tested on my git server by making changes to my gitolite
configuration and pushing those changes to the special gitolite-admin
repo.  This causes gitolite to refresh internal configuration using a
git hook, so I know that hooks can find the executables they need.
That plus the 'gitolite setup' invocation made by the service
activation script covers a fair amount of surface area, so I feel
comfortable committing it.  What do you think?

Once this part is done, I'll turn my attention to the optional extensions.

- Dave

[-- Attachment #2: 0001-gnu-gitolite-Wrap-programs-instead-of-using-propagat.patch --]
[-- Type: text/x-patch, Size: 2261 bytes --]

From 413f2d28aa8bea2274b74c2b574fb9f8bf9c16ba Mon Sep 17 00:00:00 2001
From: David Thompson <dthompson2@worcester.edu>
Date: Fri, 2 Sep 2022 14:33:01 -0400
Subject: [PATCH] gnu: gitolite: Wrap programs instead of using propagated
 inputs.

* gnu/packages/version-control.scm (gitolite)[arguments]: Add git to wrapped
$PATH and additionally wrap gitolite-shell.
[inputs]: Add git and openssh.
[propagated-inputs]: Remove it.
---
 gnu/packages/version-control.scm | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 15a9278fe8..1c775932c0 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -1573,17 +1573,15 @@ (define-public gitolite
                             (coreutils (assoc-ref inputs "coreutils"))
                             (findutils (assoc-ref inputs "findutils"))
                             (git (assoc-ref inputs "git")))
-                        (wrap-program (string-append out "/bin/gitolite")
-                          `("PATH" ":" prefix
-                            ,(map (lambda (dir)
-                                    (string-append dir "/bin"))
-                                  (list out coreutils findutils git))))))))))
+                        (for-each (lambda (file-name)
+                                    (wrap-program (string-append out file-name)
+                                      `("PATH" ":" prefix
+                                        ,(map (lambda (dir)
+                                                (string-append dir "/bin"))
+                                              (list out coreutils findutils git)))))
+                                  '("/bin/gitolite" "/bin/gitolite-shell"))))))))
     (inputs
-     (list bash-minimal perl coreutils findutils inetutils))
-    ;; git and openssh are propagated because trying to patch the source via
-    ;; regexp matching is too brittle and prone to false positives.
-    (propagated-inputs
-     (list git openssh))
+     (list bash-minimal git perl coreutils findutils inetutils openssh))
     (home-page "https://gitolite.com")
     (synopsis "Git access control layer")
     (description
-- 
2.37.2


  reply	other threads:[~2022-09-02 19:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03 21:58 bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks ng0
     [not found] ` <handler.25957.B.14885741929377.ack@debbugs.gnu.org>
2017-03-03 22:27   ` bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks) ng0
2017-03-04 13:32     ` ng0
2017-03-04 15:43       ` Danny Milosavljevic
2017-03-04 17:33         ` ng0
2022-01-05  0:07       ` bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks zimoun
2022-01-12 18:07         ` Efraim Flashner
2022-02-03  2:49           ` zimoun
2022-03-23 10:45             ` zimoun
2022-03-23 12:44               ` Maxime Devos
2022-03-28  6:49                 ` Efraim Flashner
2022-09-01 13:59                   ` bug#25957: [EXT] " Thompson, David
2022-09-01 14:20                     ` Efraim Flashner
2022-09-01 14:41                       ` bug#25957: [EXT] " Thompson, David
2022-09-01 17:00                         ` zimoun
2022-09-02  6:56                         ` Efraim Flashner
2022-09-02 11:11                           ` Thompson, David
2022-09-02 12:41                             ` Efraim Flashner
2022-09-02 12:50                               ` bug#25957: [EXT] " Thompson, David
2022-09-02 19:58                                 ` Thompson, David [this message]
2022-09-04  7:26                                   ` Efraim Flashner
2022-09-04 13:26                                     ` Thompson, David
2022-09-05  8:16                                       ` zimoun
2022-09-06 13:50                                         ` Thompson, David
2022-10-06 13:26                                         ` Thompson, David
2022-10-06 13:42                                           ` Thompson, David
2022-10-08 14:56                                           ` zimoun
2022-10-09  1:40                                             ` Thompson, David
2022-10-24 21:21                                               ` Thompson, David
2022-10-25  9:58                                                 ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ=RwfbPsTMdVPtUc0QeiPqYq3sFQPhGGvL+p2W7Dc0cicqf9w@mail.gmail.com' \
    --to=dthompson2@worcester.edu \
    --cc=25957@debbugs.gnu.org \
    --cc=efraim@flashner.co.il \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).