Throwaway1234

joined 1 year ago

Ultimately, it's for you to decide whichever suits you best. But I understand why that initial impression may have made you cautious.

[–] Throwaway1234@sh.itjust.works 6 points 1 year ago (1 children)

Does anyone happen to know if bubblewrap is more powerful than bubblejail (or vice versa). Or how they differ in the first place (beyond CLI vs GUI)?

[–] Throwaway1234@sh.itjust.works 0 points 1 year ago (2 children)

Alright. Thank you for reporting back!

Uhmm..., so, the good thing is that it's reproducible, a bug report has already been issued for it and should (therefore) eventually get a fix in upstream. The bad news, however, is that you may experience the same issue on every other relatively bleeding edge distro until then... But, there are two ways around it:

  1. Just reboot by shutting off 🤣.
  2. Or..., switch to Nobara. Some users reported the bug to its maintainer and they've fixed the issue on Nobara since. It's conceivable that the fix may already be found on other distros as well, but it's definitely fixed on Nobara. Thankfully, Nobara is based on Fedora. So you shouldn't feel too far away from home ;).
[–] Throwaway1234@sh.itjust.works 0 points 1 year ago (4 children)

Thank you for the reply!

I’ve tried rebooting it like that.

And..., what's the result? Does the problem persist? Or is it resolved? (Under strict adherence to rebooting as described*)

[–] Throwaway1234@sh.itjust.works 0 points 1 year ago (6 children)

A quick search revealed that others have experienced issues that may be related. In order to disclose that this is different from the issue reported by others, please consider the following:

After updating to the latest kernel, shut off instead of reboot. After which you turn your device back on. If strict adherence to 'rebooting' like this prevents the issue from coming up, then it's likely the aforementioned known issue with the latest generation of AMD GPUs and recent kernel updates.

Please consider to report back on your findings.

[–] Throwaway1234@sh.itjust.works 0 points 1 year ago (1 children)

I am aware that Homebrew has become the go-to solution for installing CLI applications on Bluefin. Which is exactly why I feel compelled to ask the question in my previous comment.

Btw, I don't really understand why you felt the need to share Jorge Castro's blog post on Homebrew? AFAIK it doesn't go over any security implications. Sharing the article would only make sense if Jorge Castro is regarded as some authority that's known to be non-conforming when security is concerned. While I haven't seen any security related major mishaps from him or the projects he works on, the search for the CLI-counterpart to Flatpak seemed to be primarily motivated by facilitating (what I'd refer to as) 'old habits'; which is exactly what Homebrew allows. It's worth noting that, during the aforementioned search process, they've made the deliberate choice to rely on Wolfi (which is known for upholding some excellent security standards) rather than Alpine (which -in all fairness- has also been utilized by Jorge for boxkit). IIRC, people working on uBlue and related projects have even contributed to upstream (read Distrobox) for patches related to Wolfi. So, there's reason to believe that the uBlue team takes security seriously enough to work, contribute and deliver on more secure alternatives as long as it doesn't come with a price to be paid by convenience. Which, in all fairness, is IMO exactly why Homebrew is used for in the first place (besides their recent utilization of technologies that have similarities to the 'uBlue-way' of doing things)...

[–] Throwaway1234@sh.itjust.works 0 points 1 year ago (3 children)

But then again some people use things like Homebrew and pacstall unironically so …

Thank you for mentioning this! Unfortunately a quick search on the internet didn't yield any pointers. Would you mind elaborating upon the security problems of Homebrew(/Linuxbrew)? Thanks in advance 😊!

 

Per a mutual decision, Universal Blue’s old custom image tooling has now been transferred to the BlueBuild org and development will be continuing under the BlueBuild project with basically the same team of maintainers and developers as before. The issue was discussed extensively in ublue-os/startingpoint#223 and eventually voted for in ublue-os/main#476.

We’ve been working on BlueBuild for a month now to provide you a smooth migration and exciting new features, so don’t worry, this change is positive.

To briefly summarize, this desire to split stemmed from a difference in philosophy and scope between the main Universal Blue maintainers and the developers of ‘startingpoint’. Since most of the Universal Blue project’s build systems use classic cloud methodologies like Containerfiles and GitHub Actions directly to build their images, the abstraction introduced with recipes in ‘startingpoint’ might have seemed unnecessary. Additionally, I felt that as a subproject of Universal Blue, this project couldn’t really achieve its full potential.

...

[–] Throwaway1234@sh.itjust.works 1 points 1 year ago* (last edited 1 year ago) (1 children)

so I run sudo nano /etc/default/grub

For improved security during file edits that require root access, it's highly advised to use sudoedit (or sudo -e). This method is considered the standard practice to avoid the security pitfalls associated with directly invoking editors with sudo. To ensure the use of nano with sudoedit, simply set the VISUAL environment variable with export VISUAL=nano before running sudoedit . Alternatively, for a one-off command: VISUAL=nano sudoedit /path/to/file.

Please note that while sudoedit is a safer starting point, it's not the only method available. Alternatives such as doas, doasedit, or leveraging polkit with pkexec can offer even more controlled and secure ways to manage file editing with elevated privileges. However, it's perfectly acceptable to stick with sudoedit, as it's a commonly trusted tool.

Be aware that direct usage of sudo nano or other editors is strongly discouraged. It bypasses important security mechanisms and can lead to inadvertent system-wide risks.

EDIT: changed VISUAL=nano sudoedit to VISUAL=nano sudoedit /path/to/file.