Release Candidate is simply means that it is almost ready for official release and is only making minor changes and improvements. If you saw the above post, that means it could get released soon, maybe this year or next year. It’s fine to use right now, but if it was in Alpha—it would probably not be a recommendation.
Cool, thanks for clarifying
That’s the “hardened” system part. You should ideally do each step one by one.
As I have suggested in a previous message, if you don’t actually want the hardening you initially asked for, go with Aeon or Silver blue or other atomic spins. Those don’t have any post install step and are just “install and use”.
Thats just project management buzzword for “we are just checking for minor issues before final release”. It’s fine.
Out of interest is there anyone here associated with any of the suggested options in the thread other than Qoijjj ? (not that that would be a problem, just wondered)
The only thing I should let you know is that its popularity is not like Ubuntu, openSUSE Tumbleweed or Leap, Fedora, etc. Thus, there won’t be many people to help you troubleshoot if you encounter issues.
Personally, I would use it anyway, and for your purposes there shouldn’t be any problems with it being in Release Candidate stage.
Nope.
There are plenty of people that are willing to help, including the founder itself:
2 Likes
Not at all.
No conflict of interest for me with either Aeon or Fedora or secureblue if that is what you are asking 
I just try to answer with exactly what OPs ask for, but alas, sometimes OPs don’t know if they want what they are asking for 
I agree and I’m sorry about that, sometimes the only way to know for sure is to try, nevertheless I am grateful for all the advice I have been given 
That’s not what that table was. It was a list of vanadium patches and their best-effort policy configuration that we were applying at runtime to Fedora’s chromium.
We’ve long since moved to shipping our own chromium, which allows us to simply drop in Vanadium patches: GitHub - secureblue/hardened-chromium: A hardened chromium for desktop Linux inspired by Vanadium.
Also, even vanadium doesn’t just blindly “degoogle” like ungoogled-chromium does, which is a good thing. Some of the ungoogled-chromium patches are so tunnel visioned on removing google that they remove security functionality. For example, they disable browser time validation via a network synchronization service, which is used for cert validation and is a terrible idea to disable: ungoogled-chromium/patches/core/ungoogled-chromium/disable-network-time-tracker.patch at 61b271f22b9efc91bfe3e69ee6f25f2dad87afa4 · ungoogled-software/ungoogled-chromium · GitHub
1 Like
The postinstall steps for secureblue would need to be executed on Aeon as well in order to secure the system. secureblue is simply neatly documenting those steps for user convenience, they’re largely not unique to secureblue.
Plus, some of them you would wish are available on Aeon, like the ease of nvidia configuration on secureblue/silverblue compared to aeon.
Aeon isn’t analogous to secureblue. It’s analagous to Silverblue. immutability/atomicity on its own isn’t a security feature.
If there was a hardened image of Aeon you were recommending, your post would make more sense. But this is apples and oranges. You’re comparing a hardened image of a major distro to an unhardened release of a different major distro, all of which would need similar postinstall steps executed to fully harden.
So, if you do go with opensuse Aeon, don’t forget to follow equivalent steps to secureblue’s postinstall steps after installing
1 Like
It rebooted to BIOS and I had to select options on a menu, I think I’ve done it right but not sure how to verify.
yeah we could add more details here, please open github issues for these documentation improvements
mokutil --sb-state btw
Also it mentions about rolling back to a snapshot but wasn’t sure how to create one.
That should probably say “deployment”, but anyways you don’t have to do anything. every time you make any changes via rpm-ostree, a new deployment is generated and deployed which you then boot into next reboot. The old deployment isn’t removed, two deployments are always kept. Please browse the silverblue docs as this isn’t specific to secureblue and isn’t something we’ll be documenting.
User add : Permission denied
sudo
which should probably be added as well, although it is somewhat implied by the nature of the changes
also you can run ujust audit-secureblue to check for steps you may have missed.
And again, like I mentioned previously, these are all steps you would want to do equivalent steps for on openSUSE Aeon as well if you want to harden it. So using Aeon wouldn’t really change anything in this regard except that you would have to modify the secureblue postinstall steps to be compatible with Aeon.
1 Like
You may have deleted the page from github, but webarchive is forever (that is, if it’s not hacked yet again).
https://web.archive.org/web/20240711091023/https://github.com/secureblue/secureblue/blob/e33b73d9d3bceeb26eb40271d4aaae0ac37ff5ea/config/files/usr/etc/chromium/vanadium_comparison.readme.md
You say I spread misinformation and that all desktop-relevant patches were applied. But my “misinformation” is the factual observation that only 86 of the 135 ignored patches are marked as “Android only”.
Care to explain why?
And even if you have perfectly good explanations, would you care to appologize as well?
You may have deleted the page from github
Yes because it’s from before hardened-chromium even existed.
You say I spread misinformation and that all desktop-relevant patches were applied.
Yes, you are spreading misinformation and you’re now doubling down. The page you’re linking is from before we were applying a single patch, because hardened-chromium didn’t exist yet.
But my “misinformation” is the factual observation that only 86 of the 135 ignored patches are marked as “Android only”.
No, you are doubling down on misinformation. That page has nothing to do with hardened-chromium.
Care to explain why?
Because they patched Java code that only runs on Android and were not replicable using policies (remember this is before hardened-chromium). They do nothing on desktop. They have to be rewritten in cpp to have any effect, if they’re even relevant to begin with. Now that we have hardened-chromium, we can do so if needed.
But again, in your ignorance you’re pointing to a document that isn’t even about hardened-chromium. That’s a document describing drop-in policies, not patches.
would you care to appologize as well?
Wow. You have spread misinformation, doubled down on your misinformation, refused to correct your own misunderstanding, and then to top it all off demanded an apology from me? And for what, helping educate you on the difference between policies and patches? The difference between drop-ins on top of an application vs building the application yourself?
You have been blocked. I hope you don’t treat the work of others with the same contempt, especially offline.
4 Likes