eduTrain

Lesson 14 / الدرس 14

Other people's code, running as you / كود غيرك، يعمل بصفتك

Every library you install runs with your application's full permissions, and every one you do not update accumulates published vulnerabilities. Both facts point the same way: take fewer dependencies, and update the ones you take.

كل مكتبة تثبّتها تعمل بصلاحيات تطبيقك كاملة، وكل واحدة لا تحدّثها تراكم ثغرات منشورة. والحقيقتان تشيران إلى الجهة نفسها: خذ اعتماديات أقل، وحدّث ما تأخذه.

A dependency is not a tool you use; it is code that runs inside your application with the same access you have. It can read your configuration, query your database and make network requests, and so can everything it depends on — a list you have usually never read and that grows without your involvement.

The question to ask before installing anything

  • How much of this do I need? A package to check whether a string is empty is a real thing that real projects install. If the answer is a few lines, write the few lines.
  • What does it bring with it? One package can pull in forty. Look at the count before installing, not after, because removing it later removes only the one you named.
  • Is anyone maintaining it? Last release, open issues, how many people can publish a new version. A widely used package with one maintainer is a risk to that person as much as to you.
  • What happens if it stops? Not hypothetical — packages get abandoned, renamed, and occasionally deleted. Something you could replace in a day is a different proposition from something woven through every file. 
# What am I actually running, and is any of it known-vulnerable?
$ composer show --tree | head -40
$ composer audit

# What would updating change? Read this before running it.
$ composer outdated --direct

# composer.lock is COMMITTED. It records the exact versions that were
# tested, so the server installs what you tested rather than whatever
# is newest at the moment it happens to deploy.
$ composer install --no-dev --optimize-autoloader

# NOT 'composer update' on the server. That resolves fresh versions
# nobody has run, during a deploy, which is the worst possible moment
# to first meet a breaking change.
The distinction in the last comment is the one worth carrying away. install reproduces what you tested; update decides something new. Updating is a change like any other — it happens on your machine, the tests run, and it goes out as its own deploy.

Updating is a risk; not updating is a bigger one

Teams avoid updates because an update can break something, and end up two years behind with an upgrade nobody can afford to attempt. Meanwhile every vulnerability found in those two years is published, with the version numbers affected, in a database anyone can search. Staying current is not about new features; it is that the alternative is a public list of ways into your site.

Check yourself / اختبر نفسك

1. What permissions does a library you install run with?

2. Why run composer install rather than composer update on the server?

3. Why is staying two years behind on updates dangerous?