Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
I'd just be nice to have someone actually test it. Lazlo, could you verify? Thank you for the progress! Looks like pushing works: https://codereview.qt-project.org/#change,30932 Cloning is still flaky through the init-repository perl script for webkit as the example shows above. The documentation should be extended much more. There are at least there pages: 1) Setting up Gerrit (which is still incomplete because scp'ing the commit hook should happen with the -P 443 for this case) 2) Qt5 build page: http://qt-project.org/wiki/Building-Qt-5-from-Git 3) Gerrit introduction page: http://qt-project.org/wiki/Gerrit-Introduction Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
1) Setting up Gerrit (which is still incomplete because scp'ing the commit hook should happen with the -P 443 for this case) Oh, I am sorry. That is also achievable by the ssh config. Nevertheless, this section needs to be updated, if the existing duplication remains to be in place for good: http://qt-project.org/wiki/Gerrit-Introduction#392c991242b19a7bff02f4001278e5a3 Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
Is the use of corkscrew and or socat something that should be made more widely known? http://sitaramc.github.com/tips/git-over-proxy.html http://omappedia.org/wiki/Gerrit It is possible to use this method with direct outbound port 80 and 443 connections or proxied connections using squid (3128), port 8080 proxies etc. Just make the required substitutions for the host and port numbers for your internal network structure. BR Mark -Original Message- From: development-bounces+mark.keir=nokia@qt-project.org [mailto:development-bounces+mark.keir=nokia@qt-project.org] On Behalf Of ext Laszlo Papp Sent: Saturday, July 14, 2012 2:45 AM To: Thiago Macieira Cc: development@qt-project.org Subject: Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server But let's make sure that we are NOT recommending that people circumvent IT network policies. If the IT infrastructure blocks the traffic, then they must have a reason for it. It can be because: 1) the block is overly broad and shouldn't be there or 2) the block is intentional and the Git/Gerrit/SSH traffic should not be permitted We simply don't know which it is. The use by that user of the SSH server running on port 443 could lead to a violation of the corporate network security policy. We must make it clear that we are not responsible and that the user must figure that out with their people. Which leads me to my suggestion: if your firewall blocks the traffic to port 29418, create the IT ticket now and get an approved way of doing Gerrit traffic. Follow the company's procedures. +1 And the best way to ensure that it gets done is to prove that you cannot work without the solution. Prove it by spending a week idling because you could not do your work. That's also valid for consultants. I personally believe that, this is not the good practical approach of achieving those goals or getting a good impression at the company, but it depends on the supervisor and management as well, I guess. :-) Yes, I have worked for big companies and I still do. In both Nokia and Intel, there are approved ways of accessing those ports that don't involve circumventing the security policy. The situation is simpler with big companies like Nokia and Intel since they work on open source projects as well, and some of those are hosted publically using Git, SSH, and so forth as you enumerated. Therefore, it is quite reasonable to have that internal support in place by default. This is unfortunately not the case for many big companies. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On Mon, Jul 16, 2012 at 7:47 AM, mark.k...@nokia.com wrote: Is the use of corkscrew and or socat something that should be made more widely known? Like I said, the proxy is http only. and there is a filtered (port 80, 443 only) internet connection. You are saying socat or corkscrew can help when you do not have a SOCKS proxy? That is new to me. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
Like I said, the proxy is http only. and there is a filtered (port 80, 443 only) internet connection. You are saying socat or corkscrew can help when you do not have a SOCKS proxy? That is new to me. If one had a system to port forward via, then it would be a deal done, but it is not the case anyway. Even the CONNECT method of a proxy is only valid for a fully HTTPS proxy, not a pure HTTP proxy. You would have a chance with having CONNECT enabled (HTTPS proxy), but only if the proxy is unfiltered. However, that is not the case. In addition, I personally really dislike the visible passwords that you need to compromise with socat... Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On 13.07.2012 17:10, Laszlo Papp wrote: He also says that you should at the same time have a discussion with Corporate Security to make them understand that the current situation is hurting the organization, and try to get it changed so you _don't_ have to circumvent Corporate Security. (Normally it's grounds for getting the pink slip immediately.) Why open the port up globally with its own drawbacks just because of one project? If this can get fixed, and the circumventing (communicating with patches good for a company over 443) is accepted in a network (let it corporate or personal), I do not see the problem and the reason to change the existing practicies. Closing down ports for security reasons can only be a short term emergency measure. Doing it in general does not increase security in the medium term, since the Bad Guys are now using 443 anyway (like everybody else). This whole blocking of ports caused a port-80-fication of net services which almost killed for what ports where invented in the first place: service discrimination. Now we have to use whole IPs for that discrimination (like the workaround proposed in this case) or put another addressing-layer into the HTTP content. Complete waste of time and energy in my opinion, because in the end security has not been increased. So, although I fully understand the need for a workaround to keep work going, I fully support Thiagos recommendation to put pressure on the IT departments and managers in parallel. Sven ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
Who is going to pay for the extra IP dedicated for this? Maybe we should put a price tag on uses for port 443: if you want to use it, pay $10 per month to the Qt Project Hosting Foundation and we'll enable your account to use it (IPv6-only should be free or cheaper). Then you can take it up with the Finance department instead to explain why that cost is necessary. Better, charge it to the IT department's cost centre. Discussing 10 EUR (or finding someone - company or personal - in the community to help out with such a thing) is way, way and way simpler at times than discussing things radically against the IT department policies, especially if when it comes to security as their consideration. Not to mention 10 eur each month is high though... for hetzner it is 1 eur/month for the IP. Really. Really. I understand that convincing the IT departments of some companies to change their policies is like banging the head against the wall. But we must try. I really do not like your defeatism. I really dislike your forcement for /everybody/ and /each/ case. Like, I said, let the companies decide what make sense in their case. You cannot see every company internally, how they work and so forth after all. Worked for Nokia and also with Intel tightly together back then on the Maemo and MeeGo project, and also for other companies. Perhaps, your goal is achievable in Nokia, Intel and many companies, but it does not unfortunately work in certain cases. I am sorry for saying that, but that is how I see certain companies working internally. I have had many IT tickets opened years ago which are still being there. Nothing happened. Pushed many times, nothing happened. I would not even like to put more energy uselessly into such a thing, if there is a way simpler and approved way with much less stress. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On Monday 16 July 2012 10:50:20 Laszlo Papp wrote: Closing down ports for security reasons can only be a short term emergency measure. Doing it in general does not increase security in the medium term, since the Bad Guys are now using 443 anyway (like everybody else). Yeah, the desperate ones who have not lost their sake yet... You are proposing, not increase the factor, if possible? Surely, your bicycle can be stolen with 2 u-locks as well, but more factor, ergo more difficult... Sorry, but bike locks have keys to disable them. The sanity bot have an option to override it. Where is that option in your firewall? You have no excuse. If you are supposed to work on Qt, your company should give you the infrasctructure to do your work. Did you already open the ticket for your IT department as Thiago suggested you? Because as slow as it might be, it may still take less time than waiting for qt-project to change as well. (also a big corporation). I don't know why you are even arguing to justify the bad behaviour of your IT department. Do you realize you are asking the Qt project to adapt because your company can't provide you the basics to do your work? What will be the next step? Sorry I don't compile my changes anymore because the company antivirus won't let me compile. or Can you please change gerrit to accept my patches embedded in .doc document because I'm not allowed to install git on my workstation and all I have is MS Office, lol -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
Sorry, but bike locks have keys to disable them. The sanity bot have an option to override it. Where is that option in your firewall? Going through 443. You have no excuse. If you are supposed to work on Qt, your company should give you the infrasctructure to do your work. Unless it is fixable upstream which seems to be the case anyway. KDE was able to fix this. Github was able to fix this. People so far agreed upon to fix this for the Qt Project, so nothing really needed afterwards to change at other places, just once. Did you already open the ticket for your IT department as Thiago suggested you? Because as slow as it might be, it may still take less time than waiting for qt-project to change as well. (also a big corporation). Like I said, I have had such type of tickets open for eons. I don't know why you are even arguing to justify the bad behaviour of your IT department. You did not get the whole point. Changing all the policies upside down is not the only approach to fix the situation for many places in one place, especially not for short or most of the times even for long term. Do you realize you are asking the Qt project to adapt because your company can't provide you the basics to do your work? Yes, and that is way, way, and way simpler solution than arguing in tons of companies internally for eons. Adapting the Qt Project to companies' need, if it is beneficial for the project (and no drawback for others of course) is a very good idea IMO. Like new contribution in this special case.. What will be the next step? Sorry I don't compile my changes anymore because the company antivirus won't let me compile. or Can you please change gerrit to accept my patches embedded in .doc document because I'm not allowed to install git on my workstation and all I have is MS Office, lol No comment. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On 16.07.2012 15:26, Laszlo Papp wrote: Sorry, but bike locks have keys to disable them. The sanity bot have an option to override it. Where is that option in your firewall? Going through 443. No, going through 443 is _not_ an option of the firewall, it's like lock-picking a useless lock. You have no excuse. If you are supposed to work on Qt, your company should give you the infrasctructure to do your work. Unless it is fixable upstream which seems to be the case anyway. KDE was able to fix this. Github was able to fix this. People so far agreed upon to fix this for the Qt Project, so nothing really needed afterwards to change at other places, just once. It's not a fix at all. It's a workaround. Important difference! Sven ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
No, going through 443 is _not_ an option of the firewall, it's like lock-picking a useless lock. No, the firewall and the whole establishment have the option to go out over the port 443. It's not a fix at all. It's a workaround. Important difference! My whole point is that, let us leave the decision to the companies, if it is a workaround for them or fix. It is *them* deciding about *their* policies and approvals. The Qt Project should get as much support as possible from outside, especially now. Company policies and decisions are not the target of the Qt Project after all. It can just aid them as much as possible. Some companies will open ports up, some will not. The latter might give up the contribution to the Qt Project, and will implement their own internal solution on top of Qt (not in) without contributing back. That would be a pity... Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
Hi, Cutting things short: We are working on a solution, which will probably result in a work around. I will announce once it's done. There is no point in further discussion. We all agree it sucks. But stupid firewall rules are a reality, like it or not. Let's get back to coding. Regards, Daniel -Original Message- From: development-bounces+daniel.molkentin=nokia@qt-project.org [mailto:development-bounces+daniel.molkentin=nokia@qt-project.org] On Behalf Of ext Sven Anderson Sent: Monday, July 16, 2012 3:51 PM To: development@qt-project.org Subject: Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server On 16.07.2012 15:26, Laszlo Papp wrote: Sorry, but bike locks have keys to disable them. The sanity bot have an option to override it. Where is that option in your firewall? Going through 443. No, going through 443 is _not_ an option of the firewall, it's like lock-picking a useless lock. You have no excuse. If you are supposed to work on Qt, your company should give you the infrasctructure to do your work. Unless it is fixable upstream which seems to be the case anyway. KDE was able to fix this. Github was able to fix this. People so far agreed upon to fix this for the Qt Project, so nothing really needed afterwards to change at other places, just once. It's not a fix at all. It's a workaround. Important difference! Sven ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On 16.07.2012 16:06, Laszlo Papp wrote: No, going through 443 is _not_ an option of the firewall, it's like lock-picking a useless lock. No, the firewall and the whole establishment have the option to go out over the port 443. So, you are saying, the implementer of such a firewall thinks, it's a good idea and a valid option, to tunnel all kinds of traffic through port 443? I would like to talk to that person. Well, maybe better not... ;-) It's not a fix at all. It's a workaround. Important difference! My whole point is that, let us leave the decision to the companies, if it is a workaround for them or fix. It is *them* deciding about *their* policies and approvals. The Qt Project should get as much support as possible from outside, especially now. Company policies and decisions are not the target of the Qt Project after all. It can just aid them as much as possible. Some companies will open ports up, some will not. The latter might give up the contribution to the Qt Project, and will implement their own internal solution on top of Qt (not in) without contributing back. That would be a pity... That's why we all agreed, that the workaround should be established. What confuses us is (well, me at least), that you seem to support these broken policies. Sven ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
So, you are saying, the implementer of such a firewall thinks, it's a good idea and a valid option, to tunnel all kinds of traffic through port 443? I would like to talk to that person. Well, maybe better not... ;-) Yes, we have had such solutions already in the past. Just because you have never seen such a situation, it does not mean it does not exist. Perhaps talking to such a person, and living in such a situation would widen your experience. In fact, the aforementioned Nokia was not opening ports up in certain departments either, but corkscrew, socat and other stuff were allowed... That's why we all agreed, that the workaround should be established. What confuses us is (well, me at least), that you seem to support these broken policies. KDE, github or any some other projects require a port, but it is also possible to go through 443 as well. What if the company accepts the latter, and it works fine then? You would start fighting internally, you do need that port open instantly? Why would you? You should start at companies proposing the denial of corkscrew, socat and other things internally then, how broken they are in your book. They are not in my book by any means. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On 13/07/2012 10:04, ext marius.storm-ol...@nokia.com wrote: So, I think we'll go ahead and get a port forward setup. It has been done. You can now point your git to git clone ssh://username@ssh.qt-project.org:443/qt/qt5 instead, if needed. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Contributing to the Qt Project behind a hefty firewall and proxy server
Hi, There are certain situations out there, when it is currently not so simple to contribute to the Qt Project. One typical use case, if there is a proxy server without using socks, just plain http. In those cases, ssh tunneling does not work either properly. Imagine that, the ports 80 and 443 are allowed only. What one can do for instance in the KDE project is simpler since git.kde.org does listen via ssh on the port 443, so that establishment can be used for cloning and pushing to the KDE repositories. Unfortunately, this is not the case with the Qt Project currently. As far as I have been told, the port 443 is used for the Gerrit webinterface. What one could do is to use a gateway server listetning on port 443 via ssh. Unfortunately, many people do not have such an ability. Furthermore, I do think it is suboptimal, if each contributor in this situation should solve the issue in question on their own. Many people cannot just unfortunately use the port 29418 recommended. Hence, I am now asking, if it is possible to find a solution for people willing to contribute to the Qt Project with these conditions. One option is an outside proxy on the port 443, but any solution is welcome. Thank you in advance. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On 13/07/2012 06:42, ext Laszlo Papp wrote: There are certain situations out there, when it is currently not so simple to contribute to the Qt Project. One typical use case, if there is a proxy server without using socks, just plain http. In those cases, ssh tunneling does not work either properly. Imagine that, the ports 80 and 443 are allowed only. What one can do for instance in the KDE project is simpler since git.kde.org does listen via ssh on the port 443, so that establishment can be used for cloning and pushing to the KDE repositories. Unfortunately, this is not the case with the Qt Project currently. As far as I have been told, the port 443 is used for the Gerrit webinterface. What one could do is to use a gateway server listetning on port 443 via ssh. Unfortunately, many people do not have such an ability. Furthermore, I do think it is suboptimal, if each contributor in this situation should solve the issue in question on their own. Many people cannot just unfortunately use the port 29418 recommended. Hence, I am now asking, if it is possible to find a solution for people willing to contribute to the Qt Project with these conditions. One option is an outside proxy on the port 443, but any solution is welcome. I think we could do the same setup as GitHub, and simply have port forwarding from ssh.qt-project.org:443 to codereview.qt-project.org:29418. That should enable most people to work behind corporate firewalls. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On sexta-feira, 13 de julho de 2012 12.40.12, marius.storm-ol...@nokia.com wrote: I think we could do the same setup as GitHub, and simply have port forwarding from ssh.qt-project.org:443 to codereview.qt-project.org:29418. That should enable most people to work behind corporate firewalls. I think we should try that. However, note that this could be a violation of the terms of use of that corporate network since the traffic is not web. Circumventing the protection is not a good idea. So I also think that the IT departments of those companies need to do their job. If there's a legitimate reason for a developer working behind the corporate firewall to contribute to Qt, then this developer should use the Qt methods and simply get their IT people to provide an approved and supported way of doing so. IT is a supporting organisation, they are there need to make sure that the other functions can do their jobs and that the integrity of the network is maintained. They are not there to dictate how those other functions should do their jobs. So I suggest that each developer behind such a firewall open an IT ticket and request a proxy to reach ports 9418 and 29418. If necessary, escalate to the managers and and stop working when the firewall prevents work from getting done. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
I think we should try that. However, note that this could be a violation of the terms of use of that corporate network since the traffic is not web. Not necessarily, no. The Qt Project would not be in charge of such decisions, anyway. Nothing to violate in the Qt project itself, so is this not a violation in the aforementioned examples: github, KDE, and so forth. Circumventing the protection is not a good idea. It indeed is, if it is done for good. It is like when you have a sanity bot when it defends against the most cases, but makes zero sense in certain. One will send patches to the mailing list, and someone else will go through gerrit? So I also think that the IT departments of those companies need to do their job. If there's a legitimate reason for a developer working behind the corporate firewall to contribute to Qt, then this developer should use the Qt methods and simply get their IT people to provide an approved and supported way of doing so. Qt methods could help the people better instead of blocking the new contributions. Also, changing very old company policies, for instance as a new employer, is just almost impossible even if your project depends on Qt, and you fix an upstream issue needed for your project (or implement a new feature). Not upstreaming that could actually be a violation against the Qt Project, so what? Keep sending attached patches to the mailing list? IT is a supporting organisation, they are there need to make sure that the other functions can do their jobs and that the integrity of the network is maintained. They are not there to dictate how those other functions should do their jobs. So I suggest that each developer behind such a firewall open an IT ticket and request a proxy to reach ports 9418 and 29418. If necessary, escalate to the managers and and stop working when the firewall prevents work from getting done. Are you serious? You have worked in a big company, so you do know that such changes can be /very/ long, if it gets through at all. Many supervisors would just say, attach a patch please to the mailing list (if they do not have other opportunities over 80 and 443) since it is simpler than changing the company policies upside down, so they do not stress. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
In addition to my previous reply, it can be a legit use case to make a network establishment (not just corporate, but even personal), where you would not like to open a port up globally just because of one project, if not necessary. The only drawback I could mention from my point of view for the Qt Project, is the additional maintenance, which should not be significant. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
He also says that you should at the same time have a discussion with Corporate Security to make them understand that the current situation is hurting the organization, and try to get it changed so you _don't_ have to circumvent Corporate Security. (Normally it's grounds for getting the pink slip immediately.) Why open the port up globally with its own drawbacks just because of one project? If this can get fixed, and the circumventing (communicating with patches good for a company over 443) is accepted in a network (let it corporate or personal), I do not see the problem and the reason to change the existing practicies. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On Friday 13 July 2012 16:10:22 Laszlo Papp wrote: He also says that you should at the same time have a discussion with Corporate Security to make them understand that the current situation is hurting the organization, and try to get it changed so you _don't_ have to circumvent Corporate Security. (Normally it's grounds for getting the pink slip immediately.) Why open the port up globally with its own drawbacks just because of one project? If this can get fixed, and the circumventing (communicating with patches good for a company over 443) is accepted in a network (let it corporate or personal), I do not see the problem and the reason to change the existing practicies. If it is for a personal network (as you now seem to be hinting at) then what is the issue with opening up said ports for outbound traffic? If you are really that bothered then only open up the ports for outbound traffic when you need to use them and then close them again after. You could even place restrictions on the allowed source and destination IPs etc if desired. Why would opening these ports for outbound traffic be any more risky than any other existing ports. For corporate networks I agree that the proposed solution is fine to help get around overly restrictive IT policies. I know first hand from previous experience that these can take a long time and the patience of a saint to get changed. Kind regards, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
If it is for a personal network (as you now seem to be hinting at) is the issue with opening up said ports for outbound traffic? Perhaps I associate the word corporate distinctly due to my language difficulties. :) In any case, what I mean is that, It is all policy (regardless company or personal) after all. It may be a valid use case in my opinion not opening a port globally everywhere needed in this situation, but solved centrally in one place. If I had to use the same port at many places, sure. Perhaps it is better to consider, but that is not the situation anyway. If you are really that bothered then only open up the ports for outbound traffic when you need to use them and then close them again after. You could even place restrictions on the allowed source and destination IPs etc if desired. Again, I prefer doing this in one centralized place instead of X separate where this need arises just for this project. Why would opening these ports for outbound traffic be any more risky than any other existing ports. There might be valid reasons for that, why two are only open. It is the same at a few big companies I worked with except that certain proxy servers use socks which allow easier treatment without the need for this request. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On sexta-feira, 13 de julho de 2012 15.04.36, marius.storm-ol...@nokia.com wrote: Ok, you guys just misunderstand each other. Thiago says we should do it, to ensure that the Qt Project is accessible behind badly configured corporate firewalls. He also says that you should at the same time have a discussion with Corporate Security to make them understand that the current situation is hurting the organization, and try to get it changed so you _don't_ have to circumvent Corporate Security. (Normally it's grounds for getting the pink slip immediately.) So, I think we'll go ahead and get a port forward setup. Yeah. But let's make sure that we are NOT recommending that people circumvent IT network policies. If the IT infrastructure blocks the traffic, then they must have a reason for it. It can be because: 1) the block is overly broad and shouldn't be there or 2) the block is intentional and the Git/Gerrit/SSH traffic should not be permitted We simply don't know which it is. The use by that user of the SSH server running on port 443 could lead to a violation of the corporate network security policy. We must make it clear that we are not responsible and that the user must figure that out with their people. Which leads me to my suggestion: if your firewall blocks the traffic to port 29418, create the IT ticket now and get an approved way of doing Gerrit traffic. Follow the company's procedures. And the best way to ensure that it gets done is to prove that you cannot work without the solution. Prove it by spending a week idling because you could not do your work. That's also valid for consultants. Yes, I have worked for big companies and I still do. In both Nokia and Intel, there are approved ways of accessing those ports that don't involve circumventing the security policy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
But let's make sure that we are NOT recommending that people circumvent IT network policies. If the IT infrastructure blocks the traffic, then they must have a reason for it. It can be because: 1) the block is overly broad and shouldn't be there or 2) the block is intentional and the Git/Gerrit/SSH traffic should not be permitted We simply don't know which it is. The use by that user of the SSH server running on port 443 could lead to a violation of the corporate network security policy. We must make it clear that we are not responsible and that the user must figure that out with their people. Which leads me to my suggestion: if your firewall blocks the traffic to port 29418, create the IT ticket now and get an approved way of doing Gerrit traffic. Follow the company's procedures. +1 And the best way to ensure that it gets done is to prove that you cannot work without the solution. Prove it by spending a week idling because you could not do your work. That's also valid for consultants. I personally believe that, this is not the good practical approach of achieving those goals or getting a good impression at the company, but it depends on the supervisor and management as well, I guess. :-) Yes, I have worked for big companies and I still do. In both Nokia and Intel, there are approved ways of accessing those ports that don't involve circumventing the security policy. The situation is simpler with big companies like Nokia and Intel since they work on open source projects as well, and some of those are hosted publically using Git, SSH, and so forth as you enumerated. Therefore, it is quite reasonable to have that internal support in place by default. This is unfortunately not the case for many big companies. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
