Categories

Creating and applying a patch for an Eclipse project with Git, part 2 : using github

In a recent post, I described how to contribute a patch to an eclipse project using git as its version control system.

Patches are OK, but you lack all the social aspect that is enabled with git and its tooling (be it pure git + gerrit or github with the comments on commits and pull requests)

As of today, pull requests are not accepted by Eclipse committers since they lack IP (Intellectual Property) information, and the official git repositories at eclipse are hosted by the foundation not on github (github repositories of Eclipse projects exist for mirroring only).

Recently talking with a committer on the Eclipse Tycho project (Tobias Oberlies not to name him), he suggested to me to share my contributions via github, instead of attaching patches, as long as the git contribution scenario is followed

To comply with this suggestion,

1. I would clone the official repository at git.eclipse.org

git clone http://git.eclipse.org/gitroot/tycho/org.eclipse.tycho.git

2. work on my changes, test them, add them, and commit them for each functional change

git add myfile1 myfile2
git commit -m "BZ xxxxxx : comment"

3. create a new repository on my github account

4. synchronize my new github repo with the official tycho repository

git remote add origin.github git@github.com:anthonydahanne/org.eclipse.tycho.git

« behind proxy » users can use https access instead,

git remote add origin.github  https://anthonydahanne@github.com/anthonydahanne/org.eclipse.tycho.git

5. push my committed changes to my github repository

git push -u origin.github master

6. add a comment to the bugzilla entry describing the fix or new feature I worked on, giving the github commit id

7. accept the IP conditions of the Eclipse foundation

That’s it ! you just contributed some code to a cool Eclipse project !
OK, it seems more complicated than just submitting a patch or a pull request, but once your local repo is set up,
you should have something like :

git remote -v
origin  http://git.eclipse.org/gitroot/tycho/org.eclipse.tycho.git (fetch)
origin  http://git.eclipse.org/gitroot/tycho/org.eclipse.tycho.git (push)
origin.github   https://anthonydahanne@github.com/anthonydahanne/org.eclipse.tycho.git (fetch)
origin.github   https://anthonydahanne@github.com/anthonydahanne/org.eclipse.tycho.git (push)

and it is just a matter of juggling between the original repo, synchronizing the latest changes

git pull origin master

and the github repo (pushing the latest changes)

git push origin.github master

and copying/pasting the commit ids to the bugzilla entry.

I’m still relatively new to Git, so if you think there are better ways to sync the repositories, then please add a comment to this post !

To go deeper on that topic :

Sécuriser son serveur dédié : quelques conseils

Assomption avant de commencer : Bien entendu, vous êtes à jour des derniers correctifs de sécurité de l’ensemble de vos services…

En lisant un article faisant référence à un serveur mal sécurisé ; j’ai été pris de quelques doutes : et si mon serveur dédié était lui aussi mal sécurisé ?
Étant développeur et adepte de l’auto hébergement (oui je ne suis pas un grand fan des services hébergés chez les géants du net avec leurs clauses de confidentialité obscures…) je fais évoluer mon serveur dédié (services qui tournent dessus) au rythme de mes besoins… ce qui fait que la sécurité passe souvent au second plan…
Et rien de tel que de jeter un coup d’œil à la sécurisation de ces services de temps en temps…

Audit rapide et efficace

On commence avec nmap, avec les options qui vont bien :

sudo nmap -A mon.serveurdedie.fr

On peut alors commencer à l’analyse du résultat, et à remédier aux problèmes.

DNS et Bind

Dans le rapport obtenu par nmap, si vous voyez :

| dns-zone-transfer:

et ensuite la liste de vos sous domaines; méfiance, cela veut dire que quiconque peut lister vos sous domaines; pas forcément une bonne idée si certains d’entre eux sont là pour des tests ou pour des services non publics…

Les solutions

Rendez vous dans votre fichier de configuration de bind, /etc/bind/named.conf.options, et ajouter les options suivantes :
 allow-transfer { x.x.x.x; }; --> uniquement donner accès aux informations détaillées des zones à cette IP (votre dns secondaire)
 version "Ma version"; --> pourrait derouter certaines attaques en offuscant la version de Bind; mais comme disent certains, l'obfuscation est rarement une bonne méthode de sécurisation...
 fetch-glue no; --> défendre votre serveur dns aux attaques de type déni de service
 recursion no; --> défendre votre serveur dns aux attaques de type déni de service

Ces informations sont issues d’un article de TechRepublic , et n’hésitez pas à vérifier votre configuration avec zonecheck

HTTP et Apache

Dans le rapport obtenu par nmap, si vous voyez :

80/tcp  open     http         Apache httpd 2.2.9 ((Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny13 with Suhosin-Patch mod_wsgi/2.5 Python/2.5.2)

Et bien cela signifie que votre serveur est très bavard…

La solution

Sur Ubuntu, dirigez vous vers /etc/apache2/conf.d/security et éditez :

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Si vous utilisez PHP, faites aussi un tour du côté de  /etc/php5/apache2/php.ini

expose_php = Off

Encore une fois, l’offuscation n’est pas une méthode de sécurisation en soit, mais moins les potentiels attaquants en savent, mieux c’est…
Ces informations sont issues de DebianAdmin

SSH et OpenSSH

Pour l’instant je ne peux que conseiller de lire cet article : http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html

à suivre…

Creating and applying a patch for an Eclipse project with Git

Since its move to git, contributing to the Eclipse foundation projects is a bit different.

Nothing terrible actually, let’s take the example of a contribution to the p2 project (part of the equinox umbrella at the Eclipse foundation)

  • Checkout the project
git clone http://git.eclipse.org/gitroot/equinox/rt.equinox.p2.git
  • do the changes and then commit them to your local repo (you can perform this step several times)
git commit
  • create the patch against the master branch
git format-patch origin

You  will get a file for each commit you submitted, so one commit =  one patch file.

You can attach your patch(es) to a bugzilla entry, for example , make p2 buildable with tycho (click on one of the patches)

  • what an eclipse committer will do then , is apply your patch to its local repo to test everything is ok
git apply 0001-my-patch.patch

That’s pretty much it ! A bit more tedious than a Github pull request, but it does the job !