4 ms·

The existence of that exception, the way it is implemented, the way they work with vendors to help them fit into it, and the way they do not require informing u

The existence of that exception, the way it is implemented, the way they work with vendors to help them fit into it, and the way they do not require informing users of such secondary processors are all deceptive. Just look at the Librem 5. That CPU needs a blob to even boot (to train the RAM). Normally that would just be embedded into the bootloader. But that would make it evident in the build process for their boot stack that there is a blob involved, and they can't certify that as "Respects your Freedom". So instead they worked with the manufacturer, and came up with this contrived interpretation of the "secondary processor" rule where, as long as the firmware in the "secondary processor" is at least two steps removed from the main CPU and never handled "directly" by it, it's okay. Then they had the manufacturer put the blob in a Flash ROM (Flash, so updatable, remember? just not that easily), and then they had them write a little loader code that runs on another secondary CPU. So the main CPU (running free software) boots a secondary CPU (running free software) that loads a blob from Flash and then boots a third CPU, which now runs proprietary software. According to the FSF, all this pointless obfuscation and extra levels of indirection makes the device magically compliant with their criteria. And so it got certified. It is completely evident that absolutely none of this helps end-users' freedom in any way, shape, or form vs. just having the blob in the normal bootloader where it can be more easily inspected and analyzed (and also lets users ensure that it hasn't been tampered with). It's just adding obfuscation so users won't find the blob, and therefore will feel better believing they aren't running any blobs. By this interpretation of the rule, I could ship an x86 PC with an Nvidia GPU that runs its proprietary driver on one of the CPU cores (isolated from the main OS), loaded by the UEFI firmware through ME or something, which communicates with the rest of the cores via VirtualGL or some other RPC, and that would make this PC eligible for RYF certification. Tell me that's not a farce.

medo-bear 5y ago
not knowing about https://ryf.fsf.org/ https://ryf.fsf.org/ previously, i managed to find and understand their certification process within a matter of ten minutes. if i was a user of these products i don't think i would feel decieved
- atdrummond 5y ago
  Is the poster you’re replying to saying anything about the ease of parsing their policy? He doesn’t seem to be calling it confusing. Rather, he seems to be attacking the supposed (il)logic of its contentions and the resulting consequences. At the moment this back and forth feels like you’re talking past his actual point(s).
  - medo-bear 5y ago
    no. he is calling it deceptive, which is even stronger than confusing. his statement was: > They are deceiving people into believing they are not running proprietary software edit: as regards FSF's logic i am not informed enough to comment so i didnt. but the conversation (this thread) was definitely about deceptiveness
    - User23 5y ago
      The FSF’s principles have always permitted the use of non-free software when it advances the goal of software freedom. GNU was initially built using non-free software. Given the pejorative yet inaccurate references to “religion.” I can’t help but think some people are deeply disturbed by the very concept of moral principles and and cognitive dissonance is forcing them to hallucinate that the FSF doesn’t actually have principles but is instead a cult. Very odd.
      - mindslight 5y ago
        No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page: > AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization) > AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates. "Avoid like the plague", yet there is little philosophical difference between compromising to trust AMD's 6200 masked microcode, and compromising to trust AMD's microcode update that fixed Spectre on 6300. The main possible distinction is if you want to argue that AMD became less trustworthy in the time between those two releases. Obviously if AMD releases new microcode for the 6300 going forward, it's a software freedom/security question of whether that microcode should be installed (automatically or even after review). But as it stands, slow changing microcode updates are in the same security/freedom realm as new CPU releases.
MichaelBurge 5y ago
I'm not the FSF, but one argument could be things like the Intel Management Engine that I know the FSF have strong opinions on. If that's isolated to a separate CPU, it's easier to track the signals going in and out, and the bad things it can do are limited.
- marcan_42 5y ago
  The FSF don't actually care about such details - sure, they'll deride ME, but they make no attempt to inform users about how it compares with alternatives and which options are better for users. That's because their criteria are not based on technical analysis, like determining what the access surface of the blobs is, but instead on the mere existence of the blobs. To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust.
  - medo-bear 5y ago
    >To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust. For a company that values software freedom above all else this is completely fine. If they are called Secure Software Foundation then your arguments would hold more weight. For example, I really doubt that FSF would claim that GNU Guix is more secure than Open BSD
    - marcan_42 5y ago
      The FSF have repeatedly associated software freedom (by their definition) with security and privacy. This is just one example, there are many others: https://www.fsf.org/bulletin/2020/spring/privacy-encryption https://www.fsf.org/bulletin/2020/spring/privacy-encryption
      - medo-bear 5y ago
        but security is associated with free and open source software. i think this is a common position of a vast majority of security experts. to make your claim that FSF deceives or misleads people you need to do a LOT more. for example, can you provide an example where someone claims that GNU Guix is secure by design[0] i think that taking a position that free software supports security and also that free software principles come before security considerations is not contradictory let alone deceptive [0]EDIT: i just searched the RYF site and did not obtain a signle result for the term 'security' https://ryf.fsf.org/search/node?keys=security https://ryf.fsf.org/search/node?keys=security
marcodiego 5y ago
Librem 5 is not RYF-certified.
- marcan_42 5y ago
  You're right, not yet (I wonder why? Maybe they cut too many other corners, or the FSF gave up on the program?), but that entire nonsense was squarely aimed at gaining RYF certification and done with the FSF's blessing.
LargoLasskhyfv 5y ago
Or have a proprietary RTOS running on a GPU, working hypervisor-like for the tacked on ARM-multicore, like some very popular fruity berry SBCs. (giggle)

medo-bear 5y ago

not knowing about https://ryf.fsf.org/ https://ryf.fsf.org/ previously, i managed to find and understand their certification process within a matter of ten minutes. if i was a user of these products i don't think i would feel decieved

atdrummond 5y ago
Is the poster you’re replying to saying anything about the ease of parsing their policy? He doesn’t seem to be calling it confusing. Rather, he seems to be attacking the supposed (il)logic of its contentions and the resulting consequences. At the moment this back and forth feels like you’re talking past his actual point(s).
- medo-bear 5y ago
  no. he is calling it deceptive, which is even stronger than confusing. his statement was: > They are deceiving people into believing they are not running proprietary software edit: as regards FSF's logic i am not informed enough to comment so i didnt. but the conversation (this thread) was definitely about deceptiveness
  - User23 5y ago
    The FSF’s principles have always permitted the use of non-free software when it advances the goal of software freedom. GNU was initially built using non-free software. Given the pejorative yet inaccurate references to “religion.” I can’t help but think some people are deeply disturbed by the very concept of moral principles and and cognitive dissonance is forcing them to hallucinate that the FSF doesn’t actually have principles but is instead a cult. Very odd.
    - mindslight 5y ago
      No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page: > AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization) > AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates. "Avoid like the plague", yet there is little philosophical difference between compromising to trust AMD's 6200 masked microcode, and compromising to trust AMD's microcode update that fixed Spectre on 6300. The main possible distinction is if you want to argue that AMD became less trustworthy in the time between those two releases. Obviously if AMD releases new microcode for the 6300 going forward, it's a software freedom/security question of whether that microcode should be installed (automatically or even after review). But as it stands, slow changing microcode updates are in the same security/freedom realm as new CPU releases.

MichaelBurge 5y ago

I'm not the FSF, but one argument could be things like the Intel Management Engine that I know the FSF have strong opinions on. If that's isolated to a separate CPU, it's easier to track the signals going in and out, and the bad things it can do are limited.

marcan_42 5y ago
The FSF don't actually care about such details - sure, they'll deride ME, but they make no attempt to inform users about how it compares with alternatives and which options are better for users. That's because their criteria are not based on technical analysis, like determining what the access surface of the blobs is, but instead on the mere existence of the blobs. To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust.
- medo-bear 5y ago
  >To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust. For a company that values software freedom above all else this is completely fine. If they are called Secure Software Foundation then your arguments would hold more weight. For example, I really doubt that FSF would claim that GNU Guix is more secure than Open BSD
  - marcan_42 5y ago
    The FSF have repeatedly associated software freedom (by their definition) with security and privacy. This is just one example, there are many others: https://www.fsf.org/bulletin/2020/spring/privacy-encryption https://www.fsf.org/bulletin/2020/spring/privacy-encryption
    - medo-bear 5y ago
      but security is associated with free and open source software. i think this is a common position of a vast majority of security experts. to make your claim that FSF deceives or misleads people you need to do a LOT more. for example, can you provide an example where someone claims that GNU Guix is secure by design[0] i think that taking a position that free software supports security and also that free software principles come before security considerations is not contradictory let alone deceptive [0]EDIT: i just searched the RYF site and did not obtain a signle result for the term 'security' https://ryf.fsf.org/search/node?keys=security https://ryf.fsf.org/search/node?keys=security

marcodiego 5y ago

Librem 5 is not RYF-certified.

marcan_42 5y ago
You're right, not yet (I wonder why? Maybe they cut too many other corners, or the FSF gave up on the program?), but that entire nonsense was squarely aimed at gaining RYF certification and done with the FSF's blessing.

LargoLasskhyfv 5y ago

Or have a proprietary RTOS running on a GPU, working hypervisor-like for the tacked on ARM-multicore, like some very popular fruity berry SBCs. (giggle)