<oriansj>well turns out my talk was 3rd in the round so a bit off schedule <oriansj>stikonas: well types in M2-Planet are still largely the same as was being done in cc_* so it might be time to improve the struct type to be smarter <oriansj>as it only really behaves correctly to type* with type** only kinda working correctly and type*** really behaving a bit different. <oriansj>Mostly because the only type** we needed was char** argv and char** envp and everything else was type* and below <oriansj>and this weird virtual conference thing for after talk questions and/or discussion <oriansj>where there was no actual questions about stage0 <muurkha>that's like 40% of a lightning talk slot <oriansj>I guess no one watching actually cared. <muurkha>maybe you weren't able to communicate the important aspects in 2 minutes <muurkha>even a 5-minute lightning talk is challenging <oriansj>I covered the multics paper, the Ken Thompson paper, David A Wheeler's work, Reproducible builds, Guix, Gnu Mes, stage0 and live-bootstrap and future plans. <muurkha>ouch, that's a lot to cover even in 60 minutes <oriansj>but because my talk seemed too meh, 2 minutes was the best I could get and did the best I could given those limits <oriansj>but I guess this is the first talk of mine about stage0 to be accepted and not cancelled; so there is that for a win I guess. <oriansj>The whole send us your slides, does so, yeah we changed our mind on accepting your talk sequence really hurts. <stikonas>as for type***, we probably don't need it in bootstrapping... <stikonas>basically in the test I wanted to test char and int dereferencing (as they have different sizes) and also assigning value (so where *variable is to the left hand side of equality) <oriansj>well we could make it do the structs as well if we add some complexity to assignment <oriansj>as it would only need to know the size of the struct <stikonas>yeah, I thought structs should be possible too by exactly tweaking that assignment part in the same function <stikonas>but it's somewhat other feature than pointers <stikonas>so best not to overcomplicate individual commits <oriansj>and I'll start a new fuzzing sequence <oriansj>with the latest commit as the last commit went 48 hours without any crashes (good job) <stikonas>I think I messed up whitespace a bit in my last commit <stikonas>well, will fix it locally and sneak into some other PR later... <oriansj>fortunately there is a standard astyle command for formatting and we could do a minor formatting cleanup as a single commit <oriansj>as not every line is exactly in line with the rules <oriansj>as I know I am probably guilty of a few myself and you can be the hero to help ensure the standard is enforced. <Hagfish>"Today, we [Microsoft] are working to improve trust in OSS developer ecosystem packages (NPM, NuGet, PyPI, Maven Central) by collecting and validating packages and their metadata:" <Hagfish>"Map packages back to their repository and commit ID" <Hagfish>given that microsoft own NPM, that really shouldn't be difficult to introduce <Hagfish>"Verify packaged sources/binaries are faithful compilations of their sources" <Hagfish>yeah, making sure there are no unversioned files in npm packages would be great <Hagfish>if each commit (or at least every tag/release) was signed with an offline key, we'd be in a better position too <pabs3>same with Rust, I've seen that before with crates.io <Hagfish>you can't spell "trust" without "rust" :P <Hagfish>no mention of it on that page, but i know that the Rust community are working on distributed code review, which is a great addition to this space <Hagfish>realistically it might take another couple of years for tooling to surface the sort of work that microsoft are talking about here <Hagfish>it has to reach a point where developers can make informed decisions based on the information they presented about packages <Hagfish>or ideally, policies automatically rule out entire classes of attack, or significantly raise the costs to attackers <Hagfish>some "critical" sites started adding security <Hagfish>and we got the UX of that wrong, asking users to deal with strange warnings <Hagfish>then we stopped expecting users to handle the warnings <pabs3>attackers will just shift their malicious code to being committed to git, many git repos are already full of minified obfuscated prebuilt JS, and even the non-obfuscated files are unlikely to be reviewed <Hagfish>well, if there are distributed reviews, i'd expect that minification/obfuscation would get an automated red flag from even the most casual of reviewer <Hagfish>you're right, it moves the problem into a different domain, but it's hopefully a domain where we have better tools (because code is more human-readable) <pabs3>this isn't exactly a new problem though, devs have been committing generated files like ./configure into VCS for decades. unless MS starts autoflagging .min.js and similar in their SSC tools <fossy>i should make dontcommitblobs.info <stikonas>and some of the blobs are not easily readable <fossy>nah just generally from previous conversation ***ccx_ is now known as ccx
<stikonas>(and also servers as an additional test for M2-Planet pointer dereference functionality) <riv>why have you implemented sha? <stikonas>i didn't write that file, I think oriansj added it <stikonas>but it's to calculate checksums before GNU coreutils is bootstrapped <stikonas>so stage0-posix and early stages in live-bootstrap use it <riv>why does it checksum? isn't the data known to be correct? <stikonas>well, it does help to make sure that everybody is getting the same checksum accross different machines <riv>oh the checksum is done on outputs <riv>to verify that the output is as expected, I like that <stikonas>well, mostly to ensure reproducible builds <stikonas>every time you edit code, checksum changes <stikonas>but otherwise, checksum should remain the same <stikonas>well, that reverse list thing is to make output match sha256sum form GNU coreutils <stikonas>the one from mescc-tools-extra used to print everything in reverse order