-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Oct 28, 2016 at 10:27:20AM +0000, Manuel Amador (Rudd-O) wrote:
> 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.
Much better :)
I think now setting stdin/stdout to non-blocking mode is not needed
anymore (if git want that, it should do it itself).
> 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.
I see. The server part is much more critical, so it's ok to have as it
is now. Actually my solution also pass the data manually on the client side
- - but it uses "cat" for this:
(echo $GIT_EXT_SERVICE $2 $3; exec cat) | qrexec-client-vm $VMNAME
local.Git
;)
> > 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!!!
Thanks for the report
https://github.com/QubesOS/qubes-issues/issues/2403
Fix on the way.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYEzQuAAoJENuP0xzK19csLHsH/jGSFZ3mm2EjjjFynleijA5c
w1oWbW0EMPhZdV15rgrf0kryPzlWDeS8rk6bl/gx37J3lgP80MuqAMBgQOWsAJl+
IkgfBVXsLXNKs0aGcO+QywUaWmZbwQbvEOZ5BBp0pHjEAf6fYlaAyT47nLqDslOs
Xv72+PIJKDEi4FzqCUgp5/MBB9+PbgCU1dGuEpEsG6SFobWL9KVEPUlz7ukkBaZx
S2NBrAY8Ec0omef47oNQjbPUOP/GuoqLlVpN6PjLC/2R1xcSZVR/FNgJ2TAsQ7Kk
P7ubfZOCPyvGZn+MuEmRyOtvAWxyMm4xPdwjdhNm0yRIif/p78rLMQBSyYplfpU=
=dQdE
-----END PGP SIGNATURE-----
--
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/20161028111910.GK7073%40mail-itl.
For more options, visit https://groups.google.com/d/optout.
