Re: Four people decided the fate of debian with systemd. Bad faith likely
On 2 March 2014 10:53:51 WET, Jack j...@jackpot.uk.net wrote: Systemd scares me. As far as I can see it does a lot of things right (in some cases these are things that no other contender does right); I'm not going to try to enumerate those things, that's been one elsewhere. But the way systemd has been designed, in particular the way it has borged dbus and syslog, is a real problem for me. I try to build systems that only run those daemons the system really needs. This is partly for security, and partly because I have several systems that are resource-challenged. Many of those systems have no GUI, and until now needed no dbus. I try to run nothing that depends on polkit or consolekit (it's a coincidence that those components are also Lennart's work). But the systemd approach is to use dbus for all IPC; and dbus is now part of systemd. Dbus is complicated; I don't begin to understand it. SystemD places dbus at the heart of PID1, and that IMO was a questionable technical decision. SystemD isn't just an init system; it also uses the CGROUPs kernel feature to manage user sessions. I don't understand why that functionality was incorporated into the init program. An init system, IMO, should restrict itself to bringing up services. I *really* don't want binary logs. I realise that I can make the new journald pass all log output to a text-based syslog daemon; but then I'm running a journald that I don't need. Similarly I have no need for a logind: even those of my systems that have a GUI are not multi-seat. If only systemd had been designed as a smorgasbord - a set of components designed to work in concert, but each being susceptible to being omitted in favour of its predecessor, then I would have been much less uncomfortable about it. I think it's great that Debian provides the only mainstream platform that supports The Hurd an kFreeBSD kernels, although I don't use them. The choice of systemd as a default init system will inevitably marginalise those kernels in Debian, which I think is sad. I do hope that those working on writing standalone components that implement the various systemd interfaces are successful (and soon). I will probably be sticking with Wheezy/SysV as long as possible, or until the prospects of those efforts becomes clear. I wish I had the chops to contribute to those projects - I believe they have the potential to match the strengths of systemd, while avoiding the birds-nest of dependencies that makes systemd seem such a heavy, take-it-or-leave-it deal. Of course, the CTTE's decision concerned the *default* init system for Jessie. Other init systems will continue to be packaged. So it's not an apocalypse. But systemd does *so much*, and so many other distros have decided to adopt it, that I fear that applications will come to rely on its features; the other init systems will be marginalised, and eventually wither. We will then all become dependent on Red Hat for a large part of our critical infrastructure. Red Hat is a billion-dollar commercial operation, with goals that are very different from Debian's. So I fear the CTTE's decision may in time come to harm the Debian project. I am also only a Debian user and I don't know much about the matter, but if I understand correctly systemd is a drop in replacement for sysV, which has a lot more functionalities but works fine with sysV initscrits. Wouldn't it be possible, in the future, to write a replacement to systemd which works fine with the systemd configuration, but that doesn't have most of those problems that systemd has? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/407a788a-4d3f-480a-ad6e-509d2a2ef...@email.android.com
Re: Compromising Debian Repositories
On Mon, Aug 5, 2013 at 9:17 AM, intrigeri intrig...@debian.org wrote: I need a reality check, as it's unclear to me what are the goals of this discussion. I don't think there are any goals. I asked it just to understand if it would be possible to do what I was thinking (apparently, it is) and the discussion continued from there. I think most of you are foccusing in servers running Debian, but when I asked the question I was thinking about personal computers. For example, if there are any vulnerabilities on ssh, they won't be able to get into my computer anyway because I'm always behind a NAT (and I'm not even sure that I have ssh on this computer). I understand that usually you are worried about directed attacks towards a machine, but in this case the NSA (and probably many other organizations) is interrested in infecting a lot of computers and mine data from there.
Re: Compromising Debian Repositories
I am really sorry if you think it's rude to start a topic here without subscribing. I thought that it was acceptable, since a lot of people do it in debian-users (I know it has a lot more volume than this one) and it's the default action when you click on Reply to All in most clients (well, probably a lot of people here use less standard email clients). Anyway, I just subscribed to this list ;) I am aware that it is possible to write obfuscated code that doesn't behave as expected, but I guess that the kind of people that usually write code like that aren't the kind of people that are accepted to write code for Debian. This is a problem that is harder to tackle, so now I'm assuming that any code whose source is publicly available has got enough scrutiny and we can trust it. What I was asking was about the case where the binary/package does not correspond to to the given source. Hipotetically the NSA could pay off the maintaner of some libfoo or executablebar that is required by the debian core (hence, that must be installed in all Debian systems). Before compiling that package the developer could change it to include some trojan and provide the unmodified source. In principle, deterministic builds would solve this problem, but I'm not sure how hard it is to accomplish (I'm not used to wirte compiled code). If there is a different version of the compiler, of some random lib or of some smaller thing, there could be some bytes that are differente, making it quite hard to reproduce. Creating an automated build server does not seam easy because there are packages written in a lot of languages that have a lot of different requirements. To conclude, I just want to say that I don't have any problems trusting debians mantainers in general (I currently run Debian on my personal computers and I'm setting up a personal server, also using Debian). The problem here is that only one rogue mantainer could infect every Debian system with some trojan. PS: I'm sorry if this one general answer breaks someone's threaded client, but I thinnk in this case it makes more sense one big answer than a lot of smaller replies.
Re: Compromising Debian Repositories
On Sun, Aug 4, 2013 at 2:55 PM, Michael Stone mst...@debian.org wrote: On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote: I think the real issue is about if the malicious patch is not part of the source package Why? It certainly makes your argument simpler if you arbitrarily restrict the problem set, but it isn't obvious that it makes sense. If I was going to backdoor something, I'd just make an innocent-looking coding error that would enable a successful exploit; I certainly wouldn't put in a commented section of code that says backdoor here. With sufficient effort it wouldn't be hard to inject such a vulnerability that would go unnoticed for years--and I'm not sure why that's less of an issue than someone making a one-time build with a malicious patch that is not part of the source package. First of all, they could apply that change (calling it a patch was not one of my greatest ideas) for every update they do, it's not necesserily a one time thing. It's also much easier (and probably much dangerous) to write some code that doesn't need to be cryptic, you can just write whatever you want instead of trying to find something that can pass as a mistake (although this seams a fun thing to do) Despite this, the most important reason is that I don't see anyway to prevent that from happening, but we can prevent this. It's not easy and will take a lot of work, but at least it is theoretically possible. I don't have any experience on this and I would not know where to start (I haven't even done a Debain package, ever), but if there's any workgroup or anyone working on this, I would like to help
Compromising Debian Repositories
I was reading this [1] article and it brought a question do my mind: How hard would it be for the FBI or the NSA or the CIA to have a couple of agents infiltrated as package mantainers and seeding compromised packages to the official repositories? Could they submit an uncompromised source and keep a small patch that they apply before building and sending it to the repository? Or is the building process done on Debian servers? 1: http://online.wsj.com/article_email/SB10001424127887323997004578641993388259674-lMyQjAxMTAzMDAwMTEwNDEyWj.html PS: I am not subscribed to this list, please keep my address in copy
