3 ms·
It's 2017 and we still can't distribute software or manage libraries. For some reason content addressability based on hashes for libraries has never occurred to
by api 9y ago
It's 2017 and we still can't distribute software or manage libraries. For some reason content addressability based on hashes for libraries has never occurred to anyone.
- nugator 9y agoWhat do you mean should be hashed? Each library?
- api 9y agoYes. Then add a service on the OS that fetches the libraries for any binary. It's not a complicated thing. It's been obvious to me for years that this is how exact version linking should work. Linux at least has library versioning so this is less of a problem. Windows has foo.dll and foo.dll and foo.dll, so pretty much the only way is to ship your own foo.dll.
- paulddraper 9y agoThere are schemes like this, e.g. Nix. I like it though it not without any disadvantage. It will be challenging to upgrade OpenSSL after a discovered vulnerability.
- jancsika 9y agoI think Guix has the potential to do that. At least the hash for the reproducible build is part of the package definition. So it seems like one should be able to just have that hash, and then rely on the backend to just go fetch a blob that has that hash from a list of possible sources (centralized repo, bittorrent tracker, IPFS, etc.)
- benjaminl 9y agoWindows Side-by-Side assemblies (WinSxS) are similar to this. Each assembly or .dll contains a manifest that list its dependencies by version and token id. The OS dynamically loads the dependencies based on the manifest. https://en.wikipedia.org/wiki/Side-by-side_assembly https://en.wikipedia.org/wiki/Side-by-side_assembly This was introduced in Windows 2000 and used for core OS components starting with Windows Vista.
- tentaTherapist 9y agoWhy use hashes instead of, e.g., semver, or hash + patch version, so that you could patch Heartbleed easily?