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 took
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 policies /
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
* 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
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
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
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:
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
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
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:
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
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
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
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
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.
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
* 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
* 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
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
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,
* 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
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.
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
* 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
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
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
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
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
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
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
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
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,
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
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.
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
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
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? ;-)
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 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
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,
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
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
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
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
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
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 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
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
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
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
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
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
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
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
* 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
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 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
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
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
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
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
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
* 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
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
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,
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 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
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
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 admit
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
91 matches
Mail list logo
