An ISO is used either way. There isn’t really any reason for us to keep making our own with a less-well-tested iso builder. If anything, having users use Fedora Media Writer to write an official installer is even more user friendly and more secure since users don’t even have to deal with the iso, checksum, or verification directly.
We are already publishing OCI images, so republishing them as disk images would be as wasteful as it is redundant and unnecessary.
The proposed solution is the best of all worlds:
It makes our installation documentation significantly easier to follow, since the script will interactively prompt users instead of users needing to wade through a large image directory
It means users don’t need to directly deal with ISOs or manually handle checksumming or gpg verification (since Fedora Media Writer does this by default)
It keeps all users on the same installation pathway using a well-tested and officially supported installation mechanism, improving reliability and experience consistency
Removes a dependency on a third party, less thoroughly tested ISO generation mechanism
I just checked the FAQ page again and noticed that the answer to the question on how to install Steam has been updated. It is not explained in detail why it was recommended to layer the app until a few weeks ago, but now it is not recommended. Is it updated because it is secure to install Steam in the distrobox container instead of layering it? Isn’t distrobox a container that doesn’t offer sandboxing?
A few hours ago, distrobox alternative was removed from the how do I install software answers. What is the reason for this?
These changes made me rethink the answers on the FAQ page, and the answers reminded me of the many breaches that secureblue itself has made in the walls it has built with its security hardening. Bluetooth, X11, AppImage, GNOME user extensions, KDE themes… all aimed at disabling something. Including the need to install an unverified flatpak in order to do the first recommended way to install Steam.
Is it updated because it is secure to install Steam in the distrobox container instead of layering it?
No, nothing to do with security. Locally layering steam on rpm-ostree systems causes dependency clashes. Using a distrobox avoids this.
What is the reason for this?
distrobox is useful when say building a package that only has build instructions for a specific distribution. Outside of that, it tends to be a bit of a crutch and a less secure option. flatpak provides sandboxing via bwrap, and brew has plans to add bwrap sandboxing for cli programs as well.
many breaches that secureblue itself has made in the walls
You’re calling the hardening toggles that we provide “breaches”? You’re annoyed at the added convenience for users?
GrapheneOS provides similar toggles for hardening… you can disable MTE, hardened_malloc, etc.
This seems like finding something to be annoyed about for the sake of it, and I respectfully ask you to not do that
Including the need to install an unverified flatpak in order to do the first recommended way to install Steam.
Apparently this issue didn’t exist a couple of weeks ago, but it started to happen later, and I didn’t know about it because it wasn’t mentioned in the FAQ.
I also didn’t know about this detail because it wasn’t mentioned in the FAQ.
As for your other points, what I’d like to emphasize is whether what you’re recommending to make it easier for people who are use secureblue is partially weakening the security hardening, which is your main priority. I mean, there must be reasons why users can’t use AppImage packages, user extensions, themes, why you hide unverified flatpaks, etc., that have to do with trying to improve security, right. You also mentioned these in the FAQ. Doesn’t secureblue as installed already avoid usability sacrifices for most use cases? Or is it because it is a usability-compromising distribution that we have to deal with enabling bluetooth after the fact? If the things I mentioned are not that much of a security risk, it might be better for users if these things are not disabled by default.
I’m not interested in why Valve still hasn’t released Steam for other distros. Since you are hiding unverified flatpaks, it’s contradictory to recommend this as the first way to install Steam. Either it would be better not to hide unverified flatpaks anymore, or it would be more reasonable to remove that suggestion. Because you are recommending a method that already works as it should, I haven’t tried it, but maybe installing the official Steam client via Bottles is also recommended.
Anyway, I genuinely wish you the best of luck in continuing this project.
Apparently this issue didn’t exist a couple of weeks ago, but it started to happen later, and I didn’t know about it because it wasn’t mentioned in the FAQ.
No, it’s always been a problem, it just became worse recently.
what you’re recommending to make it easier for people who are use secureblue is partially weakening the security hardening, which is your main priority.
which is also what GrapheneOS does with various hardening toggles and compatibility mode…?
Frankly, this “concern” makes no sense whatsoever. This seems like borderline trolling.
I’m not interested in why Valve still hasn’t released Steam for other distros.
Well that’s the underlying reason why there are no Valve-official mechanisms to install Steam on secureblue.
it would be better not to hide unverified flatpaks anymore, or it would be more reasonable to remove that suggestion.
Why is either necessary? secureblue’s goal is to provide images with hardened defaults, verified-only flatpaks are a hardened default. That doesn’t make other problems go away (i.e. the problem of Fedora not having an official steam installation mechanism)
Secureblue breaks from the linux desktop status quo by favoring security over usability. Nevertheless, most of its hardening can trivially be disabled at the user’s discretion. Personally, I find this approach refreshing. Usually after installing a distro, I diligently apply hardening customization to improve its security. With secureblue, the situation is flipped, and I just loosen the hardened settings I want less restriction on.
You keep talking about GrapheneOS. I’m not a GrapheneOS user and I haven’t even looked into what it adds to AOSP and I’m not interested in it at all. I don’t think I need to know about GrapheneOS project in detail before I comment on secureblue, before I ask questions about it. I know that in the readme you only refer to GrapheneOS project 3 times, and I know that your project page doesn’t mention that you were inspired by GrapheneOS when you created secureblue, that your suggestions to disable some security hardening to make things easier for secureblue users meet the criteria of GrapheneOS project, that GrapheneOS project is the legitimate basis for your decisions about secureblue.
If these problems are inherited from Silverblue, I don’t think you need to bother with fixing them. Silverblue doesn’t have security hardening defaults like hiding unverified flatpaks from its users. The priority for installing GUI apps is flatpak, but when users search for apps like ProtonVPN, Mullvad Browser, Signal Desktop, they can’t find those in the store because unverified flatpaks are hidden. But, users who want to install applications such as Mullvad Browser and Steam are recommended to install unverified flatpaks.
This is an irrelevant comment. No developer is obliged to release flatpak packages. While it was recommended to install apps without flatpak packages with the distrobox container, this recommendation is removed. As you can see, I asked the developer for information about this too.
that GrapheneOS project is the legitimate basis for your decisions about secureblue.
It’s not, I was simply using it as an example of arguably the most well known project focused on hardening, and that even it provides hardening toggles. I was using it to show how inane your “concerns” are.
users who want to install applications such as Mullvad Browser and Steam are recommended to install unverified flatpaks.
You are recommended not to use anything firefox based, we don’t support anything besides hardened-chromium. Hence I said “if you need them for some reason”. Please do not mischaracterize my remarks.
Even if you’re not a troll, your comments are at a minimum disingenuous and in bad faith, on top of being nonsensical. I’ve been taking the time to address what I assumed in good faith was genuine questioning. It seems I was mistaken to assume good faith. You have been blocked for this reason.
I think one big factor to be considered about the Secureblue project is the shift of trust. With Secureblue you are trusting the 25 contributors team there to continue maintaining the harden that they are distributing. Things can move and change very quick with a small team like that which can be good or bad. In Fedora, even with their very leaning forward philosophy things can take a bit to be modified and again that can be good or bad. I don’t want to sound as a downer, we have Divest and Nobara as example of small resource maintained projects that continue going. I think is nice to trust in projects with small teams but you have to understand clearly the risks.
Realistically it seems like it’d be more accurate (at this point in time) to say a 1 person team with occasional contributions from a handful of others. If I’m wrong about this, I’m sure @RoyalOughtness will correct me.
On the other hand, Fedora Atomic and Universal Blue are kind of designed in large part to enable this sort of small offshoot project by a small team or single individual. So it’s somewhat different than a full distro maintained by a single person. Still I agree that the size of the team and the newness of the project are relevant factors users should consider when making their choice.
If I’m wrong about this, I’m sure @RoyalOughtness will correct me.
You are indeed wrong, but only slightly
Yes, secureblue’s core contributors are a small handful of people, and there are occasional contributions outside that core team. As an example, the bulk of the recent development on hardened-chromium is being done by Rootkit404. I think most of my commits on it recently have been for bumping release versions and fixing build failures . Rootkit404 built out the entire subresource filter and source caching backend.
That said, there’s lots of work to do, and new contributors are always welcome
@RoyalOughtness do you plan on opening a matrix channel? Because I think the target audience prefer a more secure and private communication channel than Discord.
You can then setup a matrix-discord bridge so everyone can communicate while being on their preferred platform.
If your goal is E2EE with one other person, maybe. For public servers, it’s an entirely irrelevant variable.
It is clear that you have never used Matrix before.
I have used it on the privsec server In any case can we please lower the hostility a bit?
That security mindset which neglects privacy completely is very terrible.
We don’t neglect privacy completely, but it’s not the scope of the project. There are some changes we make that improve privacy, but they are auxiliary to the project’s goals. What we won’t do is sacrifice security for privacy, and that includes the choice of community discussion platform. 2FA is just one variable too. Discord’s automod is robust by comparison, which is critical for securing a public server against raids/spam/malicious links. GrapheneOS had to disable parts of their bridge for this reason, matrix was unable to prevent that kind of thing and it was getting spilled over into discord by the bridge.
tldr there are historically demonstrated, critical security improvements discord provides over matrix when it comes to providing a public community server. Matrix is better in some areas like one to one conversations with E2EE, but that’s entirely irrelevant for a public server.
. Rootkit404 built out the entire subresource filter and source caching backend.