Git SSH over HTTP Proxy

If you are like me and you are using Linux behind an HTTP proxy, you will probably want to access GitHub and other Git remote repositories through SSH. For that to work, you will likely need to use some sort of utility that will enable you to connect to an SSH server through an HTTP proxy server.

To do that, you can use the connect-proxy command. The repository has no binary, so you will have to compile it on your own. But it is not hard if you are a good Linux user . If you run the install.sh script, you will end up with the binary at /usr/local/bin.

The last thing to do is to setup your SSH config file accordingly:

$ cat ~/.ssh/config

Host *
  ServerAliveInterval 30
Host *.amazonaws.com
  ProxyCommand connect-proxy -H proxy.myserver.com:80 %h %p
Host github.com 
  ProxyCommand connect-proxy -H proxy.myserver.com:80 %h %p 

Extra bonus: access to Amazon EC2 with SSH over HTTP Proxy.

If you know a better way to do this, please comment!

Had Heartbleed showed us a new business model for Open Source?

This is what I wrote on my Twitter the day I heard about Heartbleed:

Were #OpenSSL a paid-only software (but still open source), would have been #Heartbleed avoided? http://t.co/WV8nKUNMV8
— Bruno Borges (@brunoborges) April 10, 2014

Some say this bug is the worse bug ever found, affecting the Internet as a whole, since most servers have OpenSSL. With paid and closed source software, it is easy to blame someone. At some point, there are companies who prefer paid and closed source just because of that. But what about a Free and Open Source? Who is to be blamed about the issue? I would say there are three entities to be blamed for the Heartbleed bug, each with different weights:

1. The developer who introduced the bug is the least to be blamed. Developers make mistakes, some big, some small. This one just happened to be a small bug but with a big consequence.
2. The QA developer who didn't see the bug is the least to be blamed. A developer reviewing code. In the end, continues to be a developer mistake like in (1).
3. The whole IT industry (companies and developers of all kind; FOSS or not) who uses OpenSSL for free but does not pay anything for it, and although being Open Source, don't look at it, don't review commits. Just expect it to work without bugs. These are the most to be blamed. (including myself)

As the article in my tweet above says:

Jackson also says a lesson to be drawn from the Heartbleed Bug is that "we as an industry have dramatically underinvested in software integrity and generally ignored, for a security perspective, the open source building blocks on which the Internet functions. Open source is everywhere. It is the foundation of all modern software applications."

So my question to you now is: if we, the IT industry, had put more investment into the OpenSSL development team, would the chances had been higher for the Heartbleed bug to be found? Being Open Source helps, of course, but if there is no incentive (or obligation) for people to look at it, to review the code, then most people won't look at it and instead, just use it for free. This is what happened. All companies and developers are to be blamed.

Should we consider  a different business model for Open Source software? What about a model where a company (not individual) willing to use an Open Source software has to either:

• pay for a license and/or subscription support;
• provide resources (developers and/or QA) dedicated to the software itself;
• discount on license/support based on contributions;

Is it time for a new business model for Open Source?

What are your thoughts?

UPDATE #1 13/04/2014
A headline on Slashdot shows that Apple is far from supporting Open Source. The news says:

Apple bundles software from the Apache Software Foundation with its OS X operating system, but does not financially support the Apache Software Foundation (ASF) in any way.

Isn't time for Open Source foundations such as Apache or Eclipse, charge for the use of their Open Source projects by companies who profit from these projects? Consider "charge" as either through money, contribution, or developers paid by these companies to work on these Open Source projects.

UPDATE #2 13/04/2014
Here is another blog post titled "Heartbleed, an ASL business model failure?" by Bruno Lowagie, original author of iText, covering similar ideas I wrote above.

UPDATE #3 14/04/2014
Interesting article aobut the weakenesses of Open Source: "Heartbleed and the misconceptions about Open Source". Here's a quote:

As Heartbleed showed, even mission critical software used by a large portion of the Internet does not necessarily have the resources to be professionally maintained. The OpenSSL team receives only about $2000 yearly in donations.

JavaOne 2014 na faixa, 0800, grátis!

Existem muitas coisas interessantes sobre o JavaOne, a maior conferência de Java deste planeta. Talvez a oportunidade de ficar sabendo em primeira mão sobre grandes lançamentos, ou ouvir sobre novas formas de utilizar a tecnologia, ou ainda conversar com desenvolvedores de todo o mundo, ou melhor: conhecer pessoalmente aqueles com quem conversamos somente por redes sociais e mailing lists. E é claro, a oportunidade de conhecer San Francisco, e o Vale do Silício: os escritórios da Oracle, do Google, da Apple, ou até da Microsoft. :D

Se você nunca foi ao JavaOne, mas tem muito interesse, curiosidade, e muita disposição (são várias sessões, e muitos eventos pós-sessões como happy hours, shows musicais, hackathons, etc!), e quer uma ajudinha para ir no evento, um bom patrocínio, existem duas formas de você fazer isso. A melhor opção é participar do JavaOne 2014 IoT Developer Challenge!.

O que você precisa fazer para concorrer no IoT Developer Challenge?
Tudo o que você precisa fazer é criar um projeto, bolar um vídeo e publicar o código-fonte deste projeto utilizando a tecnologia Java Embedded da Oracle, com foco em IoT: Internet of Things, com placas de embarcados como Raspberry Pi e similares, dispositivos, sensores, etc.

Quais os prêmios?
Na categoria profissional:

3 times ganharão uma viagem para o JavaOne. Três membros de cada time vencedor ganhará a entrada para o JavaOne 2014, e mais US$ 2.000,00 para custear até 4 noites de hotel e também as passagens de avião. (outras despesas como alimentação e transporte não serão custeadas).

Na categoria estudante: 

• 1º lugar: 3 membros do time vencedor ganharão cada, a entrada para o JavaOne e mais US$ 2.000,00 para custear passagens e (até) 4 noites em hotel.
• 2º lugar: 3 membros do time vencedor ganharão cada, um laptop e um voucher para certificação Oracle com valor total de até US$ 1.500,00
• 3º lugar: 3 membros do time vencedor ganharão cada, um laptop e um voucher para certificação Oracle com valor total de até US$ 1.300,00

Data Limite para Enviar
O período para enviar a sua criação termina no dia 30 de Maio de 2014.

Quer saber mais?
Se você quiser saber mais, não deixe de ler o FAQ do IoT Developer Challenge.

Precisa de ajuda?
Se precisar de uma ajudinha para criar um projeto legal, confira a página do IoT Developer Challenge. Vários webinars foram publicados. E tem até alguns exemplos de códigos!

JavaOne 2014 de graça? Com viagem e hotel pagos! :-D
Assim fica fácil ir no JavaOne e curtir toda a experiência desta grande conferência! Se você precisar de ajuda, seguem alguns videos e tutoriais para ajudar neste desafio!

Outra forma de gastar menos para ir ao JavaOne: seja um palestrante!
E se você achar que dá muito trabalho criar um projeto tão maneiro, com tecnologias tão recentes, sobre um tópico tão quente como Internet of Things, tudo bem! Outra forma de economizar, pelo menos no preço da entrada para o JavaOne 2014, é sendo um palestrante. Estes seres iguais a nós desenvolvedores, que apenas querem apresentar algo interessante e legal, e que pode ser muito útil para muitos outros desenvolvedores, ganham acesso para a conferência (passagem e hotel não incluídos).

Você tem exatamente uma semana para enviar uma palestra, pois o Call for Papers encerra no dia 15 de Abril. Bola rápido um tema bacana, e proponha sua palestra!