6 ms·

Identifying Software

120 points by ementally 3y ago

datadrivenangel 3y ago
"we believe binary artifacts should instead be treated as the result of a computational process; it is that process that needs to be fully captured to support independent verification of the source/binary correspondence. " So binary artifacts should verifiably come from source code, which can be accomplished by signing it with a signing mechanism specified in the source code?
- abound 3y ago
  Since this is coming from the GNU folk, they naturally have their inclinations towards open-source software, but I'd argue (and they probably would too) that reproducibility is a much stronger invariant than just code signing. Bootstrapping everything from a tiny first stage compiler and getting bit-identical compiled outputs is a much higher level of confidence than PKI offers, as PKI can be cracked, stolen, made to sign things it shouldn't, etc. Even if the signature is legit, it doesn't help you against insider risk (e.g. internally added backdoors) on closed source software. These are all things governments (should probably) care about.
  - tarruda 3y ago
    Here's a must read that helps newcomers understand one of the problems Guix attempts to solve: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
- yencabulator 3y ago
  Good luck including Intel microcode updates in that..
  - sham1 3y ago
    Well, Guix sidesteps that problem by (rightly) pointing out that Intel microcode updates are non-free software, and thus aren't included in the system. If one wants those updates, they have to do it themselves, usually by using a software channel that provides ways to use non-free software on their system, which means that the user makes a conscious choice to use non-free stuff instead of it being handed from up high. It might not be a satisfying answer, but oh well. One can complain at Intel about it.
    - yencabulator 3y ago
      It's extremely not satisfying in today's world where microcode updates are needed for security. So, pretty much on point for GNUy things..
Zambyte 3y ago
I have felt spoiled by GNU Guix honestly. It has documentation that is comparable to Gentoo or Arch, power over your system that generally matches Gentoo (though a system-wide equivalent of USE flags is not yet available, individual packages can be configured), the ease of maintenance of a system like Fedora Silverblue, and one of the most approachable communities I have ever dealt with. I highly recommend playing around with it :)
- xcdzvyn 3y ago
  Interesting, so the docs are better than Nix'? I've been meaning to finally figure out LISP, I'd be willing to use this as an excuse!
  - Zambyte 3y ago
    I used Nix for a few months several years ago, so their documentation is probably better now than I was when I used it, but yeah, I find the Guix documentation to be much more pleasant to use than the Nix documentation was when I used it. This is partially because it uses an existing language, rather than a home grown language. Guix was also my entry point for learning Lisp, and the abundance of learning material for the language will probably always dwarf that of Nixs homegrown language. I actually watched all of the SICP lectures; I found that to be an incredible resource to get my footing. It's also important to note that Guixs documentation is readily available on the system using the GNU info utility, which if you're not familiar with, is like man but on steroids. If you use Kagi, I also made this lens[0] that allows one to search through the web version of the documentation, the mailing list archives, and the IRC logs all at once using !guix. [0] https://kagi.com/lenses/l7mPOuJp7zljHquBjsekFn6dM9Thw1A8 https://kagi.com/lenses/l7mPOuJp7zljHquBjsekFn6dM9Thw1A8
    - kriiuuu 3y ago
      I use nix and the documentation is dogwater. It’s the best system I have ever used, but by god you need to get your hands dirty with it for a while.
weinzierl 3y ago
This is good take on the topic focusing on intrinsic identifiers. Guix has their own approach but the article also mentions SWHID[1] and OmniBOR[2] which are both contenders to fill that space. SWHID is on its way to become an ISO standard[3]. OmniBOR is quite new but a highly interesting approach. Because it does not directly solve any problems for Guix, it's fair enough that they do not talk about much about extrinsic identifiers except to rightfully dismiss CPE as "showing its limits", which is put mildly. I think there is need for an extrinsic identifier standard beyond CPEs (in addition to intrinsic identifiers). While intrinsic identifiers allow us to pinpoint artifacts exactly sometimes this is not what we want. Sometimes we deliberately want to talk about sets of artifacts together, like variants or versions of an artifact. One contender would be purl[4] (as in package URL and not the older persistent uniform resource locator). [1] https://www.swhid.org https://www.swhid.org [2] https://omnibor.io https://omnibor.io [3] https://hal.science/hal-04121507v1/file/2023-03-27-SWHID-kickoff.pdf https://hal.science/hal-04121507v1/file/2023-03-27-SWHID-kic... [4] https://github.com/package-url/purl-spec https://github.com/package-url/purl-spec
GlenTheEskimo 3y ago
Yep, it's software
- epiccoleman 3y ago
  This is exactly the meme that came to mind when I saw the topic title, glad I'm not the only one who's had their brain ruined like this ;)
robblbobbl 3y ago
Way too late but downvoting always works.
- rekado 3y ago
  What does this mean? Downvoting this submission? Why?
deleted 3y ago
[deleted]

120 points by ementally 3y ago

"we believe binary artifacts should instead be treated as the result of a computational process; it is that process that needs to be fully captured to support independent verification of the source/binary correspondence. " So binary artifacts should verifiably come from source code, which can be accomplished by signing it with a signing mechanism specified in the source code?

abound 3y ago
Since this is coming from the GNU folk, they naturally have their inclinations towards open-source software, but I'd argue (and they probably would too) that reproducibility is a much stronger invariant than just code signing. Bootstrapping everything from a tiny first stage compiler and getting bit-identical compiled outputs is a much higher level of confidence than PKI offers, as PKI can be cracked, stolen, made to sign things it shouldn't, etc. Even if the signature is legit, it doesn't help you against insider risk (e.g. internally added backdoors) on closed source software. These are all things governments (should probably) care about.
- tarruda 3y ago
  Here's a must read that helps newcomers understand one of the problems Guix attempts to solve: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
yencabulator 3y ago
Good luck including Intel microcode updates in that..
- sham1 3y ago
  Well, Guix sidesteps that problem by (rightly) pointing out that Intel microcode updates are non-free software, and thus aren't included in the system. If one wants those updates, they have to do it themselves, usually by using a software channel that provides ways to use non-free software on their system, which means that the user makes a conscious choice to use non-free stuff instead of it being handed from up high. It might not be a satisfying answer, but oh well. One can complain at Intel about it.
  - yencabulator 3y ago
    It's extremely not satisfying in today's world where microcode updates are needed for security. So, pretty much on point for GNUy things..

Zambyte 3y ago

I have felt spoiled by GNU Guix honestly. It has documentation that is comparable to Gentoo or Arch, power over your system that generally matches Gentoo (though a system-wide equivalent of USE flags is not yet available, individual packages can be configured), the ease of maintenance of a system like Fedora Silverblue, and one of the most approachable communities I have ever dealt with. I highly recommend playing around with it :)

xcdzvyn 3y ago
Interesting, so the docs are better than Nix'? I've been meaning to finally figure out LISP, I'd be willing to use this as an excuse!
- Zambyte 3y ago
  I used Nix for a few months several years ago, so their documentation is probably better now than I was when I used it, but yeah, I find the Guix documentation to be much more pleasant to use than the Nix documentation was when I used it. This is partially because it uses an existing language, rather than a home grown language. Guix was also my entry point for learning Lisp, and the abundance of learning material for the language will probably always dwarf that of Nixs homegrown language. I actually watched all of the SICP lectures; I found that to be an incredible resource to get my footing. It's also important to note that Guixs documentation is readily available on the system using the GNU info utility, which if you're not familiar with, is like man but on steroids. If you use Kagi, I also made this lens[0] that allows one to search through the web version of the documentation, the mailing list archives, and the IRC logs all at once using !guix. [0] https://kagi.com/lenses/l7mPOuJp7zljHquBjsekFn6dM9Thw1A8 https://kagi.com/lenses/l7mPOuJp7zljHquBjsekFn6dM9Thw1A8
  - kriiuuu 3y ago
    I use nix and the documentation is dogwater. It’s the best system I have ever used, but by god you need to get your hands dirty with it for a while.

weinzierl 3y ago

This is good take on the topic focusing on intrinsic identifiers. Guix has their own approach but the article also mentions SWHID[1] and OmniBOR[2] which are both contenders to fill that space. SWHID is on its way to become an ISO standard[3]. OmniBOR is quite new but a highly interesting approach. Because it does not directly solve any problems for Guix, it's fair enough that they do not talk about much about extrinsic identifiers except to rightfully dismiss CPE as "showing its limits", which is put mildly. I think there is need for an extrinsic identifier standard beyond CPEs (in addition to intrinsic identifiers). While intrinsic identifiers allow us to pinpoint artifacts exactly sometimes this is not what we want. Sometimes we deliberately want to talk about sets of artifacts together, like variants or versions of an artifact. One contender would be purl[4] (as in package URL and not the older persistent uniform resource locator). [1] https://www.swhid.org https://www.swhid.org [2] https://omnibor.io https://omnibor.io [3] https://hal.science/hal-04121507v1/file/2023-03-27-SWHID-kickoff.pdf https://hal.science/hal-04121507v1/file/2023-03-27-SWHID-kic... [4] https://github.com/package-url/purl-spec https://github.com/package-url/purl-spec

GlenTheEskimo 3y ago

Yep, it's software

epiccoleman 3y ago
This is exactly the meme that came to mind when I saw the topic title, glad I'm not the only one who's had their brain ruined like this ;)

robblbobbl 3y ago

Way too late but downvoting always works.

rekado 3y ago
What does this mean? Downvoting this submission? Why?

deleted 3y ago

[deleted]