Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

It's super easy to install a patch using dkpg and apt. I didn't question that.

The problem is that you have to wait for the patch to be bundled. I've watched that take a long time, while services I knew to be vulnerable had to sit there and be vulnerable because the organization deploying the service didn't have any infrastructure to apply a custom patch.

Consider the degenerate case, where you have to wait for a Debian patch because you paid for the research that found the vulnerability. More than one of my clients wound up in that situation. But that's not the only way to learn about a simple, critical source patch that won't land in a Debian patch for days.

You bundle or create it yourself..

    $ apt-get source bash
    $ cd bash*/
    $ quilt new my_urgent_patch
    $ patch -p1 < ~/my-urgent-patch.diff
    $ quilt add file1 file2
    $ quilt refresh
    $ dpkg-buildpackage ...
    $ dupload ../*.changes
    # trigger apt-get upgrade on target machines

That's fine. I don't care what you do with your self-built binaries once you manage to build them yourself. But too many firms have no infrastructure in place to do that. They wait for upstreams to synchronize to fix security flaws that they could fix directly.

scp and "dpkg -i" are readily available, but it's really not that much work to setup a repository (aptly, reprepro, apt-ftparchive etc.)

I know I'd personally chose maintaining the system packages and where possible put extraneous language dependencies in packages too (fpm comes in handy as it can deal with a variety of packages, gem, npm etc). It makes life a lot simpler when it comes to administering a bunch of systems and trying to keep things consistent.

Reply on news.ycombinator.com