In message: <[EMAIL PROTECTED]>
Peter Jeremy <[EMAIL PROTECTED]> writes:
: On Sat, Feb 23, 2008 at 04:50:02PM -0700, M. Warner Losh wrote:
: >In message: <[EMAIL PROTECTED]>
: >Peter Jeremy <[EMAIL PROTECTED]> writes:
: >: At the same, time, the find(1) man page needs to cle
On Sat, Feb 23, 2008 at 04:50:02PM -0700, M. Warner Losh wrote:
>In message: <[EMAIL PROTECTED]>
>Peter Jeremy <[EMAIL PROTECTED]> writes:
>: At the same, time, the find(1) man page needs to clearly distinguish
>: between the parts of find that are POSIX-complaint, the parts that are
>:
--- Dimitry Andric <[EMAIL PROTECTED]> wrote:
> On 2008-02-23 02:08, Atom Smasher wrote:
> > article below. does anyone know how this affects eli/geli?
> >
> > from the geli man page: "detach - Detach the given providers, which means
> > remove the devfs entry and clear the keys from memory." d
On Sat, 23 Feb 2008 15:49:13 -0600 Brooks Davis <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 01:19:37PM -0500, Mike Meyer wrote:
> > On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" <[EMAIL
> > PROTECTED]> wrote:
> > While I understand that it's easier to fix the BSD find, have yo
On Sat, 23 Feb 2008 16:28:36 -0700 (MST) "M. Warner Losh" <[EMAIL PROTECTED]>
wrote:
> In message: <[EMAIL PROTECTED]>
> Mike Meyer <[EMAIL PROTECTED]> writes:
> : > In short, I'm continuig the long tradition that we've done as FreeBSD
> : > and that BSD and other Unix vendors did bef
article below. does anyone know how this affects eli/geli?
There's fairly little any disk crypto system can do to thoroughly
defend
against this.
Hm. Strange. Serious hardware is very well suited to do that (usually
by adding well defended crypto hardware). Keys don't have to be stored
in u
In message: <[EMAIL PROTECTED]>
Peter Jeremy <[EMAIL PROTECTED]> writes:
: At the same, time, the find(1) man page needs to clearly distinguish
: between the parts of find that are POSIX-complaint, the parts that are
: GNU extensions and the parts that are [Free]BSD extensions. This is
In message: <[EMAIL PROTECTED]>
Jonathan McKeown <[EMAIL PROTECTED]> writes:
: What functionality does
:
: find path -lname name
:
: add that isn't already available from
:
: find path -name name -type l
:
: and what other combinations should be special-cased like this?
Wha
On 2008-02-23 02:08, Atom Smasher wrote:
> article below. does anyone know how this affects eli/geli?
>
> from the geli man page: "detach - Detach the given providers, which means
> remove the devfs entry and clear the keys from memory." does that mean
> that geli properly wipes keys from RAM wh
In message: <[EMAIL PROTECTED]>
Mike Meyer <[EMAIL PROTECTED]> writes:
: > In short, I'm continuig the long tradition that we've done as FreeBSD
: > and that BSD and other Unix vendors did before us: compatibility with
: > other implementations.
:
: I suspect your definition of "long t
Am 23.02.2008 um 22:28 schrieb Igor Mozolevsky:
Or you could carry something that emits a huge EMI pulse to destroy
the data on the disk...
It would be easier to buy a MacBook Air...
Achim
Jonathan McKeown <[EMAIL PROTECTED]> writes:
> What functionality does
>
> find path -lname name
>
> add that isn't already available from
>
> find path -name name -type l
those are two entirely different things; -lname applies to the target of
the symlink, not the symlink itself.
DES
--
On Sat, Feb 23, 2008 at 02:08:31PM +1300, Atom Smasher wrote:
> article below. does anyone know how this affects eli/geli?
There's fairly little any disk crypto system can do to thoroughly defend
against this. The best workaround currently is to turn off your machine
when not in use. This has alwa
Mike Meyer <[EMAIL PROTECTED]> writes:
> How about a question: why are you turning the FreeBSD find into the
> GNU find? The changes in the first patch looked like they added real
> functionality that wasn't available in other tools. These seem to be
> gratuitous changes to make things compatible w
On Sat, Feb 23, 2008 at 03:53:55PM -0500, Mike Meyer wrote:
>On Sat, 23 Feb 2008 12:05:46 -0700 (MST) Warner Losh <[EMAIL PROTECTED]> wrote:
>> It adds functionality. That doesn't make it gratuitous. One might
>> just as well call 'POSIX' compatibility gratuitous. Like it or not,
>> the GNU util
On 23/02/2008, Brooks Davis <[EMAIL PROTECTED]> wrote:
>
> You should actually read the paper. :) They successfully defeat both
> of these type of protections by using canned air to chill the ram and
> transplanting it into another machine.
Easy to get around this attack - store the key on a us
On Sat, Feb 23, 2008 at 01:19:37PM -0500, Mike Meyer wrote:
> On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" <[EMAIL PROTECTED]>
> wrote:
>
> > In message: <[EMAIL PROTECTED]>
> > Mike Meyer <[EMAIL PROTECTED]> writes:
> > : On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warn
Marcel Moolenaar wrote:
> On Feb 22, 2008, at 12:39 PM, Oliver Fromme wrote:
> > Yes, that'll work well for putting characters on the
> > screen. But I don't think it is suitable for generic
> > graphics operations, even (and especially) for drawing
> > single pixels.
>
> True. What do you
[Sorry to break threading - I deleted the thread before deciding to respond. I
can see both sides of this discussion, but I did want to add some hopefully
thought-provoking comments late on a Saturday night].
[M Warner Losh]
> From: Mike Meyer
> Subject: Re: find -lname and -ilname implemented
On Sat, 23 Feb 2008 12:05:46 -0700 (MST) Warner Losh <[EMAIL PROTECTED]> wrote:
> From: Mike Meyer <[EMAIL PROTECTED]>
> > On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" <[EMAIL
> > PROTECTED]> wrote:
> >
> > > In message: <[EMAIL PROTECTED]>
> > > Mike Meyer <[EMAIL PROTEC
On Sat, Feb 23, 2008 at 11:24:22AM -0800, Tim Clewlow wrote:
>
> --- Pieter de Boer <[EMAIL PROTECTED]> wrote:
>
> > Jeremy Chadwick wrote:
> >
> > > It's interesting that you classified this as a "feature" (in quotes),
> > > because there's nothing "modern" about said "feature". This issue has
On Sat, Feb 23, 2008 at 10:32:02PM +0300, Eygene Ryabinkin wrote:
> Sat, Feb 23, 2008 at 10:56:20AM -0800, Jeremy Chadwick wrote:
> > > A possible counter-measure would be to add wiping features to the RAM
> > > modules themselves. When power is lost, the memory could wipe itself.
> > > Still
>
--- Pieter de Boer <[EMAIL PROTECTED]> wrote:
> Jeremy Chadwick wrote:
>
> > It's interesting that you classified this as a "feature" (in quotes),
> > because there's nothing "modern" about said "feature". This issue has
> > existed since the beginning of RAM chip engineering; I can even confir
Pieter de Boer wrote:
Atom Smasher wrote:
article below. does anyone know how this affects eli/geli?
from the geli man page: "detach - Detach the given providers, which
means remove the devfs entry and clear the keys from memory." does
that mean that geli properly wipes keys from RAM when a l
Jeremy, list, good day.
Sat, Feb 23, 2008 at 10:56:20AM -0800, Jeremy Chadwick wrote:
> > A possible counter-measure would be to add wiping features to the RAM
> > modules themselves. When power is lost, the memory could wipe itself. Still
> > not perfect, but would certainly help.
>
> Proper s
From: Mike Meyer <[EMAIL PROTECTED]>
Subject: Re: find -lname and -ilname implemented
Date: Sat, 23 Feb 2008 13:19:37 -0500
> On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" <[EMAIL PROTECTED]>
> wrote:
>
> > In message: <[EMAIL PROTECTED]>
> > Mike Meyer <[EMAIL PROTECTED]
Jeremy Chadwick wrote:
It's interesting that you classified this as a "feature" (in quotes),
because there's nothing "modern" about said "feature". This issue has
existed since the beginning of RAM chip engineering; I can even confirm
this "feature" exists on old video game consoles such as the
On Sat, Feb 23, 2008 at 07:40:53PM +0100, Pieter de Boer wrote:
> Atom Smasher wrote:
>> article below. does anyone know how this affects eli/geli?
>> from the geli man page: "detach - Detach the given providers, which means
>> remove the devfs entry and clear the keys from memory." does that mean
Atom Smasher wrote:
article below. does anyone know how this affects eli/geli?
from the geli man page: "detach - Detach the given providers, which
means remove the devfs entry and clear the keys from memory." does that
mean that geli properly wipes keys from RAM when a laptop is turned off?
On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" <[EMAIL PROTECTED]>
wrote:
> In message: <[EMAIL PROTECTED]>
> Mike Meyer <[EMAIL PROTECTED]> writes:
> : On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" <[EMAIL
> PROTECTED]> wrote:
> :
> : > Sorry to be lame and f
article below. does anyone know how this affects eli/geli?
from the geli man page: "detach - Detach the given providers, which means
remove the devfs entry and clear the keys from memory." does that mean
that geli properly wipes keys from RAM when a laptop is turned off?
--
...atom
In message: <[EMAIL PROTECTED]>
Mike Meyer <[EMAIL PROTECTED]> writes:
: On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" <[EMAIL PROTECTED]>
wrote:
:
: > Sorry to be lame and follow up to my original email, but Ruslan was
: > way too quick to give me feedback :-)
: >
: > I
On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" <[EMAIL PROTECTED]>
wrote:
> Sorry to be lame and follow up to my original email, but Ruslan was
> way too quick to give me feedback :-)
>
> I also did a few more of the really easy ones, and added a list of
> ones that we haven't impleme
On Thu, Feb 21, 2008 at 02:15:47PM -0800, Sam Leffler wrote:
> Michael W. Lucas wrote:
> >Feb 21 09:45:57 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0
> >Feb 21 09:47:34 stretchlimo kernel: ath0: ath_chan_set: unable to reset
> >channel 40 (5200 Mhz, flags 0x140 hal flags 0x140)
>
> Not go
34 matches
Mail list logo
