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
On Wed, Mar 19, 2014 at 20:54:42 +0100, Christoph Biedl wrote:
> Moritz Muehlenhoff wrote...
>
> > LTS
> > - ---
> >
> > * Anyone interested in contributing, please get in touch with
> > t...@security.debian.org. We'll setup an initial coordination list
> > with all interested parties. All p
Moritz Muehlenhoff wrote...
> LTS
> - ---
>
> * Anyone interested in contributing, please get in touch with
> t...@security.debian.org. We'll setup an initial coordination list
> with all interested parties. All policies / exact work will be
> sorted out there.
Ups, I have to admit, it too
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
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
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
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
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
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
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
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
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
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
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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
* 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
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
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.
* 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
* 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
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
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@
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 (
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
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
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.
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
* 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
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
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
>
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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.
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? ;-)
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
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)
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
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
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
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
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
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
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
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
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
* 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,
>
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
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
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
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
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
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,
>
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
* 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
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
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.
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
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
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
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
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 mess
Hi everybody,
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 adm
88 matches
Mail list logo
