Une faille de sécurité dans Bash, Réactions à la publication du 25/09/2014

[scoch]

[...]
Reste donc à Apple à fournir un correctif rapidement : les développeurs iront-ils aussi vite que le retrait de là mise à jour iOS 8.0.1 ?
Lien vers le billet original

Mantenant qu'Apple a annoncé vouloir corriger la faille rapidement,
reste donc à MacB...ouille à nous informer comme le fait le site d'information cité dans l'article même.

Annoncer qu'Apple veut corriger rapidement la faille c'est une info ? Je ne doute pas que MacBidouille nous en informera lorsque Apple l'aura fait.
On ne peut pas dire qu'Apple soit toujours rapide pour corriger les failles de sécurité… mais étant donné que la faille est déjà corrigée sur nombre de distributions Linux ça devrait aider à accélérer.

C'est vrai que quand on voit les délais de sortie d'iOS 8.0.2 après l'embrouille de la 8.0.1, on peut douter de la réactivité d'Apple.
C'est ça. On reste objectif ici.

Ça n'a rien à voir, la 8.0.2 corrige de nouvelles erreurs introduites par la 8.0.1, pas une faille de sécurité. Voir plutôt ça : Problème de sécurité iCloud : Apple aurait été au courant depuis 6 mois ou ici si tu préfères une version qui ne vienne pas de MacBidouille.

[scoub_rosnoen]

C'est vrai que quand on voit les délais de sortie d'iOS 8.0.2 après l'embrouille de la 8.0.1, on peut douter de la réactivité d'Apple.
C'est ça. On reste objectif ici.

Le problème d'iOS 8.0.1 était un problème bloquant pour les utilisateurs et faisait mauvaise presse, les failles de sécurité, Apple à toujours pris son temps pour les combler sauf quand cela fait mauvaise presse avec des photos de "starlettes".

[valorisa]

Sinon via The MacPorts Project Official Homepage, un simple :

Code

$ sudo port -vvv selfupdate && sudo port -vvv upgrade outdated

suivi de :

Code

$ sudo port -vvv install bash

Ensuite vérification par :

Code

$ bash --version

et

Code

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Ce message a été modifié par valorisa - 26 Sep 2014, 14:05.

[chombier]

Le fait d'installer bash via MacPorts ou Homebrew va installer un nouveau bash dans le dossier /opt/local/bin, mais l'ancien bash est toujours présent dans /bin et exploitable en spéficiant son chemin d'accès.
Il faut le supprimer pour être tranquille.

Ce message a été modifié par chombier - 26 Sep 2014, 14:06.

[valorisa]

Le fait d'installer bash via MacPorts ou Homebrew va installer un nouveau bash dans le dossier /opt/local/bin, mais l'ancien bash est toujours présent dans /bin et exploitable en spéficiant son chemin d'accès.
Il faut le supprimer pour être tranquille.

Exact !

Code

$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

Code

$ /opt/local/bin/bash --version
GNU bash, version 4.3.25(1)-release (x86_64-apple-darwin13.2.0)
Copyright (C) 2013 Free Software Foundation, Inc.
Licence GPLv3+ : GNU GPL version 3 ou ultérieure <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

D'ailleurs, à ce propos, quelqu'un sait supprimer l'ancien GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) ?

Un :

Code

$ which bash

donne :

Code

/opt/local/bin/bash

Un :

Code

$ whereis bash

donne :

Code

/bin/bash

Ce message a été modifié par valorisa - 26 Sep 2014, 14:15.

[bad_duck]

D'ailleurs, à ce propos, quelqu'un sait supprimer l'ancien GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) ?

Supprime simplement l'ancien bash et accessoirement fais un lien symbolique de /bin/bash vers /opt/local/bin/bash

Code

sudo ln -s /opt/local/bin/bash /bin/bash

[chombier]

D'ailleurs, à ce propos, quelqu'un sait supprimer l'ancien GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) ?

Code

sudo rm /bin/bash
sudo ln -s /opt/local/bin/bash /bin/bash

Mais il ne faut surtout pas désinstaller MacPorts après ça. Sinon, plus de bash. Et écraser le bash original avec celui de MacPorts n'apportera rien, le bash de MacPorts dépend de shared libraries installées par MacPorts:

Code

otool -L /opt/local/bin/bash
/opt/local/bin/bash:
    /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0)
    /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0)
    /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

[valorisa]

Merci Chombier et Bad_duck pour vos réponses.

Sur la page du Macports Guide https://guide.macports.org on peut lire :

upgrade does not uninstall the old version of a port. Instead, it deactivates it, i.e., it stashes the files belonging to the older version away in a tarball. This allows you to go back to the older version if there happens to be a problem with the updated one. To do that, run

Code

$ port installed <portname>

to determine the version number of the old version you want to re-activate, and run

Code

$ sudo port activate <portname> @<old-version>

to go back to the old version.

If you do not want to keep the old versions around while upgrading, you can pass the -u option when upgrading:

Code

$ sudo port -u upgrade outdated

However, we instead recommend keeping the older versions around for a while and running

Code

$ sudo port uninstall inactive

once in a while.

D'ailleurs, à ce propos, quelqu'un sait supprimer l'ancien GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) ?

Code

sudo rm /bin/bash
sudo ln -s /opt/local/bin/bash /bin/bash

Mais il ne faut surtout pas désinstaller MacPorts après ça. Sinon, plus de bash. Et écraser le bash original avec celui de MacPorts n'apportera rien, le bash de MacPorts dépend de shared libraries installées par MacPorts:

Code

otool -L /opt/local/bin/bash
/opt/local/bin/bash:
    /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0)
    /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0)
    /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

Effectivement, en procédant de cette façon, on devient complètement dépendant du bash issu de Macports, ce qui n'est peut-être pas tout à fait une bonne idée s'agissant de l'interpréteur de commandes qui n'est pas une chose négligeable.

Ce message a été modifié par valorisa - 26 Sep 2014, 15:01.

[ericb2]

Juste pour dire que j'ai utilisé les informations de Chriz ( message #48) et Sigourney (message #50) et que tout est ok.

J'ai aussi modifié le nom (ajouté .diff pour que mc les voie comme des diffs, + une meilleure numérotation pour utiliser une boucle quand on les applique), et le contenu des patches en supprimant les références à bash4-3.patched + appliqué le patch relatif au trou de sécu pas encore comblé (appelé eol-pushback.patch) et tout est ok maintenant.

Pour les appliquer, j'ai mis ces patches dans un répertoire "patches" placé à la même hauteur que bash-4.3 et je me suis placé dans bash-4.3, puis j'ai tapé :

for ((i=1; i<26 ;i++)) do echo $i ; patch -p0 < ../patches/bash43-0$i.diff ; done
patch -p0 ../eol-pushback.patch
./configure
make

+ en admin, après avoir renommé /bin/bash en /bin/bash_old, j'ai copié bash dans bin


Si Free m'avait pas fermé mon ftp (quels c..nards ceux là, je mettais simplement des cours / des TD et des sujets+corrigés d'examens à disposition de mes élèves ...) et bien j'aurais pu les mettre en ligne.

Me contacter en privé si vous avez une solution pour que quelqu'un en profite.


Enfin, MERCI à Chriz et à Sigourney bien sûr :-)

[chombier]

+ en admin, après avoir renommé /bin/bash en /bin/bash_old, j'ai copié bash dans bin

Si tout le monde renomme /bin/bash en /bin/bash_old, je vois venir un nouveau trojan.
Il vaut mieux supprimer l'ancien bash, qui reste exploitable, ou au moins, lui ôter les droits d'exécution.

[ericb2]

@chombier

Oui, bonne remarque. Mais c'est quand même une bonne habitude de ne pas supprimer tout de suite l'ancien.

(après avoir testé quelques shells, et vu que ça fonctionnait, je l'ai finalement supprimé).

[benja]

Apple travaillerait sur un correctif :

http://arstechnica.com/security/2014/09/ap...rs-not-at-risk/

Ce message a été modifié par benja - 26 Sep 2014, 15:56.

[trouspinette]

Apple travaillerait sur un correctif :

http://arstechnica.com/security/2014/09/ap...rs-not-at-risk/

Je mets à jour la news :-)

[bad_duck]

Un récapitulatif ici
-> https://shellshocker.net/

Avec un test pour voir si on est vulnérable aux 2 failles bash ( CVE-2014-6271 et CVE-2014-7169 ) + methode pour corriger.
Pour OS X ils préconisent Brew à MacPorts (je préconise aussi brew à macports perso)

[scoub_rosnoen]

J'ai un peu la flemme d'installer Xcode sur tout mes OS X server... et de compiler J'aimerai bien qu'Apple fournisse le patche assez vite. Parce que faire ça sur 50 machines les bras m'en tombent..

[marc_os]

[...]
Bien que le Bash soit souvent exécuté localement, d'autres exploits pourraient tenter de compromettre un système affecté : un serveur Web Apache, par exemple, présentant une faille dans du code CGI (comme mod_cgi et mod_cgid) pourrait permettre à un tiers d'exécuter cet exploit. Des attaques similaires sont aussi possibles à travers OpenSSH ou CUPS.
[...]
En gros, chez Apple, ils sont sûr de leurs produits. Traduction pour les non anglophones :
[...]
Si Apple considère que seuls ses utilisateurs avancés ont la possibilité ou les moyens d'utiliser leurs produits, il est à craindre une vague de terreur, de crainte, de hantise, voire la trouille d'utiliser Mac OS X.
[...]

N'est-ce pas vous plutôt qui risquez de propager une "vague de terreur" injustifiée ?

Car si j'ai bien compris, ne sont éventuellement concernés côté Mac que les Macs dont les propriétaires ont :

• activé le partage web (serveur web, cups), ce qui n'est plus possible de manière simple depuis les Préférences Système,
• ou autorisé les "Sessions à distance" (remote login, ssh) depuis la zone Partage des Préférences Système.

Donc en gros, les serveurs.
Sinon, qui d'autre pourrait être concerné ?
Plutôt que de donner des lignes de commande à exécuter dans le Terminal, un site responsable ne devrait-il pas au contraire indiquer de manière simple et compréhensible par tout le monde comment se protéger ?
En l'occurrence, il semblerait donc bien qu'il suffise tout bêtement de ne pas activer les options sus-citées et d'attendre la mise à jour promise par Apple.
Un expert en scripts shell es sécurité peut-il confirmer ?

Edit :
D'après Arst Technica, ça y est, la faille est en cours d'exploitation.
Franchement, je ne les trouve pas cool du tout ces types qui révèlent l'existence de failles publiquement avant qu'elles ne soient corrigées.

Ce message a été modifié par marc_os - 26 Sep 2014, 16:55.

[bad_duck]

Tu as mal compris oui, j'ai par exemple posté un exemple d'escalade de privilèges lié à VMWare donc rien à voir avec le ssh ou Apache dans ce cas...

Bash est utilisé par de nombreux programmes !

[ericb2]

@marc_os

Je me suis posé la même question : quel est le but ? (à qui profite le crime ?)

Et je me suis souvenu qu'on avait eu le même effet avec OpenOffice (Apache, mais LibreOffice ils valent pas mieux).


L'histoire : un jour, il a été décidé que tout ce qui touchait la sécurité, devait obligatoirement rester secret, même avec OpenOffice.
Alors j'ai demandé, si je pouvais en savoir plus, si je pouvais être inscrit à la liste sur laquelle on pouvait "savoir".
On m'a dit non => je suis parti. Ça faisait presque 10 ans que je contribuais. Et donc, depuis, c'est la course à la sécurité.


Pour revenir au sujet, un bémol : il faut quand même être un peu connaisseur pour venir lire et surtout utiliser ce qui se raconte ici, non ?

[trouspinette]

N'est-ce pas vous qui êtes en train de propager une "vague de terreur" injustifiée ?

Je ne crois pas :-) Prenez le sur le ton de l'humour, ça passe mieux

Ceci dit, oui ça peut foutre la trouille, mais le conditionnement est [assez] élevé pour en être victime.

La communauté OpenSource a [très] vite réagi : Apple devrait bien s'en inspirer (même si visiblement certaines corrections n'ont pas eu l'effet attendu).

Tout ces points de sécurité ne sont pas à prendre à la légère : les techniques exploités par "les vilains hackers" n'ont qu'un effet limité si c'est pour changer une page d'accueil, mais d'autres exploits peuvent impacter fortement le monde numérique ultra-connecté.

Enfin, rassurez vous, l'actualité récente de l'otage français est bien plus critique que cette faille. La "vague de terreur" que d'aucuns aimeraient propager a plus d'impact...

Franchement, je ne les trouve pas cool du tout ces types qui révèlent l'existence de failles publiquement avant qu'elles ne soient corrigées.

Ah bon ??? Pourtant, ça peut servir...

[scoub_rosnoen]

Pour revenir au sujet, un bémol : il faut quand même être un peu connaisseur pour venir lire et surtout utiliser ce qui se raconte ici, non ?

En général, ceux qui ont des serveur OS x font un minimum de veille, et lisent les forum dédiés aux Mac. Cela va toucher les quelques débiles comme moi qui utilisent encore des OS X server ... En tout cas, merci aux membres qui travaillent sur ce probème .

Ce message a été modifié par scoub_rosnoen - 26 Sep 2014, 17:16.

[Chriz]

...
for ((i=1; i<26 ;i++)) do echo $i ; patch -p0 < ../patches/bash43-0$i.diff ; done
patch -p0 ../eol-pushback.patch
./configure
make

Enfin, MERCI à Chriz et à Sigourney bien sûr :-)

Merci pour l'ajout!

Plutôt que de donner des lignes de commande à exécuter dans le Terminal, un site responsable ne devrait-il pas au contraire indiquer de manière simple et compréhensible par tout le monde comment se protéger ?
En l'occurrence, il semblerait donc bien qu'il suffise tout bêtement de ne pas activer les options sus-citées et d'attendre la mise à jour promise par Apple.
Un expert en scripts shell es sécurité peut-il confirmer ?

On croyait avoir été assez explicite avec nos étapes détaillées ou en utilisant HomeBrew, mais... à défaut de vouloir mettre à jour eux-même, ceux qui hébergent des services faisant appel à bash peuvent:

- Attendre la MàJ d'Apple
- Migrer vers un environnement patché (Linux) ou non affecté (Windows)
- Ignorer le problème... (La sécurité par obscurité est aussi valable: On ne dit à personne que la technologie utilisée est affectée et on prie pour que personne ne le découvre et profite de la faille)
- Stopper les services hébergés, tirer le fil réseau ou éteindre le serveur... (Vos clients attendront)

Edit :
D'après Arst Technica, ça y est, la faille est en cours d'exploitation.
Franchement, je ne les trouve pas cool du tout ces types qui révèlent l'existence de failles publiquement avant qu'elles ne soient corrigées.

Ceci a été remonté auprès de RedHat via Bugzilla par un Belge habitant à Édimbourg. C'est la méthode utilisée pour rapporter les bugs...

Après, si certaines compagnies ne sont pas foutues d'appliquer la patch, de recompiler et de la distribuer via Software Updates dans un délai respectable... (Quoique, ça détournerait un développeur travaillant sur les patchs de iOS... )

Ce message a été modifié par Chriz - 26 Sep 2014, 17:44.

[Bicougnot]

J'ai un peu la flemme d'installer Xcode sur tout mes OS X server... et de compiler J'aimerai bien qu'Apple fournisse le patche assez vite. Parce que faire ça sur 50 machines les bras m'en tombent..

J'ai mis beaucoup de temps a comprendre que si je voulais gcc je devais installer xcode... Je comprends toujours pas comment ce n'est pas possible d'installer gcc seul sur mac. Ou alors j'ai loupé un truc. C'est le B.A.BA. pour moi d'avoir un compilateur, c'est le seul logiciel capable d'en générer et installer d'autres...

[benja]

J'ai un peu la flemme d'installer Xcode sur tout mes OS X server... et de compiler J'aimerai bien qu'Apple fournisse le patche assez vite. Parce que faire ça sur 50 machines les bras m'en tombent..

J'ai mis beaucoup de temps a comprendre que si je voulais gcc je devais installer xcode... Je comprends toujours pas comment ce n'est pas possible d'installer gcc seul sur mac. Ou alors j'ai loupé un truc. C'est le B.A.BA. pour moi d'avoir un compilateur, c'est le seul logiciel capable d'en générer et installer d'autres...

Il est possible d'installer gcc sans Xcode. Il s'agit des "Command Line Tools".

La manip par ici.

Ce message a été modifié par benja - 26 Sep 2014, 18:45.

[Bicougnot]

Oui j'ai vu ça depuis, ça n'existait pas quand j'ai acheté mon premier mac. Ceci dit c'est quand même intitulé xcode...

[oume]

Edit :
D'après Arst Technica, ça y est, la faille est en cours d'exploitation.
Franchement, je ne les trouve pas cool du tout ces types qui révèlent l'existence de failles publiquement avant qu'elles ne soient corrigées.

Elle l'est depuis mercredi soir, juste comme ça. Le truc chouette avec cette faille c'est la possibilité d'utiliser wget et d'exécuter avec les même droits que l'appli qui va traiter la requête. Du coup ils balancent tous leurs binaires backdoorés ou leurs scripts en perl/python et ya juste à tendre la main pour les récup.

Ce message a été modifié par oume - 26 Sep 2014, 22:48.

[scoub_rosnoen]

Edit :
D'après Arst Technica, ça y est, la faille est en cours d'exploitation.
Franchement, je ne les trouve pas cool du tout ces types qui révèlent l'existence de failles publiquement avant qu'elles ne soient corrigées.

Elle l'est depuis mercredi soir, juste comme ça. Le truc chouette avec cette faille c'est la possibilité d'utiliser wget et d'exécuter avec les même droits que l'appli qui va la traiter la requête. Du coup ils balancent tous leurs binaire backdoorer ou leurs scripts en perl/python et ya juste à récup à tendre la main pour les récup.

Merci oume, et pour rebondir sur ton message : Merde... et il y a des bisounours sur ce forum qui croient que les failles ne sont utilisées que lorsque qu'elles sont rendues publiques ou corrigées... Bon toujours pas de patch d'Apple actuellement, il faudrait qu'ils reviennent de congés ( pourquoi je ne suis pas étonné ? ).

Ce message a été modifié par scoub_rosnoen - 26 Sep 2014, 21:24.

[benja]

A noter qu'un nouveau patch a été distribué aujourd'hui car il semble que le premier ne résolvait pas tout. J'ai remarqué ce soir sur mon serveur debian qu'un apt-get update me donnait un nouveau patch du bash, chose confirmée depuis par ArsTechnica. Ceux qui ont patché leur bash avant aujourd'hui midi devraient vérifier si un nouveau n'est pas disponible.

Ce message a été modifié par benja - 26 Sep 2014, 21:51.

[Chriz]

A noter qu'un nouveau patch a été distribué aujourd'hui car il semble que le premier ne résolvait pas tout. J'ai remarqué ce soir sur mon serveur debian qu'un apt-get update me donnait un nouveau patch du bash, chose confirmée depuis par ArsTechnica. Ceux qui ont patché leur bash avant aujourd'hui midi devraient vérifier si un nouveau n'est pas disponible.

Je confirme: La patch bash43-026 est maintenant disponible sur le site de GNU.

Merci!

[r@net54]

si appel a sudo il faut un mot de passe...
de plus les appels au shell existent depuis une eternite

Ben la première fois oui, apres il y a une temporisation qui permet d'exécuter des instructions sans rentrer le mot de passe… la meme connerie que sur l'itune store…

Apres, oui il faut un mot de passe, mais pour peu qu'il n'y ait qu'un compte (donc avec droit d'administrateur) on peut faire une petite horreur du genre
sudo zsh
(ça marche avec tous les shell)
et la on exécute le shell en administrateur tout le temps…

tant qu'en shell on pourra faire
eval "$1" et que l'on pourra fixer des drapeaux ( setuid Permission) pour exécuter en root sans sudo initial (genre /usr/bin/passwd) il y aura des risques.

[gedsismik]

Pour celles et ceux que ça intéresse, j'ai utilisé ça :

1. Pour celles et ceux qui peuvent compiler

1.1. Prérequis :

• gcc (installable via XCode ou https://github.com/kennethreitz/osx-gcc-installer )

1.2. Les scripts

01-dlPatch.sh

Code

#!/bin/sh

[[ ! -e bash-4.3.tar.gz ]] && curl -O ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz

for i in {1..27}
do
    echo $i
    F=$i
    [[ $F -lt 10 ]] && F="0$i"
    if [ ! -e "bash43-0$F" ]
    then
        curl -O "ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-0$F"
    fi
done

02-compil.sh

Code

#!/bin/sh

PATCHDIR=$PWD
DEST=$PWD/install

[[ -e "$DEST" ]] && rm -rf "${DEST}"
mkdir -p "${DEST}"

tar -xvf bash-4.3.tar.gz
cd bash-4.3
for i in $PATCHDIR/bash43-*
do
    cat $i | patch -p0
done

./configure || exit 1
make -j6 || make || exit 2
make install DESTDIR=$DEST

if [ $? -eq 0 ]
then
    echo "[INFO] La compilation s'est bien passee"
else
    echo "[ERREUR] Probleme a la compilation"
fi

03-install.sh

Code

#!/bin/sh

DEST=$PWD/install

if [ $(id -u) -ne 0 ]; then echo "[ERREUR] Le script doit etre lance en root"; exit 1;fi
if [ ! -d "$DEST" ]; then echo "[ERREUR] $DEST inexistant"; exit 1; fi
if [ ! -e "$DEST/usr/local/bin/bash" ]; then echo "[ERREUR] binaire bash inexistant"; exit 1;fi

[ -e /bin/bash-faille ] && mv /bin/bash-faille /bin/bash-faille-$(date +%Y%m%d%H%M%S)
mv /bin/bash /bin/bash-faille
cp $DEST/usr/local/bin/bash /bin/bash

Les scripts sont téléchargeables ici : http://dl.free.fr/peu3NBNpn ou en pièce jointe ci-dessous.

1.3. Procédure

Code

$ ./01-dlPatch.sh
$ ./02-compil.sh
$ sudo ./03-install.sh

1.4. Résultat

Code

mavericks:~ gedsismik$ bash --version
GNU bash, version 4.3.25(1)-release (x86_64-apple-darwin13.4.0)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
mavericks:~ gedsismik$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

2. Pour celles et ceux qui ne veulent/peuvent pas compiler
Dans le fichier http://dl.free.fr/peu3NBNpn (ou en pièce jointe ci-dessous), j'ai placé aussi le binaire bash que j'ai compilé (3.4.25).

• Décompressez
• Tester le binaire bash-osx-10.9.5.OK
• Si il fonctionne, copiez-le : mv /bin/bash /bin/bash-old ; cp bash-osx-10.9.5.OK /bin/bash

J'ai un peu la flemme d'installer Xcode sur tout mes OS X server... et de compiler J'aimerai bien qu'Apple fournisse le patche assez vite. Parce que faire ça sur 50 machines les bras m'en tombent..

Compile sur chaque OS/archi. Ca va te faire ptet 3 binaires si t'es sous 3 versions différentes d'OS X (et encore, c'est surement compatible d'une version sur l'autre). Et déploie ces 3 versions sur tous les serveurs.

EDIT : Prise en compte des patchs 26 et 27 et lien pour les packages de gcc.
EDIT2 : Arf... je viens de découvrir qu'on pouvait mettre des pièces jointes aux posts. Ajout du zip en pj.

Ce message a été modifié par gedsismik - 30 Sep 2014, 11:42.

Fichier(s) joint(s)

 bash_fix_pack.zip ( 1.02 Mo ) Nombre de téléchargements : 6