Young Hands
ossasepiaeuloratrilemaspykedtrinquetrilema-hanbotagriculturalsupremacy
5h 43m9h 48m54m54m15d 14h 58m1h 49m5m
Ossasepia



spyked: http://logs.ossasepia.com/log/trilema/2019-12-02#1954056 <-- apologies for the radio silence. I've been down with a nasty stomach flu the last few days. I'll catch up with the discussion in the next coupla days and I'll give my take on bios/bootloader ownership
ossabot: Logged on 2019-12-02 18:36:12 dorion_road: http://logs.ossasepia.com/log/trilema/2019-11-29#1953812 << thanks for the background spyked. I agree we're at the phase of figuring out what is really needed.
spyked: in related news, my november review/december plan was also delayed because of that, I'll have it published on saturday, along with my notes on current tmsr-os status
spyked: http://logs.ossasepia.com/log/trilema/2019-12-03#1954183 <-- ftr, I'm not especially familiar with coreboot, though I've swimmed for a while in the SeaBIOS code a couple of years ago. but otoh the uefi 1/2 cleavage is worth studying and documenting in detail and I'll take that up if you think it's a priority.
ossabot: Logged on 2019-12-03 18:05:46 dorion_road: as it turns out, it seems to my eye that it'd suit you well, given, e.g., the low level firmware work you're doing. do you want it ?
spyked: also otoh, I'm not entirely sure custom biosen/chips are the way to go, since they require a fair amount of reverse engineering, which is usually a massive time sink. it'd certainly be an interesting research project, but it's not something I'd make the delivery of tmsr-os depend on.
mircea_popescu: it's only interesting because it's how "bake own hardware" eventually starts ; sure as fuck can't have anything stalled on it.
diana_coman: !!up dorion_road
deedbot: dorion_road voiced for 30 minutes.
dorion_road: ty diana_coman.
dorion_road: http://logs.ossasepia.com/log/trilema/2019-12-05#1954366 << thank you for the update, sorry to hear you're under the weather. I hope you're able to rest up and recover. I look forward to the discussion!
ossabot: Logged on 2019-12-05 05:49:41 spyked: http://logs.ossasepia.com/log/trilema/2019-12-02#1954056 <-- apologies for the radio silence. I've been down with a nasty stomach flu the last few days. I'll catch up with the discussion in the next coupla days and I'll give my take on bios/bootloader ownership
dorion_road: http://logs.ossasepia.com/log/trilema/2019-12-05#1954369 << interesting to know on the SeaBIOS experience, what'd you do with that ?
ossabot: Logged on 2019-12-05 06:29:20 spyked: http://logs.ossasepia.com/log/trilema/2019-12-03#1954183 <-- ftr, I'm not especially familiar with coreboot, though I've swimmed for a while in the SeaBIOS code a couple of years ago. but otoh the uefi 1/2 cleavage is worth studying and documenting in detail and I'll take that up if you think it's a priority.
dorion_road: the uefi 1/2 cleavage is a priority crevice to map in detail.
dorion_road: how about you outline your first steps there in the plan you'll be publishing saturday ?
dorion_road: http://logs.ossasepia.com/log/trilema/2019-12-05#1954371 << I agree reversing chips is not a dependency of tmsr-os. My thought process there is it's an optional package.
ossabot: Logged on 2019-12-05 06:33:41 spyked: also otoh, I'm not entirely sure custom biosen/chips are the way to go, since they require a fair amount of reverse engineering, which is usually a massive time sink. it'd certainly be an interesting research project, but it's not something I'd make the delivery of tmsr-os depend on.
dorion_road: While there must be a bootloader to run tmsr-os, Coreboot need not be utilized on a system, even if that system is already supported by Coreboot.
dorion_road: With that being said, BIOS auditability and integrity is a key piece of the pie and someone owning it and adding configs for the set of supported boards would be a win to my eye.
dorion_road: spyked et. al, is ^ that a sensible approach to you ?
diana_coman: !!up dorion_road
deedbot: dorion_road voiced for 30 minutes.
dorion_road: It occurred to me this morning, this tmsr-os project could be utilized medium to long term in both lifetime support consultancy and the hottest business idea in btc (code review and code insurance) ventures.
dorion_road: I haven't developed it very far past what's in those articles and what we've done to develop JWRD, but seems like there is a medium to long term profit center to establish.
ossabot: Logged on 2019-05-17 19:17:54 trinque: republic is scant of profit centers
dorion_road: life's too short to salt mine for idiots any longer than you have to.
ossabot: Logged on 2019-03-04 16:14:16 mircea_popescu: empire does not in any factual sense exist. man who works 70% of the time for idiots is === the remaining 30% of that man.
mircea_popescu: in other "lulz", in the sense that koch & co are so fucking evil it boggles the mind : gpg has an ascii armored mode, which however contains no error recovery.
mircea_popescu: so koch-gpg is, out of the box, worse than useless for archival : tar / zip / etc as they exist on unix-likes are fucked in the head enough such that if there's a byte error, either the remainder of the archive or the bytes past that one in the list are lost ; but this can be mitigated at least by having multiple copies. gpg however, multiple copies are equally useless, if none make it intact the contents is lost, because
mircea_popescu: well, different bytestreams.
mircea_popescu: the WHOLE FUCKING POINT of "armored" mode is to armor it, you're not wasting those 40% extra bytes just for the sake of wasting them wtf.
mircea_popescu: it's high fucking time for a ~comprehensive~ archival-and-encryption util that handles compression, encryption ~and error redundancy~!!!! correctly.
mircea_popescu: i must know, at the end of its run a) that it optimally used the bytespace by wringing out periodicity in the input ; b) that only the designated keys can ever get the input back out and c) that a specific set of occurences will not harm the contents. such as "two consecutive lost bytes once ; AND six independent lost bytes". or w/e it is. set percentually or w/e.
mircea_popescu: this is ~all~ obviously crypto-matter (which'd explain why the forefuckwits managed it so poorly -- crypto is like the intellectual antithesis of moronman)
feedbot: http://qntra.net/2019/12/vpn-breaking-zero-day-effective-against-many-nix-systems-burned/ << Qntra -- VPN Breaking Zero Day Effective Against Many *nix Systems Burned
BingoBoingo: ^ In other lulz
BingoBoingo: !!seen zx2c4
deedbot: 2018/11/30 04:54:33 <zx2c4> My "nice post" remark wasnt sarcastic, if thats what youre responding to
BingoBoingo: The whole "we're going to Microsoft better than Microsoft crowd seems to have been caught prone in the field this time.
mircea_popescu: and every other time
mircea_popescu: "I orignally listed CentOS as being vulnerable
mircea_popescu: to the attack, but this was incorrect, at least regarding IPv4" << the moneyshot there.
BingoBoingo: We appear to be first outside of the mailing list on this, so taking a bit of time to try spreading
mircea_popescu: jfw's been a busy boy, has he!
BingoBoingo: jfw has indeed. Publishing quite the treasure trove. The jfw/dorion pairing seems to be a great benefit to the both of them.
diana_coman: well, they have actually developed a partnership that works, certainly.
BingoBoingo finally applying to places in Buquebus range (also Missouri en Argentina del Norte). Trying not to hold "No querés re-activar tu proyecto de venta de servicios web? Nosotros para ayudarte podemos ofrecerte el servicio sin costo inicialmente..." against them.
feedbot: http://bvt-trace.net/2019/12/keccak-hashing-for-kernel-rng/ << bvt's backtrace -- Keccak Hashing for Kernel RNG

Random(trilema) | Download daily DB snapshot | Get Source Code