Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
composer global einstellen
2 views
Skip to first unread message
Tim Ritberg
Jan 14, 2022, 1:50:41 PM1/14/22
to
Hi!
Welche Möglichkeiten gibt es composer global auf einem Server (root)
einzustellen?
Zb. nur bestimmte Quellen erlauben?
Tim
Welche Möglichkeiten gibt es composer global auf einem Server (root)
einzustellen?
Zb. nur bestimmte Quellen erlauben?
Tim
Arno Welzel
Jan 14, 2022, 4:23:28 PM1/14/22
to
Tim Ritberg:
> Welche Möglichkeiten gibt es composer global auf einem Server (root)
> einzustellen?
> Zb. nur bestimmte Quellen erlauben?
Keine. Jeder Entwickler kann in packages.json beliebige Quellen eintragen:
<https://getcomposer.org/doc/05-repositories.md>
Composer ist auch *nicht* für die Nutzung auf Servern gedacht!
Deployment auf Servern macht man anders, z.B. einem Script, was
Composer, NPM etc. lokal ausführt, und das Ergebnis dann als Paket
bereitstellt, was man auf einem Server einrichten kann.
--
Arno Welzel
https://arnowelzel.de
> Welche Möglichkeiten gibt es composer global auf einem Server (root)
> einzustellen?
> Zb. nur bestimmte Quellen erlauben?
<https://getcomposer.org/doc/05-repositories.md>
Composer ist auch *nicht* für die Nutzung auf Servern gedacht!
Deployment auf Servern macht man anders, z.B. einem Script, was
Composer, NPM etc. lokal ausführt, und das Ergebnis dann als Paket
bereitstellt, was man auf einem Server einrichten kann.
--
Arno Welzel
https://arnowelzel.de
Karl Pflästerer
Jan 14, 2022, 4:41:19 PM1/14/22
to
Server.
Immer lokal, dann checke ich sie in die Versionskontrolle ein und daraus
werden sie beim Deployment ausgespielt. Da vermeidet man jede
Überraschung mit Paketen, die sich plötzlich ändern (sie npm )
Und als root laufen lassen?
Tim Ritberg
Jan 14, 2022, 5:40:17 PM1/14/22
to
Am 14.01.22 um 22:41 schrieb Karl Pflästerer:
> Was willst du denn erreichen? composer libs lade ich *nie* auf einem
> Server.
> Immer lokal, dann checke ich sie in die Versionskontrolle ein und daraus
> werden sie beim Deployment ausgespielt. Da vermeidet man jede
> Überraschung mit Paketen, die sich plötzlich ändern (sie npm )
>
> Und als root laufen lassen?
>
in /etc.
Tim
Arno Welzel
Jan 15, 2022, 4:48:42 AM1/15/22
to
Tim Ritberg:
Composer hat keine Konfiguration in /etc. Es nutzt die Datei
composer.json im aktuellen Verzeichnis - und da können eben beliebige
Quellen drinstehen, eben weil es ein Entwicklungswerkzeug ist. curl und
wget kann man auch nicht verbieten, bestimmte URLs aufzurufen.
composer.json im aktuellen Verzeichnis - und da können eben beliebige
Quellen drinstehen, eben weil es ein Entwicklungswerkzeug ist. curl und
wget kann man auch nicht verbieten, bestimmte URLs aufzurufen.
Tim Ritberg
Jan 15, 2022, 5:22:55 AM1/15/22
to
Am 15.01.22 um 10:48 schrieb Arno Welzel:
> Composer hat keine Konfiguration in /etc. Es nutzt die Datei
> composer.json im aktuellen Verzeichnis - und da können eben beliebige
> Quellen drinstehen, eben weil es ein Entwicklungswerkzeug ist. curl und
> wget kann man auch nicht verbieten, bestimmte URLs aufzurufen.
>
>
Naja, wget hat schon eine Config in /etc, kann man aber sicher umgehen.
Der einzige Ansatz scheint wohl ein Proxy zu sein.
Tim
> Composer hat keine Konfiguration in /etc. Es nutzt die Datei
> composer.json im aktuellen Verzeichnis - und da können eben beliebige
> Quellen drinstehen, eben weil es ein Entwicklungswerkzeug ist. curl und
> wget kann man auch nicht verbieten, bestimmte URLs aufzurufen.
>
>
Der einzige Ansatz scheint wohl ein Proxy zu sein.
Tim
Arno Welzel
Jan 15, 2022, 6:20:51 AM1/15/22
to
Tim Ritberg:
> Am 15.01.22 um 10:48 schrieb Arno Welzel:
>
>> Composer hat keine Konfiguration in /etc. Es nutzt die Datei
>> composer.json im aktuellen Verzeichnis - und da können eben beliebige
>> Quellen drinstehen, eben weil es ein Entwicklungswerkzeug ist. curl und
>> wget kann man auch nicht verbieten, bestimmte URLs aufzurufen.
>>
>>
>
> Naja, wget hat schon eine Config in /etc, kann man aber sicher umgehen.
Aber auch da steht nicht drin, dass bestimmte URLs nicht aufgerufen
werden dürfen.
> Der einzige Ansatz scheint wohl ein Proxy zu sein.
Korrekt.
> Am 15.01.22 um 10:48 schrieb Arno Welzel:
>
>> Composer hat keine Konfiguration in /etc. Es nutzt die Datei
>> composer.json im aktuellen Verzeichnis - und da können eben beliebige
>> Quellen drinstehen, eben weil es ein Entwicklungswerkzeug ist. curl und
>> wget kann man auch nicht verbieten, bestimmte URLs aufzurufen.
>>
>>
>
> Naja, wget hat schon eine Config in /etc, kann man aber sicher umgehen.
werden dürfen.
> Der einzige Ansatz scheint wohl ein Proxy zu sein.
Tim Ritberg
Jan 15, 2022, 6:51:38 AM1/15/22
to
Am 15.01.22 um 12:20 schrieb Arno Welzel:
>> Der einzige Ansatz scheint wohl ein Proxy zu sein.
>
> Korrekt.
Kannst du mehr dazu erzählen?
Wenn ich composer jetzt mit apt oder yum vergleiche, scheindet das ja
sehr schlecht ab.
Wie ist da eine gute Strategie für Sicherheit?
Tim
>> Der einzige Ansatz scheint wohl ein Proxy zu sein.
>
> Korrekt.
Wenn ich composer jetzt mit apt oder yum vergleiche, scheindet das ja
sehr schlecht ab.
Wie ist da eine gute Strategie für Sicherheit?
Tim
Arno Welzel
Jan 16, 2022, 11:48:28 AM1/16/22
to
Tim Ritberg:
> Am 15.01.22 um 12:20 schrieb Arno Welzel:
>
>>> Der einzige Ansatz scheint wohl ein Proxy zu sein.
>>
>> Korrekt.
>
> Kannst du mehr dazu erzählen?
Die übliche Vorgehensweise:
1) Per Paketfilter alle Zugriffe auf externe IP-Adressen verbieten, bis
auf den HTTP-Proxy, der auf einem anderen Server läuft.
2) Den HTTP-Proxy so einrichten, dass er nur Adressen auf einer
Whitelist erlaubt. Das geht z.B. auch mit NGINX:
<https://www.shayanderson.com/linux/setup-nginx-as-forward-http-proxy-with-ip-address-whitelist.htm>
3) Die Proxy-Variablen http_proxy und https_proxy entsprechend setzen,
so dass composer auch weiß, welchen Proxy er benutzen soll, z.B:
export https_proxy='http://proxy-server:8080'
export http_proxy='http://proxy-server:8080'
Composer darf natürlich nicht als root laufen, weil sonst bösartige
Pakete einfach den Paketfilter ändern.
Aber wie ich schon gesagt habe, ist composer auf einem Server ohnehin
wenig sinnvoll. Normalerweise würde man composer woanders auführen und
nur das Ergebnis auf den Server übertragen.
> Wenn ich composer jetzt mit apt oder yum vergleiche, scheindet das ja
> sehr schlecht ab.
apt und yum haben mit composer nur gemeinsam, dass sie Pakete verwalten.
Aber apt und yum dienen für die Verwaltung von Paketen einer
Linux-Distribution und *müssen* sicher sein. composer und dagegen sind
Werkzeuge für *Softwareentwickler*.
> Wie ist da eine gute Strategie für Sicherheit?
composer *nicht* auf Servern verwenden.
Oder benutzt Du auch git und make, um Software nicht als Paket via
apt/yum zu installieren, sondern direkt als Quellcode von Github zu laden?
> Am 15.01.22 um 12:20 schrieb Arno Welzel:
>
>>> Der einzige Ansatz scheint wohl ein Proxy zu sein.
>>
>> Korrekt.
>
> Kannst du mehr dazu erzählen?
1) Per Paketfilter alle Zugriffe auf externe IP-Adressen verbieten, bis
auf den HTTP-Proxy, der auf einem anderen Server läuft.
2) Den HTTP-Proxy so einrichten, dass er nur Adressen auf einer
Whitelist erlaubt. Das geht z.B. auch mit NGINX:
<https://www.shayanderson.com/linux/setup-nginx-as-forward-http-proxy-with-ip-address-whitelist.htm>
3) Die Proxy-Variablen http_proxy und https_proxy entsprechend setzen,
so dass composer auch weiß, welchen Proxy er benutzen soll, z.B:
export https_proxy='http://proxy-server:8080'
export http_proxy='http://proxy-server:8080'
Composer darf natürlich nicht als root laufen, weil sonst bösartige
Pakete einfach den Paketfilter ändern.
Aber wie ich schon gesagt habe, ist composer auf einem Server ohnehin
wenig sinnvoll. Normalerweise würde man composer woanders auführen und
nur das Ergebnis auf den Server übertragen.
> Wenn ich composer jetzt mit apt oder yum vergleiche, scheindet das ja
> sehr schlecht ab.
Aber apt und yum dienen für die Verwaltung von Paketen einer
Linux-Distribution und *müssen* sicher sein. composer und dagegen sind
Werkzeuge für *Softwareentwickler*.
> Wie ist da eine gute Strategie für Sicherheit?
Oder benutzt Du auch git und make, um Software nicht als Paket via
apt/yum zu installieren, sondern direkt als Quellcode von Github zu laden?
Tim Ritberg
Jan 16, 2022, 3:04:40 PM1/16/22
to
Am 16.01.22 um 17:48 schrieb Arno Welzel:
> ...
> composer *nicht* auf Servern verwenden.
Es ist kein Live-Server.
Tim
> ...
> Composer darf natürlich nicht als root laufen, weil sonst bösartige
> Pakete einfach den Paketfilter ändern.
>
> Aber wie ich schon gesagt habe, ist composer auf einem Server ohnehin
> wenig sinnvoll. Normalerweise würde man composer woanders auführen und
> nur das Ergebnis auf den Server übertragen.
Und genau dieses Ergebnis kann doch verseucht sein.
> Pakete einfach den Paketfilter ändern.
>
> Aber wie ich schon gesagt habe, ist composer auf einem Server ohnehin
> wenig sinnvoll. Normalerweise würde man composer woanders auführen und
> nur das Ergebnis auf den Server übertragen.
> composer *nicht* auf Servern verwenden.
>
> Oder benutzt Du auch git und make, um Software nicht als Paket via
> apt/yum zu installieren, sondern direkt als Quellcode von Github zu laden?
Sehr selten.
> Oder benutzt Du auch git und make, um Software nicht als Paket via
> apt/yum zu installieren, sondern direkt als Quellcode von Github zu laden?
Tim
Arno Welzel
Jan 17, 2022, 5:21:44 AM1/17/22
to
Tim Ritberg:
> Am 16.01.22 um 17:48 schrieb Arno Welzel:
>> ...
>> Composer darf natürlich nicht als root laufen, weil sonst bösartige
>> Pakete einfach den Paketfilter ändern.
>>
>> Aber wie ich schon gesagt habe, ist composer auf einem Server ohnehin
>> wenig sinnvoll. Normalerweise würde man composer woanders auführen und
>> nur das Ergebnis auf den Server übertragen.
> Und genau dieses Ergebnis kann doch verseucht sein.
Eben - deswegen sollte man es nicht auf produktiven Umgebungen machen.
Gegen mögliche bösartige Pakete oder Pakete mit Sicherheitslücken auf
den offiziellen Repositories wie packagist.org kannst Du effektiv nichts
tun, außer eben alle Pakete selber zu kontrollieren.
> Am 16.01.22 um 17:48 schrieb Arno Welzel:
>> ...
>> Composer darf natürlich nicht als root laufen, weil sonst bösartige
>> Pakete einfach den Paketfilter ändern.
>>
>> Aber wie ich schon gesagt habe, ist composer auf einem Server ohnehin
>> wenig sinnvoll. Normalerweise würde man composer woanders auführen und
>> nur das Ergebnis auf den Server übertragen.
> Und genau dieses Ergebnis kann doch verseucht sein.
Gegen mögliche bösartige Pakete oder Pakete mit Sicherheitslücken auf
den offiziellen Repositories wie packagist.org kannst Du effektiv nichts
tun, außer eben alle Pakete selber zu kontrollieren.
Tim Ritberg
Feb 3, 2022, 3:12:31 AM2/3/22
to
Am 14.01.22 um 22:23 schrieb Arno Welzel:
Tim
> Tim Ritberg:
>
>> Welche Möglichkeiten gibt es composer global auf einem Server (root)
>> einzustellen?
>> Zb. nur bestimmte Quellen erlauben?
>
> Keine. Jeder Entwickler kann in packages.json beliebige Quellen eintragen:
>
> <https://getcomposer.org/doc/05-repositories.md>
>
> Composer ist auch *nicht* für die Nutzung auf Servern gedacht!
Hm, Typo3, Wordpress und Drupal machen doch genau das.
>
>> Welche Möglichkeiten gibt es composer global auf einem Server (root)
>> einzustellen?
>> Zb. nur bestimmte Quellen erlauben?
>
> Keine. Jeder Entwickler kann in packages.json beliebige Quellen eintragen:
>
> <https://getcomposer.org/doc/05-repositories.md>
>
> Composer ist auch *nicht* für die Nutzung auf Servern gedacht!
Tim
Arno Welzel
Feb 3, 2022, 1:04:37 PM2/3/22
to
Tim Ritberg:
Nein, nicht dass ich wüsste.
Üblicherweise werden Archive zum Download angeboten, die man in das
Verzeichnis der Website entpackt, wo das Ding dann soll. Composer wird
für die Installation *nicht* benötigt, auch nicht für Updates.
Siehe auch:
<https://get.typo3.org/#download>
<https://wordpress.org/download/#download-install>
<https://www.drupal.org/download>
Üblicherweise werden Archive zum Download angeboten, die man in das
Verzeichnis der Website entpackt, wo das Ding dann soll. Composer wird
für die Installation *nicht* benötigt, auch nicht für Updates.
Siehe auch:
<https://get.typo3.org/#download>
<https://wordpress.org/download/#download-install>
<https://www.drupal.org/download>
Arno Welzel
Feb 3, 2022, 1:08:26 PM2/3/22
to
Arno Welzel:
Ergänzend:
Ich sehe gerade, dass Drupal *auch* die Option anbietet, es mit Composer
zu installieren. Das bedeutet aber *nicht*, dass man das auf einem
produktiven Server so tun sollte - schon deshalb, weil man nie weiß, was
Composer in dem Moment wirklich installiert.
Drupal wird auch als komplettes Paket wahlweise als ZIP-Datei oder
tarball mit allen Abhängigkeiten angeboten.
Ich sehe gerade, dass Drupal *auch* die Option anbietet, es mit Composer
zu installieren. Das bedeutet aber *nicht*, dass man das auf einem
produktiven Server so tun sollte - schon deshalb, weil man nie weiß, was
Composer in dem Moment wirklich installiert.
Drupal wird auch als komplettes Paket wahlweise als ZIP-Datei oder
tarball mit allen Abhängigkeiten angeboten.
Tim Ritberg
Feb 3, 2022, 2:05:05 PM2/3/22
to
Am 03.02.22 um 19:08 schrieb Arno Welzel:
> Arno Welzel:
>
>> Tim Ritberg:
>>
>>> Am 14.01.22 um 22:23 schrieb Arno Welzel:
>>>> Tim Ritberg:
>>>>
>>>>> Welche Möglichkeiten gibt es composer global auf einem Server (root)
>>>>> einzustellen?
>>>>> Zb. nur bestimmte Quellen erlauben?
>>>>
>>>> Keine. Jeder Entwickler kann in packages.json beliebige Quellen eintragen:
>>>>
>>>> <https://getcomposer.org/doc/05-repositories.md>
>>>>
>>>> Composer ist auch *nicht* für die Nutzung auf Servern gedacht!
>>> Hm, Typo3, Wordpress und Drupal machen doch genau das.
>>
>> Nein, nicht dass ich wüsste.
>>
>> Üblicherweise werden Archive zum Download angeboten, die man in das
>> Verzeichnis der Website entpackt, wo das Ding dann soll. Composer wird
>> für die Installation *nicht* benötigt, auch nicht für Updates.
>>
Das war mal nur früher(tm) so.
>
>> Tim Ritberg:
>>
>>> Am 14.01.22 um 22:23 schrieb Arno Welzel:
>>>> Tim Ritberg:
>>>>
>>>>> Welche Möglichkeiten gibt es composer global auf einem Server (root)
>>>>> einzustellen?
>>>>> Zb. nur bestimmte Quellen erlauben?
>>>>
>>>> Keine. Jeder Entwickler kann in packages.json beliebige Quellen eintragen:
>>>>
>>>> <https://getcomposer.org/doc/05-repositories.md>
>>>>
>>>> Composer ist auch *nicht* für die Nutzung auf Servern gedacht!
>>> Hm, Typo3, Wordpress und Drupal machen doch genau das.
>>
>> Nein, nicht dass ich wüsste.
>>
>> Üblicherweise werden Archive zum Download angeboten, die man in das
>> Verzeichnis der Website entpackt, wo das Ding dann soll. Composer wird
>> für die Installation *nicht* benötigt, auch nicht für Updates.
>>
https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/QuickInstall/Composer/Index.html
Kommt mir das nur so vor, ist das eine Fehlentwicklung.
Tim
Arno Welzel
Feb 3, 2022, 5:12:56 PM2/3/22
to
Tim Ritberg:
> Am 03.02.22 um 19:08 schrieb Arno Welzel:
[...]
<https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/QuickInstall/GetAndUnpack/Index.html#install-typo3-without-composer>
Wenn es irgendwann *nur* noch mit composter geht, würde ich das als
Fehlentwicklung ansehen.
Composer ist für die Entwicklung zweifellos bequem - man erstellt nur
eine Liste von Abhängigkeiten und muss nich nicht darum kümmern, wie man
die Pakete herankommt.
Aber wenn man als Anbieter am Ende selber etwas ausliefert, sollte man
schon sicherstellen, dass genau das geliefert wird, was man ausliefern
will und nicht am Ende von composer irgendwas installiert wird, was
womöglich komprimittiert wurde.
Mag sein, dass sowas bei npm eher passiert, als bei composer - aber die
Möglichkeit ist nicht nur graue Theorie:
<https://www.inside-it.ch/post/php-supply-chain-schwachstelle-in-composer-entdeckt-20210505>
<https://www.heise.de/news/Unbekannte-infiltrieren-Paketmanager-npm-und-verseuchen-Tools-mit-Schadcode-6260153.html>
<https://alltechnews.de/beliebtes-npm-paket-wird-zur-veroeffentlichung-von-krypto-mining-malware-gekapert-7394>
<https://www.zdnet.de/88375891/microsoft-schaedliches-npm-paket-stiehlt-vertrauliche-daten-von-unix-systemen/>
> Am 03.02.22 um 19:08 schrieb Arno Welzel:
>>> Üblicherweise werden Archive zum Download angeboten, die man in das
>>> Verzeichnis der Website entpackt, wo das Ding dann soll. Composer wird
>>> für die Installation *nicht* benötigt, auch nicht für Updates.
>>>
>
> Das war mal nur früher(tm) so.
> https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/QuickInstall/Composer/Index.html
>
> Kommt mir das nur so vor, ist das eine Fehlentwicklung.
Es geht auch ohne Composer:
>>> Verzeichnis der Website entpackt, wo das Ding dann soll. Composer wird
>>> für die Installation *nicht* benötigt, auch nicht für Updates.
>>>
>
> Das war mal nur früher(tm) so.
> https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/QuickInstall/Composer/Index.html
>
> Kommt mir das nur so vor, ist das eine Fehlentwicklung.
<https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/QuickInstall/GetAndUnpack/Index.html#install-typo3-without-composer>
Wenn es irgendwann *nur* noch mit composter geht, würde ich das als
Fehlentwicklung ansehen.
Composer ist für die Entwicklung zweifellos bequem - man erstellt nur
eine Liste von Abhängigkeiten und muss nich nicht darum kümmern, wie man
die Pakete herankommt.
Aber wenn man als Anbieter am Ende selber etwas ausliefert, sollte man
schon sicherstellen, dass genau das geliefert wird, was man ausliefern
will und nicht am Ende von composer irgendwas installiert wird, was
womöglich komprimittiert wurde.
Mag sein, dass sowas bei npm eher passiert, als bei composer - aber die
Möglichkeit ist nicht nur graue Theorie:
<https://www.inside-it.ch/post/php-supply-chain-schwachstelle-in-composer-entdeckt-20210505>
<https://www.heise.de/news/Unbekannte-infiltrieren-Paketmanager-npm-und-verseuchen-Tools-mit-Schadcode-6260153.html>
<https://alltechnews.de/beliebtes-npm-paket-wird-zur-veroeffentlichung-von-krypto-mining-malware-gekapert-7394>
<https://www.zdnet.de/88375891/microsoft-schaedliches-npm-paket-stiehlt-vertrauliche-daten-von-unix-systemen/>
Tim Ritberg
Feb 4, 2022, 1:56:44 AM2/4/22
to
Am 03.02.22 um 23:12 schrieb Arno Welzel:
>
> Wenn es irgendwann *nur* noch mit composter geht, würde ich das als
> Fehlentwicklung ansehen.
>
> Composer ist für die Entwicklung zweifellos bequem - man erstellt nur
> eine Liste von Abhängigkeiten und muss nich nicht darum kümmern, wie man
> die Pakete herankommt.
>
> Aber wenn man als Anbieter am Ende selber etwas ausliefert, sollte man
> schon sicherstellen, dass genau das geliefert wird, was man ausliefern
> will und nicht am Ende von composer irgendwas installiert wird, was
> womöglich komprimittiert wurde.
> ...
Das ist meine Befürchtung.
Tim
> Es geht auch ohne Composer:
>
> <https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/QuickInstall/GetAndUnpack/Index.html#install-typo3-without-composer>
Weiss ich doch. Ich bin noch Generation Tarball.
>
> <https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/QuickInstall/GetAndUnpack/Index.html#install-typo3-without-composer>
>
> Wenn es irgendwann *nur* noch mit composter geht, würde ich das als
> Fehlentwicklung ansehen.
>
> Composer ist für die Entwicklung zweifellos bequem - man erstellt nur
> eine Liste von Abhängigkeiten und muss nich nicht darum kümmern, wie man
> die Pakete herankommt.
>
> Aber wenn man als Anbieter am Ende selber etwas ausliefert, sollte man
> schon sicherstellen, dass genau das geliefert wird, was man ausliefern
> will und nicht am Ende von composer irgendwas installiert wird, was
> womöglich komprimittiert wurde.
Das ist meine Befürchtung.
Tim
0 new messages