Re: [aur-general] Git over HTTPS
Instead of requiring others to solve your problem, you should explain to your network administrators that this rule is counterproductive. I don't really think that this will hinder adoption since port 22 is the default ssh port.
I'm not requiring that others solve my problem, Giancarlo. As mentioned, this is an impossibility in our organization, and (I'm sure) many others. There are many technical reasons for this limitation in our organization, too in-depth to discuss here. I've pointed out an issue which I'm sure currently will will continue to affect users, and here is my suggested solution: I'm stating that the latest update the the AUR, which seems to be `git-via-ssh-port-22-only` should expand the options for use. I'm suggesting that there should at least be some discussion about adopting a GitHub-style connections; wherein standard connections are via standard protocol; ssh on port 22, or (optionally, in the instances where it's not technically feasible) via an alternate method; ssh via port 443. While this exact solution does not need to be followed to the letter, I'm describing it here so that my point may be made. I can say with 100% certainty that my PKGBUILDS will not be updated without an alternate form of access that is not SSH via Port 22. It's infeasible to transport my PKGBUILDS off-site just so I can run some git commands on another network. I'd welcome any suggestions otherwise. Cheers, -- Thomas Swartz
Em 15-06-2015 22:20, Tom Swartz escreveu:
I'm not requiring that others solve my problem, Giancarlo. As mentioned, this is an impossibility in our organization, and (I'm sure) many others.
Not that many, I hope.
There are many technical reasons for this limitation in our organization, too in-depth to discuss here.
None of them are technical, but are misguided choices and preferences.
I've pointed out an issue which I'm sure currently will will continue to affect users, and here is my suggested solution: I'm stating that the latest update the the AUR, which seems to be `git-via-ssh-port-22-only` should expand the options for use.
It's not via ssh only. You have the option of clonning the repo over https. Of course it's read only, but you at least can see the contents of the repo.
I'm suggesting that there should at least be some discussion about adopting a GitHub-style connections; wherein standard connections are via standard protocol; ssh on port 22, or (optionally, in the instances where it's not technically feasible) via an alternate method; ssh via port 443. While this exact solution does not need to be followed to the letter, I'm describing it here so that my point may be made.
Strangely enough, github only allow this method of connection for their github.com repos, not the, aham, GitHub Enterprise repos. Guessing these poor companies have to allow ssh over port 22 because the evil github won't allow other ports.
I can say with 100% certainty that my PKGBUILDS will not be updated without an alternate form of access that is not SSH via Port 22. It's infeasible to transport my PKGBUILDS off-site just so I can run some git commands on another network. I'd welcome any suggestions otherwise.
A PKGBUILD of only a few Kb? You can't email it to yourself? Really, your arguments are getting more and more pointless. I'm really sorry for you that you can't access an unblocked internet. Cheers, Giancarlo Razzolini
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 <eschwartz93@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
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 <eschwartz93@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
* Alexander Görtz <aur@nyloc.de> (Tue, 16 Jun 2015 11:04:51 +0200):
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.
Lukas already explained in the second half of [1] why this is hardly an option. Best, Marcel [1]https://lists.archlinux.org/pipermail/aur-general/2015-June/030880.html
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
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 <manuel.reimer@gmx.de> 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
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 <alan.james.jenkins@gmail.com> 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 <manuel.reimer@gmx.de> 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
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
Em 16-06-2015 14:20, Alan Jenkins escreveu: 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
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 <grazzolini@gmail.com> 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
Asking for a response from the OP: Do you not have other network access available to maintain your AUR packages? More to the point, are you maintaining packages on AUR as part of your official responsibilities? Or just in spare time? Leaving aside, for the moment, all other arguments regarding blocking outbound SSH, I believe these are fundamental questions. On Tue, Jun 16, 2015 at 4:22 PM, Alan Jenkins <alan.james.jenkins@gmail.com> wrote:
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 <grazzolini@gmail.com> 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 Tue, Jun 16, 2015 at 08:11:59PM -0300, Giancarlo Razzolini wrote:
Em 16-06-2015 17:22, Alan Jenkins escreveu: [...]
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.
From my POV you are moaning because someone's asking for help to contribute to Arch! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Never be afraid to try something new. Remember, amateurs built the ark; professionals built the Titanic. -- Anonymous
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...
On Sat, Jun 20, 2015 at 09:12:06AM +0300, Mihamina Rakotomandimby wrote:
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...
Oh, you clearly have no clue about the extent of the madness of it all :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus The definition of insanity is doing the same thing over and over again and expecting different results. -- Albert Einstein
I'm not requiring that others solve my problem, Giancarlo. As mentioned, this is an impossibility in our organization, and (I'm sure) many others.
...or even hotels. Damian.
...or even hotels. Ok. I can provide nginx, openssh and sshlp configuration to the AUR
Em 17-06-2015 22:24, Damian Nowak escreveu: maintainers if that's what you guys want. I bet that they already know how to implement this anyway. But I still believe it's a dumb idea. Much better to implement proper git https write access. I'll take a look at AUR code and see if it's difficult to implement it. If it's not, I might write a patch. But the fact that Lukas didn't weighed in on this thread yet, is not a good sign to you guys. P.s.: If you guys use hotel wifi without a VPN... well... not that much I can say at this point, just wish good luck. Cheers, Giancarlo Razzolini
participants (11)
-
Alan Jenkins
-
Alexander Görtz
-
Damian Nowak
-
David Kaylor
-
Eli Schwartz
-
Giancarlo Razzolini
-
Magnus Therning
-
Manuel Reimer
-
Marcel Korpel
-
Mihamina Rakotomandimby
-
Tom Swartz