69400+ entries in 0.039s
ave1: I know, it was more a description of how my memory was playing
tricks on me
ave1: asciilifeform, I was looking for mux just now in ffa just now and I came by
the add_gated which uses a different method,.
ave1: and for
the
table lookup, it's
the
the
table access part
that's not constant
time? (lookup(0) might
take different
time
than loop(255))?
ave1: asciilifeform, well bits are being checked
to be able
to determine if xor div is needed
ave1: the div variant could be made
to be constant
time using
the ffa primitives but currently is not.
diana_coman: ave1,
thank you, I'll look
through it in more detail a bit later
today
a111: Logged on 2018-10-12 09:41 diana_coman:
there is also
the bit-keccak in eucrypt and
that is
the same really - reference code rather
than production code
a111: Logged on 2018-10-12 09:00 mircea_popescu:
there's absolutely no excuse for having "urandom" as a kernel signal. applications
that both a) care about entropy debit over
time and b) can get away with substituting shit for entropy should simply manage
their entropy/shitropy interface in a dedicated
thread. let it read from /dev/random, add however many bits of 11110000
they want whenever
they want
to and vomit
the resulting cesspool as
the app
that spawned
them demands.
a111: Logged on 2018-10-12 08:40 mircea_popescu:
this creates a flow issue ?
ave1: diana_coman, I'll add my
test and fix
the
typo and regrind
diana_coman: you might want perhaps
to add a call + check
to it in
the
tests
too?
diana_coman: typo in manifest "emplementation" -> implementation ; but one can live with
that
diana_coman: keeping it separate certainly makes sense (so
that it's not a mandatory piece in
there) but if it's code it's still basically under V
that it belongs
diana_coman: there is also
the bit-keccak in eucrypt and
that is
the same really - reference code rather
than production code
☟︎ ave1: I'll make it a vpatch later
today...
ave1: well mostly because I see
this more as reference code (this is how it can be done with division) and less so as production code (the
table driven works very well for
that)
☟︎ diana_coman: ave1, at any rate, <pre>
tags added, looks good
diana_coman: ave1, why not add it as a .vpatch on
the eucrypt
tree?
mircea_popescu: there's absolutely no excuse for having "urandom" as a kernel signal. applications
that both a) care about entropy debit over
time and b) can get away with substituting shit for entropy should simply manage
their entropy/shitropy interface in a dedicated
thread. let it read from /dev/random, add however many bits of 11110000
they want whenever
they want
to and vomit
the resulting cesspool as
the app
that spawned
them demands.
☟︎ mircea_popescu: there shall be ONE random. and if
there isn't one,
throw
the shirt iron out with
the garbage. and if
there's "two",
throw
the "engineer" responsible out with
the garbage.
mircea_popescu: (but, importantly, /dev/random === /dev/urandom is a fundamental ideological patch. fuck
the fucking idiocy!)
mircea_popescu: i'm naively assuming it wouldn't, but in fairness haven't actually looked into
the gnarl.
ave1: now, I'll have
to check
mircea_popescu: i don't get it. you have one (kernel) reading from
tty putting it into /dev/?random ; and however many apps reading from
there as now.
ave1: no,
that you have multiple concurrent applications all reading from
the
tty at
the same
time. Some kind of intermediate is needed
to divide
the bytes.
ave1: the wrappers read directly from
the
tty and work one processor at
the
time.
☟︎ a111: Logged on 2018-10-11 19:59 phf: but it also seems
that before
that becomes reality we either have
to patch linux kernel or implement a rng daemon or somesuch
a111: Logged on 2018-10-11 19:36 phf: asciilifeform: nah, you want a random seed always, because you're
trying
to avoid race by producing a least likely collision.
the race will always exist between existance check and initial creation
a111: Logged on 2018-10-11 19:34 asciilifeform: phf, bvt : i
thought of a possible algo for sane
tmp file creation
that dun need rng or global counter. 1) pick a file name in
tmp dir, if none exists,
take empty string, as string S 2) produce S' = H(S) , H is hash (e.g. keccak) 3) stat(S') ; if already exists,
take S'' = H(S') and repeat .
a111: Logged on 2018-10-11 17:08 asciilifeform: draws 400mW in reflector mode (~1/5 of what colour panel of
that weight class eats) .
trinque: phf: appears
to have worked; give it a shot
mod6: TomServo:
This weather is getting ole mod6 down.
bvt: i will have a look at what primitives i need for
the implementation
today and
tomorrow, and will come back here if i get stuck on something.
phf: asciilifeform: so
the posix solution is
to call open with O_CREAT | O_EXCL, which will attempt
to create but will signal EEXIST if
the file already exists. curiously default behavior O_CREAT will simply clobber
☟︎ phf: tmp file gets created when you have any sort of patching operation, gets cleaned up when you no longer need it. but you could conceivably have it for
the duration of
the runtime. (except instead of doing file move at
the end of a single file patch, you do file copy)
phf: bvt:
that doesn't contradict what i said
bvt: uhm, strace shows me here
that
the
temporary filename changes
phf: you're probably right
though,
the
temp_file_name interface needs
to be replaced with open_temp_file
phf: asciilifeform: oh yeah it is, hash a bunch of random stuff, check for collision.
that's
the pragmatic solution. i'm
talking about
the
take aways
phf: but it also seems
that before
that becomes reality we either have
to patch linux kernel or implement a rng daemon or somesuch
☟︎ phf: asciilifeform: i believe
that was
the real conclusion of yesterday's conversation: you want easy access
to a real rng from any republican process at any
time, and
that makes a lot of idiotic problems go away
phf: bvt: as of right now
there's only one
temporary file at a
time during a vpatch run, so you're essentially in
the same situation
temp file name or
temp directory anme
bvt: perhaps better way would be
to create a
temporary directory (for which
there is atomic create-or-die) at
the vpatch start, and place all
temporary files
there?
phf: asciilifeform: counters exhibit exactly
the same problem as a non-random seed
bvt: and i'm don't know yet if files created
this way can be mv'ed
to file system
phf: asciilifeform: well,
temp_file_name makes a
temporary _name_, if you're relying on an atomic create,
then you need
to change
the interface, where you
try and create a
temp file, and
then bail. in
that case
though you don't even need any randomness. just use a counter
bvt: there is a recent linux O_TMPFILE flag
to open(2), but i'm not sure we want
to use
that
bvt: right, Ada.Directories.Exists was
the missing piece.
phf: asciilifeform: nah, you want a random seed always, because you're
trying
to avoid race by producing a least likely collision.
the race will always exist between existance check and initial creation
☟︎ phf: bvt:
this doesn't need much C, it's a loop with a
termination condition of not Ada.Directories.Exists(Filename), and
the
tricky part is
the construction of said Filename. it could be a Prefix ("vpatch.") + keccak hash(salt + pid +
time + ???).
bvt: i will give it a
try. i'm still learning ada, will have
to
take a look at how strings and interfacing with C are done properly.
phf: bvt: you know you could
take a stab at proper
temp_file_name :> it'll have
to be written anyway,
to fix
this bug. i suspect by
the
time someone else runs into
this issue, a replacement will already be available.
phf: i've used a variety, including
the
two you mentioned. ave1's, adacore 2016 and 2018 on linux and mac
bvt: did you use ave1's gnat or
the adacore-provided distro? My understanding is
that it should work with both,
taking 2 different code paths, and fail only with gnat17.
phf: well, it's also a reason why bug wasn't caught in development. a sequence of wtfs: linux man page says mktemp should be 3 or more X's, so project builds on a non-musl build. meanwhile POSIX mandates
there
to be exactly 6 X's, so a musl build fails
to produce a random string, returning instead a blank one, which is when gnat decides
to not only generate a
temp file but also do cleanup.
bvt: that was a wtf moment for me, i'm not used
to such service from
the runtime
phf: i like
that ada will create a
temp file for you and
then clean it up on empty string,
though
that's a bit
too magical (the interface, not
the behavior)
bvt: I understand
this, but still it's better
to drop
the vpatch, at least in
the logs, in case someone else stumbles upon
this problem.
lobbesbot: phf: Sent 1 hour and 48 minutes ago: <asciilifeform> i recently found
that lcd panel made by (defunkt) 'pixelqi co', pq3qi-01 , is still sold by chinese ( i have nfi if clones, or old stock ), ~100 $ ea;
the
thing
toggles from 1024x600 colour/backlit into a 3072x600 greyscale reflector
thing, worx with various lappies ( sadly not x60, it's a 16:9 )
phf: bvt: i
think
the conclusion of yesterday's
thread was
that using mktemp is a bad idea, and
that it's better
to rewrite
temp_file_name
to be self contained, i.e. get rid of mktemp pragma and have
temp_file_name do its own random string/stat loop
bvt: Apparently
those addresses are used as 'poor man's RNG'