On 10/28/2016 09:17 AM, Marek Marczykowski-Górecki wrote: > On Fri, Oct 28, 2016 at 04:56:36AM +0000, Manuel Amador (Rudd-O) wrote: > > On 10/27/2016 01:13 PM, Marek Marczykowski-Górecki wrote: > >> On Thu, Oct 27, 2016 at 11:47:04AM +0000, Manuel Amador (Rudd-O) wrote: > >>> It gives me great pleasure to announce the inter-VM Git bridge for > Qubes > >>> OS, which allows you to git push and git pull from VMs stored in other > >>> repos, with no networking involved whatsoever, and observing full > >>> compliance with Qubes OS qrexec policy. > >> > >>> This should usher in a new era of software development that allows > >>> people to segregate their secure Git repos from insecure build VMs and > >>> other engineering constructs I can't even think of (after doing > >>> low-level socket programming for a week, which has left my brain > utterly > >>> fried). > >> > >> Hmm, have you seen this? > >> > https://www.qubes-os.org/doc/development-workflow/#git-connection-between-vms > >> > > > I had. That inspired me to package up the solution in a nice-to-use and > > easy-to-install way, that is more general and is not limited to Qubes OS > > development. As you know, instructions are cool, but ready-to-go > > software is cooler. I quite like that my solution actually has a > > distinct protocol qubes:/// too. > > I think it should be possible without manually copying the data back and > forth, too. In other words: connect git directly to stdin/out and wait > it for finish, then handle next command (if any). The amount of code > scares me - over 10x more over something that works just fine...
I appreciate your security instincts. I tried that first, but, you see, there was a huge problem. I explain: When the slave spawns / execs git-blah-borg-flurb, and that thing happens to die (say, because the remote repo directory does not exist), then the master (git-remote-qubes invoked by git itself) hangs. Why? Well, I don't ******* know, but I spent literally four days battling with that, until I decided that the sensible thing to do would be to just copy the data back and forth. Now, something must have changed lately, because now if I make the slave execvp() the git receive pack program, it works fine. So I suppose the problem was all along in the master. Thus, I have changed the slave to execvp(). This reduces the amount of code being executed to a minimum. Master (src/gitremotequbes/client.py) still needs to copy to and from the VM, because the connection to the slave is spawned *before* beginning to process what Git wants us to do. It would be the only way in which I could (for later iterations of the program) detect whether Git wants to push or to pull. > > One possible problem is that it gives access to all the repositories > (there is an info about that in doc). It may not always be desired > effect. The instruction above have a place to limit the access, I see > two easy ways how to do it in your solution: > > 1. Add some configuration in target VM - like > .config/qubes-git/allow-from-MY_SOURCE_VM_NAME and put allowed paths > there. > > 2. Use qrexec service argument[1]. This way it can be specified in > policy (and > single "yes" on ask would allow only specific repository access). Using > the same way you could also add access level: pull/push only. > > The second one is surely more flexible and more user friendly (no new > config, the same confirmation, etc). But probably require few more > changes. Also note that service argument cannot contain "/", so you'll > need to encode the path somehow. And also service name + argument is > limited to 64 characters, but this shouldn't be a big problem in > practice. > > [1] https://www.qubes-os.org/doc/qrexec3/#service-argument-in-policy > Honestly, UNIX permissions should suffice for that purpose. A VM that wants access to pull but not push can contact the Git server using a user that is not the "user" user, and then the files will appear read-only to that VM. Or even completely barred, if the repo in question is mode 0700 owned by user:user. BUT, I can add the argument thing. That is not hard to do. Edit: BIG FAT PROBLEM: if I say "yes to all" when there is an argument (it's already in the code I just pushed to Github) then nothing actually gets saved as "yes to all" anywhere. In other words: there's a bug as "Yes to all" does nothing when an argument is specified. Please fix!!! -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/6d2c214d-dbdc-187a-1294-40b445869801%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
