<stikonas>oriansj: quick question, in hex2_word.c::DoByte you call hex(c, source_file) quite a few times. Can't you just call it at the beginning of the file and store the result? <stikonas>well, hex does consume the whole comment but that should be fine <Hagfish>stikonas: if it's anything like Trillian (another new project which Google is backing), it will work like Certificate Transparency <Hagfish>i'm not sure that using a blockchain (maybe ethereum) would be a bad idea, but i don't think we have enough data on possible attacks to decide what a realistic threat model is yet <stikonas>well, that function either reads 0 or entire line, we read character earlier and just pass it to that fucntion <oriansj>and updates the line_number so that error messages can have an accurate line number in the message <oriansj>and yes we could do caching of the input (or the generated hex) but that would add complexity to any implementation in assembly. <stikonas>oh yes, ok I was ignoring that line_number because I don't need it for hex1 <stikonas>trying to keep hex1 as short as possible <stikonas>so non-essential features can go to hex2 <stikonas>anyway, more work on hex1 will have to wait for another day <oriansj>stikonas: which format do you tend to you for jumps and function calls? <oriansj>because you could limit hex1 to just @ or $ <stikonas>oh yes, definitely single character labels <stikonas>we'll see regarding other encodings, they might not be too bad <oriansj>and you can collapse UpdateShiftRegister if you can find a way to just use one of the type formats <oriansj>(skip !, ~, ., %, & and > entirely for hex1) <oriansj>probably can skip < and ^ too (I don't think we even use ^ in RISC-V yet) <oriansj>and DoByte needs only handle hex so that can be seriously simplified <oriansj>and you can even reduce line comment support to just # or ; <oriansj>and Throwaway_token and consume_token can be reduced to a single fgetc <oriansj>using a 256 element array is all one needs for label address lookups and storage <oriansj>just read the char after : and << 2 + base_address of table to store to read the address relating to the :l <stikonas[m]>(I started by cleaning up my hex1_x86.S and building on top of that, some parts are now changed, but comment implementation is already there) <oriansj>I trust you'll find the minimal subset so that you will not have to deal with jump and/or call offsets when dealing with hex2 <pabs3>Hagfish: re "everyone will keep using language-specific package managers", do you see a way to change that trend? <Hagfish>i'm wondering if they might all converge towards a standard package format + security model <Hagfish>The Update Framework are doing some good work in that area <Hagfish>i can see the argument that there should be multiple competing tools for downloading packages and maintaining repos, etc. <Hagfish>and there should be multiple organisations who decide what is allowed in each repo <Hagfish>so some amount of "fragmentation" is healthy <Hagfish>i think the biggest cultural divide is how much an ecosystem values stability and long-term support <Hagfish>i don't know if the technology itself can help much with that <pabs3>I think language-specific package managers arose because the Linux package managers weren't targetted at proprietary OSes like Windows/macOS, and any cross-language package manager would need this to have any chance of replacing them. also I think people often want the tools for the language to be written in the language so they can understand/modify them <siraben>pabs3: I think Nix has been a great way to reduce reliance for me on language-specific package managers <siraben>In particular, ecosystems like Python are a mess in terms of reproducibility <pabs3>which OSes are you using it on? <siraben>My home configuration is the same across all of them <pabs3>during the next Debian cycle I want to try to wean Debian off using source artefacts from packaging ecosystems like PyPI and move towards upstream git repos <siraben>drakonis suggests Guix which is the same idea as Nix <siraben>but it's more restrictive for me because no macOS support <pabs3>it highlighted that just switching to upstream git isn't enough, we should audit the diffs between the two <siraben>Yeah, there can be differences between upstream git and pypi <pabs3>same in the Rust ecosystem. the diffs in the browser extension ecosystem can be much much worse though <siraben>Nix prefixes store entries with a hash of the derivation (build recipe) so if anything changes in the underlying derivation, the hash does as well and so do all the reverse dependenncies <pabs3>in one particular case, the Rust crate shipped some pre-generated stuff and didn't ship the source/tool needed to re-generate it, which were in the git repo though <siraben>Also in doing so it makes it safe to get from the cache instead of rebuilding <siraben>For Rust packages we prefer upstream git repos and have a vendor sha hash <pabs3>I've pretty much given up on devs doing the right thing when it comes to choosing their source and actually building from source <drakonis>siraben: has nix's packaging quality improved in the past several months? <siraben>we're still more up to date than any other distro and almost as large as AUR <drakonis>perhaps the best way to measure quality is whether they follow a certain level of cleanliness? <siraben>There's people fixing cross-compilation issues, broken packages get fixed, reproducibility fixes, etc. <siraben>So I think the quality is getting better all the time <siraben>we're deprecating phases and other legacy things <siraben>IMO quality and quantity are always improving for Nixpkgs <drakonis>upstreaming work on the home manager equivalent still ongoing <siraben>I wish I could use Guix to get some ideas from it <drakonis>python still in better condition than nixpkgs <drakonis>as guix does not rely on scripts for generating language specific environment on the fly <drakonis>it has packaged things in a way that if you install them or invoke a regular environment, the packages are visible to the resulting environment <drakonis>and it should be exposed to further python invocations <drakonis>siraben: anyhow, the next release will be plenty interesting <siraben>I still have the urge to reduce Nixpkgs' bootstrap <drakonis>since there isnt exactly a huge drive to do it <drakonis>maybe i should hit up the matrix channels ***ChanServ sets mode: +o oriansj
<Hagfish>"Maybe the solution is some kind of standard spec for how package management should work, and the manifest formats, etc, and then each language ecosystem implements that standard." <Hagfish>that's basically what i was thinking ***jackhill_ is now known as jackhill
<stikonas>gforce_de1977, might be due to 32-bit kernel, not sure if fossy tested it with it <stikonas>gforce_de1977: running with a 32-bit kernel is a bit on hold right now anyway <stikonas>until fossy finishes kernel building work <oriansj>The 3 failures seems related to perl 5.32.1 <oriansj>Hagfish: in regards to sigstore. I don't quite see how it improves things. If anything I can see ways it can be abused to make things far worse. FLOSS at its heart is a people sharing code with friends and the community; with curation occuring at the distro level. <oriansj>but perhaps that is because I am doing a compare against what NIX and Guix provide out of the box. <Hagfish>oriansj: yeah, i think the value proposition is much smaller for ecosystems like Guix/Nix <Hagfish>it's probably supposed to appeal to ecosystems that want to keep doing things their own way, but still get the benefit of signed releases <Hagfish>i do like the idea, though, that a package manager could check an append-only log, to ensure that the software you are downloading has been publicly announced (and hasn't been specially crafted to exploit you) <Hagfish>of course a malicious update could contain a branch like "if MAC address == ...", but that should be hard to explain to an auditor <xentrac>Hagfish: I recall that one of the Underhanded C Contest winners would falsify votes only on Wednesdays <xentrac>because formatting a date with a Wednesday in it would overflow a buffer <xentrac>the certificate transparency benefit sounds pretty significant <Hagfish>i wonder what the limits of static analysis are in terms of security <Hagfish>i like the fact that ecosystems are starting to think about making apps state up front which permissions they need <Hagfish>obviously apps do that, and browser extensions, but i think Deno does that for javascript packages <Hagfish>Endo is another (more experimental) technology that tries to give capability security to javascript modules <Hagfish>and obviously there are attempts like SELinux and similar which try to apply this to existing desktop apps (somewhat awkwardly) <Hagfish>just being able to say "the code in this library will never be able to start a new process, or access the network, or the filesystem" is a really useful primitive to have when pulling in a dependency <Hagfish>developers probably need to get used to putting "guards" into their test suites, to detect if code is trying to exfiltrate data <Hagfish>assert that no network connections are made, or unexpected files written to or read, when the feature/unit test suite is run <Hagfish>i've read discussions of interesting theoretical approaches of code detecting when it is run in a production environment, versus in a test <Hagfish>one of the things you need to lock down is access to the current time, so that a function can't become malicious after a certain date <Hagfish>also not allowing access to randomness, otherwise it could execute its payload only one in a billion invocations <Hagfish>these are all defences in depth that increase the cost to the attacker (and make it harder for someone to claim that a security issue is accidental) <Hagfish>security doesn't have to be perfect, it just has to raise the cost of the attack above the value to the attacker <xentrac>you can guarantee that sort of limitation either statically or dynamically <xentrac>SELinux has a hard time because it's working at process granularity <xentrac>while technically it's true that "security doesn't have to be perfect, it just has to raise the cost of the attack above the value to the attacker" nearly every inference you could make from this requires knowing both the cost of the attack and the value to the attacker, at least roughly <xentrac>but it's easy to make errors of literally ten orders of magnitude in those estimates <xentrac>because the same code may be safeguarding resources that are worth a microdollar or a teradollar, and an exploit, once developed, may be used against one device or against ten billion devices <xentrac>so in general I am very skeptical of reasoning that invokes "defences in depth that increase the cost to the attacker" <xentrac>the traditional term for such things is "snake oil security" or "security by obscurity". when it's all you've got, well, might as well make it good, but having actual Kerckhoffs-compliant security is a lot better