log
▁▁▁▁▁▁⏐
BingoBoingo: With the apartment key scheduled to monday and the friend girl gone, this could be a very stressful period of time for the Peruana
ben_vulpes: how's that?
asciilifeform: mircea_popescu: the 2nd key ( http://phuctor.nosuchlabs.com/gpgkey/620344B54A5B77C0D59A9A430097097B0A13758B9902F0593BBF0C7929F4F857 ) stood. i therefore suspect that i did not make any mistake in conversion.
asciilifeform: mircea_popescu: it remains to be determined exactly how to go about signing with a key that doesn't have a mult inv. i suspect that in this puzzler also lies the answer to how the infamous 'mirrored' mods were fired in the field.
asciilifeform: ( and whether this actually requires finding ~all~ of the prime factors , or not )
mircea_popescu: as an obvious possibly : there's some error that creates a functional inverse out of an unrelated numbar.
asciilifeform: aha
mircea_popescu: this would then equally afflict phuctored and unphuctored key
mircea_popescu: "hey guys, did you know your key has mathematically unsound but computably useful pseudoinverse ?"
asciilifeform: it'd afflict 'soup instead of primes' keys as a class
mircea_popescu: conceivably, all keys.
mircea_popescu: ben_vulpes cuz he plans of fucking her in all holes at once 24/7.
mircea_popescu: he's got tentaclepeni.
mircea_popescu: BingoBoingo btw, did you have the common decency of introducing them ?
BingoBoingo: <mircea_popescu> BingoBoingo btw, did you have the common decency of introducing them ? << Was scheduled for next week
mircea_popescu: maybe she ran away then!
BingoBoingo: The venezolana has a special friend she ran away to Uruguay with. She lives with the friend's family and the two girls share a bed.
mircea_popescu: that sounds sweet.
BingoBoingo: And the Peruana absolutely adores me and does bed and bathroom well, but... she can be very boring
BingoBoingo: From what I understand the Venezolana's special friend is staying here for the duration.
asciilifeform: mircea_popescu: in other twists, not only is neither key in the cr50 fw image i have, but the verification routine does not correspond to the 'open' sores.
asciilifeform: ( mega-surprise )
BingoBoingo: Blog the details. It's friday night. Two and a half days to SEO it
asciilifeform: BingoBoingo: details will take a while to pry out.
BingoBoingo: This feeds, what is commonly called a series. Sometimes they go exciting places... Sometimes they don't
BingoBoingo has doubts the venezolana is running away for keeps, because she keeps asking how alf is doing
asciilifeform: lolwaat
BingoBoingo: Girl thinks alf is a cool dood and does interestin work
mod6: :]
BingoBoingo: brb
mod6: k
mircea_popescu: haha. they all think this before they meet him :D
asciilifeform: so, meanwhile : finds : key id's seen in http://www.loper-os.org/pub/c101pa/c101pa_unlock_nodice.txt , lead to pay dirt,
asciilifeform: 1) the pubs thrown earlier in phuctor ( seen in e.g. https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_v3.4/chip/g/loader/verify.c#17 ) dun appear anywhere in fw 3.4
asciilifeform: 2) the RW key, corresponding to 'RW keyid: 0xde88588d(prod)' , appears , and is identical to what lives in https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_v3.4/util/signer/cr50_RW-prod.pem.pub
asciilifeform: http://p.bvulpes.com/pastes/t16fl/?raw=true << dump of RW key
asciilifeform: this in turn , is found in 4 places in the rom , http://p.bvulpes.com/pastes/dqhNR/?raw=true ( labels mine , offsets preserved )
asciilifeform: ( there's a rw and ro piece in each of the 2 redundant sections of the rom , and each contains a copy of rw key -- why? ask'em, not me )
asciilifeform: however, after this, gets moar interesting:
asciilifeform: http://p.bvulpes.com/pastes/corod/?raw=true << the RO pubkey. (labels mine, offsets original). does not appear to be posted publicly anywhere.
asciilifeform: stored in presumably same bass-ackwards form as the RW.
asciilifeform: the last bit of wtf, is that there dun appear to be anyffing corresponding to the published loader
asciilifeform: in particular, the '0xcafebabe' magicturd in https://github.com/coreboot/chrome-ec/blob/b9f5a3d6baae84950f5ff0c4f7c588e55944818a/chip/g/loader/main.c#L102 , dun appear at all in the bin
asciilifeform: it remains possible that the loader crapola lives in some part of the rom that doesn't get updated and thereby not part of my bin image.
asciilifeform: in other lulz, https://github.com/coreboot/chrome-ec/blob/b9f5a3d6baae84950f5ff0c4f7c588e55944818a/chip/g/config_chip.h#L135 >>
asciilifeform: 'Note: early versions of the SoC would let us build and manually sign our own bootloaders, and the RW images could be self-signed. Production SoCs require officially-signed binary blobs to use for the RO bootloader(s), and the RW images that we build must be manually signed. So even though we generate RO firmware images, they may not be useful.'
asciilifeform: for today this'll be all.
asciilifeform: oh , for compleeetness, http://loper-os.org/pub/c101pa/cr50.bin.prod << the 0.3.4 cr50 fw currently installed in my box. ( the offsets above, are valid for it)
phf: the later is a guess though right, that it's currently installed?
asciilifeform: phf: nein, i flashed it in earlier, recall
asciilifeform: overwrote factory 0.3.3
phf: oh oh of course, you can still flash official ones in
asciilifeform: so as to get a known turd
phf slow
asciilifeform: https://github.com/coreboot/chrome-ec/blob/48d6891db8b5b2b0825136f6f9013a110b2a98da/util/signer/create_released_image.sh << moar re the layout of the fw. apologies for l0gz clutter.
phf: what's the executable substrate? i mean it's an fpga carrying its own architecture, what's it compiled with?
asciilifeform: phf: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_v3.4/chip/g/build.mk#10 << see
asciilifeform: ( spoiler : CFLAGS_CPU+=-march=armv7-m -mcpu=cortex-m3 )
asciilifeform: it's an arm7 m3 with a few custom i/o regs and some iron for crypto accel ( strictly hashing & symmetric , all else in soft )
asciilifeform bbl
phf: ty
mod6: i broke my trb blockchain.
mod6: thing was stuck, flooded with connections, not keeping up, wouldn't respond to any rpc calls. this going on for hours and hours. finally i just killed it. i probably instead should have just firewalled off 8333 instead.
mod6: anyway, now the db is corrupt.
mod6: will need to probably resync the whole thing.
mod6: this ip from the nodes list: 208.94.240.42
lobbes: ouch... I could see myself doing the same thing
mod6: yeah, ensure that if something like this happens to you, you do not kill it -- instead firewall it off. wait until all connections drop.
mod6: i think i'm just gonna cutblock all the blk*.dat files, and eatblock 'em.
mod6: should take 10 days.
lobbes makes a literal note
mod6: i'll probably just turn all of this into a blog post.
mircea_popescu: mod6 nah, listen, do you have an index saved ?
mircea_popescu: just reinstate the old index, have it check the chain. odds are it'll be able to recover, because it doesn't so much care about data ~past~ its index point.
mod6: i have a backed up index, but its from long ago.
mircea_popescu: meanwhile in the basement, https://78.media.tumblr.com/df0b4f8fa317c5110325b4496d0a7dee/tumblr_o6gtpxaWH61rhup7qo1_540.gif
mircea_popescu: mod6 backups are your friend! this whole trb stuff is a little friable.
mod6: anyway, will try it. (it's from january)
mircea_popescu: then maybe not worth it, likely will take more than 10 days to sync
mod6: ah. perhaps ya.
mod6: but backing up the chain is a good idea. i actually have backups more recent than that, but from other trbs, not this specific one.
mircea_popescu: ah. yeah, i mean weekly rotation, monthly, something.
mod6: *nod*, lesson learned.
lobbes: http://btcbase.org/log/2018-06-22#1828740 << so I figured it out: cause of downtime ended up being a flood of tor exit nodes >> http://p.bvulpes.com/pastes/VYVGW/?raw=true ☝︎
a111: Logged on 2018-06-22 16:14 lobbes: http://btcbase.org/log/2018-06-21#1828477 << ack, ty for letting me know. I'll try sshing in tonight to rule out webserver failure before I flag down BB to check out the situation manually. (I must say, it is a good feeling knowing that nowhere in this troubleshooting cycle will I need to interface with orcs.)
lobbes: snippet of access log for additional wtf >> http://p.bvulpes.com/pastes/DtslR/?raw=true
mircea_popescu: lobbes that's not overmuch by web standards. same one or diff ones ?
mircea_popescu: ah, crapolade trying to spam. shouldn't really bring mp-wp down afaik.
mircea_popescu: of course... this is the rockchip ?
lobbes: word, well that is good to know at least.I tried to deny a shitload of em via virtualhosts.conf. Blog is back up for now, but I half-expect it to be down again by morning
lobbes: yeah, rockchip
lobbes: and to boot, I tried setting up some rules in iptables, but it barfs claiming it is missing 'insmod' module or somesuch
lobbes: in other words, iptables currently unavailable until I figure out more of arm64 peculiarities
mircea_popescu: the thing is very stringently optimized to waste as little as possible on the spammer wanna-bes, but then again i never tried it on an arm.
mircea_popescu: i could say "trilema runs like that ~70% of the time", but then again trilema's got a larger box. pretty sure you can set it up though so it rejects multiple conns like that. there's a setting somewhere to limit inbound.
lobbes: hm, yeah, looks like there is mod_limitipconn but the arm64 support looks dismal >> https://packages.gentoo.org/packages/www-apache/mod_limitipconn
mircea_popescu: mod_whateverthefuck the common one also can do it for you. and also csf or w/e you use to manage the firewall.
mircea_popescu: in principle saying something like "no more than x connection from a given ip will be entertained" is perfectly reasonable ; though careful how low you set the x, some browsers (especially the mobile versions dedicated to fucking as much battery as possible) can turn a pageload into 10-20 simultaneous requests.
mircea_popescu: meanwhile poolside, https://78.media.tumblr.com/3f6248c3f0a886611472762ba6bf4bbb/tumblr_inline_p1onsoyrKB1vpaf4h_500.gif
asciilifeform: http://btcbase.org/log/2018-06-23#1829030 << hey mod6 is this the same box as in the last coupla similar threads, with the questionable hdd ? ☝︎
a111: Logged on 2018-06-23 04:30 mod6: thing was stuck, flooded with connections, not keeping up, wouldn't respond to any rpc calls. this going on for hours and hours. finally i just killed it. i probably instead should have just firewalled off 8333 instead.
asciilifeform: http://btcbase.org/log/2018-06-23#1829041 << mircea_popescu has it , index is the only piece that actually bitrots ( bdb was written by the maliciously retarded ) ☝︎
a111: Logged on 2018-06-23 04:45 mircea_popescu: just reinstate the old index, have it check the chain. odds are it'll be able to recover, because it doesn't so much care about data ~past~ its index point.
asciilifeform: fwiw asciilifeform has not suffered this problem in many yrs, for box on uninterruptible power ( and resist the temptation to fiddle! no it ain't 'stuck', it stands up again by itself in coupla hrs ) -- no bitrot
asciilifeform: unless dying hdd, etc, all bets off then.
asciilifeform: http://btcbase.org/log/2018-06-23#1829051 << lobbes didja determine what proggy (e.g. apache?) it was that actually fell down ? ☝︎
a111: Logged on 2018-06-23 05:10 lobbes: http://btcbase.org/log/2018-06-22#1828740 << so I figured it out: cause of downtime ended up being a flood of tor exit nodes >> http://p.bvulpes.com/pastes/VYVGW/?raw=true
asciilifeform: meanwhile, for fyootoor ref, http://btcbase.org/log/2018-06-23#1829003 >>>> http://phuctor.nosuchlabs.com/gpgkey/2F5EC26698365939D499561F385A39A4217604DEB38913D71AFD135B28009DAF ☝︎
a111: Logged on 2018-06-23 02:09 asciilifeform: http://p.bvulpes.com/pastes/t16fl/?raw=true << dump of RW key
mircea_popescu: asciilifeform same here, lotta problems in 2012ish but meanwhile fuzzed out the weird, learned like ox, by trying.
asciilifeform: mircea_popescu: for comparison : the last time i reset 'zoolag' was to change ps. and the time before that -- to swap in the 'aggression' build
mircea_popescu: aha
asciilifeform: thing has roughly same uptime as its upstream isp.
mircea_popescu: meanwhile in true romance, https://78.media.tumblr.com/026a35dd07d2f0e4b08676f607ad9f52/tumblr_nconfxDv7X1rzv0kmo1_400.gif
asciilifeform: !Q later tell phf http://btcbase.org/log/2018-06-22#1828933 >> http://btcbase.org/log/2018-06-23#1829007 >> https://github.com/coreboot/chrome-ec/blob/master/chip/g/signed_header.h >>>>> http://www.loper-os.org/pub/c101pa/ro_signature.txt ( not the only 1, but illustrative ) ☝︎☝︎
a111: Logged on 2018-06-22 22:35 asciilifeform: if nobody finds obvious mistake, i guess i'ma have to pull an actual enemy signature out of the binariola, and see wtf
a111: Logged on 2018-06-23 02:18 asciilifeform: http://p.bvulpes.com/pastes/corod/?raw=true << the RO pubkey. (labels mine, offsets original). does not appear to be posted publicly anywhere.
lobbesbot: asciilifeform: The operation succeeded.
mod6: <+asciilifeform> http://btcbase.org/log/2018-06-23#1829030 << hey mod6 is this the same box as in the last coupla similar threads, with the questionable hdd ? << yup, same item. will post more about it later for sure. ☝︎
a111: Logged on 2018-06-23 04:30 mod6: thing was stuck, flooded with connections, not keeping up, wouldn't respond to any rpc calls. this going on for hours and hours. finally i just killed it. i probably instead should have just firewalled off 8333 instead.
asciilifeform takes break, lets the red hot barrels cool...
asciilifeform: mod6: by all indications you have a box with iron problem. in your place i'd get a fresh set of iron, rather than sinking sweat into interpreting randomly flipped bits as 'bug'
asciilifeform: !Q later tell phf other interesting observations: 1) loader is not the same as what appears in the src, in either 3.3 or 3.4 fw bin; not only key differs, but eggog strings, and possibly the rsa per se. 2) seems like : nowhere else in the fw is there any other routine which checksums/rsaverifies the cr50 fw , or references the rsa keyz at all other than to print keyid .
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: summary : google set up what is likely a deliberate bullshit dangle re the loader src; for reasons that are yet unclear
asciilifeform: not a terribly high quality dangle, took roughly a day to uncover.
mircea_popescu: google would lie ?!
asciilifeform: never!111
mircea_popescu: this comes as such a shock to absolutely nobody.
asciilifeform: the only even mild surprise is the sheer pile of echafaudage
mircea_popescu: well, the cloud of oricsh morons a la amstan are an expensive luxury.
mircea_popescu: useless, it is true. but expensive nevertheleess.
asciilifeform: pretty great lolcow, btw, that d00d. spilled what he thought was a carefully incomplete pile of beans to 'get asciilifeform to waste months making debug cable', i suspect, didn't quite expect us to get a working one in 1wk
asciilifeform: since his monumental 'nobody has the keys!' gem, all i saw of him was that 1 time he popped in here and drooled for coupla min.
mircea_popescu: eh. from a statistical perspective, it can't be said we don't get enough tards talking, so...
asciilifeform: btw i did figure out the http://btcbase.org/log/2018-06-22#1828757 matter -- their key format reserves 1st 4bytes for 'keyid' . but the lulzimplementation pictured in the (useless, doesn't seem to occur in the bin) published 'loader', treats the key as starting there . as i currently understand, couldn't actually work as written, barring some mathematical curio ☝︎
a111: Logged on 2018-06-22 18:17 asciilifeform: static const uint32_t LOADERKEY_A[RSA_NUM_WORDS + 1] = { ...blah... } where #define RSA_NUM_WORDS 96 ...
asciilifeform: http://btcbase.org/log/2018-06-22#1828901 << this kind of thing was a multi-week headache for asciilifeform the last time he had to actually uncork the launch codes and move coin; and i expect that it will only ever get worse ☝︎
a111: Logged on 2018-06-22 21:55 ben_vulpes: next thing i'm going to try is manually walk the spend-to-self down by 100 satoshis until this trb shits a tx out and then look at what it produces
asciilifeform: possibly the 2nd dumbest thing shitoshi did, after the mining algo -- the coin fragging nonsense.
ben_vulpes: would it be sensible for the send* commands to eat a changeaddress argument?
asciilifeform: ben_vulpes: absolutely, this has been a sore spot of asciilifeform's since day1
mircea_popescu: yes.
asciilifeform: http://btcbase.org/log/2016-03-16#1434267 << see also oldthread ☝︎
a111: Logged on 2016-03-16 15:42 mircea_popescu: both the "shittier than historical" and "new addr for change" bits are satoshi's dubious kludges to protect "anonimity"
BingoBoingo: In miscellani-lulz: "The Serbian football association says it will demand that FIFA take action against Granit Xhaka and Xherdan Shaqiri for their eagle salute goal celebrations in Switzerland’s 2-1 World Cup win in Kaliningrad on Friday. Shaqiri and Xhaka, both of whom were born in Kosovo and are of Albanian descent, celebrated their goals in Switzerland’s comeback win by making an eagle salute in apparent reference to the Alban
BingoBoingo: ian flag." << Apparently the whole swiss team is Albanian or Bosnian
deedbot: http://qntra.net/2018/06/austria-threatens-border-controls-against-increasingly-isolated-germany/ << Qntra - Austria Threatens Border Controls Against Increasingly Isolated Germany
phf: asciilifeform: https://www.youtube.com/watch?v=SPu8iRwZBZU
lobbesbot: phf: Sent 3 hours and 6 minutes ago: <asciilifeform> http://btcbase.org/log/2018-06-22#1828933 >> http://btcbase.org/log/2018-06-23#1829007 >> https://github.com/coreboot/chrome-ec/blob/master/chip/g/signed_header.h >>>>> http://www.loper-os.org/pub/c101pa/ro_signature.txt ( not the only 1, but illustrative )
lobbesbot: phf: Sent 2 hours and 54 minutes ago: <asciilifeform> other interesting observations: 1) loader is not the same as what appears in the src, in either 3.3 or 3.4 fw bin; not only key differs, but eggog strings, and possibly the rsa per se. 2) seems like : nowhere else in the fw is there any other routine which checksums/rsaverifies the cr50 fw , or references the rsa keyz at all other than to print keyid .
mircea_popescu: you dare speak in #trilema ?! here's eight lines of stuff from the logs!
asciilifeform: lol!
phf: "have you been reading your log? but in case you haven't here's some more log in your log"
mircea_popescu: exactly!
asciilifeform was aiming to nail down from what derives what, rather than flooding phf, lel
asciilifeform: the other interesting bit ( from asciilifeform's disasm of the 3.4 fw) is that there doesn't seem to be any pinning of the keys! ( i.e. i can't currently find any reason why it wouldn't eat a rw-fw update signed with a variant key, so long as said key is stuffed in where expected)
asciilifeform: nao this is imho hard to swallow ('submarine with screen door') and so currently i'm assuming that i simply missed something. will have to test, at any rate.
phf: "beware of dog"? seems unlikely though..
BingoBoingo: I have become utterly unaccustomed to dogs being beasts to fear
ben_vulpes: http://btcbase.org/log/2018-06-23#1829108 << the alternative, which would be a smaller patch, is a "setchangeaddr" RPC function. i'm leery of changing the call signatures of sendfrom and sendmany, but doing so might be The Right Thing nevertheless ☝︎
a111: Logged on 2018-06-23 17:59 ben_vulpes: would it be sensible for the send* commands to eat a changeaddress argument?
asciilifeform: ben_vulpes: if changing the semantics, i recommend new names ( new commands )
asciilifeform: eliminate possibility of confusion with old , or reactor meltdown if new trb is plugged into a scriptolade harness meant for old, etc
asciilifeform: e.g. 'sendbtc to=<destaddr> change=<chgaddr> [from=<optionalfromaddr_0,optionalfromaddr_1,...,optionalfromaddr_n>]'
ben_vulpes: it would be much easier to make a sendmanywithchangeaddr than to rework both sendfrom and sendmany
asciilifeform: or some other name, but idea being that it must be 1) impossible to confuse it with old 2) keywords ~named~, no order dependency plox
ben_vulpes: yeah that fucking horror of ordered args
asciilifeform: srsly we have enuff pistols that fire from 2 ends. time for a normal one.
mircea_popescu: hehehe
asciilifeform: ben_vulpes: dun forget fee=<...>
ben_vulpes: aha
ben_vulpes: ty
asciilifeform: and not optionally, but errytime.
asciilifeform: upstack : http://btcbase.org/log/2018-06-23#1829075 << for the record , it withstood (not much surprise) phuctoring (incl. fermat etc) ☝︎
a111: Logged on 2018-06-23 14:46 asciilifeform: meanwhile, for fyootoor ref, http://btcbase.org/log/2018-06-23#1829003 >>>> http://phuctor.nosuchlabs.com/gpgkey/2F5EC26698365939D499561F385A39A4217604DEB38913D71AFD135B28009DAF
ben_vulpes: am i thick or does nothing in the rpc take named args already?
asciilifeform: not thick, this is so
ben_vulpes: how cool
asciilifeform: ben_vulpes: funnily enuff, ~this very item~ is how asciilifeform got mired in attempt to bolt a lisp onto trb
asciilifeform: 'this arg parser, with all of the eggog handlings/safeties already weighs 85% of lisp interpreter...'
ben_vulpes: noooooshit
asciilifeform: writing parsers in overflowsanddanglingpointers-lang is braindamaged.
ben_vulpes: sarcasm fails me in the face of cpp
asciilifeform: ( btw, this does not appear to be in the l0gz as-such, so asciilifeform will note : c was an evil thing from ~birth~. on machines so impoverished that 'c is necessary', oughta be writing in asm; on machines where not necessary -- well, obvious )
mircea_popescu: heh
ben_vulpes: !!up epony do you plan to register a key or what
deedbot: epony voiced for 30 minutes.
epony: don't know, I'll read on for now..
epony: devoice if you please, nothing to say on my end
ben_vulpes: epony: what do you perceive the cost of registering a key to be?
ben_vulpes: put another way, why *not* do it?
epony: because, why would I want to say anything before getting a feel of the tone of the conversation..
epony: put another way, ephemeral is nice
ben_vulpes: consider, one day, you find yourself inspired to say something, you then go to register a key first? and then conversation gets derailed with "oh ho, look who finally registered a key" or alternatively "oh ho, who are you now?"
ben_vulpes: chance favors the prepared keyring or what was it.
epony: I'll then say "just nobody" :-)
epony: It's fun playing mental experiments anyway
ben_vulpes: epony: still haven't digested the epsilon appetite for nobodies? not obvious in your 11 days reading?
epony: I cherry pick 1 line at a view.
epony: I think it's 9 days since I pop back in.
epony: Don't know where these 11 days come from...
ben_vulpes: http://btcbase.org/log/2018-06-12#1823667 ☝︎
a111: Logged on 2018-06-12 06:20 mircea_popescu: !!up epony
epony: :)
ben_vulpes: assuming that epony is this epony
epony: same
epony: so, idling 12-15 and out... back in 9 days...
ben_vulpes: dun dun dun
asciilifeform: this reminds me, not long ago asciilifeform picked up a little chinese toy, item shaped like tennis raquet but the wires are charged to 4000v and connect to (small) cap; a sort of mechanized fly swatter, they pop, little blue plasma burst, vapour. nominally. so then , having used it, later i see a most peculiar insect, did not immediately realize what it is, never having seen before. looked closely, turns out -- fly head + front legs
asciilifeform: , still waking along, mostly torso-less and wingless...
asciilifeform: *walking
asciilifeform: mm pretty satisfying, swinging that thing through cloud of mosquito