11 septembre 2012

maven settings et sécurité apparente

Maven 3 permet de crypter les mots de passe serveurs stockés dans votre fichier settings.xml. C'est un net progrès pour ce fichier qui peut vite contenir tous les sésames de votre infrastructure. Cependant beaucoup (trop ?) de personnes semblent se contenter de la sécurité apparente de voir leur mot de passe remplacé par un obscur "{ABCDEF1234567890ABCDEF1234567890=}".

Un indice : Maven 3 est en mesure de retrouver vos mots de passe, sans vous demander quoi que ce soit : le cryptage est donc réversible sans votre intervention. Si vous utilisez un client ssh vous vous souvenez peut-être avoir mis en place un agent qui "cache" votre passphrase pour ne pas avoir à la retaper à chaque commande. Bien pratique, l'effet pervers de ces outils est qu'on finit par oublier où se situe la réelle sécurité dans le système.

Petit rappel donc : Maven utilise un mot de passe maître,  stocké dans votre settings-security.xml, et lui même cryptée pour ne pas révéler de manière trop évidente cette info capitale. Cette clé sert pour crypter vos autres mots de passes. Si cette clé est inaccessible à un malveillant, vous êtes en sécurité (dans la limite du raisonnable, comme tout système cryptographique l'attaquant très bien armé et très patient pourra passer au travers - il peut aussi vous couper les orteils un a un pour vous faire révéler votre mot de passe c'est souvent plus simple)

On se retrouve donc avec deux fichiers bien obscurs qui donne un sentiment de sécurité. Seulement que ce passe t-il si un vilain pas bô peut accéder à ces deux fichiers ? Disons qu'il passe 2 minutes à regarder le code de maven et qu'il essaye un truc du genre :

PlexusCipher _cipher = new DefaultPlexusCipher();
String bare = _cipher.unDecorate( "{...=}" );
String master = _cipher.decryptDecorated("{...=}", SYSTEM_PROPERTY_SEC_LOCATION);
System.out.println( _cipher.decrypt(bare, master) );


Ne m'accusez pas de révéler une faille de sécurité, c'est vraiment à la portée du premier stagiaire venu de retrouver ce fragment de code à partir du code source Maven :P

La documentation de Maven vous le dit très clairement, le fichier settings-security.xml est la clé du système et doit donc être traité avec tous les égards. La solution recommandée consiste à renvoyer, dans le settings-security.xml par défaut, vers un autre fichier que vous placez sur une clé USB, disque réseau, ou tout autre ressource que vous pouvez "débrancher" en votre absence. On en revient donc au final à la bonne vielle sécurité physique. 

La réelle sécurisation proposée par Maven consiste donc à déplacer le problème de sécurité des mots de passe. En fait, si on considère le scénario où vous placez votre fichier sensibles sur une clé USB à reconnaissance d'empreinte digitale,  une simple redirection du fichier settings.xml donnerait une sécurité globalement équivalente. La sécurisation proposée par maven 3 est donc :

  1. d'éviter que vos mots de passe apparaissent en clair, par exemple lorsque vous ouvrez votre fichier settings.xml en plein pendant une démo lors d'une conférence (non, ça ne m'est pas arrivé :P)
  2. de vous permettre de séparer l'accès à vos mots de passe en deux fichiers. Un attaquant opportuniste qui vous piquerait l'un des deux éléments ne serait pas plus avancé.


C'est donc un réel progrès, mais le risque que je constate - risque général d'ailleurs - c'est qu'on est tenté d'utiliser son ID et le même mot de passe un peu partout. Résultat, dans le settings.xml utilisé par le serveur d'intégration continue je vais retrouver les clés du responsable technique du projet. Si celui-ci est conscient de ce risque (et c'est désormais le cas, vu qu'il lit forcément assidument ce blog) il aura créé un utilisateur dédié sur son Nexus / Artifactory / Archiva pour les déploiements maven. 

Moralité, sortez couverts !

update : 
si vous récupérez le mot de passe de session Windows de votre chef-de-projet-apprenti-responsable-technique par ce biais, merci d'envoyer de sa part un mail à toute l'équipe déclarant que la journée du 14 septembre sera chômée afin de tous vous envoyez au JugSummercamp à ses frais.

09 septembre 2012

Jenkins User Event CPH

Une fois n'est pas coutume, pour être lisible de mes hôtes je rédige ce billet en pseudo-anglais (c'est comme le pseudo-code, ça ne compile pas mais ça donne l'idée générale)


Last week, praqma was organizing in Copenhague a "Jenkins User Event". A User Event, compared to JenkinsConf, is a lighter meeting with (suposed to be) reduced costs organized by volunteers. Praqma got sponsorship from both CloudBees and Programing Research so that they can book a high quality conference room and prepare a nice meeting with all commodities.

That was my first travel to Danemark. I enjoyed the winds-farm on northern sea as well as the duty-free lego shop at airport, but didn't have much time to discover the city - so will have to come back next year ;)


Thursday was about a Jenkins Code Camp (aka "hackathon"), that I joined late at 2pm due to flight being delayed. 20 geeks were talking about some technical issues, new features, implementation strategies for a large set of topics. I contribute a group to solve an integration issue by creating a new extension point in jenkins-core. Those already confident with jenkins development helped to write this code, some discovered the extension point design as well as way to contribute to jenkins (github pull request, etc), some were looking at jenkins source code for first time so learned a lot.



Day ended with beer then a chinese restaurant (typical Danish food :P), with lots of fun and nice discussions.


Ajouter une légende
Friday was the Jenkins User Event. To reduce costs for such an event, compared to other Jenkins Conferences organized by CloudBees this year, lunch was not provided and conference program was "packed" into afternoon. This let praqma get a "reasonable" cost for this nice event, but still have a high quality conference, with printed programs, goodies, and coffee break. All praqma team was involved to make this event as pleasant as possible for all attendees, thanks a lot to them for contributing !

Conference was sold-out on friday morning, with 80 attendees.

After Lars Kruse welcome speak, and CloudBees to announce partnership with Praqma for DK, the conference started with two options : either an introduction to Jenkins, or an open-space discussion (~barcamp-like) for those that already know it well. I joined a small group first discussing about pre-tested commit, and then we divert speaking about best-practices, job and test performances issues, etc. Was a great exchange with interesting feedback.

The rest of the conference was single-track.


1rst session was about "facilitate strategic reuse of software" using jenkins CI. This session exposed how a industrial company changed it's internal software development practices and team organization to share components and be more efficient. This for sure introduced some coordinations and integration costs but resulted in a significant productivity improvement. This talk was interesting as it demonstrate that highly industrial companies (here, a low energy consuming water pumps producer) today follow development practice to share component and use continuous integration practice to help. I just wondered speaker said "Clearcase facilitated" sharing components  -I wouldn't expected those two words in same sentence :P

"Tales from the trenches" was a funny session explaining how Nokia came from stone age (manual integration with code freezes) to modern development practices. After reinventing the wheel with ~15 home made, perl-script based CI tools, they switched to Jenkins and Git as common tooling. Explanation on Git selection, evaluating multiple DVCS popularity, then migration from ClearCase, helping a lot early adopters, and later evaluating benefits (1 day / week / developer) was very interesting. Conclusion was that, "some tools a radically better" and "deep process renewal depends heavily on tools renewal".

"Continuous Code Inspection" talk explained use of industrial C++ coding standard and normative coding convention, with dedicated analysis tools. After explanation on those rules and tooling, a dedicated jenkins plugin was demonstrated. Such jenkins integration makes QA mostly a single checkbox to enable, and provide history graphs, reports, and external tools integration. Introduction was a little slow imho but content was demonstrating the power of jenkins plugin model to adapt software factory to specific industrial needs.


Coffee break with delicious Danish chocolates ...

Sony was presenting its "Huge Jenkins Cluster", with 4 master, some of them handling up to 6000 jobs, 300 slaves, 7000 builds a day an executing 175,000 tests a day for android platforms. Development teams use a dedicated slave machine with android devices connected through USB.

Such a build farm requires a dedicated support team and monitoring/maintenance tooling. IT only provides the computer and maintain the OS, but all Jenkins stuff is under the hands of a dedicated team. They evaluate plugins and core upgrades, educate teams, and analyse errors.

With 45Gb for a single full android build, they have to monitor available disk space, and developed maintenance scripts to delete old build artifacts and cleanup /tmp. They also use a local git mirror to speed-up cloning, and integrated with CFEngine-managed infrastructure to ensure no update occurs as a slave is running a build. They also significantly optimized build speed by switching from NFS to SAN, and are now evaluating XFS.

Remaining issue is about jenkins build queue (subject discussed on Jenkins Code Camp) because a 9 in the morning, thousand users connect to jenkins master and the UI widget to expose the queue status hits the queue synchronisation bottleneck.


Next talk was mine, exposing Jenkins Enterprise and demonstrating one ouf our Enterprise plugins. I'm not pleased by my talk, both because my english is crappy (maybe you already noticed?) and also because I was not confident with the standard JE slides. Assuming I jad more time to prepare this talk, and as a tribute to this Danish event, I'd have used a bunch of lego bricks pictures to present Cloudbee plugins. So I quickly left the slides to run a demo, setting-up Jenkins Enterprise to run pre-tested commits. Hope you enjoyed the talk.

Last talk was Lars one, exposing praqma "Corporate approach to opensource". This light, generalist talk was welcome as last one after a heavy-technical afternoon. Lars exposed reason to switch to open-source :

  • costs - for sure, 
  • but also open standards and interoperability, 
  • and contribution to public good. 
This last point distinguish "innovators" that create new content and contribute to the oss project, and "free riders" that only want to save money and consume other efforts. Lars didn't went deeper into what "contributing" can be about, but spending some time joining the mailing lists, exposing detailled bug report, or writing blogs or documentation about the issues you encounter is already a huge contribution to opensource. Organizing such a great user event also is ;)



Meeting ended with a "socialize" time, sponsored by Pragmatic Research, with beer and sandwiches. A nice time to discuss with speakers, know a face to match an #irc nickname, discuss about everything geeks like to discuss about, and round off this pleasant day.

So, back in France, and hope we can find volunteers, sponsors, and a low-cost location to get a comparable Jenkins User Event in Paris the day before Devoxx France 2013, stay tunned !