3 ms·

I was doing sysadmin the "right way" a long, long time ago, and I don't see much difference. Maybe the author regularly does full audits of the source code of e

I was doing sysadmin the "right way" a long, long time ago, and I don't see much difference. Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. There's no wisdom or security to be gained from the act of running "make", much less "make install".

rlpb 11y ago
There's a huge difference. > Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. What matters is that the source code is auditable. It only takes one person to investigate something suspicious, raise a flag and get it fixed. This is certainly still true for Debian - not being able to build from source is considered a release blocking bug.
- kibibu 11y ago
  Assuming you: - trust your compiler and linker - trust your tar extractor / package manager / whatever - trust your editor - trust your http library (or whatever you used to download/distribute the code)
  - Nursie 11y ago
    >> - trust your http library (or whatever you used to download/distribute the code) This can be overcome with signing. We're all well aware of how deep this rabbit-hole goes, however that doesn't mean that it's a good idea to throw all trust away.
  - rlpb 11y ago
    It comes down to trusting two key things. Trusting your initial distribution download (which contains the package signing keys), and trusting the toolchain (in a Reflections on Trusting Trust way). But the deeper you go, the harder it is for malicious code to reside there. In theory it's possible, but in practice I'd like someone to show me some code somebody could have written into the toolchain a decade ago, without hindsight, which could still exist today. Whichever way, it's clearly far tougher for a malicious actor to compromise a system by injecting something into a distribution ecosystem than it is to inject a signed-by-unknown-reputation binary-only package into the Maven ecosystem.
  - davexunit 11y ago
    This is where reproducible builds [0] come in. We can trust our binaries much more if the same build inputs yield the same build output. Building on that, could we find a fixed point where the OS builds the exact same bootstrap binaries that were used to bootstrap the OS to begin with? [1] That would give us even more confidence that the binaries we're using are as they should be. Interesting place for experimentation. [0] https://reproducible.debian.net/reproducible.html https://reproducible.debian.net/reproducible.html [1] https://gnu.org/software/guix/manual/html_node/Bootstrapping.html#Building-the-Bootstrap-Binaries https://gnu.org/software/guix/manual/html_node/Bootstrapping...
  - vacri 11y ago
    Trust isn't binary. It's a scale of weighted risks.
Nursie 11y ago
>> Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. This is not the point being made. Trust is often offloaded, say to the debian people, but it is present in most modern linux systems as a basic part of the setup. >> There's no wisdom or security to be gained from the act of running "make", much less "make install". 'make' is brought up not because everyone should be running "make" or "make install", but because it's a standard and it is understood by many people. It's brought up in the context of hadoop because the hadoop build system appears to be just so complicated and non-standard, including pulling in untrusted sources from all over the place, that it is near impossible to set it up as a well-audited, standardised package. Given this, it is likely to be a hive of vulnerabilities, either during the setup phase (if any of the third party servers gets compromised or MITM'd) or during deployment (that java VM it pulled in during setup is never going to get patched).
hahainternet 11y ago
> There's no wisdom or security to be gained from the act of running "make", much less "make install". You were not doing sysadmin right. DESTDIR and checkinstall are two vital tools that are learned from the mistakes of make/make install.

rlpb 11y ago

There's a huge difference. > Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. What matters is that the source code is auditable. It only takes one person to investigate something suspicious, raise a flag and get it fixed. This is certainly still true for Debian - not being able to build from source is considered a release blocking bug.

kibibu 11y ago
Assuming you: - trust your compiler and linker - trust your tar extractor / package manager / whatever - trust your editor - trust your http library (or whatever you used to download/distribute the code)
- Nursie 11y ago
  >> - trust your http library (or whatever you used to download/distribute the code) This can be overcome with signing. We're all well aware of how deep this rabbit-hole goes, however that doesn't mean that it's a good idea to throw all trust away.
- rlpb 11y ago
  It comes down to trusting two key things. Trusting your initial distribution download (which contains the package signing keys), and trusting the toolchain (in a Reflections on Trusting Trust way). But the deeper you go, the harder it is for malicious code to reside there. In theory it's possible, but in practice I'd like someone to show me some code somebody could have written into the toolchain a decade ago, without hindsight, which could still exist today. Whichever way, it's clearly far tougher for a malicious actor to compromise a system by injecting something into a distribution ecosystem than it is to inject a signed-by-unknown-reputation binary-only package into the Maven ecosystem.
- davexunit 11y ago
  This is where reproducible builds [0] come in. We can trust our binaries much more if the same build inputs yield the same build output. Building on that, could we find a fixed point where the OS builds the exact same bootstrap binaries that were used to bootstrap the OS to begin with? [1] That would give us even more confidence that the binaries we're using are as they should be. Interesting place for experimentation. [0] https://reproducible.debian.net/reproducible.html https://reproducible.debian.net/reproducible.html [1] https://gnu.org/software/guix/manual/html_node/Bootstrapping.html#Building-the-Bootstrap-Binaries https://gnu.org/software/guix/manual/html_node/Bootstrapping...
- vacri 11y ago
  Trust isn't binary. It's a scale of weighted risks.

Nursie 11y ago

>> Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. This is not the point being made. Trust is often offloaded, say to the debian people, but it is present in most modern linux systems as a basic part of the setup. >> There's no wisdom or security to be gained from the act of running "make", much less "make install". 'make' is brought up not because everyone should be running "make" or "make install", but because it's a standard and it is understood by many people. It's brought up in the context of hadoop because the hadoop build system appears to be just so complicated and non-standard, including pulling in untrusted sources from all over the place, that it is near impossible to set it up as a well-audited, standardised package. Given this, it is likely to be a hive of vulnerabilities, either during the setup phase (if any of the third party servers gets compromised or MITM'd) or during deployment (that java VM it pulled in during setup is never going to get patched).

hahainternet 11y ago

> There's no wisdom or security to be gained from the act of running "make", much less "make install". You were not doing sysadmin right. DESTDIR and checkinstall are two vital tools that are learned from the mistakes of make/make install.