Edwin Török

@mdione@en.osm.town @david_chisnall@infosec.exchange I'm not sure which one is better from a security point of view: a native PDF viewer exploit may allow arbitrary code execution. A pdf.js exploit may allow arbitrary JavaScript execution, and although you'd still have another layer of defense from the JavaScript sandbox, it may already be able to steal high value secrets (session cookies, registering a malicious passkey, etc.) The Qubes approach (opening a PDF viewer in a disposable VM) may be safer.

@Nonya_Bidniss@infosec.exchange @david_chisnall@infosec.exchange even without switching search engines you can turn that off, see https://tenbluelinks.org/ on how

@undead@masto.hackers.town @amydiehl@mstdn.social how do you deal with projects mentioned on the CV if the name is removed? If an unfamiliar project is mentioned you may want to look it up, and then it'd be useful to know whether they were one of the main contributors (probably only relevant for people who have open source contributions on their CV). Perhaps this could be anonymized to some degree without revealing the identity (classify into: top contributor, regular contributor, occasional contributor, never contributed) which could be cross-checked against the claims on the CV. But I think a human still needs to make that judgement, evaluating contributions is not always straightforward (e.g. someone could've contributed a lot of bugreports, or wikipages, or conference talks, or could've used slightly different usernames/name spellings/etc). Also you'd need to evaluate whether those contributions are relevant for the position they apply for. Papers cited on a CV are also difficult to anonymize, they usually have a small number of authors, and together with other information on the CV it may be obvious who it is. Or do you restore the serial number back to a name for the technical evaluation/interview?

@cancel@merveilles.town @xerz@soc.masfloss.net how about startpage.com? If a site blocks Google, will it disappear from there too?

@starchturrets@mastodon.social @david_chisnall@infosec.exchange I don't know whether they still use Xen or not, but according to this https://perspectives.mvdirona.com/2021/11/xen-on-nitro-aws-nitro-for-legacy-instances/ what they've done is to provide the Xen interfaces and virtual devices, but implemented on the Nitro (KVM) hypervisor. So then it'd be almost transparent to the VM whether it runs on legacy hardware on Xen, or on newer hardware using Nitro providing the Xen interfaces. I could be wrong, but the migration is probably one way (XenVM-on-XenHypervisor -> XenVM-on-NitroHypervisor), and they've done this to make migration easier, not necessarily so they could switch back in an emergency. In particular I don't think they've implemented NitroVM-on-XenHypervisor, so if the VM booted on a Nitro configuration to begin with, it wouldn't be able to live migrate back

@david_chisnall@infosec.exchange probably also run a mix of hypervisors (not just different versions, completely different ones), and a mix of CPU vendors (multiple hypervisors don't help when they're all affected by the same Intel or AMD bug) and a mix of CPU architectures. Although that still doesn't protect you against bugs that affect all or most architectures (like some of the side-channel attacks). If you run an unpopular OS, hypervisor, or architecture you may have some protection against widely used exploits until your OS/hypervisor/architecture becomes widely used and targeted by exploits. Having said that if we ever get to live in a CHERI monoculture that wouldn't be so bad, it'd significantly raise the complexity and reduce the likelihood of attacks :)

@david_chisnall it is also interesting to look at how it changes when you go back from a higher level language to writing C (e.g. some glue code between the high-level language and the system). In my case (where I write OCaml day-to-day), going back to C makes me realize just how much code is *not for the thing*: there is a lot of code to handle allocation, and manual error handling. You need much less manual error handling when you have exceptions, or result types in your language (where the compiler tells you if you forgot to handle an error). And having a GC means you write less code that deals with memory management (not 0, because you still need to think about limiting memory usage).

@david_chisnall @regehr I think that even without LTO, looking at the number and size of inputs to a linker could be useful for limiting memory usage, while preserving some parallelism.

@david_chisnall @regehr if you have LTO enabled then linking becomes much slower, so running multiple linking jobs in parallel is still useful if your project consists of lots of executables. I noticed this when Fedora turned on LTO by default in GCC. Perhaps the build manager could look at the number and size of input files to the linker and try to limit parallelism based on that. E.g. you could probably link 2 executables in parallel if each uses 3 small inputs, but not if they use 1000 small inputs, or 3 large inputs. i.e. gave a budget of N linket inputs and M MiB and only launch additional linker jobs if this is not exceeded (with an exception to always launch the first if it is alone). But I don't know how to express this in any existing build system.

@avsm@amok.recoil.org reminds me of Turris's dynamic firewall (https://docs.turris.cz/basics/sentinel/dynfw/) and Razor2 antispam (https://notes.sagredo.eu/en/qmail-notes-185/razor2-pyzor-spamcop-and-dcc-setup-251.html) Would be interesting to see how distributed defense approaches could be integrated with an antibotty-like system. (The 2 examples I mention are still largely static once they get an update, but what if each host got a slightly different update, e.g. to A/B test defenses and evolve a better defense using a model)

@filippo I still think hybrid is the way to go. PQ crypto algorithms and their implementations are still very new, with undiscovered flaws. If you use hybrid and PQ is broken by a bug or flaw, no problem, you still have the same protection or better than the classical one. Even when quantum computers exist you'd have to break both the classical one (with a quantum computer) and the PQ one (with an implementation flaw, or mathematical breakthrough). If you deploy only PQ and a flaw is found you are *worse* than classical, depending on how bad the flaw is you might not be much better from transmitting in plain text. IOW a PQ crypto algoritm protects against an attack from a machine which doesn't yet exist. Deploying it standalone makes you vulnerable against a bug that doesn't yet exist. *But* we've seen a steady stream of bugs in OpenSSL, and it is very likely that there will be one in the PQ implementation too. I think it is more likely that such a bug is discovered before a quantum computer is built that is capable of a practical attack. For example there could be side channel attacks if you forget to implement protections similar to RSA blinding (constant time CPU instructions are not side-channel free, see latest Hertzbleed attack from 2025 about remote power analysis leaks). And there probably plenty of other "classical" attacks that will work on PQ algorithms too, since they execute on a classical computer... Of course implementation flaws in a classical+PQ hybrid could be worse off than just classical too (e.g. some C memory bug), but that might be an acceptable risk. I'm not sure what the best ordering for a hybrid would be, but I guess PQ encryption first, then classical? So you always have to break the classical first (which won't be instant, even with quantum computers). There is of course a performance cost, but AFAICT encryption isn't really the bottleneck in TLS, from some testing with 'curl' and 'stunnel' they achieve much lower speeds than what 'openssl speed' reports, so increasing encryption time may not affect overall time that much.

@avsm@amok.recoil.org I didn't know about the Analog Library! It is so much faster and cleaner than the ACM DL, thanks for recommending it.

@avsm@amok.recoil.org perhaps a lint tool could check the consistency between information in the repository, and information in the VCS. They are both useful for different reasons (e.g. disclosure in the commit itself can help reviewers, and may be required by some projects; whereas the info in the repo is a good way to tell at a glance how AI is used in a project, or in places where VCS is unavailable, like an opam release).

@avsm@amok.recoil.org the Linux kernel requires the use of Assisted-By tags in git commits https://docs.kernel.org/process/coding-assistants.html#attribution (be careful when parsing, this is used to declare both AI assistance and regular analysis tools like sparse. AI is distinguished by having an AGENT_NAME:MODEL_VERSION format). Also some AI tools add a Co-authored-by tag. Adding support for parsing these conventions may help in classifying existing code/commits (at least in the 'unknown' -> 'ai-assisted' direction).

It is also useful to list what cannot be used as an indicator of AI assistance, e.g. the presence of a CLAUDE.md file and similar. I've seen projects that added such a file containing and instructed the AI to refuse to contribute to that repository (and for Claude sometimes including the official refusal magic string). Although the presence of such a file could still be used to issue a warning, or a hint when trying to update the classification of unknown disclosure states.

@david_chisnall @nixCraft the thread also mentions a bug where the bot undid already translated elements and resets them to English ... That means the bot should've been turned off immediately to prevent further damage, but I don't think that has been done.I can see how that bug together with the automated translation will drive contributors away. Machine translation could be useful, but perhaps only as a sanity check (reverse translate back to English and compare), and should only be used if the contributors actually want it.

@jk yeah Win11 looks like it was designed on a Mac...