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

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 deb

Re: Bits from the Security Team

Christoph Biedl 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 ti

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 s

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 s

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 be

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 mis

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 fro

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

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

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 > >

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 s

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 ap

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 magnitud

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 lik

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 cha

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

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 woul

Re: Bits from the Security Team

Christoph Biedl 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 inte

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 mainta

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 unt

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 apparent

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-install

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? > Pr

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 w

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/

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 tha

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 pac

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

Re: Bits from the Security Team

On Fri, Mar 7, 2014 at 18:41:02 +0100, Jakub Wilk wrote: > * Vincent Danjean , 2014-03-07, 15:41: > >>hidepid=1 means users may not access any /proc// > >>directories but their own. > > > >Even that is strange. I just tried. Processus that are not mine > >are not shown anymore by ps, but even som

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.

Re: Bits from the Security Team

* Stephan Seitz , 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 ide

Re: Bits from the Security Team

* Vincent Danjean , 2014-03-07, 15:41: hidepid=1 means users may not access any /proc// 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

Re: Bits from the Security Team

On 05/03/2014 22:33, Jakub Wilk wrote: > hidepid=1 means users may not access any /proc// 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 t

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@

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 (

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 f

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

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.

Re: Bits from the Security Team

Hi Jakub, On Wed, Mar 05, 2014 at 10:33:23PM +0100, Jakub Wilk wrote: > * Guido Günther , 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

Re: Bits from the Security Team

* Moritz Muehlenhoff , 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 sy

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 objec

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 >

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

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 swi

Re: Bits from the Security Team

Paul Wise 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 d

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 impleme

Re: Bits from the Security Team

On 05/03/2014 22:33, Jakub Wilk wrote: > * Guido Günther , 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, i

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 w

Re: Bits from the Security Team

* Guido Günther , 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

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 o

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 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

Re: Bits from the Security Team (for those that care about bits)

Thijs Kinkhorst 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

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 standa

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 > en

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

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.

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? ;-)

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 tes

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)

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 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) providin

Re: Bits from the Security Team (for those that care about bits)

On Mon, Jan 24, 2011 at 7:19 AM, 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 bu

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 >> ins

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

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

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

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 d

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 wil

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 dur

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, >

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

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

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

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" que

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

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, >

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

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

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

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.

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 vis

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 > no

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 r

Re: Bits from the Security Team

Adrian von Bidder wrote: >>=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". Trou

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 > > which is really a Bits from the Security Team. > > Why is - once again - a message that I'd consider appropriat