3 ms·

Mostly agree. I think they have some improvement to do on supply-chain though. A lot of random COPRs and kernel patches pulled in from various random third- an

by baobun 1y ago

Mostly agree. I think they have some improvement to do on supply-chain though. A lot of random COPRs and kernel patches pulled in from various random third- and first party repos that I think should get consolidated before I can consider it mature and really ready for prime time. Similarly it would also be nice to see end-to-end builds being reproducible locally. (Things are currently hardcoded to github.com or tied to GitHub Actions in a few places. The patching required for that is nothing crazy - Good First Issue material :))

jcastro 1y ago
For Bluefin LTS we're in control of all the 3rd party repositories we use. We depend on EPEL but so does everybody else. I am unaware of any kernel patches that we are shipping since we ship the default CentOS Stream kernel and the optional hwe kernel ships CentOSs' kmod kernel.
- hedora 1y ago
  You control github?
- baobun 1y ago
  Really? Do you control the negativo17.org repo (just one example from akmods)? https://github.com/ublue-os/akmods/blob/9946c17373b1a49e60a02ae4adb4d1310c60fb25/build_files/nvidia/build-kmod-nvidia.sh#L11 https://github.com/ublue-os/akmods/blob/9946c17373b1a49e60a0... https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5a0bb1067e42a85182cd2bd129/build_scripts/10-packages-image-base.sh#L34 https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5... How about jreilly1821? Looks like nothing's really preventing them from sneaking in a malicious version of glib2.. https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5a0bb1067e42a85182cd2bd129/build_scripts/10-packages-image-base.sh#L21 https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5...
  - trogdor3000 1y ago
    Hi I'm jreilly1821, I made those COPRs for Bluefin LTS. I guess I could put something malicious but you can see that they are all just packages from Fedora DistGit. I'm not sure what your preference would be? I think distros have mystique given to them that is misappropriated. At the end of the day they are mostly middlemen packaging someone else's code. Bootc is and will change things, images will be tested as an integrated experience and we'll continue to strive to pull from as far upstream as we can. Negativo17 is Simone, an NVIDIA employee who has been instrumental in packaging nvidia drivers for linux for years. I don't know for certain, but I wouldn't be suprised if they are also doing the official packaging for nvidia drivers as well. Needless to say they are very trusted and a known entity in the Linux community
    - moltopoco 1y ago
      I think I agree with what the grandparent poster wrote, and I'll try to expand on my reasoning. As a mildly paranoid user, I cannot possibly keep track all of all the individuals who maintain parts of Bluefin, no matter how much I like following all of you on Discord etc. I still don't even know what a DistGit or COPR is. When I install a more corporate product such as Ubuntu or macOS, sure, it's also mostly middlemen repackaging other people's code. But it is clear what and who belongs to the company or team, and the team has a shared interest in protecting its reputation, and hopefully pwning or buying a single individual's accounts cannot infect everything else. To that end, I agree that "consolidation" would help - sometimes that might mean controlled mirroring of things into the Bluefin org or so - but that is exactly what distros do, and I understand that Bluefin does not want to be a distro.
      - jcastro 1y ago
        > I still don't even know what a DistGit or COPR is. I agree, I hate all of this too. The wolfi version will be much better.
  - jcastro 1y ago
    I would be in trouble if I didn't trust jreilly1821 since he's one of the Bluefin maintainers. And the nvidia binaries come from an nvidia employee.
bjconlan 1y ago
Perhaps if a supply chain attack is your largest concern then using some well vetted system like wolfi is more up your alley. (See some of their related repos on GitHub https://github.com/projectbluefin https://github.com/projectbluefin - I've been following the development of it and currently it still under development.) Again "vetting" is a source of contention here as I'm not sure how the quality of official rpm sources compare to those outlined in an sbom

by baobun 1y ago

jcastro 1y ago

For Bluefin LTS we're in control of all the 3rd party repositories we use. We depend on EPEL but so does everybody else. I am unaware of any kernel patches that we are shipping since we ship the default CentOS Stream kernel and the optional hwe kernel ships CentOSs' kmod kernel.

hedora 1y ago
You control github?
baobun 1y ago
Really? Do you control the negativo17.org repo (just one example from akmods)? https://github.com/ublue-os/akmods/blob/9946c17373b1a49e60a02ae4adb4d1310c60fb25/build_files/nvidia/build-kmod-nvidia.sh#L11 https://github.com/ublue-os/akmods/blob/9946c17373b1a49e60a0... https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5a0bb1067e42a85182cd2bd129/build_scripts/10-packages-image-base.sh#L34 https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5... How about jreilly1821? Looks like nothing's really preventing them from sneaking in a malicious version of glib2.. https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5a0bb1067e42a85182cd2bd129/build_scripts/10-packages-image-base.sh#L21 https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5...
- trogdor3000 1y ago
  Hi I'm jreilly1821, I made those COPRs for Bluefin LTS. I guess I could put something malicious but you can see that they are all just packages from Fedora DistGit. I'm not sure what your preference would be? I think distros have mystique given to them that is misappropriated. At the end of the day they are mostly middlemen packaging someone else's code. Bootc is and will change things, images will be tested as an integrated experience and we'll continue to strive to pull from as far upstream as we can. Negativo17 is Simone, an NVIDIA employee who has been instrumental in packaging nvidia drivers for linux for years. I don't know for certain, but I wouldn't be suprised if they are also doing the official packaging for nvidia drivers as well. Needless to say they are very trusted and a known entity in the Linux community
  - moltopoco 1y ago
    I think I agree with what the grandparent poster wrote, and I'll try to expand on my reasoning. As a mildly paranoid user, I cannot possibly keep track all of all the individuals who maintain parts of Bluefin, no matter how much I like following all of you on Discord etc. I still don't even know what a DistGit or COPR is. When I install a more corporate product such as Ubuntu or macOS, sure, it's also mostly middlemen repackaging other people's code. But it is clear what and who belongs to the company or team, and the team has a shared interest in protecting its reputation, and hopefully pwning or buying a single individual's accounts cannot infect everything else. To that end, I agree that "consolidation" would help - sometimes that might mean controlled mirroring of things into the Bluefin org or so - but that is exactly what distros do, and I understand that Bluefin does not want to be a distro.
    - jcastro 1y ago
      > I still don't even know what a DistGit or COPR is. I agree, I hate all of this too. The wolfi version will be much better.
- jcastro 1y ago
  I would be in trouble if I didn't trust jreilly1821 since he's one of the Bluefin maintainers. And the nvidia binaries come from an nvidia employee.

bjconlan 1y ago

Perhaps if a supply chain attack is your largest concern then using some well vetted system like wolfi is more up your alley. (See some of their related repos on GitHub https://github.com/projectbluefin https://github.com/projectbluefin - I've been following the development of it and currently it still under development.) Again "vetting" is a source of contention here as I'm not sure how the quality of official rpm sources compare to those outlined in an sbom