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

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 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

On 06/16/2015 08:24 AM, Alan Jenkins wrote:

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.

You can do this via HTTPS, too. --> Bad argument. Manuel

Also may I remind you that the focus of this conversation is allowing users in corporate environments access to be able to contribute to the AUR. These environments block SSH for multiple reasons but are able to allow HTTPS as they are able to more tightly regulate it. We just need git/https and then there is no problem. Also as I didn't want to have to type it all up myself here is a link that explains how https is scanned: http://security.stackexchange.com/questions/8145/does-https-prevent-man-in-t... On 16 June 2015 at 17:42, Alan Jenkins wrote:

Actually they very often strip https traffic too. I used to work for Symantec.cloud and we did both http and https scanning so don't try to say that it is not a valid argument as I assure you you can scan and do content filtering on https.

On 16 June 2015 at 14:35, Manuel Reimer wrote:

...

On 06/16/2015 08:24 AM, Alan Jenkins wrote:

...

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.

You can do this via HTTPS, too.

--> Bad argument.

Manuel

Hey Giancario, Most of the large companies block everything and start from there, normally everything is blocked outbound and only things that are business critical are allowed until the business is able to function. In many cases they will block all outbound traffic and only allow access to the internet via ftp, http and the mitm style https via a proxy that is able to scan the content being sent across the connections to ensure they do not fall foul of a trojan or other malware. So unless I am missing something how are you going to tunnel out of a network if you only have port 21, 80 and 443 which are all really just going to the proxy server? If you do know a way I would love to hear it as I am interested, but as I stated in the previous email we are off topic. The problem is that no matter how hard you moan at the people in control of the firewalls they will normally not allow access to something unless *they* deem it to be secure, and once the person you are communicating with gets annoyed with you they will just send you to the next guy until you get annoyed and just give up (been there done that). Can we please stick to the feasibility of doing git+https? Github + Bitbucket are able to do it so surely we can too right? Or is there too much code relying on the SSH public key auth now? On 16 June 2015 at 20:30, Giancarlo Razzolini wrote:

Em 16-06-2015 14:20, Alan Jenkins escreveu:

...

Also may I remind you that the focus of this conversation is allowing users in corporate environments access to be able to contribute to the AUR. These environments block SSH for multiple reasons but are able to allow HTTPS as they are able to more tightly regulate it.

There are literally tons of ways to tunnel out of a network. SSH is just one of them. Instead of blocking anything, network admins should monitor the traffic using netflow, and set alarms when too much data is leaving the network. That would prevent a lot of data breaches. Or at least minimize their impact.

Expecting to block something to avoid information breach, or any other kind of data theft is dumb. Also, come on people. It's 2015. Doesn't everybody also have a machine at home?

Cheers, Giancarlo Razzolini

Em 16-06-2015 17:22, Alan Jenkins escreveu:

Most of the large companies block everything and start from there, normally everything is blocked outbound and only things that are business critical are allowed until the business is able to function. In many cases they will block all outbound traffic and only allow access to the internet via ftp, http and the mitm style https via a proxy that is able to scan the content being sent across the connections to ensure they do not fall foul of a trojan or other malware.

This is stupid, as I already pointed. Besides, unless the machines are rigged with a self signed CA on their browsers stores, you can't inspect anything without trowing a big warning to every https site the user visit. It certainly breaks a lot of mobile apps functionality.

So unless I am missing something how are you going to tunnel out of a network if you only have port 21, 80 and 443 which are all really just going to the proxy server? If you do know a way I would love to hear it as I am interested, but as I stated in the previous email we are off topic.

You can punch a hole using DNS requests, you can use https, you can use websockets, you can use a VPN, etc. As I said, there are a lot of options.

The problem is that no matter how hard you moan at the people in control of the firewalls they will normally not allow access to something unless *they* deem it to be secure, and once the person you are communicating with gets annoyed with you they will just send you to the next guy until you get annoyed and just give up (been there done that).

I'm not moanning at the people in control of the firewalls (heck, I'm one of them). I'm complaining with the OP requests and demands that AUR devs do something because he needs it.

Can we please stick to the feasibility of doing git+https? Github + Bitbucket are able to do it so surely we can too right? Or is there too much code relying on the SSH public key auth now?

Is it feasible? Of course it is. Just install sshlp in the machine, configure it, configure nginx and ssh, and you're done. But you can also implement a token auth system over https, like the one github have, so we could have git over https. I don't see the devs doing it also, but it would be better than to run sshlp on the machine. Again, you can always use another network for doing all this. A more open one. Cheers, Giancarlo Razzolini

On 06/16/2015 09:24 AM, Alan Jenkins wrote:

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 [...]

[...] I seriously dont believe that in 2015 security is port based...