Recent searches
Search options
@dysfun i mean, same? but that ship sailed well before lennart entered the picture
@leftpaddotpy @ariadne @dysfun And it was all modelled on COM by folks who thought Windows was doing things that made sense...
@leftpaddotpy @ariadne @dysfun There is really a clash of two *philosophies* here:
One that believes software systems should be tightly coupled with every piece of software interacting with the events and data of one another, mediated through object oriented abstractions.
And one that believes software should be decoupled, staying out of each other's way and exchanging data and reacting to events only through standard data formats and system interfaces.
@dalias uhhhhh
> software should be decoupled, staying out of each other's way and exchanging data and reacting to events only through standard data formats and system interfaces.
"standard data formats". do you mean "text", for which you have a "broken handrolled C parser full of CVEs" because it's not actually structured *or* standard? or is there some magical format I have forgot about?
dbus is a standard data format. the systemd-standardized interfaces are a standard, structured format.
@leftpaddotpy Um, you're reading some weird ideas you had in your head into what I said...?
@dalias every time I see people accusing systemd of not using the standard APIs, the so-called standard APIs in question did not exist before, and the functionality was, prior to systemd, achieved by the client software mutating things in such a way that assumes they were the only possible client (e.g. /etc/resolv.conf with VPN software, vs under systemd-resolved)
I simply do not understand your argument.
@leftpaddotpy @dalias oh, systemd-resolved handling of /etc/resolv.conf is great example how to do it wrong way. Yes, there was maybe resolvconf only, hackish command. But because no other service claimed to be best #DNS cache everyone should use. I am quite confident resolved is broken. It supports only itself, unlike other solutions. Okay, it has decent dbus API. But also unfixed issues. Systemd has excellent integration skills, but fails to export it for use by 3rd party services.
@pemensik @leftpaddotpy Nobody actually wants resolv.conf to get rewritten based on what network they connect to, with a garbage ns serving fake results with ads injected. They want it statically pointed at 127.0.0.1, 8.8.8.8, or something they trust. That something *should* be on 127.0.0.1, with full dnssec validation & efficient upstream querying, which systemd kinda tried to do, but botched...
@dalias @leftpaddotpy that depends. If systemd is preventing some features like dnssec or single label queries, then I want working resolvers instead. Statically configured servers won't know site-specific domains. Sure, you want to override DNS servers network has provided *sometime*. But you would want privacy VPN on such networks anyway, if you need to use that network at all. I get broken experience even on trusted networks with resolved.
@pemensik @leftpaddotpy VPN UX on Linux is just messed up. We now have the tools to do it right (user+net namespaces with their own localhost & own ns running on it with no access to outside-vpn network), but are doing it still with fragile hacks messing up global system network config. 
@dalias @leftpaddotpy I am not sure, why would you want to lock a process into separate namespace with a VPN. In most cases I *want* site-enabling VPN to modify *global* system configuration. I just want to choose which parts this VPN can provide, for example limiting it to only selected domains. It would be nice to have simpler ways to bind a service to just one network interface, but I don't need it often.
@pemensik @leftpaddotpy I was speaking more with sn assumption of a privacy providing VPN where you don't want any traffic to leak. But a site-enabling VPN also makes sense to scope only to processes meant to have access. A compromised nobody account shouldn't have access to VPN your user account has access to.
@dalias @leftpaddotpy I think general assumption is once local machine is compromised, security falls apart. I would say untrusted nobody user (and it's services) should have filtered access to the system network. Especially if you run a code without trusted source from it. Sort of podman solves it. Okay, it would be nice to restrict domains and IP ranges such process can access. I don't know anything simple offering that.
@pemensik @leftpaddotpy If that's true, sounds like really, really bad news for most Android users...
@dalias @leftpaddotpy who said VPN server on Android cannot filter out ads or unwanted traffic? I think iptables should be able to filter based on userid or pid. I admit it would be great for flatpaks also. Name resolution usually does not have user or pid information for each request, it would have to use Unix socket instead of IP+port domain. So it would be difficult to apply ACL on those. But having alternative DNS cache on non-default address would be simple.
@dalias @leftpaddotpy Android apps have good sandbox from other users. Each app is separate user there. Unless given rights to media access, they are well separated. Except network and DNS, correct. I would not expect Google to make ads blocking trivial task for obvious reasons.
@pemensik @leftpaddotpy That's exactly what I said. If you consider the whole local system compromised because one user account (one Android app) is, Android users must be screwed.
@dalias @leftpaddotpy what I thing we miss is a good implementation of provisioning domains RFC draft, well integrated with the system. And proper support for site-specific domains (discovery), not ~example.com hacks in dns-search.