openSUSE has issued an advisory on January 18: https://lists.opensuse.org/opensuse-updates/2019-01/msg00062.html The issue is fixed upstream in 3.6.11. Mageia 6 is also affected.
Whiteboard: (none) => MGA6TOOCC: (none) => bruno
gitolite-3.6.11-1.mga7 uploaded for Cauldron by Shlomi.
Version: Cauldron => 6Whiteboard: MGA6TOO => (none)
I submitted it to 6/updates-testing: http://pkgsubmit.mageia.org/
Advisory: ======================== Updated gitolite package fixes security vulnerability: In commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync, mishandles the rsync command line, which allows attackers to have a "bad" impact by triggering use of an option other than -v, -n, -q, or -P (CVE-2018-20683). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20683 https://lists.opensuse.org/opensuse-updates/2019-01/msg00062.html ======================== Updated packages in core/updates_testing: ======================== gitolite-3.6.11-1.mga6 from gitolite-3.6.11-1.mga6.src.rpm
Assignee: shlomif => qa-bugsCC: (none) => shlomif
MGA6-32 MATE on IBM Thinkpad R50e No installation issues at first. Ref to bug23680 Comment 5 for tests At CLI: $ ssh-keygen -t rsa -f gitolitekey Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in gitolitekey. Your public key has been saved in gitolitekey.pub. etc ..... $ gitolite setup -pk gitolitekey.pub sh: git: opdracht niet gevonden i.e. command not found This is a recently setup M6 installation with mostly only the default packages, so understandibly (in hindsight) git was not installed. Went back to MCC and installed git plus its dependencies. Back to CLI: $ gitolite setup -pk gitolitekey.pub fatal: Not a git repository (or any of the parent directories): .git Indeed. there is no .git folder in my home. In other words: installing gitolite does not draw in git as a dependecy, and it does not get started if git on its own has not been used before on this machine. Right????
CC: (none) => herman.viaene
Tried to get any further: $ git init Initialized empty Git repository in /home/tester6/.git/ $ gitolite setup -pk gitolitekey.pub FATAL: could not symlink /home/tester6/.gitolite/hooks/common/update to gitolite-admin.git/hooks at /usr/share/gitolite/lib/Gitolite/Conf/Store.pm line 374.
I was going to look at this, and had found your very good test routine. Do you know whether you had GIT already installed for that? I do have it (but never knowingly used). Given that you are well started on this, I do not want simply to repeat the problems. Give a shout if I might help. FWIW "Gitolite allows you to setup git hosting on a central server, with fine-grained access control and many more powerful features." http://sitaramc.github.com/gitolite/ http://gitolite.com/gitolite/fool_proof_setup Among its 'assumptions': - You have a workstation. - You have a server called server. Hmm.
CC: (none) => lewyssmith
On testing bug 23680 I had git alreday installed before, most probably due to other update tests before. Since then I wiped M6 completely from the laptop and reinstalled it with just the default, only selection MATE as only desktop. What you found from gitolite makes me think that one needs to setup a (be it empty) server before trying to use gitolite. No promises, but I hope I can give it a try today.
Found a hint to create an empty git repos by $ git init --bare then added and committed a text file, but the result on the gitolite setup command remained the same. By guessing I found out that by installing gotolite also a group gitolite had been created, so made my user member of this group, logged out and in again, but that made no difference.
Not intending to take this very far - just trying out the tutorial without running the update to see what happens. Created a user called frodo with no home files $ cp ~/.ssh/id_rsa.pub /tmp/frodo $ su # su - git # git clone https://github.com/sitaramc/gitolite # cd $HOME # mkdir -p bin # gitolite/install -to $HOME/bin # bin/gitolite setup -pk /tmp/frodo.pub Back in user home: $ git ls-remote git@difda:gitolite-admin <some ssh warnings> 6d7d11ae017c364123b2b10886434d62f08000ff HEAD 6d7d11ae017c364123b2b10886434d62f08000ff refs/heads/master $ su - git # git clone git@difda:gitolite-admin [...] remote: Counting objects: 6, done. remote: Compressing objects: 100% (4/4), done. remote: Total 6 (delta 0), reused 0 (delta 0) Receiving objects: 100% (6/6), done. # ls -A gitolite-admin conf/ .git/ keydir/ # cd gitolite-admin # ls -A conf keydir .git conf: gitolite.conf .git: branches/ description hooks/ info/ objects/ refs/ config HEAD index logs/ packed-refs keydir: frodo.pub # cat conf/gitolite.conf repo gitolite-admin RW+ = frodo repo testing RW+ = @all <Really got lost at this point> # git add conf; git commit -m 'new repo foo'; git push *** Please tell me who you are. ............ <exit>
CC: (none) => tarazed25
@Len I see you run the gitolite setup as root, pointing to the key of your normal user. Did you get that from the tutorial. I failed this (I guess now), because I run this command as the normal user, as it worked for me in the older release. Could you cheeck that??
@Herman: Yes, I followed the tutorial slavishly. It is badly written in the sense that the author does not distinguish clearly enough which are user commands and which root. The convention is to use '$ command' for the user and '# command' for superuser. I was very confused about users anyway in that tutorial nor is it apparent to me what purpose gitolite serves. I do understand why the git commit/push commands failed. There is nothing in the tutorial about how to tell github who is calling. There is an implicit understanding that gitolite users will already be completely familiar with git. Trying to learn the two in parallel is a bit of a nonsense.
Looking at comment 6, what does "git hosting on a central server" actually mean?
Re comment 12: Thinking about it, the nearest I can get is "spinning your own independent github".
About Comment 12: my understanding is that git can be completely installed (executables and data) on a server, whether this one is in the same LAN or remote w.r.t the workstations. And to Comment 13: that's my understanding as well. I cann't imagine myself having a real client/server configuration available for QA testing. It would get too complicated.
Regarding CVE-2018-20683, logged in to user git: $ su # su git # cd $HOME # grep -i rsync .gitolite.rc # According to https://github.com/sitaramc/gitolite/commit/5df2b817255ee919991da6c310239e08c8fcc1ae this means that we are not affected by the security issue. Any line enabling rsync needs to be commented out. This is before the update by the way.
Rereading the tutorial page for the nth time I noticed the suggestion about reading the concepts page. That does very little to enhance one's understanding. It mentions something called a "hook" without any clear explanation but, taking a wild guess, is that what redirects the git command to the local host instead of sending it out on the internet? If so how is it set up? How do we ensure that it is invoked? These pages also indicate that one should be completely familiar with git terminology and operations, so see you in six weeks time. :-;
From whatis.com: In programming, a hook is a place and usually an interface provided in packaged code that allows a programmer to insert customized programming. For example, a programmer might want to provide code that analyzed how often a particular logic path was taken within a program.
@Len: you have pushed this far. Ignore the hook business. If the update goes OK and the system 'works' as before, OK! I am unsure about Herman not getting it to work now, when it used to. I am willing to add something if I can, already having GIT installed at least. But we should be careful about trying too much on this. From your toils (both), can you say whether this should work on the same machine? I was not sure from looking at the comments, old & new; nor not always what user you were doing things from. Did you both follow: https://bugs.mageia.org/show_bug.cgi?id=23680#c5. and which 'tutorial' is referred to, the original: http://www.bigfastblog.com/gitolite-installation-step-by-step or the other: http://gitolite.com/gitolite/fool_proof_setup From your experience, do you have to set up SSH access to root as stated somewhere? TIA
@Lewis I did not know about 23680. Followed the tutorial at http://gitolite.com/gitolite/fool_proof_setup I could have tried this on two machines but since many people are not in this position have tried to implement it on one machine. It should work. I am still trying to get my head round this user Ron business - frodo in my case. I suspect that that is a red herring. Your last question; don't know nuffink about that guv. If it is the case then I have not done it.
Have had a quick look at the step-by-step tutorial and decided to scrap everything on this machine and set up gitolite on another machine, but not tonight. There is a bug in a production program of mine which needs to be fixed so I shall be incommunicado for a day or two, possibly.
Moving to another machine was not very successful. Tried the step-by-step instructions and hit many snags. The tutorial is for Ubuntu who seem to have different versions of system commands like useradd. Gave up on that and returned to difda. Reestablished the git server id as gitter. Followed the "fool-proof" utorial as far as $ git clone gitter@difda:gitolite-admin $ git ls-remote gitter@difda:gitolite-admin Warning: Permanently added 'difda,192.168.1.103' (ECDSA) to the list of known hosts. X11 forwarding request failed on channel 0 81f2ce4a37bf437370ed2ba6b962aed5511370e4 HEAD 81f2ce4a37bf437370ed2ba6b962aed5511370e4 refs/heads/master gitolite-admin ended up in the user directory. At no time have I seen any reference to generating a keypair for root. su is needed for access to the server directory but otherwise does not seem to be involved. The git commands are run as the user. Back on the server: $ cat .ssh/authorized_keys # gitolite start command="/home/gitter/bin/gitolite-shell lcl",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa .......... ........ lcl@difda # gitolite end The "no-agent-forwarding" looks a bit worrisome. Needs an expert's opinion. Harking back to hooks, this file might be the way they are implemented. Anyway it has every appearance of being crucial to the whole thing.
Flogging M6/64 on a single box. 1. Installed gitolite-3.6.10-1.mga6 2. From my *normal* user, created an SSH key: [lewis@localhost ~]$ ssh-keygen and both lost the O/P to record, and unwisely accepted its choice of key file /home/lewis/.ssh/id_rsa.pub which presumably overwrote what was there before... 3. Created a new user 'gituser' (from MCC, but useradd would have been fine). 4. Found then followed /usr/share/doc/gitolite/gitolite-README-fedora 5. copy your admin user's ssh public key to /tmp/gituser.pub [lewis@localhost ~]$ cp .ssh/id_rsa.pub /tmp/gituser.pub Not knowing what key it is talking about, however. 6. run "su - gitolite" to get a login shell on the gitolite user [lewis@localhost ~]$ su - gituser Password: 7. run "cp /tmp/gituser.pub ." [gituser@localhost ~]$ cp /tmp/gituser.pub . 8. run "gitolite setup -pk ~/gituser.pub" [gituser@localhost ~]$ gitolite setup -pk ~/gituser.pub Initialized empty Git repository in /home/gituser/repositories/gitolite-admin.git/ Initialized empty Git repository in /home/gituser/repositories/testing.git/ This user ends up with a directory tree called repositories and containing gitolite-admin.git & testing.git among a great deal more. [Up to here, like https://bugs.mageia.org/show_bug.cgi?id=23680#c5] 9. all done, exit the gitolite user shelll [gituser@localhost ~]$ exit *not* Ctrl/D logout 10. From the 'fool-proof' guide, as normal user, tried: [lewis@localhost ~]$ git ls-remote gituser@localhost:gitolite-admin /home/lewis/.ssh/config line 6: Unsupported option "compressionlevel" @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:ybBavdLlWQmDeX210GGJqkzSTF6o77n8gSErfS6TVKw. Please contact your system administrator. Add correct host key in /home/lewis/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/lewis/.ssh/known_hosts:2 Password authentication is disabled to avoid man-in-the-middle attacks. Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks. Agent forwarding is disabled to avoid man-in-the-middle attacks. X11 forwarding is disabled to avoid man-in-the-middle attacks. 3f7c2946deabec0b7976857d273ea5e75090768d HEAD 3f7c2946deabec0b7976857d273ea5e75090768d refs/heads/master and if nothing else, the last two lines are right! Clearly I have messed my SSH keys. [lewis@localhost ~]$ git clone gituser@localhost:gitolite-admin Cloning into 'gitolite-admin'... /home/lewis/.ssh/config line 6: Unsupported option "compressionlevel" [same error O/P as above] remote: Counting objects: 6, done. remote: Compressing objects: 100% (4/4), done. remote: Total 6 (delta 0), reused 0 (delta 0) Receiving objects: 100% (6/6), done. which looks OK: [lewis@localhost ~]$ tree gitolite-admin/ gitolite-admin/ ├── conf │ └── gitolite.conf └── keydir └── gituser.pub Back to Herman's earlier test URL above: [lewis@localhost ~]$ su - gituser Password: [gituser@localhost ~]$ gitolite list-users @all gituser [gituser@localhost ~]$ gitolite list-repos gitolite-admin testing [gituser@localhost ~]$ gitolite query-rc -a ACCESS_1=ARRAY(0x1d4b9e0) COMMAND=ARRAY(0x205c638) COMMANDS=HASH(0x203c4d0) ENABLE=ARRAY(0x1d4bcb0) GIT_CONFIG_KEYS= GL_ADMIN_BASE=/home/gituser/.gitolite GL_BINDIR=/usr/share/gitolite GL_LIBDIR=/usr/share/gitolite/lib GL_LOGFILE=/home/gituser/.gitolite/logs/gitolite-2019-01.log GL_REPO_BASE=/home/gituser/repositories GL_TID=4101 LOG_EXTRA=1 LOG_TEMPLATE=/home/gituser/.gitolite/logs/gitolite-%y-%m.log POST_COMPILE=ARRAY(0x205c578) POST_CREATE=ARRAY(0x205c5c0) ROLES=HASH(0x1d4ba58) UMASK=63 which is what Herman got then. ================================================================= AFTER update: gitolite-3.6.11-1.mga6.noarch [Note the noarch] All the commands (valid or not) behaved the same as before: [lewis@localhost ~]$ git ls-remote gituser@localhost:gitolite-admin [lewis@localhost ~]$ git clone gituser@localhost:gitolite-admin [gituser@localhost ~]$ gitolite list-users [gituser@localhost ~]$ gitolite list-repos [gituser@localhost ~]$ gitolite query-rc -a We have spent overtime on this. OK, validating, advisory comment 3.
Keywords: (none) => advisory, validated_updateWhiteboard: (none) => MGA6-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0058.html
Status: NEW => RESOLVEDResolution: (none) => FIXED