If the distro supports apparmor, then firejail + apparmor offer together sandboxing for quite a set of applications (apparmor includes few profiles by itself, but firejal has quite a few, and one can enable apparmor on all, or the ones wnated). Arch has pretty good wikies about firejail + apparmor.
Jami doesn't require a phone number, which is p2p. Xmpp (+ Omemo) doesn't require a phone number and it's federated... I mean, if a service is willing to rid of phone numbers, it'll do totally without them.
Bloated and unnecessary if freeSW or openSW. That's what system shared libraries are for. If sandboxing is a thing, then firejail is availble, which can be combined with apparmor if looking for extra MAC security.
@infeeeee@lemm.ee, I think I got now why by default the keep strip and debug together. stripseems to be removing them only from the non -debug package generated, and not doing so on the -debug package generated. So they actually make sense together.
That said, you were right. If not interested on the -debug packages getting generated, just use !debug.
LTO is a different thing, and I'm not sure why it was enabled by default until now (well, It's said it doesn't play nice with clang), see this RFC from 2 years back. Also notice what current makepkg uses is LTOFLAGS="-flto=auto". The idea according to the RFC, is that for packages failing to use the default, options=('!lto') can be added to the PKGBUILD.
So that should be safe, and iif you're wondering, it stands for Link Time Optimization. On AUR, I guess users adding new packages or maintaining packages, should be aware, and add that option if they find out LTO by default is giving issues.
I guess the current defaults are sane. All I said the original post, is that the strip option, which is still enabled by default gets rid of the debug symbols. So yes, now they are getting generated by default, but also stripped off by default. And that's what I don't understand. Perhaps that's a good topic for the arch-general mailing list, hoping some developer is around to clarify things. Perhaps the current makepkg.conf is an intermediate one, and there will come another one using !strip instead. Or maybe currently strip doesn't get rid of all debug symbols generated by debug. But the current documentation on makepkg.conf is not clear enough...
So I would leave the current defaults if it's not clear yet if changing them is something that would help you out. As mentioned, with strip you shouldn't get that huge packages. But also it'd be good to make sure, asking on a Arch forum involving devs...
But strip is still enabled on new makepkg.conf, so all debug symbols get removed when packaging. Actually I don't get it why stripping debug symbols while also generating them first. So are those two actually compatible?
Will they keep doing that, is there a policy about it written somewhere? Have they expressed something about it in a forum or news, just like mint did at some point when ubuntu started with firefox mess and others. I can't find anything from their web site, and on this reddit post, Does Rhino Linux use Ubuntu mirrors for apt packages?, it seems they follow closely ubuntu's mirrors, and if they do so, whatever ubuntu stops supporting on APT, sounds like rhino will stop supporting on APT as well.
This would be very sad at least for me.
Besides !rhinolinux@lemmy.ml, which is not officially supported by rhino, there are 5 social media mechanisms they support, which I don't have account for neither I want to, and I don't want to subscribe to another mailing list either. Good old IRC is not one of the contact mechanisms supported BTW, neither email (but even if they did, I don't want to subscribe to yet another email list)... Perhaps someone on any of those official communication channels can ask and share what they answer, making a reference to what they answered already regarding repos...
Are you looking to clean up your client inbox, or the server inbox?
If your client inbox, you don't need a plugin, on the account settings synchronization & storage, on the section disk space, select the synchronize the most recent and specify the amount days, months, years, whatever.
If you want to remove too old messages from the server, perhaps the server itself offers a way to do so...
I read about its rhino-pkg, which is just a wrapper as I mentioned. My concern is not about not being able to use each package manager directly, but rather on its packaging policy. Is it to follow canonical/ubuntu decisions? Or will it keep packaging what it as a distro offers to users on deb packages controlled by apt?
Yes, I cross posted it to !rhinolinux@lemmy.ml once I noticed it had a community, though I guess that would be the 1st post ever, :)
Being using mull for so long, even when it was not available on f-droid official repos, but only divestos f-droid repo.
The only thing really bothering on mull is a config one really must change, security.OCSP.require, the default to true prevents reaching several sites. But other than that mull shouldn't get in your way, and one can change other config to one's liking if in need.
I'm wondering how both mkinitcpio alternatives work on non systemd boxes with full disk encryption. With both, I refer to dracut and booster. On its origins I believe dracut was pretty tight involved with systemd, and booster is developed/maintained by an arch developer/user if not mistaken, and arch supposes systemd, though none of those things actually mean non systemd boxes are not supported.
I'm also wondering if the initrds generated can be launched by grub (I do /boot partition encryption/decryption with grub), and I also do / full partition encryption with luks. This booster issue sort of indicates as of now booster initrd images can't be loaded by grub...
I see, I didn't dig into the cause, being sort of a buffer overflow. Indeed that would be prevented by other languages, sorry for my misinterpretation. Other vulnerabilities unintentionally introduced by developers on logging what shouldn't are not dependent on anything other than auditing them, but that was not the case then.
True, the logging is part of the library, but it's totally centered on what the developers are logging. It's a bad practice to log sensitive information, which can be used by someone with access to the logs for sure, but that doesn't mean the library is broken and has to be replaced. The library's logs need to be audited, and this as true for glibc as it is for musl, no exception, and it's not a one time thing, since as the libraries evolve, sensitive information can be introduced unintentionally (perhaps debugging something required it on some particular testing, and it was forgotten there).
BTW, what I meant with the language, is that no matter the language, you might unintentionally allow some sensitive information in the logs, because that's not a syntactic error, and it's not violating any compiling rules. It's that something is logged that shouldn't.
Also, the report indicates that the vulnerability can't be exploited remotely, which reduces the risk for several systems...
If the distro supports apparmor, then firejail + apparmor offer together sandboxing for quite a set of applications (apparmor includes few profiles by itself, but firejal has quite a few, and one can enable apparmor on all, or the ones wnated). Arch has pretty good wikies about firejail + apparmor.