hunger

hunger, 6 months ago

The one thing you can learn from sysv init isnthat asking devs to pitncode into their programs or into starter scripts does not work. They will not bother: Those will notmworkmcross platform.

So you need to cebtralize that task. You can either write a wrapper program that sandboxes starts applications in a sandbox or do that whereever the programs as are started anyway.

A separate sandboxing app that starts services complicates configuration: You basically need to configure two things the starter and the service. On the up-side you have the sandboxing code separate. Merging the sandboxing into the program starting the service makes configuration simple but adds moremcode into the the starter program.

So it is basically a decision on what you value more. Systemd decided to favor simpler configuration. The cost for adding the sandboxing is small anyway: It’s all Linux kernel functionality that does need a bit of configuration to get rolling, with much of that code being in the systemd-init anyway: It uses similar functionality to actually separate the processes it starts from each other to avoid getting confused by programs restarted and thusnchanging PIDs – something still a thing in many other inits.

I am convinced that making sandboxing easy does a lot formits adoption. No admin will change the entire startup configuration to add a sandboxing wrapper around the actual service. It is way more likely for them to drop in a override file with a couple of lines and without any problems when upstream changes command line options.

hunger, 6 months ago

You make it sound as if corporations actually contribute a lot to open source projects they use. That is not the case in 99.9% of all cases where corporations decide to use some open source project.

If you are lucky as an open source maintainer you get a few patches from devs using their private email addresses to sneak the contribution around the legal department, but even that is rare. What you will see is random requests from company users to provide an SBOM for the entire project right now or bug reports asking to fix something right now.

So I seriously doubt you loose out when using AGPL or GPL.

hunger, 6 months ago

Most of your examples are projects started by a company. The very few remaining are those 0.01% that got lucky.

My point stands: When you start an open source project, there is no need to worry about what companies might like or not. You will not get money from anyone.

hunger, 6 months ago

I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that’s due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.

In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.

hunger, 6 months ago

It is all about whos freedom you care for: GPL protects the freedom of end users, MIT and other permissive licenses focus on the freedoms of developers instead.

GPL defines freedoms end users of software have. It has to limit the freedoms of developers between the GPL project and the end user so that those developers can not strip out any of the freedoms the GPL wants end users to have. The hope is to build a better society by enabling everybody to understand the machines they own.

MIT and other permissive license care for the freedoms of people using the project directly, granting freedoms to those users only. Those people are free to forward the same rights to their own users or to remove them as they see fit. Thatbis way simpler for developers to work with: Basically do whatever you want.

Guess which option is more popular with developers and the companies that employ many of those developers?

hunger, 7 months ago

It is the same as with all logins: It goes through the Pluggable Authentication Modules. So you need a service that uses PAM (they basically all do for a long time now) and the configuration of that service needs to include homed as an option to authenticate users. Check /etc/pam.d for the config files.

hunger, 7 months ago

I use toolbox: Distrobox is a pretty horrible shell script and deleted parts of my home directory when I tried that.

In the end I just pointed toolbox to a script named podman that just adjusts the setup to what I need, implementing the missing features I wanted that way.

hunger, 7 months ago

Removing dump stuff to keep a community relevant, on topic and with a good signal to noise ratio is not censorship. Claiming so is just dumb.

hunger, 7 months ago

Yes, wayland by design does not let random applications grab events intended for other applications nor does it let random applications take screenshots at any point in time showing other applications screens. This requires applications to do screen sharing differently, and it indeed breaks random applications sending events to random other applications. That is basically all you wail about and an absolutely necessary property of any sensible system and it is very embarrassing that it took so long to get this.

hunger, 7 months ago

Small communities have a hard time staying up to date. X11 was ported decades ago, when non Linux OSes had more mind share and commercial backing. I doubt anyone could port X11 if that was the new thing mainly developed on Linux today.

hunger, 7 months ago

Censorship is about you being limited in the actions you can take to express yourself. It is not about cushioning you from the consequences of those actions from the people around you.

You obviously were allowed to take action: The contents was apparent upon on a forum and here as well. People reacted to your actions: Admins removed your contents and blocked you and I am telling you that your understanding of wayland as well as politics is limited.

Deal with it.

hunger, 8 months ago

Add a /var partition, boot from some live system, copy over the data, delete it in the root partition after making sure it was copied ok and add the new filesystem to fstab. /var is the only place we that will grow significantly(especially when younuse flatpaks).

hunger, 8 months ago

The idea behind TPM-locked boot is that you can boot into your system unattended, but it stops booting into any other system. Typically no password is needed, but you can also assign an additional (non-user) password if you want.

This is nice if you trust your system to be basically secure. Nothing else can access its filesystems, so no external tool can be used to break into it. Rescue disks can not access any data without knowing a special rescue key – so make sure to set one up! A nice side effiect is that the key is only available while setting up disks in the initrd and totally inaccessible at any other time. That makes it very hard to extract the password once the system is running.

You can encrypt the home directories of users using other services like systemd-homed. That will prevent anyone from accessing any data in the user’s directory while that user is logged out. Homed will basically use your password to unlock your disk and if that works, then the password is accepted. So you do not need that user to be listed in the traditional /etc/passwd file, which is useful as you can just copy the users homedir image file onto another system to move a user account over.

hunger, 8 months ago

But if the key is fully wrench-safe inside the TPM. You do not know it, you can not get convinced to give it up – even after repeated wrench use.

Of course the recovery key that typically goes with it and you logging password is not wrench safe, so that does not protect the system fully, while getting you a matching set of broken kneecaps.

hunger, 8 months ago

The point of using the TPM is that it does not unlock the drive unless it has a certain set of software is loaded in a certain sequence on the machine with that specific TPM chip.

So if somebody breaks grub and makes it load a shell, then that results in different software loaded (or at least loaded in a different sequence) and will prevent the TPM to unlock the system. The same is true if somebody boots from a rescue disk (different software loaded) or when you try to unlock the disk in an unexpected phase of the boot process (same software but different sequence of things loaded, e.g. after boot up to send the key to some server on thr network. The key is locked to one TPM, so removing the drive and booting it in a different machine also does not work.

The TPM-locked disk is pretty secure, even more so than that USB idea of yours – if the system you boot into is secure. It basically stops any attacker from bringing extra tools to help them in their attack. All they have available is what your system has installed. Do not use auto-login or run some root shell in some console somewhere…

hunger, 8 months ago

Systemd-networkd (not systemd the init system) defaulted to the google DNS servers when:

• the admin did not change the configuration
• the user did not configure anything
• the network did not announce anything
• the packagers had not changed it as they were asked to do
• the distribution actually decided to switch to networkd. Few have done somtomthis day.

That is indeed a serious issue worth bringing up decades later.

hunger, 8 months ago

might want to look at the more “advanced” distributions that let you choose the init system.

Yeah, sure… integrating a init system is a huge task (if you want to do it properly). Let’s do that several times!

hunger, 8 months ago

Why would he? It never was an issue.

hunger, 8 months ago

Why? Slab sysv-init (or openrc or s6) and the gnu tools the onto it and you will hardly be able to tell the difference :-)

That is actually the thing I like about systemd: They expose a lot of linux-only features to admins and users, making the kernel shine.

hunger, 8 months ago

Where are those “many of us”?

It is what the CI uses for testing. If several layers of people decide to not do their job and you have no hardware in your network that announces the DNS servers to use like basically everybody has, then those CI settings might leak through to the occassional user. Even then, at least there is network: Somebody that can’t be arsed to configure their network or pick any semi-private distribution will probably prefer that.

Absolutely no issue here, nothing to see.

hunger, 8 months ago

Last time I tried it was an apt install followed by a reboot. If your distribution claims to support several inits and it is harder than that: Your distribution did a poor job.

hunger, 8 months ago

Are they embracing activity pub? I read it is just one guy in the community working in it.

And the vast majority of users are on GitHub, looking for code on there. Having activity pub on other forges will not change that big time:-(

hunger, 8 months ago

Oh, the repository are easy to move.

The bug reports, PRs, wikis, CI/CD are stuck in github though. There is a huge lock in.

hunger, 8 months ago

Maybe the Mac uses full disk encryption? Clonezilla will clone everything incl. the empty areas as the entire drive contains data indistinguishable from random bits in that case. Encrypted data also does not compress.

hunger, 8 months ago

Starting the init system is the task of the root filesystem or initrd, with any boot loader. Systemd-boot happily boot into any init system just fine, just like any other bootloader that can boot Linux will boot into systemd just fine.

Systemd-boot boots kernel images (with efi-loader code embedded) and only offers a menu to pick which kernel file to load. What makes systemd-boot interesting is that it does nothing more than that: It does not read random filesystems, it does not implement random encryption things, does not parse image files and complex theme configuration, … .

hunger, 8 months ago

Build everything you use and ackage it in flatpak?

It’s not even that hard to build your own gentoo-based runtimes and install stuff on top of that. Fedora does offer that, too, offering fatpaks based on their own fedora based runtime + rpms.

hunger, 8 months ago

Works for me on arch linux. No hickups or anything and I am using it since it was first announced.

hunger, 9 months ago

The problem is that you lose out on dev attention when moving away from github.

I moved my projects into github when placeholder projects literally containing a README with a link to the real repo only got way more interaction on github than in the real repository: More stars, more views, more issue reports and even more PRs (where the devs have obviously Cloned the repo from the actual repository but could not be arsed to push there as well).

If you want your project to be visible, it needs to be on github at this point in time:-(

hunger, 9 months ago

After applying an update you need to make sure anything using the unmatched code is replaced by the patched code. A reliable way to do that is a reboot. Actually a reboot is pretty much the only reliable way to do that.

So I am not surprised that a distribution targeting end users asks for a reboot.

hunger, 9 months ago

X11 probably has only a few years before development stops

Development has stopped. The only things that see updates still are those that are needed to run X11 apps on Wayland transparently.

hunger, 10 months ago

Yeap, it is always the same set of poorly researched links that get pasted in threads like this.

Unix philosophy, evil corporate interests, insecure, bloated, entangled mess… it is these individuals thatbhave seen the light, notnthe silent majority that does all the work in distributions and when developing software that kind of opted withbtheir feet.

hunger, 9 months ago

First off, there are lots of problems with systemd (mostly down in the details) and controversial defaults at times, bugs, bloat, and hickups and whatnot. Like basically in all projects all the time. So of course there is valid critique on systemd, lots of it.

But I have a problem taking any argument seriously that is based on “I am smarter than everybody else”. I do not like detail Y or developer Z, so the project X sucks and everybody that disagrees is either a paid shill, forced into it or just stupid. There is no point in even talking with people like that.

hunger, 10 months ago

That comparison is bad on several levels:

First off, systemd-the-repo does contain way more than an init system. But yes, I am pretty sure systemd-the-init is slightly bigger than runit.

Secondly: Systemd-init does set up some useful linux kernel features for the processes it manages in an easy and consistent way. That’s why other services started to depend on systemd-the-init by the way: Systemd does linux-specific things developers find so useful that they prefer adding a dependency on systemd over not having the functionality.

Runit does not support any linux kernel specific features at all to stay portable to other unixes. Other alternative inits made the same design choice.

Thirdly: The overall attack surface of the system without systemd is bigger than a typical systemd system. That’s because so much code run by the init system is way more locked down as systemd provides easy ways to lock down services in a cross-distribution way. Note that the lockdown functionality is 100% linux kernel features, so it involves little code in the init itself. Users of other inits can of course add the same lockdown features as service-specific startup code into the init scripts. We saw how well that works across distributions with sysv-init…

Finally lots of security features implemented outside systemd-the-init require a systemd system as they need the lockdown features offered by the systemd-init. One example is systemd-logind: That depends on systemd-init to be secure where the pre-systemd attempts all failed to archive that goal. Logind makes sure only the user sitting at a screen/keyboard can actually interact with the device interfaces of the kernel device files managing that hardware, so no other user but you can see ehat you type and take screenshots of your screen. Contrast that to devuans approach: Add all users allowed to start the UI to a group and make the devices controllable by that group. Much simpler, KISS and the Unix way… but it also allowes all users on the system that ssh into the machine somebody sits on can log what other users can type. Apparently that is not a problem, since no system ever will have more than one user in the age of personal laptops and desktops. That seriously isvtheir answer… and they even rejected to maintain the ubuntu-before-systemd logind replacement when canonical asked them, because such functionality is not needed im Devuan.

hunger, 10 months ago

SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.

No, it is not. It is always the same few people that repeat the same slogans that failed to convince anyone ten years ago. But that does not really matter: In open source the system that can captures developer mind share wins. Systemd did, nothing else came even close.

hunger, 10 months ago

Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That’s because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.

Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).

Or if you prefer a more negative spin: “Systemd is on huge entangled mess of interdependent binaries” :-)

hunger, 10 months ago

None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there. Thatbis a design decision eachnofnthese made.

So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features. Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.

Systemd moved the goal posts for what a Linux init system needs to do. I doubt any generic Unix init system can compete.

hunger, 10 months ago

There is no significant section. It is just a few people telling each other the same old conspiracy stories over and over again.

hunger, 10 months ago

Portability matters.

In general: Yes. In the specific case of an init system for a specific OS: Not so much.

This is nicely demonstrated by none of the non-Linux OSes embracing any of the options you listed. They all want something that plays to the strength of their specific systems over some generic Unix thing.

If using Linux specific features was the only approach to security, I wonder how OpenBSD exists.

It is the best approach we have on anything running a Linux kernel.

systemd cannot compete with their simplicity, maintainability, smaller attack surface, and the list goes on and on and on.

It is also easy to have really simple code that does nothing interesting whatsoever. And for something that does not do much at all, the fork-dance that e.g. s6 does is pretty complex.

Maintainability also does not seem to be a big issue for systemd at this point in time either.

The smaller attack surface is relative as well: systemd-the-init is a bit bigger than the ones you list. But the difference is not as big as you make it sound and an init system does not do many interesting things that can get attacked by either.

On the other hand systemd can seriously lock down any service it starts (and does so out of the box for anything from the systemd project and many upstream projects that ship locked down systemd unit files). The init systems you listed do can not do that directly and either need helpers (which increases their attack surface again) or just do not bother. Considering that a init system starts way more lines of code that do more security critical things than an init system: I think this lockdown does lead to a smaller attack surface of the system overall.

systemd de-facto causing other projects to put in (sometimes radically) more work than they should have to, is not okay;

Somebody has to invest work to make things convenient and easy to use. You either run with what everybody else uses and share the effort or you do not and do the work all by yourself.

This is in no way systemd specific.

hunger, 10 months ago

Check out the devuan mailing lists then:-)

hunger, 9 months ago

I am not trying to convince you: Use whatever you want.I am trying to explain it, so that people can have a more informed discussion. The web is full of either systemd is the best since sliced bread and systems is horrible. It is neither: It is just a technical system that made technical choices that make certain things easier or even possible and others harder or even impossible.

The sytemd time thingy is actually more minimal than openntpd: It only supports sNTP and not the full NTP protocol and is a client only… Openntpd is a full NTP implementation with both client and server. It also is a great technical choice, so keep using it, especially when you need an NTP daemon.

You behemoth is my plumbing layer:-)

I like the ton of small and simple tools that systems brings along: systemd-nspawn is a really lightweight way to run containers that works basically everywhere, no need to install docker or podman. Disk resizing, sysusers, tmpfiles, boot, Key Management, homed, etc. enables me to build reliable, immutable images for my systems. There is no tooling whatsoever for this outside the systems umbrella.

If you do not try to build a 1980-style UNIX system, then you basically are stuck with systemd. Nobody else is even thinking about how to move forward. If you try to raise the challenges you see outside systemd, you get laughed at and are told that your usecase is obviously stupid. The limitations admins ran into 1980 are gospel now and you may not question any of that.

hunger, 9 months ago

Fuck binary logs too.

Text logs are binary, too… they just uses a pretty common binary encoding.

Where do you actually use text logs? I did not use text logs outside of hobby machines ever during my career. Logs were either aggregated in databases or at least stored in temper-resistant formats (usually due to legal requirements).

Do you actually use text logs in a professional setting? Just curious.

hunger, 9 months ago

With textlogs you have a hard time noticing a couple of added/removed/changed characters or even entire log entries. Thats exactly why some industries may not use text logs in the first place as permanent records that are at least temper-evident are mandated.

If binary logs go kaputt they tell you exactly which entries were effected and still display every bit of data they contain. Typically you do not grep in binary logs: Grep can not make sense of all the extra data in the logs (way more than in a typical syslog), so grep is just a poor tool for the job. You typically can use grep as binary logs so contain lots of text. This is ignoring compression, encryption and other extras of course.

hunger, 10 months ago

Librewolf

Maintaining a browser is a huge endeaver. Using some random browser that is maintained by a a lone person or maybe even a handful of developers basically guarantees that the whole thing is insecure. This is especially true when keeping functionality around that was removed in the “main” browser to improve security there. One example is the old plugin system that firefox replaced with a more secure one with less hooks into the core engine, breaking some old plugins.

Stay with mainstream browsers folks and install some plugins to improve them that way. At least you get patches asap.

hunger, 10 months ago

supply chain attacks are a serious problem that needs addressing.

Last I checked: I am not a supplier. So I will not invest effort to secure some supply chain for people that I do not have any obligations to: The license clearly states “no warranty” for a reason. I do those projects for fun, not to bother me with security stuff, notifications about security problems some automatic thing “found” that do not really effect my code and bogus merge requests to upgrade dependencies for no reason… this are all cool things if you are a supplier, do not get me wrong, but I am not. No, I will not invest hours of my free time to sign binaries nobody uses either or to fill out security surveys for badges I can display on github.

If you want me to act like a supplier: Pay me like all the other suppliers you have. I doubt there is any interest to do so for the projects I have on my private github :-)

For your own projects, it might be worth considering a move away from GitHub. (I’ve been thinking about it since Microsoft bought them.) Codeberg looks like a good alternative.

That also has associated costs: Your project gets instantly much less visible, so you need to keep a mirror on github for visibility. Unfortunately that also means that you will also get interactions on github, so you will need to log in occasionally to not make people think the project is dead.

hunger, 10 months ago

Maybe you are running Wayland and not X11?

hunger, 10 months ago

Autsch! I would never do that… X11 is such a broken mess, but then my window management needs seem to be very different from yours.

Applications do have a say in how big they get rendered (typically by giving a min/max/preferred size), which window managers may or may not resepct/adjust for after the window comes up. Maybe it is just that.

hunger, 10 months ago

Not at all: I listed the arguments you will get for that question of yours. They all are bogus, as I tried to explain between the parens.

hunger, 10 months ago

Where are those alternatives? I have not seen anything that is Baustoff convincing yet…

It is not a project owned by redhat… the lead guy not even works there anymore. So the more interesting question is: What happens if Microsoft closes down the project? The answer: It will be forked.