Re: Call for votes re new member for the Technical Committee
* Ian Jackson (ijack...@chiark.greenend.org.uk) [131122 13:30]: Ian Jackson writes (New member for the Technical Committee - formal proposal): In two weeks' time (say, 2013-11-21 14:00Z) I will call for a vote on all of the names put forward by TC members. Sorry about the delay. Here is the final resolution. I hereby call for a vote. There are three options: Packard, Kern and FD. Intro, common to all non-FD options: 1. The Technical Committee thanks all the candidates who put themselves forward for the vacant TC seat. 2. We appreciate the opportunity to select from a strong field of candidates. Option Packard: 3. We propose to the DPL that Keith Packard should be appointed to the TC. (Constitution 6.2(2)) Option Kern: 4. We propose to the DPL that Philipp Kern should be appointed to the TC. (Constitution 6.2(2)) Ian. I vote Packard, Kern, FD. I would like to personally thank Phil for running. It wasn't easy to take a decision between both but well - at the end it has to be taken. Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129092841.ga30...@mails.so.argh.org
Bug#685795: Technical Committee proposes Keith Packard to fill vacant TC seat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The Technical Committee has passed the following resolution: 1. The Technical Committee thanks all the candidates who put themselves forward for the vacant TC seat. 2. We appreciate the opportunity to select from a strong field of candidates. 3. We propose to the DPL that Keith Packard should be appointed to the TC. (Constitution 6.2(2)) Background: In mid 2012 we took nominations from the project at large for a possible addition to the Debian Technical Committee. We received a number of nominations, both self-nominations and suggestions from co-contributors. In December 2012 we asked each of the suggested nominees whether they were willing. Unfortunately there was a hiatus in the process until September 2013, at which point we collated the nominees' responses. The resulting longlist of nominees who said they were willing was: Michael Biebl Julien Cristau Raphael Hertzog Philipp Kern Keith Packard Craig Small We apologise for not having published this list at the time. During September, October and November we discussed privately the merits of the candidates. We were pleased with the strength of the field of candidates, although the lack of some kinds of diversity (particular, gender diversity) was disappointing. After our private discussion had come to a natural end, with everyone having said what they felt was important, we moved onto the formal vote. The voting process is constitutionally defined: any TC member may nominate a candidate to be voted on by other TC members; there is then a Condorcet vote between those options and Further Discussion. TC members nominated a shortlist of two candidates: Philipp Kern Keith Packard The votes were as follows: Ian Jackson, Bdale Garbee, Russ Allbery, Andreas Barth: 1. Keith Packard 2. Philipp Kern 3. Further Discussion Don Armstrong, Steve Langasek, Colin Watson: 1. Philipp Kern 2. Keith Packard 3. Further Discussion Once again, thanks to everyone who stood. The Debian Project Leader now has the opportunity to confirm, or to reject, the nomination. Ian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJSmHw2AAoJEOPjOSNItQ05U0EH/0Syy+eGvKY02VG8SOBjXD1p mFOb3uldLlDainZ0RpPeGxBJkK+1ak+B1YrEX3dFLgLvTgAF6loxE5N7CDP10mSH 9iZ2mUmAcboDhN4sR7OQcsZ3u+Eu11ga8sHcKkKSvBMSPwfTxH5IEcWlDpUbza/W +TXRSj8WtKpQSZ12YH+HhKGRHNGIhSlMjgulih0Z5EuqliIaTO7gDEy7uQh8cETh /gcy5zCR43T9tOcIqMIqqlIrpum7CMfk4GoUb7Y8AptSm4Eg9BiBSF8tGeyReWRo f9yc5C0iVGyJnKMO1GyH+KZmj2sExMYug4DJSqloXPBGZqxS/zcSFH3jXDxRMb8= =lJYa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21144.31871.634419.342...@chiark.greenend.org.uk
Bug#727708: systemd (security) bugs (was: init system question)
Le jeudi 28 novembre 2013 à 13:43 +, Ian Jackson a écrit : In summary, I agree with Andrew Kanaber's view that the security and bug history of systemd is worrying. Personally, I find the flow of bugs (including security bugs) for moderately recent software the sign of a healthy project. A simple look at a few packages in the BTS will show that packages with lots of reported bugs are packages with lots of users and features, regardless of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come to mind as being full of bugs, including security bugs. Indeed, systemd has not been written with security in mind. Neither have sysvinit nor upstart, AFAICT. Yes, it would be better if *all* developers had a better grasp of secure programming, but on the other hand, asking the first people to use some advanced kernel interfaces to understand all their security implications is unfair. Just like we don’t hold the Mozilla developers responsible for security issues in brand-new Javascript engines that maybe 10 developers in the world could understand. As Michael mentioned, systemd has a broader scope than alternatives. You’d have to use a system providing similar features as a basis for a fair comparison, and such a system doesn’t really exist in the Unix world. If you only take into account the features that are also provided by upstart or sysvinit/insserv, you won’t find that many of these bugs apply. Compare that to the number of unfixable bugs in sysvinit due to broken design. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385744139.24216.1151.camel@dsp0698014
Bug#727708: systemd (security) bugs (was: init system question)
Josselin Mouette writes (Bug#727708: systemd (security) bugs (was: init system question)): Personally, I find the flow of bugs (including security bugs) for moderately recent software the sign of a healthy project. A simple look at a few packages in the BTS will show that packages with lots of reported bugs are packages with lots of users and features, regardless of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come to mind as being full of bugs, including security bugs. All of those components are to a greater or lesser extent optional. What we are being asked is to make use of systemd mandatory. Indeed, systemd has not been written with security in mind. What an alarming comment on a program which has ultimate privilege, is intended to be universally deployed even in the most demanding security environment, crosses security boundaries (without, IMO, a sufficient justification), and is being touted as the single systemwide manager for security features like cgroups ! Neither have sysvinit nor upstart, AFAICT. I will leave the upstart maintainers to comment on this in more detail, but sysvinit has had remarkably few security bugs for a program of its vintage. This is because it has very few, and very restricted, interfaces to untrusted parts of the system. Just like we don’t hold the Mozilla developers responsible for security issues in brand-new Javascript engines that maybe 10 developers in the world could understand. The security record of web browsers is indeed atrocious. It is the result of a persistent swamp of bad design decisions, hideous overcomplexity, plain bad code, and lack of attention to mitigation measures. Google's efforts in this area are to be applauded, even though I have serious privacy problems with Google. It is very alarming that web browsers are being presented as the security benchmark for our new init system. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21144.51928.798814.268...@chiark.greenend.org.uk
Bug#727708: systemd (security) bugs (was: init system question)
On Fri, Nov 29, 2013 at 05:55:39PM +0100, Josselin Mouette wrote: Indeed, systemd has not been written with security in mind. Neither have sysvinit nor upstart, AFAICT. I wouldn't presume to say whether the systemd authors had security in mind while writing it. But I will stand by the overall security design of either sysvinit or upstart, namely that the user-accessible interfaces are kept as small as possible to make them as auditable as possible. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: systemd (security) bugs (was: init system question)
Le vendredi 29 novembre 2013 à 17:11 +, Ian Jackson a écrit : Josselin Mouette writes (Bug#727708: systemd (security) bugs (was: init system question)): Personally, I find the flow of bugs (including security bugs) for moderately recent software the sign of a healthy project. A simple look at a few packages in the BTS will show that packages with lots of reported bugs are packages with lots of users and features, regardless of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come to mind as being full of bugs, including security bugs. All of those components are to a greater or lesser extent optional. Linux is optional? X is optional? Not for everyone. (X is a bad example anyway, because, unlike the rest, it *has* a bad security design.) What we are being asked is to make use of systemd mandatory. It doesn’t mean that all of systemd’s features should be enabled on all machines. The reason why embedded manufacturers are sponsors for systemd’s development is that it means less code, and therefore less bugs (security or not), than alternatives. Indeed, systemd has not been written with security in mind. What an alarming comment on a program which has ultimate privilege, is intended to be universally deployed even in the most demanding security environment, crosses security boundaries (without, IMO, a sufficient justification), and is being touted as the single systemwide manager for security features like cgroups ! Only an extreme minority of Debian packages have been written with security in mind. Not all packages can be OpenSSH or Postfix, and we have to live with that fact, because we need the features in other packages (starting with a kernel and libc). Neither have sysvinit nor upstart, AFAICT. I will leave the upstart maintainers to comment on this in more detail, but sysvinit has had remarkably few security bugs for a program of its vintage. This is because it has very few, and very restricted, interfaces to untrusted parts of the system. And of course, there has never been any buggy init script. Again, your comparison doesn’t make any sense since you don’t compare similar functionality scopes. Just like we don’t hold the Mozilla developers responsible for security issues in brand-new Javascript engines that maybe 10 developers in the world could understand. The security record of web browsers is indeed atrocious. It is the result of a persistent swamp of bad design decisions, hideous overcomplexity, plain bad code, and lack of attention to mitigation measures. Google's efforts in this area are to be applauded, even though I have serious privacy problems with Google. I’m afraid you don’t entirely understand why the security record of web browsers looks atrocious. Because of a swamp of bad decisions *from web developers and designers*, backed by users, browsers have to cover a functional scope that far exceeds in complexity any other kind of software. A typical browser has to include several virtual machines, graphical/layout toolkits, JIT compilers, advanced cryptographic software, all of which have to work with heaps of untrusted data. When taking all of that into account, as much as I hate dealing with them, I have to admit the security record for several browsers is good, and it’s because they *are* developed with security in mind. It is very alarming that web browsers are being presented as the security benchmark for our new init system. It is quite alarming that a member of the Technical Committee demonstrates lacks in security knowledge while at the same time using security bugs as a measure for comparing solutions. This “security” discussion has nothing to do with the case in point, though. If you have specific points you want addressed by the systemd position (like how systemd’s upstream designs user interfaces to avoid security bugs, or handles security alerts), please state them clearly and I will do my best to gather information for you and answer them. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385749113.24216.1192.camel@dsp0698014
Bug#727708: systemd (security) bugs (was: init system question)
On Fri, Nov 29, 2013 at 05:11:52PM +, Ian Jackson wrote: It is very alarming that web browsers are being presented as the security benchmark for our new init system. So, I tend to agree with Joss here - Web browsers is the biggest attack surface that we have today, bar none. I don't think anyone really disputes this. The safety of modern web browsers is (well, minus a qualifier below), frankly, shockingly good. The amount of exploits from JS is crazy low for something that's able to do so much (store data locally, use WebGL / 3D rendering, play audio), it is shockingly hard to exploit. When you look at the entire stack (CSS parsers / evaluators, HTML parsers evaluators, JS parsers and evaluators), the only disaster would be stuff like ActiveX. I'm not sure of it's state, since I've never run a platform that supports it, but I hear it's getting better. So, yes, browsers are a cespool, but it's one that runs complete garbage on the internet. I'd be stunningly happy to see an init system that can handle as much pure crap as browsers have to put up with :) More on-topic, I do think that the systemd bugs are more likely because people are playing with the code, exploring it for holes, and pushing them, which is healthy. I'm sure if you poked hard enough, most systems would show such bugs. (as has been already said, really) Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]
On Fri, 2013-11-29 at 12:37 +, Ian Jackson wrote: Uoti Urpala writes (Bug#727708: systemd (security) bugs (was: init system question)): My guess is that most people do not consider that exciting or really care - thinking of system states in terms of runlevels is mostly obsolete, and the flaws do not bother many people in the cases where backwards compatibility is still needed. Statements like this are part of what make me think this might be a fundamental problem. When a systemd proponent tells me that a particular use pattern is unimportant or wrongheaded, I tentatively infer that systemd cannot support it properly. At least here this logic led you to the wrong conclusion, so you might want to reconsider it. It seems to me that the difficulties with the runlevel emulation are likely to affect other similar use patterns too. The problems don't seem specific to the nature of runlevels. Perhaps they are specific to the way runlevels are emulated by systemd but in that case that emulation should surely be fixed. The issue was legacy runlevel changes being simply mapped to isolate new_runlevel, which does not have quite the same semantics as sysvinit runlevel changes (most importantly, it stops everything not in the new_runlevel target, without limiting to only things that were part of original runlevel target). There's no reason why the set of services to stop could not be calculated in a way closer to sysvinit semantics. But there's little reason to deal with runlevels at all when using systemd, and it seems most people don't. So while the backwards compatibility support could be improved (probably rather easily), I think it's clear why this has not been a priority for either developers or users. More importantly it is one which is exploitable only as a consequence of the questionable design decision to expose pid 1 to ordinary users. I think there are good reasons to allow querying status directly. One sanity check that IMO should be kept in mind for perspective when considering any even one DoS issue in PID 1 is a catastrophe arguments is that Debian will always require running a kernel, and there have been lots of DoS or worse issues there. Unless you expect the majority of Debian users to move to minimal microkernels in the near future, there is little basis to demand an absolutely minimal init process when the kernel contains much more code in a more critical role. The same applies to this: and is being touted as the single systemwide manager for security features like cgroups ! Parts of the implementation for this are on the kernel side, parts on the systemd side. I see no reason to think that the systemd side would be the more problematic one. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385755769.13584.51.camel@glyph.nonexistent.invalid
Re: Bug#727708: systemd (security) bugs (was: init system question)
As a system administrator, the idea of a 'kitchen sink' init system terrifies me. I would need exceptionally high confidence in its authors and design principles before allowing it to run as root on my systems and depend on it to boot even to single user. I wouldn't even invest much time enquiring into this, if I knew I could manage with something simpler having less scope for security/reliability bugs. OTOH I would be much more forgiving if this were being used for, say, employees' own desktop machines in a protected corporate IT environment. Lots of systemd's features seem particularly convenient for that use case. And security is enforced in other ways there (the only people with access at all, know they risk getting fired for trying to escalate privileges or DoS). Adopting systemd may have been much simpler if it had been separate from and launched by the simple init, starting only the services that have unit files because they really require its functionality. If no installed software on that system needs it, it wouldn't even need to be installed. But otherwise I think there are GNU/Linux users who want the choice of using systemd or being able to use something else. Preferably without having to switch a different distro or third-party derivative. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298f9d0.8000...@pyro.eu.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
The original question was which init system[s] are going to be the default. But there are still some other things I'm curious about: 1. we already have alternate init systems in the archive; could it be some kind of release goal to ensure they are installable? i.e. make it possible for them to satisfy the dependencies of essential packages. (Steve Langasek's metapackage idea in [0] seems to be in the right direction for accomplishing that, except it wouldn't work for OpenRC or indeed for keeping the original sysvinit/sysv-rc). [0]: http://lists.debian.org/debian-devel/2013/11/msg00389.html 2. would exceptions be permitted; could some packages explicitly depend on a non-default init system if it's the only one providing functionality it needs (and still be part of a stable release)? I'm thinking that GNOME might (someday, if replacements for logind or other APIs can't be found) want to do this, if systemd isn't chosen as the sole default on GNU/Linux. (It seems similar to a maintainer being able to restrict packages to Arch: linux-any if they cannot / do not want to support non-Linux ports). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529907fc.7040...@pyro.eu.org
