> I am with the OP on this, having worked in a cloud security company I > understand why they block port 22 out bound and know it to be a common > problem. It is blocked to stop employees accidentally or intentionally > leaking important customer or business data. You can also use SSH to bypass > security measures in place within the network and even create tunnels back > into the network. > > Seriously I believe that there should be the option to do git over ssh as > the limitation to just SSH is going to cause problems for those in > corporate environments meaning we will lose out. > > On Tue, 16 Jun 2015 05:33 Eli Schwartz <eschwart...@gmail.com> wrote: > > It is not necessarily Arch's problem that a tiny minority of users have > > the > > standard connection methods blocked. While it would be nice if lots of > > options are offered for every possible scenario, that may not necessarily > > happen. > > Think of Github's alternative method as being a bonus, not something to be > > taken for granted. :) > > > > And the move to git repos may already be alienating some people. > > Regardless, progress and efficiency have been made a priority over > > preserving every last contributor. > > > > > > -- Eli Schwartz
Am Dienstag, 16. Juni 2015, 06:24:05 schrieb Alan Jenkins: > I am with the OP on this, having worked in a cloud security company I > understand why they block port 22 out bound and know it to be a common > problem. It is blocked to stop employees accidentally or intentionally > leaking important customer or business data. With that reasoning you have to block 80 and 443 too, but I don't think that the why is the really important point. I think that this is a reason more to implement an alternative of uploading a aur ball, as discussed in another thread, and creating a git commit from it. I don't know any implementation details, but this shouldn't be too hard as the useres are autheticated by the webserver already. Alex
signature.asc
Description: This is a digitally signed message part.