On Friday, Sep 26, 2003, at 13:29 US/Eastern, Terry Lambert wrote:
Which begs the question... is 5.2 going to ship with WITH_LIBMAP
enabled by default?
http://www.google.com/search?q=libmap+default+WITH_LIBMAP&ie=UTF-
8&oe=UTF-8
http://people.freebsd.org/~bmah/relnotes/CURRENT/relnotes-i386.txt
Hi,
In order to debug a minor problem with the ar-driver, I installed DP2
on an Abit KR7A-RAID with HighPoint ATA-RAID controller. The machine
contains two identical 40GB IBM drives as masters on each of the two
HighPoint IDE channels.
The issue I ran into was that the partition editor in s
ready have something that works this way.
> It's called "ant", if my memory from my early 2001 work with j2ee,
> doesn't fail me.
Almost. It's indeed called Ant but has been developed under the
umbrella of the Apache Jakarta project.
-J
--
Jeroen C. van Gelderen -
Umemoto-san,
May I ask what motivated this change?
-J
On Thursday, Jul 25, 2002, at 11:51 US/Eastern, Hajimu UMEMOTO wrote:
> Hi,
>
> I've just committed to change an IPv4-mapped IPv6 address off by
> default.
> The existing applications may be affected this change. The
> applications which d
I would expect that for the GCC 4.0 upgrade a similar freeze
request will go out. And that seems fair enough since it does not
prevent anyone from applying the actual code fixes. We want to make this
import stuff as easy on David as we can, no? It is a job from hell
already.
Cheers,
Jeroen
--
ding message just
like that. It turned out that /dev/random was not available
or not working properly.
Cheers,
Jeroen
--
Jeroen C. van Gelderen - [EMAIL PROTECTED]
"A government that robs Peter to pay Paul can always depend
upon the support of Paul." -- George Bernard Shaw
To Unsubsc
f any knowledge of reseed timings (or
lack thereof).
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_\_| \ _|/' \/
(_)>(_) (_)
>
> Yeah; that monotonically-increasing counter bothers me slightly.
Why? How would it affect security if one assumes the blockcipher
is secure?
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
at a high enough rate that
> this is not necessary.
What if you cannot guarantee that (and you cannot guarantee that
in practice)?
> I also agreed to _maybe_ look at a re-engineer of the "old" code in a
> secure way if a decent algorithm could be found (I am reading some
>
Brian Fundakowski Feldman wrote:
>
> On Mon, 24 Jul 2000, Jeroen C. van Gelderen wrote:
>
> > > > What I meant with that point is that the user may get, say an extra few
> > > > hundred bits out of it with no new entropy before the scheduled reseed
> > >
on on the practical issues
and explain why you think backing /dev/random with Yarrow and
changing the semantics is justifyable or even a good thing.
Cheers,
Jeroen
[1] And, should we decide not to change /dev/random semantics,
can we still back /dev/random with a modified Yarrow?
--
Jeroen
Kris Kennaway wrote:
>
> On Sun, 23 Jul 2000, Jeroen C. van Gelderen wrote:
>
> > > Well, a simple scheme which doesn't seem to suffer from any of the
> > > vulnerabilities discussed in the schneier papers is to accumulate entropy
> > > in a pool, and
hronously
> with respect to PRNG output).
Reseeds do not *have* to happen asynchronously as pointed out
above. What is of importance is that you *cannot* forcibly
trigger a reseed without there being enough entropy in the
poo
events you from adapting Yarrow so that current
/dev/random semantics are preserved, making Yarrow even
better. It can be done with the current design it's just
not very beneficial to do it.
5. Yarrow was designed as a better replacement for most any
PRNG by a couple of bright
Kris Kennaway wrote:
>
> On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:
>
> > You don't care in practice, 256 bits are unguessable.
>
> Actually, I do..that's the entire point of using long keys.
I agree that you need long RSA keys ... but the real
di
by saving the complete state, as opposed to
> an extract.
Well, academic or not (not when you run financial transactioning
systems on FreeBSD) you can edit rc.shutdown to not write out a
seed file. You don't have to use it but it's good that it's there
doesn't change the fact that Yarrow-256 is only good for 256 bits
> of entropy between reseeding operations. You can pull all you want out of
> it but will never get more than 256 bits until it reseeds.
You don't care in practice, 256 bits are unguessable.
If you do care, you load
art using it. Your
co-worker reboots your machine afterwards and recovers
the PRNG state that happens to be stashed on disk. He
can then backtrack and potentially recover the exact same
random numbers that you used for your key.
Cheers,
Jeroen
--
Jeroen C. van Geldere
ng. And read your PGP mail for the coming couple
of years because your PGP key was compromised without you
noticing. Perfect Trojan horse to write for the FBI, IRS,
anyone who doesn't like you. Oops.
Cheers,
Jeroen
--
Jero
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, "Jeroen C. van Gelderen" writes:
>
> >> People have tried for 30+ years to predict what a quartz xtal
> >> will do next. Nobody expects any chance of success. Add to this
> >> th
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, "Jeroen C. van Gelderen" writes
> :
>
> >> Predicting the clock's offset from reality and the two way path to
> >> the server of choice is impossible, plus if people enable authenti
to quantify all this to make a good entropy estimate.
Just implementing this functionality because 'predicting the
clock's offset [...] is impossible' is pretty pointless.
Cheers,
Jeroen
[1] And then, what's the effect of an attacker sniffing your
LAN? What info
tify 'impossible'.
> We need an enterprising soul to add an option (default on) to
> ntpdate to write the received packets in toto to /dev/random
> if it exists.
I think we first need to figure out t
and an attacker laughingly sniffing those bits.
I think you forgot a ';-p'
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_\_| \ _|/' \/
e with this algorithm.
>
> On the other hand, didn't you say that at system boot the RNG is
> essentially unseeded, so this is actually a liability because processes
> cannot be sure they're getting real randomness.
/dev/random should block until it has seeded. If it doe
m except that it has been broken
for a while whilst MarkM brought it up to snuff. The mailing
list archives ought to contain all of the details one needs
to fix this temporary problem. No need to resort to EGD, just
tweak some config.
Cheers,
Jeroen
--
Jeroen C. van Gelderen
updating to a more recent -CURRENT, that should help.
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_\_| \ _|/' \/
(_)>(_) (_)
lity
randomness is broken. This includes SSH, PGP, GnuPG,
Apache/SSL random pid generation and what not. No, upgrading
is not fine at all.
Cheers,
Jeroen
--
Jeroen C. van
Kris Kennaway wrote:
>
> On Sat, 10 Jun 2000, Jeroen C. van Gelderen wrote:
>
> > > Actually, it's not of course a security risk in the new algorithm (this is
> > > mktemp() after all), but it's a potential failure mode which can cause
> > > applic
to fail in ways they otherwise wouldn't (with some very low
> probability) on a normal system. But, I don't think it's a big enough
> problem to worry about (numbers still coming :-)
It's not a new situation, any application that can write to /tmp ca
Peter Wemm wrote:
>
> Christopher Masto wrote:
> > On Fri, Jun 09, 2000 at 01:14:35PM -0400, Jeroen C. van Gelderen wrote:
> > > I'm not sure it is a good idea to name this variable VMWare as
> > > that is implementation specific. It may be better to have a
-say- Microsoft tends to think.
It's probably better to just get rid of the PID and use randomness
troughout the name than to use 72 characters. 64^6 vs. 2*(72^3) .
Cheers,
Jeroen
--
will get collisions which you will have to deal with. I am not
familiar with the code but if we can handle collisions nicely then that
would be the way to go: 64^6 = 2^36 possibilities which is nice...
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTE
It may be better to have a var
named 'emulation' set to 'none' or 'vmware' or 'bochs' or ...
Just my EC 0.02,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_&
:-). Much better is to use something
> cheaper like time-of-day XOR 1 << whatever.
Pseudo random numbers are so cheap (or they should be) that you
just don't want to try and 'optimize' here. It is much better to
be conservative and use a good PRNG until it *proves* t
Mark Murray wrote:
>
> > > > I want to commit a new /dev/random RSN, so I'll be needing a major
> > > > device; what is the procedure for getting one? I know how to steal one,
> > > > but ISTR that this is not how it is done.
> > >
> > > Just edit sys/conf/majors and claim the next available numb
Bruce Evans wrote:
>
> On Mon, 8 May 2000, David O'Brien wrote:
>
> > On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote:
> > > Or just settle for a more intuitive solution:
> > > MAKEDEV acd2 creates /dev/acd2
> > > MAKEDE
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, "David O'Brien" writes:
> >On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote:
> >> Or just settle for a more intuitive solution:
> >> MAKEDEV acd2 creates
David O'Brien wrote:
>
> On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote:
> > Or just settle for a more intuitive solution:
> > MAKEDEV acd2 creates /dev/acd2
> > MAKEDEV 2 acd creates /dev/acd[01]
> > which would allow for "MAK
[CC culled, -stable removed]
David O'Brien wrote:
>
> On Sun, May 07, 2000 at 04:59:46PM +0200, Jeroen Ruigrok van der Werven wrote:
> > Can we settle this once and for all in a slightly sane manner?
> >
> > I committed the change so that MAKEDEV acd1 creates acd1 and not just
> > acd0.
>
> Thi
Richard Wackerbarth wrote:
>
> On Mon, 24 Apr 2000, Matthew Dillon wrote:
> > : However, I consider your SMP changes VERY destablizing; they BREAK
> > : lots of modules :-(
> >
> > Huh? No they don't. They simply require recompiling the modules. If
> > they actually broke the modules I
Brad Knowles wrote:
>
> At 11:59 AM -0400 2000/4/3, Jeroen C. van Gelderen wrote:
>
> > PERL is not just used by the FreeBSD system, it's also used by many
> > applications ran on top of FreeBSD. Those applications are more likely
> > to require an up-to-date
Nick Hibma wrote:
> Are there actually any good reasons why we _should_ upgrade in the first
> place? Security fixes, added functionality we require, etc. The perl we
> have is stable and the problems it has are well known, which is good
> enough in 99% of the cases.
PERL is not just used by the
7;s patented in Japan and USA too, basically
a useless algorithm as there are better free replacements available.
(Especially by the time the patent expires.)
Cheers,
Jeroen
--
Jeroen C. van Gelderen - [EMAIL PROTECTED]
Interesting read: http://www.vcnet.com/bms/ JLF
To Unsubscribe: send m
ric solution that still allows for holes. Not possible because
of compatibility issues? I'm willing to give it a go.
Cheers,
Jeroen
--
Jeroen C. van Gelderen - [EMAIL PROTECTED]
Interesting read: http://www.vcnet.com/bms/ JLF
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
suspends don't seem to work
yet, but that can be pilot error as well...
Cheers,
Jeroen
--
Jeroen C. van Gelderen - [EMAIL PROTECTED]
Interesting read: http://www.vcnet.com/bms/ JLF
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
application become
> aware that the sysctl space has changed?
I seem to recall that John Poltstra was working on a notification
system (for use with CVSup) that would allow you to subscribe to
certain change events...
Cheers,
Jeroen
--
Jeroen C. van Gelderen - [EMAIL PROTECTED]
Interesting
e person with this
> problem.
I had to boot a kernel and /dev off a floppy to fix the /dev.
Cheers,
Jeroen
--
Jeroen C. van Gelderen - [EMAIL PROTECTED]
Interesting read: http://www.vcnet.com/bms/ JLF
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
From:
"Jeroen C. van Gelderen" <[EMAIL PROTECTED]>
14:33
Subject:
Re: Mount problems after lockup
To:
Poul-Henning Kamp <[EMAIL PROTECTED]>
P
0
0
/dev/ccd0c /mnt/ccd0 ufs rw 0
2
/dev/wd2s1e /mnt/wd2ufs rw 0
2
/dev/wd3s1e /mnt/wd3ufs rw,sync 0
2
proc /proc procfs rw
to update include files to build several inpcb
> aware tools and applications. (fstat, netstat, systat, etc)
Thanks!
Cheers,
Jeroen
--
Jeroen C. van Gelderen - [EMAIL PROTECTED]
Interesting read: http://www.vcnet.com/bms/ JLF
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
cussion until spam becomes a
real problem on this list? So far this thread has generated more noise
than all spam that slipped trough to the list in the past year. Jonathan
is doing an awful job, please give him credit for stopping the vast
majority of spam messages and let this thread die.
Chee
Hi,
I seem to remember someone requesting cryptfs. It's available outside
the US on my webserver:
http://wit395301.student.utwente.nl/~gelderen/fist/. It will go to
replay soon.
Cheers,
Jeroen
--
Jeroen C. van Gelderen - gelde...@mediaport.org - 0xC33EDFDE
To Unsubscribe: send mail to m
sed to see a Postfix port. Not having to deal with
Sendmail would render FreeBSD more usable for non-die-hard users.
Cheers,
Jeroen
--
Jeroen C. van Gelderen - gelde...@mediaport.org - 0xC33EDFDE
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
e worked for the ports tree as well.
Another advantage of the flat model is that it's way easier to browse. IMHO
it's a real pain to have descend into subdirectories, only to find out that
you want to look in another one.
Cheers,
Jeroen
--
Jeroen C. van Gelderen -- gelde...@mediaport.org -- 0x46D8D3C8 -- &[8-D}~<=
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Hi,
Might it be a good idea to choose a consistent naming scheme for the
modules? I'd think so because it would help blind loading at the boot
prompt. If you choose names it the following format:
type_name
saver_warp
saver_daemon
the modules of one type will sort together in a directory listing.
ions)
4096MB (8388608 512 byte sectors: 255H 63S/T 522C)
A combination of these ideas might do. Basically you want to get rid of the
warnings when there's nothing wrong with the hardware.
DISCLAIMER: I don't know much about CAM so please don't shoot me if this is
nonsense...
Cheer
57 matches
Mail list logo
