4 ms·

> when things go wrong, you want to be prepared to patch source on a moment's notice, rather than waiting for the upstream synchronization dance This is IMHO t

by _wmd 11y ago

> when things go wrong, you want to be prepared to patch source on a moment's notice, rather than waiting for the upstream synchronization dance This is IMHO the most backwards logic ever. Everything about dpkg and apt makes this process easy, from running an internal custom packages repository, through to "apt-get source" for any system package on a moment's notice, through to having everything just magically revert back to Debian-patched versions as part of the normal upgrade process assuming you versioned your custom packages carefully. A well run Debian shop is a thing to be seen, unfortunately it's not cohesively documented in any one location on the Internet. If there's any problem encountered in the wild on the Internet, after 22 years, there is almost certainly a solid process built into Debian to handle it. Compare that to home directories full of tarballs of binaries with dubious compiler settings and godknows what else, I have no idea why someone would advocate against it, assuming of course they've actually done sysadmin anywhere aside from the comfort of an armchair

tptacek 11y ago
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.
- _wmd 11y ago
  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
  - tptacek 11y ago
    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.
    - coalescence 11y ago
      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.

by _wmd 11y ago

tptacek 11y ago

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.

_wmd 11y ago
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
- tptacek 11y ago
  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.
  - coalescence 11y ago
    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.