Re: Bits from the Security Team
Hi, On Montag, 17. März 2014, Moritz Muehlenhoff wrote: When doing security work you'll inevitably run into svn at some point, e.g. when digging for upstream fixes (also also cvs, hg, bzr etc)... well, true, but still, it's more appealing if ones primary VCS is sane. Holger (and yay for your LTS plans and all the work anyway :) With the current level of commitment an LTS is unlikely. what are you missing exactly? More people telling you I will support this by doing foo? I'd imagine the problem is, that foo is rather unclear. In general I'd be happy to support + probably even commit to LTS plans, but as it's rather unclear what it means, I'm rather carefully here. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Bits from the Security Team
Didier 'OdyX' Raboud wrote... I was trying to say that there is no policy currently in place to ensure that skip-upgrades actually work, Agreed. If LTS is going to be a permanent thing, this has to change. For any squeeze-lts to jessie upgrades, the ride might become a bit bumpy although I suspect the number of affected packages is *that* big. But no doubt it's above zero. Preventing skip-upgrade for a certain package using technical means doesn't look easy. The only solution available now I can think of is a come from version number check in preinst. That's ugly. So again, let's see squeeze-LTS as an experiment. But time is running up if any finding should result in updates policy etc. before the jessie freeze. and at least one maintainer has already started to cleanup pre-wheezy stuff from his packages [0]. [0] I'd be surprised to be the only one, who knows. Just in this thread, I've counted two :) Christoph -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395122...@msgid.manchmal.in-ulm.de
Re: Bits from the Security Team
Christoph Biedl debian.a...@manchmal.in-ulm.de writes: Didier 'OdyX' Raboud wrote... and at least one maintainer has already started to cleanup pre-wheezy stuff from his packages [0]. [0] I'd be surprised to be the only one, who knows. Just in this thread, I've counted two :) I cleaned up some of mine a long time ago. I usually remove upgrade support for oldstable shortly after the stable release, in my first upload targetted at the new release. But then I tend to be fairly aggressive in trying to decruft my packages. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ob14gfbl@windlord.stanford.edu
Re: Bits from the Security Team
Moritz Muehlenhoff wrote... With the current level of commitment an LTS is unlikely. Um, not good. Awaiting your announced separate message, then it's time for those who promised commitment back in last August to prove they are still interested. Christoph -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395126...@msgid.manchmal.in-ulm.de
Re: Bits from the Security Team
Hi, On Mittwoch, 5. März 2014, Moritz Muehlenhoff wrote: Security release workflow - * We're currently using Subversion. We discussed changing to git, but git doesn't offer significant benefit for our purpose so we decided to stick with it. I think you've missed one significant benefit here: (I believe) for quite many people by now it's a showstoper to join a team which is using subversion for it's workflow. I would certainly *not* join the security team while you're using subversion. (And I doubt I'm alone here.) Git is *so* much faster, more logical and easier to use. I cannot imagine (many) new people (as in fourteen or 42 year olds) wasting there time with subversion today, so to attract new contributors, please switch. I know it's your bikeshed, but... you are looking for help and my point is that it's harder to attract people with the tools of the last millenium. cheers, Holger (and yay for your LTS plans and all the work anyway :) I'll happily configure piuparts.d.o and jenkins.d.n to test what can reasonably can be tested here. signature.asc Description: This is a digitally signed message part.
Re: Bits from the Security Team
On Mon, Mar 17, 2014 at 10:33:32AM +0100, Holger Levsen wrote: Hi, On Mittwoch, 5. März 2014, Moritz Muehlenhoff wrote: Security release workflow - * We're currently using Subversion. We discussed changing to git, but git doesn't offer significant benefit for our purpose so we decided to stick with it. I think you've missed one significant benefit here: (I believe) for quite many people by now it's a showstoper to join a team which is using subversion for it's workflow. When doing security work you'll inevitably run into svn at some point, e.g. when digging for upstream fixes (also also cvs, hg, bzr etc)... Holger (and yay for your LTS plans and all the work anyway :) With the current level of commitment an LTS is unlikely. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140317162012.gc29...@inutil.org
Re: Bits from the Security Team
Hi, Le lundi, 17 mars 2014, 10.33:32 Holger Levsen a écrit : I think you've missed one significant benefit here: (I believe) for quite many people by now it's a showstoper to join a team which is using subversion for it's workflow. git-svn usage is a manpage away: once you've learned `git svn rebase` and `git svn dcommit`, you're basically with pure git. I would certainly *not* join the security team while you're using subversion. (And I doubt I'm alone here.) That's quite ironic from a DebConf chair's mouth. :-P Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7470528.AlHlBr3Krs@gyllingar
Re: Bits from the Security Team
Le lundi, 10 mars 2014, 22.00:09 Christoph Biedl a écrit : The problem is that there is no policy in place to make us support oldstable-to-testing upgrades. If there's interest, that'd need to be decided with a more firm policy than encourage maintainers. Would you have preferred to read something putting the burden onto the maintainers? Re-reading my statement again after hitting the send button made me admit that I didn't express what I intended to… I was trying to say that there is no policy currently in place to ensure that skip-upgrades actually work, and at least one maintainer has already started to cleanup pre-wheezy stuff from his packages [0]. People encouraging maintainers not to gratuitously break skip-upgrades on debian-devel is by far not equivalent to a Release Team decision on bug severity for a failure to skip-upgrade for example. Cheers, OdyX [0] I'd be surprised to be the only one, who knows. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7312246.zXeI0qdFfj@gyllingar
Re: Bits from the Security Team
Simon McVittie writes (Re: Bits from the Security Team): On the other hand, going directly from oldoldstable to stable pulls in 4 years of changes, and I think that's likely to result in having to keep too many workarounds and too much cruft for too long, and having to hold back progress for too long. For instance, wanting to be able to do the upgrade from oldstable to stable using oldstable's apt and dpkg means it already takes us 2 years to deploy an archive-wide feature like dpkg multiarch - I wouldn't want it to take 4. Package management tools are a special case. I imagine the way you'd do it would be to ship the new tools, built against oldoldstable, in a special skip-upgrade partial suite. I don't think this is at all impossible. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21279.10020.796829.209...@chiark.greenend.org.uk
Re: Bits from the Security Team
Didier 'OdyX' Raboud writes (Re: Bits from the Security Team): I was trying to say that there is no policy currently in place to ensure that skip-upgrades actually work, and at least one maintainer has already started to cleanup pre-wheezy stuff from his packages [0]. People encouraging maintainers not to gratuitously break skip-upgrades on debian-devel is by far not equivalent to a Release Team decision on bug severity for a failure to skip-upgrade for example. We could start small, by putting the encouragement in the policy manual rather than on -devel. I don't think this needs to involve release team decisions on bug severity, unless we want to go as far as declaring failure to support a skip upgrade an RC bug (which I think is probably impractical right now). Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21279.10153.492761.105...@chiark.greenend.org.uk
Re: Bits from the Security Team
Paul Wise writes (Re: Bits from the Security Team): Debian doesn't support skipping releases right now and I expect if we support releases for a longer amount of time that won't change. But, in practice, skip upgrades often work anyway. I'd encourage maintainers not to gratuitously break them. For example, aggressively removing compatibility code is a bad idea. (It's bad for our downstreams too). We don't yet do any testing for upgrades from oldstable2testing etc so there will probably be some broken things, perhaps we should? That would be nice but I don't have any effort to do it personally... Thanks, Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21277.50107.155216.490...@chiark.greenend.org.uk
Re: Bits from the Security Team
Christoph Biedl debian.a...@manchmal.in-ulm.de schrieb: Matthias Urlichs wrote... IMHO the decision to designate release N to be a LTS release has too be made at release time of N+1 _at_the_latest_, so maintainers know that they may not remove their old upgrade script snippets. Agreed, but given the long intervals between releases: Waiting until wheezy enters that state means at least two years, and I'd expect the enthusiasm I've seen for LTS to cool down a lot in that time. (In case sufficient momentum is reached for squeeze-lts, which *hint* *hint* needs actual commitment:) Skipping releases will not be possible/supported, if anyone wants to upgrade from squeeze-lts to jessie both updates can to be done subsequently in one maintenance windows. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnlhrmkc.4jj@inutil.org
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 09:00:13AM +0800, Paul Wise wrote: * There are quite some vulnerabilities which are addressed in Debian, but for which no CVE identifier has been assigned. Perhaps we could encourage those submitting security bugs to X-Debbugs-CC the oss-sec list? That would generate to much noise. Reading LWN I sometimes note the same issue happens for other distributions. Does the security team monitor the advisory announcements of upstreams and other distributions and auto-correlate those with CVEs? Yes, from time to time we pick up issues from distros which don't request CVE IDs for their advisories. * We're currently using Subversion. We discussed changing to git, but git doesn't offer significant benefit for our purpose so we decided to stick with it. From when alioth was having repository issues, it appears having the full history locally is useful so git would still be a net win. Also is the SHA-1 hash chain not useful? It doesn't really outweigh the additional work needed for the move. * In order to avoid bottlenecks and to open up the security process further we're planning to allow maintainers which are not part of the security team to release security updates on their own The backports archive has a whitelist mechanism, would that be useful? Probably, we'll have a look when we get into the actual implementation. The information at www.d.o/security could use some updates. Please file bugs against the www.debian.org pseudo bug with specific changes. Will security team members be at DebConf14? Most likely not. Is the team filtering debian-devel-changes and looking for words like security, overflow, attack etc? This might turn up some things that don't have CVEs but should. Yes, at least two people are reading d-d-changes on a daily basis. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140310153043.GA4777@pisco.westfalen.local
Re: Bits from the Security Team
Hi, Skipping releases will not be possible/supported Oh, it's certainly *possible*. The question is, how painful an experience fixing the resulting problems will be … However, LTS releases should support upgrades from one LTS to the next. That's kindof what I'd expect, and Ubuntu certainly shows that it's possible. Downloading a GByte of packages just to immediately drop them again does not strike me like a good solution, even in these days of mostly-high bandwidth 'net access; don't forget that a couple of our users don't have that luxury. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bits from the Security Team
Le lundi, 10 mars 2014, 13.52:59 Ian Jackson a écrit : Paul Wise writes (Re: Bits from the Security Team): Debian doesn't support skipping releases right now and I expect if we support releases for a longer amount of time that won't change. But, in practice, skip upgrades often work anyway. I'd encourage maintainers not to gratuitously break them. For example, aggressively removing compatibility code is a bad idea. (It's bad for our downstreams too). I, for one, have been routinely dropping transitional binary packages that were in the latest stable; they were needed to migrate from (the releases which are now) oldstable to stable but are only archive noise now. Delaying that cleanup for an additional stable release cycle really feels like unnecessary delay, during which we pretend to maintain code that hardly anyone tests. The problem is that there is no policy in place to make us support oldstable-to-testing upgrades. If there's interest, that'd need to be decided with a more firm policy than encourage maintainers. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/69734414.qmXaMjuj1O@gyllingar
Re: Bits from the Security Team
On 10/03/14 15:44, Matthias Urlichs wrote: However, LTS releases should support upgrades from one LTS to the next. That's kindof what I'd expect, and Ubuntu certainly shows that it's possible. I think LTS is being used to mean two different things here. Debian releases are already more like Ubuntu LTS than Ubuntu non-LTS, and Debian doesn't really have an equivalent of Ubuntu non-LTS releases. Upgrading between 6-monthly Ubuntu releases is presumably rather easier to support, since there's only 6 months' development churn to deal with. Similarly, Ubuntu supporting an upgrade from old-LTS to current-LTS is a lot like Debian supporting an upgrade from oldstable to stable - either way it's a matter of about 2 years' development. If people want to support oldstable for more than (1 release cycle + 1 year) but still disallow skipping releases, then the upgrade is still feasible - it still pulls in about two years' worth of development, and the only difference is that those two years were longer ago. On the other hand, going directly from oldoldstable to stable pulls in 4 years of changes, and I think that's likely to result in having to keep too many workarounds and too much cruft for too long, and having to hold back progress for too long. For instance, wanting to be able to do the upgrade from oldstable to stable using oldstable's apt and dpkg means it already takes us 2 years to deploy an archive-wide feature like dpkg multiarch - I wouldn't want it to take 4. Does Ubuntu support upgrading directly from old-old-LTS to current-LTS, e.g. from hardy to precise or from lucid to trusty? Ubuntu's Wikipedia page doesn't seem to think so. A direct upgrade from squeeze to jessie would be of a similar magnitude. (With upstream hat on, my co-maintainers already think I'm going a bit far by doing security releases for 2 year old D-Bus and Telepathy code to support Debian stable, and I don't intend to extend that to a longer-lived oldstable.) S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531de47b.6000...@debian.org
Re: Bits from the Security Team
Hi, Simon McVittie: Does Ubuntu support upgrading directly from old-old-LTS to current-LTS, e.g. from hardy to precise or from lucid to trusty? Not that I know of, no. Ubuntu's Wikipedia page doesn't seem to think so. A direct upgrade from squeeze to jessie would be of a similar magnitude. Well, yes, except that I continue to hope that with a LTS release in our archive the non-LTS releases would appear somewhat more often. If not, I'd consider the exercise to be pointless, to be frank. (With upstream hat on, my co-maintainers already think I'm going a bit far by doing security releases for 2 year old D-Bus and Telepathy code to support Debian stable, and I don't intend to extend that to a longer-lived oldstable.) 'xactly. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bits from the Security Team
On 2014-03-10 17:32, Matthias Urlichs wrote: Simon McVittie: Ubuntu's Wikipedia page doesn't seem to think so. A direct upgrade from squeeze to jessie would be of a similar magnitude. Well, yes, except that I continue to hope that with a LTS release in our archive the non-LTS releases would appear somewhat more often. If not, I'd consider the exercise to be pointless, to be frank. I'd still buy us releases where you don't need to upgrade one year after another release happened, which is relatively painful. For Ubuntu it's a new release after two years, and then you still enjoy three more years of support. (Of course for main only, which needs to be reiterated quite often.) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8b0096a400aa04d6e1995eb8abba8...@hub.kern.lc
Re: Bits from the Security Team
Didier 'OdyX' Raboud wrote... I, for one, have been routinely dropping transitional binary packages that were in the latest stable; they were needed to migrate from (the releases which are now) oldstable to stable but are only archive noise now. Delaying that cleanup for an additional stable release cycle really feels like unnecessary delay, during which we pretend to maintain code that hardly anyone tests. The missing tests are indeed a problem. For migration code in (usually) postinst or transitional packages I don't see the big issue, besides a maintainer's notion of I'd like to get rid of that old stuff. Face the fact: Users *will* skip upgrade from squeeze-lts to (then stable) jessie, you cannot bar them from doing this. If they break their system, any That was not supported, told you so is not helping, neither them nor Debian's reputation. Better support such upgrades from the beginning. So I was thinking whether there was a way packages that do not support skip upgrade may enforce an upgrade path via the intermediate distribution. First idea was a new Pre-Conflicts: package relationship, then I was wondering whether it shouldn't be simply possible to write (for a package in jessie): Package: foo Conflicts: foo ( $[wheezy-version]~) But Policy 7.4 has the answer, it's no. Assuming we could somehow turn off that exception, a skip upgrade is impossible for that package, but it's blocked /before/ things break. The solution for the user then was to add the skipped release to sources.list temporarily, and go on. The search engines soon will learn that trick from the first bug reports, and users can find it using the specific error message they see. Benefit: Only the packages that do not support skip upgrades will need that step, also reducing bandwidth usage and walltime needed for the skip upgrade. The problem is that there is no policy in place to make us support oldstable-to-testing upgrades. If there's interest, that'd need to be decided with a more firm policy than encourage maintainers. Would you have preferred to read something putting the burden onto the maintainers? Christoph -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394480...@msgid.manchmal.in-ulm.de
Re: Bits from the Security Team
Hi, On Sat, Mar 08, 2014 at 07:36:23PM +0100, Christoph Biedl wrote: Moritz Muehlenhoff wrote... Security archive - * In order to avoid bottlenecks and to open up the security process further we're planning to allow maintainers which are not part of the security team to release security updates on their own. This applies to packages which have frequent vulnerabilities and where the maintainers are involved in the update process anyway. The current model at least theoretically allows someone (read: the security team) to review the patch provided by the maintainer. I like that four-eyes principle and wouldn't want to give it away. But perhaps you plan is rather about moving the task of the actual upload to the maintainer *after* some discussion? Or will you stand being surprising by an unannounced security upload? (This is none of my business, I'm just curious.) Disclaimer: there is no actual implementation for this yet, so only a comment on that: The idea is to have something like the DM upload permissions. There are packages which recieve frequent updates trough security, where already now the maintainer is the one doing all the packaging work, has the most knowledge and testing tme, but then the bottleneck to actual release the package is the load/time missing on the team. As Moritz writes, this will apply only to some specific packages. Hope that clarifies, Regards, Salvatore signature.asc Description: Digital signature
Re: Bits from the Security Team
On Sun, Mar 09, 2014 at 06:50:36AM +0800, Paul Wise wrote: On Sat, 2014-03-08 at 18:23 +0100, Florian Weimer wrote: * Moritz Muehlenhoff: I agree we should stick with dpkg-buildflags until this is fixed upstream. Gentoo Hardened tried to upstream this a year ago, but apparently this didn't make the cut yet: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html It looks like the Gentoo Hardened folks addressed all of the concerns of the GCC folks but didn't push for the patches to be included after that had finished doing that. Perhaps also the GCC folks didn't have time to do a full review. The Gentoo Hardened folks say bootstrap was achieved. On the other hand, it is somewhat doubtful if we can come up with a one-size-fits-all compile time option. For example, Fedora wants to enable -grecord-gcc-switches, but maybe Debian doesn't (e.g. because it impacts reproducible builds). It should at least be an option to enable these at GCC compile time so that all binaries compiled by GCC use them. As long as GCC supports the corresponding command-line options for turning off enabled options at runtime, this approach should be viable since upstreams that need these flags disabled can do that in their build systems. I kind of agree here, but Matthias made it clear that upstream inclusion was a prerequisite (and I'm not sure he's interested in actually pushing that upstream). It might be worth contacting Gentoo Hardened people, Ubuntu security people (although I think Kees Cook was the most active one and he's now working at Google) and gcc upstream, asking for status and maybe pushing a little bit forward. But right now I'm not sure that, in Debian, we have people knowledgeable enough on the intimate gcc behavior to push that directly. That's a bit unfortunate. Regards, -- Yves-Alexis Perez Debian security team signature.asc Description: Digital signature
Re: Bits from the Security Team
Matthias Urlichs wrote... IMHO the decision to designate release N to be a LTS release has too be made at release time of N+1 _at_the_latest_, so maintainers know that they may not remove their old upgrade script snippets. Agreed, but given the long intervals between releases: Waiting until wheezy enters that state means at least two years, and I'd expect the enthusiasm I've seen for LTS to cool down a lot in that time. So let's see squeeze-lts as an experiment, and I read it is declared as such: Limited set of architectures, no promises this will last. Then all people involved can learn about any pitfalls. Once the jessie release get closer, enough experience should have been gathered to tell whether LTS is feasible. If yes, package maintainers should be encouraged to support leap-frog upgrades. The right time for that decision was freeze in my opinion. Christoph -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394353...@msgid.manchmal.in-ulm.de
Re: Bits from the Security Team
* Moritz Muehlenhoff: I agree we should stick with dpkg-buildflags until this is fixed upstream. Gentoo Hardened tried to upstream this a year ago, but apparently this didn't make the cut yet: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html This is interesting. One potential issue here is that GCC doesn't really know about _FORTIFY_SOURCE, and we'd like to see this covered as well. On the other hand, it is somewhat doubtful if we can come up with a one-size-fits-all compile time option. For example, Fedora wants to enable -grecord-gcc-switches, but maybe Debian doesn't (e.g. because it impacts reproducible builds). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87siqsd2oy@mid.deneb.enyo.de
Re: Bits from the Security Team
Moritz Muehlenhoff wrote... Security archive - * In order to avoid bottlenecks and to open up the security process further we're planning to allow maintainers which are not part of the security team to release security updates on their own. This applies to packages which have frequent vulnerabilities and where the maintainers are involved in the update process anyway. The current model at least theoretically allows someone (read: the security team) to review the patch provided by the maintainer. I like that four-eyes principle and wouldn't want to give it away. But perhaps you plan is rather about moving the task of the actual upload to the maintainer *after* some discussion? Or will you stand being surprising by an unannounced security upload? (This is none of my business, I'm just curious.) Others - -- * In some cases the scope of security support needs to be limited (e.g webkit-based browsers in Wheezy) and sometimes packages need to end-of-lifed before the security support time frame ends. Currently this information needs to be retrieved from the release notes or announcement mails. We'd like to see a more technical solution which displays the unsupported packages for the installed packages on a specific system. If anyone wants to work on such a script, please contact t...@security.debian.org and we can hash out the details. That's much-needed, especially with an upcoming LTS. Expect mail. LTS - --- * At the moment it seems likely that an extended security support timespan for squeeze is possible. The plan is to go ahead, sort out the details as as it happens, and see how this works out and whether it is going to be continued with wheezy. At least worth a try. I was wondering whether popcon gather data to learn how many people will actually use LTS (I think it does). The rough draft is that updates will be delivered via a separate suite (e.g. squeeze-lts), where everyone in the Debian keyring can upload in order to minimise bottlenecks and allow contributions by all interested parties. Some packages will be exempted upfront due to their volatile nature (e.g. some web applications) and others might be expected to see important changes. The LTS suite will be limited to amd64 and i386. The exact procedures will be sorted out soon and announced in a separate mail. Be prepared to answer some questions, like: Are maintainers expected to support leap-frog upgrades, i.e. from squeeze-lts to jessie? If no, users will try this anyway at EOL of squeeze-lts (in two years or so), brace for nasty bug reports. If yes, some maintainers already might had have dropped the squeeze-to- wheezy upgrade scripts in their packages, thus possibly causing breakage. At least I did. No evil intentions, that was before the LTS discussion came up. Christoph -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394299...@msgid.manchmal.in-ulm.de
Re: Bits from the Security Team
On Fri, Mar 07, 2014 at 01:57:17PM +0100, Stephan Seitz wrote: On Thu, Mar 06, 2014 at 12:21:06PM +1100, Craig Small wrote: You apparently can have a special group that can see everything. Aren’t there PAM modules which can grant capabilities to certain users? No idea, adduser thisuser thatgroup seems a reasonably simple fix. That might be worthwhile for a default. It makes things like pstree look odd, so I'll be expecting some new bug reports. It will break software like nagios with check_procs. Any ideas how one can solve this? dpkg-stateoverwrite doesn’t support capabilities, only the standard chmod commands. That's why I think there should be a defined group. Then anything that needs or anyone that wants, normal access just gets added to this group. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140308215200.gf7...@enc.com.au
Re: Bits from the Security Team
On Sat, 2014-03-08 at 18:23 +0100, Florian Weimer wrote: * Moritz Muehlenhoff: I agree we should stick with dpkg-buildflags until this is fixed upstream. Gentoo Hardened tried to upstream this a year ago, but apparently this didn't make the cut yet: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html It looks like the Gentoo Hardened folks addressed all of the concerns of the GCC folks but didn't push for the patches to be included after that had finished doing that. Perhaps also the GCC folks didn't have time to do a full review. The Gentoo Hardened folks say bootstrap was achieved. On the other hand, it is somewhat doubtful if we can come up with a one-size-fits-all compile time option. For example, Fedora wants to enable -grecord-gcc-switches, but maybe Debian doesn't (e.g. because it impacts reproducible builds). It should at least be an option to enable these at GCC compile time so that all binaries compiled by GCC use them. As long as GCC supports the corresponding command-line options for turning off enabled options at runtime, this approach should be viable since upstreams that need these flags disabled can do that in their build systems. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bits from the Security Team
On Sun, Mar 9, 2014 at 2:36 AM, Christoph Biedl wrote: Moritz Muehlenhoff wrote... LTS - --- * At the moment it seems likely that an extended security support timespan for squeeze is possible. The plan is to go ahead, sort out the details as as it happens, and see how this works out and whether it is going to be continued with wheezy. At least worth a try. I was wondering whether popcon gather data to learn how many people will actually use LTS (I think it does). Here is the information about popcon version numbers that we have (from the font page of popcon.d.o) for oldstable (squeeze) and earlier. So at least 38918 machines could benefit from a squeeze LTS effort. 1.28 (sarge) : 67 1.31 : 5 1.32 : 6 1.33 : 17 1.34 : 5 1.36 : 3 1.38 : 5 1.39 : 20 1.40 : 13 1.41 (etch) : 2511 1.42 : 73 1.43 : 3 1.44 : 6 1.45 : 79 1.46 (lenny) : 8746 1.47 : 24 1.48 : 547 1.49 (squeeze): 38918 Are maintainers expected to support leap-frog upgrades, i.e. from squeeze-lts to jessie? If no, users will try this anyway at EOL of squeeze-lts (in two years or so), brace for nasty bug reports. If yes, some maintainers already might had have dropped the squeeze-to- wheezy upgrade scripts in their packages, thus possibly causing breakage. At least I did. No evil intentions, that was before the LTS discussion came up. Debian doesn't support skipping releases right now and I expect if we support releases for a longer amount of time that won't change. We don't yet do any testing for upgrades from oldstable2testing etc so there will probably be some broken things, perhaps we should? https://piuparts.debian.org/ -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6EE1Or0JVZUaFKR=f6lx7m8hby3-rjpwaexoaxp7bt...@mail.gmail.com
Re: Bits from the Security Team
Hi, Paul Wise: Debian doesn't support skipping releases right now and I expect if we support releases for a longer amount of time that won't change. We don't yet do any testing for upgrades from oldstable2testing etc so there will probably be some broken things, perhaps we should? Prepare to not find most problems if you just do automated testing. IMHO the decision to designate release N to be a LTS release has too be made at release time of N+1 _at_the_latest_, so maintainers know that they may not remove their old upgrade script snippets. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bits from the Security Team
Paul Wise wrote (08 Mar 2014 23:49:22 GMT) : We don't yet do any testing for upgrades from oldstable2testing etc so there will probably be some broken things, perhaps we should? https://piuparts.debian.org/ See also the Jenkins upgrade tests: http://jenkins.debian.net/view/chroot-installation/ .. configured in this Git repository: http://anonscm.debian.org/gitweb/?p=users/holger/jenkins.debian.net.git;a=summary Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85k3c4rzq5@boum.org
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 05:33:42AM +0100, Matthias Klose wrote: Am 06.03.2014 02:00, schrieb Paul Wise: * The distribution hardening using dpkg-buildflags is coming along nicely. Unfortunately this doesn't apply to binaries compiled outside of the package building system. It would be great if we could adopt the Ubuntu approach of just enabling the flags in GCC itself. Even better would be to get GCC upstream to finally enable them by default. This should not be enabled in the distro itself, and if, then not before it can be enabled upstream. From my point of view it was a mistake to enable it this way before getting this upstream. However it is a lot of work to get the compiler to build itself with these flags and the testsuite produce the same results as without these. In the past neither the Ubuntu security team nor the Google ChromeOS team had time and resources to bring these patches upstream. I agree we should stick with dpkg-buildflags until this is fixed upstream. Gentoo Hardened tried to upstream this a year ago, but apparently this didn't make the cut yet: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html As for the GSoC project; GCC partiticates, if anyone wants to push this, I suggest to talk to GCC developers and see whether there's a mentor available. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307094212.ga1...@inutil.org
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 12:21:06PM +1100, Craig Small wrote: On Thu, Mar 06, 2014 at 12:54:00AM +0100, Vincent Danjean wrote: I'm not sure I will let this setup (hidepid=1) on my computers. My current POV (that can change) is that I prefer to be able to do the maximum of thing as a normal user (top, ps, read log (I'm in the adm group), ...) ans switch to root when I really need to do some modifications. You apparently can have a special group that can see everything. Aren’t there PAM modules which can grant capabilities to certain users? That might be worthwhile for a default. It makes things like pstree look odd, so I'll be expecting some new bug reports. It will break software like nagios with check_procs. Any ideas how one can solve this? dpkg-stateoverwrite doesn’t support capabilities, only the standard chmod commands. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 04:32:34PM +0100, Guido Günther wrote: Luckily this is not the case. :) root can see other users' /proc entries just fine. Perhaps the documentation should be improved. I should have checked the code first. If I read that correctly CAP_SYS_PTRACE is necessary here. I've forwarded a patch upstream. I did a „setcap cap_sys_ptrace+eip /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still check for running programs of another user. What did I wrong? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bits from the Security Team
Hi, Stephan Seitz: I did a „setcap cap_sys_ptrace+eip /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still check for running programs of another user. What did I wrong? check_procs is a script, not a real executable. Since starting an interpreter with capabilities (or setuid, for that matter) of a script involves a race condition (kernel starts interpreter with script's rights, Joe Badass replaces the script with something nefarious, interpreter gets around to opening script) this is a good thing. So you need a small C helper program here. Or not so small -- Apache's suexec is a good example of almost-all of the things which can go wrong. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Bits from the Security Team
On Fri, Mar 07, 2014 at 02:51:41PM +0100, Matthias Urlichs wrote: I did a „setcap cap_sys_ptrace+eip /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still check for running programs of another user. What did I wrong? check_procs is a script, not a real executable. Wrong. [stse@osgiliath]: file /usr/lib/nagios/plugins/check_procs /usr/lib/nagios/plugins/check_procs: ELF 64-bit LSB shared object… If I do a „chmod u+s check_procs” it works. But I think capabilities are a safer solution than s-bit. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: Bits from the Security Team
On 05/03/2014 22:33, Jakub Wilk wrote: hidepid=1 means users may not access any /proc/pid/ directories but their own. Even that is strange. I just tried. Processus that are not mine are not shown anymore by ps, but even some of mine disappeared! (mostly urxvt ones) See this example (the [] in the grep command are here to avoid to find the grep command itself): $ ps axfu | grep 321[6]1 vdanjean 32161 0.0 0.0 104796 2244 ?Sfévr.24 0:01 /usr/bin/urxvt $ sudo mount -o remount,hidepid=1 /proc $ ps axfu | grep 321[6]1 $ sudo mount -o remount,hidepid=0 /proc $ ps axfu | grep 321[6]1 vdanjean 32161 0.0 0.0 104796 2244 ?Sfévr.24 0:01 /usr/bin/urxvt $ logname vdanjean $ sudo mount -o remount,hidepid=2 /proc $ ps axfu | grep 321[6]1 $ sudo ps axfu | grep 321[6]1 vdanjean 32161 0.0 0.0 104796 2244 ?Sfévr.24 0:01 /usr/bin/urxvt $ sudo mount -o remount,hidepid=1 /proc $ sudo ps axfu | grep 321[6]1 vdanjean 32161 0.0 0.0 104796 2244 ?Sfévr.24 0:01 /usr/bin/urxvt # == root still see my processus $ ps axfu | grep 321[6]1 $ ls /proc/32161/ ls: impossible d'ouvrir le répertoire /proc/32161/: Opération non permise $ ls -ld /proc/32161 dr-xr-xr-x 9 vdanjean vdanjean 0 mars 7 15:33 /proc/32161 $ Why can't I see my own urxvt processus ? Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5319daa6.3040...@free.fr
Re: Bits from the Security Team
* Vincent Danjean vdanjean...@free.fr, 2014-03-07, 15:41: hidepid=1 means users may not access any /proc/pid/ directories but their own. Even that is strange. I just tried. Processus that are not mine are not shown anymore by ps, but even some of mine disappeared! (mostly urxvt ones) $ ls -l /usr/bin/urxvt -rwxr-sr-x 1 root utmp 1272864 Dec 22 18:50 /usr/bin/urxvt It's setgid, so it can't be ptraced, so it doesn't show up in /proc. The inability to see your own setgid processes makes this feature unappealing. :( -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307174102.ga3...@jwilk.net
Re: Bits from the Security Team
* Stephan Seitz stse+deb...@fsing.rootsland.net, 2014-03-07, 15:25: But I think capabilities are a safer solution than s-bit. Maybe, maybe not. Many capabilities, including CAP_SYS_PTRACE, can be easily elevated to full root. Adding capabilities to software that wasn't specifically designed to deal with them is a bad idea. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307180322.ga5...@jwilk.net
Re: Bits from the Security Team
previously on this list Matthias Urlichs contributed: I did a „setcap cap_sys_ptrace+eip /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still check for running programs of another user. What did I wrong? check_procs is a script, not a real executable. Since starting an interpreter with capabilities (or setuid, for that matter) of a script involves a race condition (kernel starts interpreter with script's rights, Joe Badass replaces the script with something Is it writable by others than root? I don't know the details of hidepid but the grsecurity patch has similar? functionality and lets users see their own processes or a group see them all. +menu Filesystem Protections +depends on GRKERNSEC + +config GRKERNSEC_PROC + bool Proc restrictions + help + If you say Y here, the permissions of the /proc filesystem + will be altered to enhance system security and privacy. You MUST + choose either a user only restriction or a user and group restriction. + Depending upon the option you choose, you can either restrict users to + see only the processes they themselves run, or choose a group that can + view all processes and files normally restricted to root if you choose + the restrict to user only option. NOTE: If you're running identd or + ntpd as a non-root user, you will have to run it as the group you + specify here. + +config GRKERNSEC_PROC_USER + bool Restrict /proc to user only + depends on GRKERNSEC_PROC + help + If you say Y here, non-root users will only be able to view their own + processes, and restricts them from viewing network-related information, + and viewing kernel symbol and module information. + +config GRKERNSEC_PROC_USERGROUP + bool Allow special group + depends on GRKERNSEC_PROC !GRKERNSEC_PROC_USER + help + If you say Y here, you will be able to select a group that will be + able to view all processes and network-related information. If you've + enabled GRKERNSEC_HIDESYM, kernel and symbol information may still + remain hidden. This option is useful if you want to run identd as + a non-root user. + +config GRKERNSEC_PROC_GID + int GID for special group + depends on GRKERNSEC_PROC_USERGROUP + default 1001 + +config GRKERNSEC_PROC_ADD + bool Additional restrictions + depends on GRKERNSEC_PROC_USER || GRKERNSEC_PROC_USERGROUP + help + If you say Y here, additional restrictions will be placed on + /proc that keep normal users from viewing device information and + slabinfo information that could be useful for exploits. + +config GRKERNSEC_LINK + bool Linking restrictions + help + If you say Y here, /tmp race exploits will be prevented, since users + will no longer be able to follow symlinks owned by other users in + world-writable +t directories (e.g. /tmp), unless the owner of the + symlink is the owner of the directory. users will also not be + able to hardlink to files they do not own. If the sysctl option is + enabled, a sysctl option with name linking_restrictions is created. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/64312.74336...@smtp121.mail.ir2.yahoo.com
Re: Bits from the Security Team
On Fri, Mar 7, 2014 at 18:41:02 +0100, Jakub Wilk wrote: * Vincent Danjean vdanjean...@free.fr, 2014-03-07, 15:41: hidepid=1 means users may not access any /proc/pid/ directories but their own. Even that is strange. I just tried. Processus that are not mine are not shown anymore by ps, but even some of mine disappeared! (mostly urxvt ones) $ ls -l /usr/bin/urxvt -rwxr-sr-x 1 root utmp 1272864 Dec 22 18:50 /usr/bin/urxvt It's setgid, so it can't be ptraced, so it doesn't show up in /proc. The inability to see your own setgid processes makes this feature unappealing. :( Any reason urxvt can't use libutempter? Cheers, Julien signature.asc Description: Digital signature
Re: Bits from the Security Team
* Moritz Muehlenhoff j...@debian.org, 2014-03-05, 20:03: * Since Wheezy the Linux kernel features a security mechanism which nullifies many symlink attacks (fs.protected_symlinks). For the lazy, documentation of protected_symlinks: When the value in this file is 0, no restrictions are placed on following symbolic links (i.e., this is the historical behaviour before Linux 3.6). When the value in this file is 1, symbolic links are followed only in the following circumstances: * the filesystem UID of the process following the link matches the owner (UID) of the symbolic link (as described in credentials(7), a process’s filesystem UID is normally the same as its effective UID); * the link is not in a sticky world‐writable directory; or * the symbolic link and its parent directory have the same owner (UID) A system call that fails to follow a symbolic link because of the above restrictions returns the error EACCES in errno. We're planning to treat any vulnerabilities which are rendered moot by this protection as non-issues. If you're using custom Linux kernels builds you need to enable this option. It should be noted here that while symlink attack is the most well-known way to exploit insecure use of /tmp, it is not the only way, and often even not the most exciting way. The symlink protection does not exempt you from having to care about using temporary files securely! -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306114759.ga1...@jwilk.net
Re: Bits from the Security Team
Hi Jakub, On Wed, Mar 05, 2014 at 10:33:23PM +0100, Jakub Wilk wrote: * Guido Günther a...@sigxcpu.org, 2014-03-05, 20:54: [..snip..] I looked at the docs and as I read them this would affect uid 0 as well. Luckily this is not the case. :) root can see other users' /proc entries just fine. Perhaps the documentation should be improved. I should have checked the code first. If I read that correctly CAP_SYS_PTRACE is necessary here. I've forwarded a patch upstream. Thanks! -- Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306153234.ga27...@bogon.m.sigxcpu.org
Re: Bits from the Security Team
Hi, the work of the security team is very, very much appreciated! On Wed, Mar 05, 2014 at 08:03:01PM +0100, Moritz Muehlenhoff wrote: * We're planning to request for hidepid to be enabled by default (to 1). This will squash an entire class of information leaks. If you have any comments or objections, please get in touch with us. I looked at the docs and as I read them this would affect uid 0 as well. In this case tools like checkrestart and whatmaps wouldn't be able to detect mapped libraries anymore actually preventing security updates for running processes. Maybe excempting uid 0 would be good. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305195409.gb23...@bogon.m.sigxcpu.org
Re: Bits from the Security Team
* Guido Günther a...@sigxcpu.org, 2014-03-05, 20:54: * We're planning to request for hidepid to be enabled by default (to 1). This will squash an entire class of information leaks. If you have any comments or objections, please get in touch with us. For the lazy, this is documentation for hidepid: hidepid=0 means classic mode - everybody may access all /proc/pid/ directories (default). hidepid=1 means users may not access any /proc/pid/ directories but their own. Sensitive files like cmdline, sched*, status are now protected against other users. This makes it impossible to learn whether any user runs specific program (given the program doesn't reveal itself by its behaviour). As an additional bonus, as /proc/pid/cmdline is unaccessible for other users, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers. hidepid=2 means hidepid=1 plus all /proc/pid/ will be fully invisible to other users. It doesn't mean that it hides a fact whether a process with a specific pid value exists (it can be learned by other means, e.g. by kill -0 $PID), but it hides process' uid and gid, which may be learned by stat()'ing /proc/pid/ otherwise. It greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, etc. I looked at the docs and as I read them this would affect uid 0 as well. Luckily this is not the case. :) root can see other users' /proc entries just fine. Perhaps the documentation should be improved. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305213323.ga9...@jwilk.net
Re: Bits from the Security Team
On Thu, Mar 6, 2014 at 3:03 AM, Moritz Muehlenhoff wrote: * We're planning to request for hidepid to be enabled by default (to 1). This will squash an entire class of information leaks. If you have any comments or objections, please get in touch with us. Apparently this breaks suspend with systemd and maybe causes some issues with login and other things under systemd: https://bugzilla.redhat.com/show_bug.cgi?id=1043134 http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html http://lists.freedesktop.org/archives/systemd-devel/2012-October/006860.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6EbTYiZYJXaVkJtQm=ru3iDN6O6+VWi4GXZ-1tqs9m=u...@mail.gmail.com
Re: Bits from the Security Team
On 05/03/2014 22:33, Jakub Wilk wrote: * Guido Günther a...@sigxcpu.org, 2014-03-05, 20:54: I looked at the docs and as I read them this would affect uid 0 as well. Luckily this is not the case. :) root can see other users' /proc entries just fine. Perhaps the documentation should be improved. So, it means that most of live supervision I was doing from time to time as a 'normal' user will need to be done as root (top, ps axf, ...) I'm not sure I will let this setup (hidepid=1) on my computers. My current POV (that can change) is that I prefer to be able to do the maximum of thing as a normal user (top, ps, read log (I'm in the adm group), ...) ans switch to root when I really need to do some modifications. Regards, Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5317b918.10...@ens-lyon.org
Re: Bits from the Security Team
A lot of this is really great news, thanks for your work! On Thu, Mar 6, 2014 at 3:03 AM, Moritz Muehlenhoff wrote: * In some cases source packages get renamed, These renames currently need to be tracked manually. We're planning to automate these. If anyone wants to help and implement it, please see #738172 The debbugs maintainers were going to implement something like this and Don already has some code apparently so it would be a good idea to co-ordinate there. * We've discussed whether older release information should be kept in the database. This might be useful for folks still using EOL releases. * debsecan is a tool which is closely related to the Security Tracker: I've 3 patches pending for debsecan so I'd definitely appreciate a move to collab-maint. * There are quite some vulnerabilities which are addressed in Debian, but for which no CVE identifier has been assigned. Perhaps we could encourage those submitting security bugs to X-Debbugs-CC the oss-sec list? Reading LWN I sometimes note the same issue happens for other distributions. Does the security team monitor the advisory announcements of upstreams and other distributions and auto-correlate those with CVEs? * We're currently using Subversion. We discussed changing to git, but git doesn't offer significant benefit for our purpose so we decided to stick with it. From when alioth was having repository issues, it appears having the full history locally is useful so git would still be a net win. Also is the SHA-1 hash chain not useful? * In order to avoid bottlenecks and to open up the security process further we're planning to allow maintainers which are not part of the security team to release security updates on their own The backports archive has a whitelist mechanism, would that be useful? * We're tentatively aiming for another Security Team meeting at the beginning of 2015. At that time Jessie will be in freeze which is a good opportunity to plan for jessie/jessie+1. From memory some folks not in the security team who wanted to come missed the last meeting. It would be great to get more people at the next one. * In some cases the scope of security support needs to be limited (e.g webkit-based browsers in Wheezy) and sometimes packages need to end-of-lifed before the security support time frame ends. A mechanism for this already exists/existed, some links: https://lists.alioth.debian.org/pipermail/debtags-devel/2008-June/001795.html https://bugs.debian.org/436161 http://anonscm.debian.org/viewvc/debtags/vocabulary/trunk/security-team?view=markup * Our documentation is currently spread across (too) many places. We're planning to create a one-stop site http://security-team.debian.org which links all information wrt to working/contributing on security Any reason not to use the wiki? https://wiki.debian.org/Teams/Security * The distribution hardening using dpkg-buildflags is coming along nicely. Unfortunately this doesn't apply to binaries compiled outside of the package building system. It would be great if we could adopt the Ubuntu approach of just enabling the flags in GCC itself. Even better would be to get GCC upstream to finally enable them by default. * Since Wheezy the Linux kernel features a security mechanism which nullifies many symlink attacks kfreebsd (currently a technology preview) and Hurd (currently not a release arch) don't implement this security feature. We welcome feedback from the porters whether similar protections exist or whether they're feasible within the jessie release time frame. I expect it would be a good idea to directly consult the porting lists for these ports, not all porters may have read the full mail. * At the moment it seems likely that an extended security support timespan for squeeze is possible. The rough draft is that updates will be delivered via a separate suite (e.g. squeeze-lts) Why not just use the existing suite for this? Other things: The information at www.d.o/security could use some updates. The Ubuntu security folks have a tool called ubuntu-security-tools that they use for auditing new packages coming in and packages where flaws are discovered. I expect it would be a lot of work to do that for Debian but it might be worth it. git clone bzr::lp:ubuntu-security-tools Is there much collaboration/synergy with the Ubuntu security team or those of any other derivatives? Will security team members be at DebConf14? Is the team filtering debian-devel-changes and looking for words like security, overflow, attack etc? This might turn up some things that don't have CVEs but should. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6egjefxwgy2wde_ghhwhbaxu5pw52tznehexdgp7k5...@mail.gmail.com
Re: Bits from the Security Team
Paul Wise p...@debian.org writes: Perhaps we could encourage those submitting security bugs to X-Debbugs-CC the oss-sec list? I don't think the list would really appreciate that. Most of the CVE requests it currently gets have been vetted by either a developer of the software or by the security team of a distribution, and right now the signal-to-noise ratio is very high. I think we want to at least peer-review the bug before we send it to oss-sec to make sure that we have good-quality requests. We also don't want to do something that would cause the whole bug discussion to get copied to the list. The list maintainers aren't particularly happy when that happens and the discussion drifts away from the specific security issue. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ob1kdt2s@windlord.stanford.edu
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 12:54:00AM +0100, Vincent Danjean wrote: I'm not sure I will let this setup (hidepid=1) on my computers. My current POV (that can change) is that I prefer to be able to do the maximum of thing as a normal user (top, ps, read log (I'm in the adm group), ...) ans switch to root when I really need to do some modifications. You apparently can have a special group that can see everything. That might be worthwhile for a default. It makes things like pstree look odd, so I'll be expecting some new bug reports. Someone might like to fix mount(8) too, especially the bit about procfs if this is the new default. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306012106.ga30...@enc.com.au
Re: Bits from the Security Team
Am 06.03.2014 02:00, schrieb Paul Wise: * The distribution hardening using dpkg-buildflags is coming along nicely. Unfortunately this doesn't apply to binaries compiled outside of the package building system. It would be great if we could adopt the Ubuntu approach of just enabling the flags in GCC itself. Even better would be to get GCC upstream to finally enable them by default. This should not be enabled in the distro itself, and if, then not before it can be enabled upstream. From my point of view it was a mistake to enable it this way before getting this upstream. However it is a lot of work to get the compiler to build itself with these flags and the testsuite produce the same results as without these. In the past neither the Ubuntu security team nor the Google ChromeOS team had time and resources to bring these patches upstream. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5317faa6.6090...@debian.org
Re: Bits from the Security Team
On Thu, Mar 6, 2014 at 12:33 PM, Matthias Klose wrote: This should not be enabled in the distro itself, and if, then not before it can be enabled upstream. From my point of view it was a mistake to enable it this way before getting this upstream. However it is a lot of work to get the compiler to build itself with these flags and the testsuite produce the same results as without these. In the past neither the Ubuntu security team nor the Google ChromeOS team had time and resources to bring these patches upstream. So, probably too much work for a GSoC project? If not would you mentor such a project? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6etczrhzqjy_fepqrzg73w+kspxijdap6biflk13km...@mail.gmail.com
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 07:51:28AM +0800, Paul Wise wrote: On Thu, Mar 6, 2014 at 3:03 AM, Moritz Muehlenhoff wrote: * We're planning to request for hidepid to be enabled by default (to 1). This will squash an entire class of information leaks. If you have any comments or objections, please get in touch with us. Apparently this breaks suspend with systemd and maybe causes some issues with login and other things under systemd: https://bugzilla.redhat.com/show_bug.cgi?id=1043134 http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html http://lists.freedesktop.org/archives/systemd-devel/2012-October/006860.html I do use systemd and hidepid=2 and it seems to work just fine here (please keep me on CC:, I'm not subscribed to -devel anymore). From the bug report, I'm quite unsure it's actually related to hidpid=2 and not just to the lack of systemd/logind support in current Xfce stack. Regards, -- Yves-Alexis Perez Debian security team signature.asc Description: Digital signature
Re: Bits from the Security Team (for those that care about bits)
Thijs Kinkhorst th...@debian.org writes: * Issues in specific packages We further discussed some specific problematic packages. One example is ia32-libs, which is difficult because it includes 100+ other source packages. This will be handled better for Squeeze: we'll have to ensure it's as up to date as possible at time of release, and will keep updating it in stable point updates to include newer package versions from the security archive (or the stable release itself). A while back I looked into making the detection of security bugs in ia32-libs (which is all just code duplication of other packages) automatic. But the config for that detection would have needed 100+ config entries, which would ahve become verry ugly to maintain. Has there been any change for this? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipxb6ak7.fsf@frosties.localnet
Re: Bits from the Security Team (for those that care about bits)
On Wed, 26 Jan 2011 14:47:52 +0100, Goswin von Brederlow wrote: Thijs Kinkhorst th...@debian.org writes: * Issues in specific packages We further discussed some specific problematic packages. One example is ia32-libs, which is difficult because it includes 100+ other source packages. This will be handled better for Squeeze: we'll have to ensure it's as up to date as possible at time of release, and will keep updating it in stable point updates to include newer package versions from the security archive (or the stable release itself). A while back I looked into making the detection of security bugs in ia32-libs (which is all just code duplication of other packages) automatic. But the config for that detection would have needed 100+ config entries, which would ahve become verry ugly to maintain. Has there been any change for this? I think it will be easier to just track the issues in the security tracker manually. I'm already tracking all of the packages in ia32-libs as embedded code copies, and I wrote a script that inserts code copy info into the CVE list automatically. Anyway, I think this can be left up to the security team. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126114757.aab379fd.michael.s.gilb...@gmail.com
Re: Bits from the Security Team (for those that care about bits)
On Sun, Jan 23, 2011 at 11:32:07PM +0100, Thijs Kinkhorst wrote: * README.test Although many packages include a test suite that is run after package build, there are packages that do not have such a suite, or not one that can be run as part of the build process. It was proposed to standardise on a README.test file, analogous to README.source, describing to others than the regular maintainer how the package's functionality can properly be tested. This is something we would like to see discussed and implemented for the Wheezy development cycle. Wouldn't it be more prudent to have this be part of README.source? That was always meant as a document for human consumption, to help the casual maintainer or NMU'er understand how the package works, and help them be able to work on it. Since 'testing the result' is very much part of 'working on a package,' I believe it belongs there; and such a description would certainly fall under the debian/README.source may also include any other information that would be helpful to someone modifying the source package sentence in the final paragraph If people aren't doing this, then perhaps a minor policy amendment to add 'test suite usage' as one of the examples in that final paragraph could make sense. OTOH, explicitly adding more and more examples when that part of policy already explicitly mentions that you can put 'any other information that would be helpful' in there could be confusing. Regards, -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125152620.gs3...@celtic.nixsys.be
autopkgtest (was Re: Bits from the Security Team (for those that care about bits)
Hi, On Montag, 24. Januar 2011, Iustin Pop wrote: Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Package: autopkgtest Description: automatic as-installed testing for Debian packages autopkgtest runs tests on binary packages. The tests are run on the package as installed on a testbed system (which may be found via a virtualisation or containment system). The tests are expected to be supplied in the corresponding Debian source package. . See adt-run(1) and /usr/share/doc/autopkgtest. Use of adt-virt-xenlvm requires the autopkgtest-xenlvm package too; Use of the pre-cooked adt-testreport-onepackage script requires curl. I'm happy that you like piuparts, but it's not the best tool for everything :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 07:48:18AM +0100, Iustin Pop wrote: IMHO what would be a sufficient first step would be much simpler: - being able to know if a package does offer build post-install tests - how to run such tests - for post-install tests, what are the depedencies (Test-Depends? ;-) True. However, we are trying to think this somewhat trough so we have a better picture what will be typical use cases for testing within Debian. One thing we need to deal with in our field are tests that require substantial amounts of additional data (not part of any package right now) and sometimes also the test suite is not part of a source package, but shipped separately (due to size, ...). This would allow a maintainer to implement an automatic test of his packages whenever doing a new upload (which is my personal issue :). A framework like your proposed DebTest can then build upon such basic functionality to provide coordinated, archive-wide or package-set-wide running of tests. Yes, that was the idea. A few comments on your proposal: - “Metainformation: duration”: how do you standardise CPU/disk/etc. performance to get a useful metric here? - assess resources/performance: in general, across architectures/platforms and varied CPU speeds, I think it will be hard to quantify the performance and even resources needed for a test suite All these are just meant to be things to consider while planning. I personally don't believe it is possible to give an accurate 'in-advance' estimate of test-runtime (given the large variety in performance). However, it might still be valuable to indicate whether a test is relatively resource hungry. Maybe it turns out that anything but a tag 'slow' is impossible to achieve. But we also thought about a Debian-dashboard for test results. That could gather information about the typical resource demands (per architecture) and give more accurate estimates. - some structured output: given the variety of test suites, this might be very hard to achieve; in my experience, the best that can be hoped for across heterogeneous software is a count of pass/fail, and log files should be left for human investigation in case of failures True. Although not being able to be smart in some cases doesn't imply that we don't try to be clever when we can. We want to aim for a system that has a very low entry threshold. In the simplest case the package maintainer only places a symlink/script/binary with the package name implementing the test suite into a certain directory. When called and exiting normally the test will count is passed or failed otherwise. the structured output in this case is stderr and stdout. However, there are subsystems of Debian with more standardized approaches to testing (e.g. Python). DebTest should have the ability to add plugins for specific test environments to allow people to make it more clever. We only need to make sure that more structured information about test results have a place to go to and being handled in this framework. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124133435.GA12160@meiner
Re: Bits from the Security Team (for those that care about bits)
On 24/01/11 02:52, Paul Wise wrote: * README.test An alternative is to just provide *-test Debian packages. If the package exists then building it is the same as running a test of the packages it requires to be installed - maybe just the * package, but it could also be an integration test. I've got some packages in SourceForge that allow you to - build from GIT version control - install to a sandbox - do a make distcheck and build the Debian package from the tar ball. - check a particular branch with make git branch=X check The build goodies are in the v3c project http://www.sourceforge.net/projects/v3c All the other projects inherit these features from v3c. I hope this gives you some food for thought. Philip
Re: autopkgtest (was Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 10:37:26AM +0100, Holger Levsen wrote: Hi, On Montag, 24. Januar 2011, Iustin Pop wrote: Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Package: autopkgtest Description: automatic as-installed testing for Debian packages autopkgtest runs tests on binary packages. The tests are run on the package as installed on a testbed system (which may be found via a virtualisation or containment system). The tests are expected to be supplied in the corresponding Debian source package. . See adt-run(1) and /usr/share/doc/autopkgtest. Use of adt-virt-xenlvm requires the autopkgtest-xenlvm package too; Use of the pre-cooked adt-testreport-onepackage script requires curl. I'm happy that you like piuparts, but it's not the best tool for everything :-) As I said, E.g. - for example. Thanks for mentioning autopkgtest, I didn't know about it. iustin signature.asc Description: Digital signature
Re: Bits from the Security Team (for those that care about bits)
On Monday 24 January 2011, Iustin Pop wrote: This is a very good idea, but I think it could be taken two steps further. These are just some ideas I have but did not explore in depth, so take them with a grain of salt. First, tests run during a package build are good, but they do not ensure, for example, that the package as installed is working OK. I've been thinking that (also) providing tests to be run after the package is installed (and not on the build results) would be most useful in ensuring that both the build process and the packaging is correct. Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Of course, these would be useful only for some classes of packages, but for those they would be of much help. I have something like this in one package of mine, and it gives me a lot of confidence while doing packaging changes. FWIW, Ubuntu has a regression test suite: https://code.launchpad.net/~ubuntu-bugcontrol/qa-regression- testing/master I didn't have a chance to look at it, yet, though. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101242132.26170...@sfritsch.de
Re: Bits from the Security Team (for those that care about bits)
On Sun, Jan 23, 2011 at 11:32:07PM +0100, Thijs Kinkhorst wrote: Hi! In the weekend 14-16 January 2011, the Debian Security Team convened in Linux Hotel, Essen. We discussed many things, a lot of security work was done and of course the necessary socialising wasn't forgotten. We'd like to thank the Linux Hotel for again receiving us in such a great way! […] * README.test Although many packages include a test suite that is run after package build, there are packages that do not have such a suite, or not one that can be run as part of the build process. It was proposed to standardise on a README.test file, analogous to README.source, describing to others than the regular maintainer how the package's functionality can properly be tested. This is something we would like to see discussed and implemented for the Wheezy development cycle. This is a very good idea, but I think it could be taken two steps further. These are just some ideas I have but did not explore in depth, so take them with a grain of salt. First, tests run during a package build are good, but they do not ensure, for example, that the package as installed is working OK. I've been thinking that (also) providing tests to be run after the package is installed (and not on the build results) would be most useful in ensuring that both the build process and the packaging is correct. Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Of course, these would be useful only for some classes of packages, but for those they would be of much help. I have something like this in one package of mine, and it gives me a lot of confidence while doing packaging changes. thanks, iustin signature.asc Description: Digital signature
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: First, tests run during a package build are good, but they do not ensure, for example, that the package as installed is working OK. I've been thinking that (also) providing tests to be run after the package is installed (and not on the build results) would be most useful in ensuring that both the build process and the packaging is correct. Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Exactly. In the NeuroDebian team we started playing around with more comprehensive testing -- both regarding single packages, but also integration tests involving multiple packages. We started composing a SPEC for a testing framework, but we haven't gotten very far, yet. What we have is here http://neuro.debian.net/proj_debtest.html and here http://git.debian.org/?p=pkg-exppsy/neurodebian.git;a=blob_plain;f=sandbox/proposal_regressiontestframwork.moin If somebody is interested in working on this topic, we'd be glad to join forces. Originally, we wanted to develop the SPEC a little further, but since the topic came up, I figured it might be better to add these pointers now. Michael -- Michael Hanke http://mih.voxindeserto.de signature.asc Description: Digital signature
Re: Bits from the Security Team (for those that care about bits)
Michael Hanke wrote: On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Exactly. In the NeuroDebian team we started playing around with more comprehensive testing -- both regarding single packages, but also integration tests involving multiple packages. We started composing a SPEC for a testing framework, but we haven't gotten very far, yet. What we have is here http://neuro.debian.net/proj_debtest.html Thanks for starting this project! I hope a lot of progress is made so that it can be used for Wheezy. This topic is something I've been slowly working but haven't had much time. Other ideas: * http://bugs.debian.org/512265 * Something I wrote the other day (related to the d-d-a email): A long term plan could be to push the creation of a framework so that it is easy to test things such as webapps (which may require an httpd) and other packages that are not very to setup (e.g. by providing a script that creates a basic virtual machine, installs the needed stuff and then control is handed over to the package-specific bits). Automated testing is something that we really ought to push. And there's also the possibility of re-using the same test framework to allow automated fuzzing (and easier fuzzing using custom environment, etc.) Somehow related to DACA too. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ihipds$t3k$1...@dough.gmane.org
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 7:19 AM, Iustin Pop ius...@debian.org wrote: First, tests run during a package build are good, but they do not ensure, for example, that the package as installed is working OK. I've been thinking that (also) providing tests to be run after the package is installed (and not on the build results) would be most useful in ensuring that both the build process and the packaging is correct. Debian has definitely needed this for a long time. I'm thinking that these automated post-install tests are something that all distributions could benefit from and probably we should push them upstream. Automated post-install testing would be great, but it cannot apply in all cases and should be complemented by README.test. I think both approaches are needed. For example: libwww-topica-perl: This is a perl module that interacts with a web service and screen scrapes their email list archive format to convert it to mbox format. Every few months I run the program on a specific list and compare it to the previously saved mbox file. The list is long-dead so there are no changes at all, unless the site changed its HTML and broke the package. This is trivially automatable. warzone2100: This is an interactive game. Testing it involves playing for several hours in single player mode and maybe trying to find someone to play in multiplayer mode. Definitely not automatable. Probably the only automatable test here would be to run it in Xvfb but that wouldn't test the package usefully. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikojANFHmf9=AEKauwB+BXf2O_ud=ON=X5x=i...@mail.gmail.com
Re: Bits from the Security Team (for those that care about bits)
On Mon, Jan 24, 2011 at 10:52:54AM +0800, Paul Wise wrote: On Mon, Jan 24, 2011 at 7:19 AM, Iustin Pop ius...@debian.org wrote: First, tests run during a package build are good, but they do not ensure, for example, that the package as installed is working OK. I've been thinking that (also) providing tests to be run after the package is installed (and not on the build results) would be most useful in ensuring that both the build process and the packaging is correct. Debian has definitely needed this for a long time. I'm thinking that these automated post-install tests are something that all distributions could benefit from and probably we should push them upstream. Automated post-install testing would be great, but it cannot apply in all cases and should be complemented by README.test. I think both approaches are needed. Agreed—I wasn't suggesting that README.test is not useful, just that there is potential for more in this area, at least for some class of packages. For example: libwww-topica-perl: […] warzone2100: […] Good examples, indeed. regards, iustin signature.asc Description: Digital signature
Re: Bits from the Security Team (for those that care about bits)
On Sun, Jan 23, 2011 at 06:45:56PM -0500, Michael Hanke wrote: On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: First, tests run during a package build are good, but they do not ensure, for example, that the package as installed is working OK. I've been thinking that (also) providing tests to be run after the package is installed (and not on the build results) would be most useful in ensuring that both the build process and the packaging is correct. Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Exactly. In the NeuroDebian team we started playing around with more comprehensive testing -- both regarding single packages, but also integration tests involving multiple packages. We started composing a SPEC for a testing framework, but we haven't gotten very far, yet. What we have is here http://neuro.debian.net/proj_debtest.html and here http://git.debian.org/?p=pkg-exppsy/neurodebian.git;a=blob_plain;f=sandbox/proposal_regressiontestframwork.moin If somebody is interested in working on this topic, we'd be glad to join forces. Originally, we wanted to develop the SPEC a little further, but since the topic came up, I figured it might be better to add these pointers now. Thanks for sharing. Your proposal seems to focus on a higher level, e.g. group-based testing, resource and scheduling, etc. IMHO what would be a sufficient first step would be much simpler: - being able to know if a package does offer build post-install tests - how to run such tests - for post-install tests, what are the depedencies (Test-Depends? ;-) This would allow a maintainer to implement an automatic test of his packages whenever doing a new upload (which is my personal issue :). A framework like your proposed DebTest can then build upon such basic functionality to provide coordinated, archive-wide or package-set-wide running of tests. A few comments on your proposal: - “Metainformation: duration”: how do you standardise CPU/disk/etc. performance to get a useful metric here? - assess resources/performance: in general, across architectures/platforms and varied CPU speeds, I think it will be hard to quantify the performance and even resources needed for a test suite - some structured output: given the variety of test suites, this might be very hard to achieve; in my experience, the best that can be hoped for across heterogeneous software is a count of pass/fail, and log files should be left for human investigation in case of failures regards, iustin signature.asc Description: Digital signature
Re: Bits from Testing Security team
On Sat, 28 Jun 2008 08:45:54 pm Holger Levsen wrote: Hi Testing Security team, thanks for the announce-mail and your work! On Wednesday 25 June 2008 11:08, Nico Golde wrote: General security support for testing [...] kernel. Also, we would like to state that packages that are not security supported for stable are likewise unsupported for testing. This list includes all packages in contrib and non-free, as well as the ones that are marked unsupported (for example, kfreebsd). The maintainers are solely responsible for security and there won't be any DTSAs for such packages. Where / how are packages marked as unsupported? We just started the work on that together with Enrico. So far, we have a file in svn called package-tags and it currently has the following content: # In this file we keep the debtags for packages in main # where special conditions apply [etch] kfreebsd-5 unsupported (FreeBSD not yet supported) [lenny] kfreebsd-6 unsupported (FreeBSD not yet supported) [lenny] kfreebsd-7 unsupported (FreeBSD not yet supported) Please note that atm all contrib/non-free packages are unsupported by default. Cheers Steffen signature.asc Description: This is a digitally signed message part.
Re: Bits from Testing Security team
Hi Testing Security team, thanks for the announce-mail and your work! On Wednesday 25 June 2008 11:08, Nico Golde wrote: General security support for testing [...] kernel. Also, we would like to state that packages that are not security supported for stable are likewise unsupported for testing. This list includes all packages in contrib and non-free, as well as the ones that are marked unsupported (for example, kfreebsd). The maintainers are solely responsible for security and there won't be any DTSAs for such packages. Where / how are packages marked as unsupported? regards, Holger pgpdRWheLYzoL.pgp Description: PGP signature
Re: Bits from Testing Security team
On Wed, Jun 25, 2008 at 11:08:50AM +0200, Nico Golde wrote: testing. This list includes all packages in contrib and non-free, as well as the ones that are marked unsupported (for example, kfreebsd). Hi. You mention packages that are marked unsupported: where is that mark stored? I'm asking because of #436161: the list of such marks seems like a perfect data source for a prototype. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bits from the Security Team
Steve Langasek wrote: The Security Team is now using Request Tracker to coordinate work and our RT processes have already been refined a lot. If you're a package maintainer working towards a security update, you're now encouraged to open a ticket directly. You will be kept in CC during the life time of the ticket. If you're opening a ticket for a security problem, which is not yet publicly known, e.g. if you've discovered it by yourself or if you have been contacted by upstream, please open a ticket in the Security - Private queue. These issues will only be visible by the Security Team. If you're opening a ticket for a security problem which is publicly known, e.g. if it's announced on the project web site, please open a ticket in the Security queue. These issues will be visible publicly. As far as I can see, this announcement mail doesn't mention where the RT instance is running, nor the means of opening a ticket in the appropriate queue. Where is this information available? We're using the official rt.debian.org. Full details will be folded into the developer's reference soon. We're planning to improve our quality assurance process for security updates by providing a public security update beta test program in addition to the existing QA done for security updates. During the preparation of security updates, there's an inherent delay between the initial upload of the fixed packages and the time until the packages have been built on porter machines. This time gap will be used for a new security update beta program. The test program will be targeted at large installations, which install security updates in a test environment before installing them into the production environment. This test group will be initially limited. Is this meant to apply only to unembargoed security updates? AIUI, the practice today is that for embargoed security updates, all of the binaries are kept in the queue until they're ready for release; so I don't really see a gap when the security update is public but the binary packages aren't built? Yes, this is limited to non-embargoed security issues. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On 2008-03-11, Don Armstrong [EMAIL PROTECTED] wrote: On Sun, 09 Mar 2008, Moritz Muehlenhoff wrote: If you're opening a ticket for a security problem which is publicly known, e.g. if it's announced on the project web site, please open a ticket in the Security queue. These issues will be visible publicly. Is there any particular reason why we're duplicating this information that should already be present in the bts as bugs with severity serious tagged security marked found in a version in stable in RT? If there are some change to the BTS needed for the security team to track the non-embargoed issues more easily, I'd be glad to make (or at the very least discuss) them. From where I sit it seems non-ideal for both the security team and maintainers (as well as anyone else who is interested) to put this information in a system which isn't tied in strongly with the BTS or otherwise is unable to track package versioning. This doesn't intend to duplicate information from the BTS. The RT queues even contain direct links to the BTS. RT is used to distribute work among the members of the security team and to keep pending issues more organized. RT mostly replaces sending to mail to [EMAIL PROTECTED] if a maintainer wants to assist in preparing a security update. Mail doesn't scale very well, so we've had occasional smaller issues being lost in the noise. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Fri, 14 Mar 2008, Moritz Muehlenhoff wrote: This doesn't intend to duplicate information from the BTS. The RT queues even contain direct links to the BTS. RT is used to distribute work among the members of the security team and to keep pending issues more organized. You could actually do all of that pretty easily using usertags or similar, but it's your process. The main reason that I wanted to clarify this is because the instructions sound like RT should be used in lieu of the BTS, which isn't such a great idea. The secondary reason is that it's very useful to see in a single location the exact status of non-embargoed security bugs; using RT means that someone who is interested has to find the RT bug which corresponds to the package they're interested in and then check the corresponding BTS bug (though I suppose this could be mitigated by adding a reverse link to the RT bug from the bts using the forwarded field or similar.) RT mostly replaces sending to mail to [EMAIL PROTECTED] if a maintainer wants to assist in preparing a security update. Mail doesn't scale very well, so we've had occasional smaller issues being lost in the noise. I agree that some method of tracking what the stable security team is working on is a good idea; e-mail definetly doesn't scale. Don Armstrong -- This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
Hi Don, * Don Armstrong [EMAIL PROTECTED] [2008-03-14 20:42]: On Fri, 14 Mar 2008, Moritz Muehlenhoff wrote: [...] The secondary reason is that it's very useful to see in a single location the exact status of non-embargoed security bugs; using RT means that someone who is interested has to find the RT bug which corresponds to the package they're interested in and then check the corresponding BTS bug (though I suppose this could be mitigated by adding a reverse link to the RT bug from the bts using the forwarded field or similar.) That's what the security tracker is for. http://security-tracker.debian.net/tracker/CVE id http://security-tracker.debian.net/tracker/src package Kind regards Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpjXrX7ffNWJ.pgp Description: PGP signature
Re: Bits from the Security Team
Hi Moritz, On Sun, Mar 09, 2008 at 11:05:11PM +0100, Moritz Muehlenhoff wrote: The Security Team is now using Request Tracker to coordinate work and our RT processes have already been refined a lot. If you're a package maintainer working towards a security update, you're now encouraged to open a ticket directly. You will be kept in CC during the life time of the ticket. If you're opening a ticket for a security problem, which is not yet publicly known, e.g. if you've discovered it by yourself or if you have been contacted by upstream, please open a ticket in the Security - Private queue. These issues will only be visible by the Security Team. Should the RT also be used for breackage caused by a security update? E.g. Icedove is pretty broken since the last update: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466527 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465531 Is the security team interested in this kind of information our should this be handled by the maintainer? Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
* Guido Günther: Hi Moritz, On Sun, Mar 09, 2008 at 11:05:11PM +0100, Moritz Muehlenhoff wrote: The Security Team is now using Request Tracker to coordinate work and our RT processes have already been refined a lot. If you're a package maintainer working towards a security update, you're now encouraged to open a ticket directly. You will be kept in CC during the life time of the ticket. If you're opening a ticket for a security problem, which is not yet publicly known, e.g. if you've discovered it by yourself or if you have been contacted by upstream, please open a ticket in the Security - Private queue. These issues will only be visible by the Security Team. Should the RT also be used for breackage caused by a security update? Sure, but keep in mind that RT is intended for coordinating the actual upload, and not primarily for reporting the bug itself. Is the security team interested in this kind of information our should this be handled by the maintainer? Maintainer involvement is always desirable because it's better if someone familiar with the software prepares the upload. With complex packages, maintainer involvement is a must. It's not clear from the bug reports what's causing this regression, so there's little what we (the security team) can do what other interested parties can't do better and more quickly.
Re: Bits from the Security Team
Hi Moritz, On Sun, Mar 09, 2008 at 11:05:11PM +0100, Moritz Muehlenhoff wrote: Use of RT = The Security Team is now using Request Tracker to coordinate work and our RT processes have already been refined a lot. If you're a package maintainer working towards a security update, you're now encouraged to open a ticket directly. You will be kept in CC during the life time of the ticket. If you're opening a ticket for a security problem, which is not yet publicly known, e.g. if you've discovered it by yourself or if you have been contacted by upstream, please open a ticket in the Security - Private queue. These issues will only be visible by the Security Team. If you're opening a ticket for a security problem which is publicly known, e.g. if it's announced on the project web site, please open a ticket in the Security queue. These issues will be visible publicly. As far as I can see, this announcement mail doesn't mention where the RT instance is running, nor the means of opening a ticket in the appropriate queue. Where is this information available? We're planning to improve our quality assurance process for security updates by providing a public security update beta test program in addition to the existing QA done for security updates. During the preparation of security updates, there's an inherent delay between the initial upload of the fixed packages and the time until the packages have been built on porter machines. This time gap will be used for a new security update beta program. The test program will be targeted at large installations, which install security updates in a test environment before installing them into the production environment. This test group will be initially limited. Is this meant to apply only to unembargoed security updates? AIUI, the practice today is that for embargoed security updates, all of the binaries are kept in the queue until they're ready for release; so I don't really see a gap when the security update is public but the binary packages aren't built? Cheers, -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Mon, March 10, 2008 09:24, Steve Langasek wrote: If you're opening a ticket for a security problem which is publicly known, e.g. if it's announced on the project web site, please open a ticket in the Security queue. These issues will be visible publicly. As far as I can see, this announcement mail doesn't mention where the RT instance is running, nor the means of opening a ticket in the appropriate queue. Where is this information available? We appearently assumed that all developers were aware of where the Debian RT is located and how it's used, but for those that missed it, instructions are here: http://people.debian.org/~terpstra/message/20070323.015558.db94cadf.en.html Sorry for the inconvenience. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Mon, 10 Mar 2008, Thijs Kinkhorst wrote: On Mon, March 10, 2008 09:24, Steve Langasek wrote: If you're opening a ticket for a security problem which is publicly known, e.g. if it's announced on the project web site, please open a ticket in the Security queue. These issues will be visible publicly. As far as I can see, this announcement mail doesn't mention where the RT instance is running, nor the means of opening a ticket in the appropriate queue. Where is this information available? We appearently assumed that all developers were aware of where the Debian RT is located and how it's used, but for those that missed it, instructions are here: http://people.debian.org/~terpstra/message/20070323.015558.db94cadf.en.html Don't assume that people remember everything. :) And the preferred way to open a ticket for DD is usually by sending a mail and the mail above does only document the DSA and keyring queues. You should point to the corresponding email alias for the security queues IMO. And giving a few more direct links into the web interface can't hurt :) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Mon, Mar 10, 2008 at 09:28:24AM +0100, Thijs Kinkhorst wrote: On Mon, March 10, 2008 09:24, Steve Langasek wrote: If you're opening a ticket for a security problem which is publicly known, e.g. if it's announced on the project web site, please open a ticket in the Security queue. These issues will be visible publicly. As far as I can see, this announcement mail doesn't mention where the RT instance is running, nor the means of opening a ticket in the appropriate queue. Where is this information available? We appearently assumed that all developers were aware of where the Debian RT is located and how it's used, but for those that missed it, I'm well aware of where the existing Debian RT is. Nowhere in the announcement mail was it stated that the security team was using the *same* RT instance. instructions are here: http://people.debian.org/~terpstra/message/20070323.015558.db94cadf.en.html Sorry for the inconvenience. Which gives information about opening tickets in two queues: the keyring queue, and the DSA queue. Or do you mean that there's no email address for opening Security tickets, and any tickets for the security queue can only be opened using the generic 'debian' user on the website? -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Sun, 09 Mar 2008, Moritz Muehlenhoff wrote: If you're opening a ticket for a security problem which is publicly known, e.g. if it's announced on the project web site, please open a ticket in the Security queue. These issues will be visible publicly. Is there any particular reason why we're duplicating this information that should already be present in the bts as bugs with severity serious tagged security marked found in a version in stable in RT? If there are some change to the BTS needed for the security team to track the non-embargoed issues more easily, I'd be glad to make (or at the very least discuss) them. From where I sit it seems non-ideal for both the security team and maintainers (as well as anyone else who is interested) to put this information in a system which isn't tied in strongly with the BTS or otherwise is unable to track package versioning. Don Armstrong -- You could say to the Universe this is not /fair/. And the Universe would say: Oh it isn't? Sorry. -- Terry Pratchett _Soul Music_ p357 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Bits from the Security Team
On Sun, Mar 09, 2008 at 11:05:11PM +0100, Moritz Muehlenhoff wrote: * You need to be familiar with how the wide variety Debian packages are maintained, patched and built. If you're not scared by packages generating their patch series by applying sed statements from cdbs include files before passing the patches through an awk filter to quilt until they're finally built with yada, you might be the right person. OTOH, if you're doing that in one of *your* packages, you're probably not the right person. The security team prefers its members to be sane. ;) noah signature.asc Description: Digital signature
Re: Bits from the Security Team
On Tue, Oct 30, 2007 at 09:04:12PM +0100, Moritz Muehlenhoff wrote: Embedded code copies Developers are encouraged to communicate amongst their colleague developers for cases where their packages have code in common with other packages. For example a package which contains an embedded library which is also packaged should be encouraged to use the shared library, as this means a potential security update only requires a single update. A prominently horrible example is the xpdf code base which is embedded in ten different source packages in Debian Sarge. (For Debian Etch this could already be reduced significantly thanks to the xpdf library fork named poppler and for Lenny we'll reduce it even more) You need to tell us about such cases, we can't review all of Debian's 18k packages on our own. Wouldn't be the case to add a suitable control field, as proposed in a previous thread for that case? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
* Francesco P. Lovergine: On Tue, Oct 30, 2007 at 09:04:12PM +0100, Moritz Muehlenhoff wrote: Embedded code copies Wouldn't be the case to add a suitable control field, as proposed in a previous thread for that case? For various reasons, we need something that can be changed without a new upload. An additional data source is welcome, of course, but a separately maintained will always be necessary. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
pe, 2007-10-19 kello 18:29 +0200, Adrian von Bidder kirjoitti: Seriously: I think exactly this kind of not really much new stuff going on, but here's what we're continuing to do kind of information should be more visible, because it, too, is valuable information to somebody who is not involved tightly in the Debian teams. Aye. In many corporations, a weekly or monthly status report is required from employees. I don't think we want to make it a requirement, but I do think the Bits from mails are a great thing, and getting them, say, monthly would be very nice, even if they just say business as usual, Steve still likes pies. So please take this as encouragement if you're thinking about whether you or your team should send more of them. :) I appreciate that writing such mails takes effort. That's one of the reasons I don't think we can or should require them, but even lightweight ones are useful. -- You need fewer comments, if you choose your names carefully. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Sat Oct 20, 2007 at 12:00:23 +0300, Lars Wirzenius wrote: pe, 2007-10-19 kello 18:29 +0200, Adrian von Bidder kirjoitti: Seriously: I think exactly this kind of not really much new stuff going on, but here's what we're continuing to do kind of information should be more visible, because it, too, is valuable information to somebody who is not involved tightly in the Debian teams. I do think the Bits from mails are a great thing, and getting them, say, monthly would be very nice, even if they just say business as usual, Steve still likes pies. I agree. I like reading them myself, which is why I posted my little entry with the subtitle I did. Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Fri Oct 19, 2007 at 18:29:46 +0200, Adrian von Bidder wrote: That you like pies is important. :) Though in the specific case of the security team, the flow of security updates is an indication that the team is working Yes, this is what I think too. Could've cc:ed you at least. Apologies. No problem. Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Friday 19 October 2007 17.52:29 Steve Kemp wrote: I don't believe that post contains significant new information, (except that I like pies!), and as such I didn't believe it deserved massive visibility. That you like pies is important. Seriously: I think exactly this kind of not really much new stuff going on, but here's what we're continuing to do kind of information should be more visible, because it, too, is valuable information to somebody who is not involved tightly in the Debian teams. To the insider, it's obviously not important as they key people keep in touch anyway. Though in the specific case of the security team, the flow of security updates is an indication that the team is working (and I didn't want to imply that I felt the team was not working anyway!), so maybe your judgement was better than mine - it's not a case of wrong vs. right anyway. To be honest I'm a little disappointed that you chose to complain here about that, rather than commenting/mailing me personally. Could've cc:ed you at least. Apologies. cheers -- vbi -- featured link: http://www.pool.ntp.org signature.asc Description: This is a digitally signed message part.
Re: Bits from the Security Team
Adrian von Bidder wrote: http://blog.steve.org.uk/articles/2007/10/19/as-i-move-on-through-the-year= =20 which is really a Bits from the Security Team. Full Bits will appear soon. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On Fri Oct 19, 2007 at 17:36:21 +0200, Adrian von Bidder wrote: Allow me to point out the message at http://blog.steve.org.uk/articles/2007/10/19/as-i-move-on-through-the-year which is really a Bits from the Security Team. Why is - once again - a message that I'd consider appropriate for d-d, or perhaps even d-d-a (though I admit that the real information content is not extremely high. But still, it is information that Steve is active and outlines some of the problems and ways how people can help) hidden on a blog? I don't believe that post contains significant new information, (except that I like pies!), and as such I didn't believe it deserved massive visibility. To be honest I'm a little disappointed that you chose to complain here about that, rather than commenting/mailing me personally. (Apologies if I'm just too quick and Steve posted his Bits to d-d or d-d-a but the mail just hasn't reached me or the mail archives yet.) It hasn't been posted elsewhere. I'm happy to write more, later, and post to the devel-announc list, once I've got a chance to do so. But even so the content would be largely known, and largely un-newsworthy. And to reiterate things slightly; If there were something that users/developers are supposed to know then it shouldn't be posted to just a random blog. It should go to the development/announcement lists. I don't believe I'm guilty of that here, and I don't believe anybody else has been guilty of that recently. (ie. I agree. Fragmentation is something to be avoided). Steve -- http://www.steve.org.uk/ pgpUaUrLFx3t7.pgp Description: PGP signature
