I still don’t understand why pledge(2)/unveil(2) have not been ported to other kernels. They have proven to work very well for a almost a decade now, as they were introduced in 2015.
We’re doing a capstone project with one of my students where we’re porting pledge to FreeBSD. We’re not doing unveil because I don’t know the internals as good as pledge, but hopefully something good comes out of this experiment.
You might want to reach out to some of the HardenedBSD community members. We have a port of pledge that is nearing completion and will likely be merged into HardenedBSD on the inside of a year, quicker if we have help. :-)
The Linux approach, for better or worse, is to provide more generic/complex kernel APIs, the two most similar to pledge/unveil being respectively seccomp-bpf and landlock. Given those, you can port pledge/unveil in userspace. But that obviously results in less uptake than an API blessed/mandated by the OS developers in the OpenBSD style.
For example, let’s say you want to do something on Linux like control whether or not some program you downloaded from the web is allowed to have telemetry.
This seems pretty easy on Linux with systemd, am I missing something? The program itself doesn’t even have to know about any control mechanisms like pledge or whatever, we can enforce it from outside.
pledge and unveil are specifically designed as tools for the programmer. They aren’t meant to be imposed from the outside as a sandbox. Theo has repeatedly rejected the idea of adding a utility to OpenBSD that runs an arbitrary command line under a particular pledge, for example. The intended use is for the developer (or knowledgeable porter) to pledge/unveil down to the resources that they know the program needs. It’s a tool for defensive programming: if your pledged process gets owned, it has as little ambient authority as possible.
I agree. The programmer knows better than the user what resources a program needs.
Besides, the external approach imposes a static set that stays the same during the entire runtime, which is sort of critical, mostly because many programs require more privileges during the initialization which can then be dropped later.
The programmer knows better than the user what resources a program needs.
I agree, but OTOH the user has the much greater incentive to care about sandboxing programs than their programmers (when the user and the programmer are not the same).
OK but my point is that the linked post says that this functionality is extremely difficult in Linux, but if we shift our thinking slightly to work with Linux’s execution resource controls, it seems to be quite easy.
It…depends. Linux sandboxing solutions are not particularly unified and depend on stitching a lot of pieces together, sometimes with confusing or bizarre edge cases. It’s not awful, but it’s still a fair bit of effort and a surprising amount of room for error.
(I will say that Landlock helps a lot here by being a relatively high-level set of access controls for things that are otherwise more difficult to sandbox.)
No, it really looks quite simple. Check the link I posted earlier. It’s as simple as adding a couple of lines to the systemd unit file or a couple of flags to the systemd-run command line.
There’s a significant structural difference between the two. I honestly don’t know why the Internet keeps lumping them together. Yes, both apply restrictions, but they’re completely different mechanisms. It’s like lumping email and keyloggers together because both ultimately boil down to delivering a series of keypresses to a third-party.
pledge and unveil are things that the program does, which has two major implications:
It’s generally expected that the program is written in such a manner that pledgeing a particular restriction is a supported mode of operation.
Breaching a pledge kills the program with SIGABRT and you get a stack trace pointing to wherever the promise was broken.
You can pledge or unveil whenever you want during a program’s execution (but there are restrictions to what you can “unpledge” or “un-unveil”). So you can e.g. start with full access rights to the user’s home path in order to read configuration, and you can drop filesystem access privileges entirely once you’ve read configuration data.
“External” sandboxing solutions allow you to apply the same restrictions, but:
They’re going to apply regardless of whether the program supports them or not. E.g. you can IPAddressDeny= an address, but if sending telemetry to that address is a blocking operation, you’ll just get a blocked program. That’s obviously not on the sandboxing method itself, but…
…breaching a restriction doesn’t necessarily give you any useful debugging context. The failure mechanism for breaching a restriction is usually operation-dependent. E.g. IPAddressDeny= packets just get dropped.
Those restrictions apply throughout a program’s execution lifecycle. So if you need higher privileges at start-up you’re out of luck, since external tools have no insight into what a program is doing.
The whole point of pledge and unveil is that you write your program so that you make certain promises about how it’s going to work, and sandboxing works as protection against accidentally breaking those promises, either straight as a bug, or through a bug getting exploited. They’re design-by-contract tools, more or less.
I’m a bit confused, I wouldn’t expect “Linux’s execution resource controls” to include systemd-specific APIs? Tbc these toggles do not cleanly map to OS primitives at all; you can’t just go “ah yes I want systemd’s IP address restrictions myself” without writing your own BPF filtering.
If you did just mean systemd specifically, note that it’s quite a bit trickier to, say, sandbox things in a flexible way with that. In particular, to sandbox something that’s not a service with systemd-run has the overhead of spawning the child under the service manager and piping the output, and you lose the ability to easily control and kill the child (because you’re just killing the proxying process, not the actual child).
I didn’t say it’s a ‘flat out replacement’, I said it achieves the same goals that were mentioned in the linked post ie preventing a piece of software I downloaded off the internet from ‘phoning home’ and uploading telemetry.
Okay I understand now.. The way I see it, the example in that post was a one-off example, and a pretty bad one, because I think from this you’ve misunderstood the purpose of pledge. While there may be some overlap in the functionaility of BPF filters they are far, far, from 1-1.
To help clear this up:
pledge is not for sandboxing existing/binary (i.e. already complied) software, nor limiting network connections in software (the former would preferably be done with network controls like firewalls).
pledge must be added to the source code of the software itself (either by a dev or maintainer).
on a violation of “promises” the program is killed
you can limit network connection but it’s simply “all or nothing”; your software gets all network, or no network.
So in this scenerio of telemetry:
if devs/maintainers have source access to add pledge then they also have source access to just rip out that telemetry code right?
There would be no point in using pledge here.
in using pledge, as soon as the software tries to do any networking, the program is killed! The connection is blocked – only because your software is now not running at all!
Yeah exactly, the overlap is what I’m talking about. This is what I was referring to earlier–if you shift your mindset a bit, it becomes pretty easy to externally impose similar security restrictions using systemd. If you don’t mind that the exact way it’s done is a bit different, you can achieve very similar goals.
Part of the pledge/unveil model is that you can progressively drop privileges during program execution. The observation is that programs may need a lot of privileges in order to start themselves up, and then hardly any for the remainder of runtime. For example, consider the recommendations for using pledge when opening handles to sndiod in OpenBSD:
If the sndio library is used in combination with pledge(2), then the sio_open() function needs the stdio, rpath, wpath, cpath, inet, unix, dns, and audio pledge(2) promises.
However:
Once no further calls to sio_open() will be made, all these pledge(2) promises may be dropped, except for the audio promise.
And in fact aucat(1) does exactly this, using a bunch of privileges at startup time (but dropping other very sensitive promises like proc and exec right away) and then dropping most of them when it’s time to start playback or recording from the sound device handle.
The purpose of pledge is for the programmer to mitigate the privileges available to exploits, not for the user to defend against code they chose to run. As far as I know, these goals, which are the main point of pledge and unveil, do not overlap at all with what you can do by filtering access via systemd.
They overlap with the goal that was stated in the linked post. That was what I was referring to. I agree that dropping complex combinations of privileges in Linux at different points within an application’s lifecycle doesn’t seem easy.
Yeah but the linked post misunderstands what pledge is actually for; “sandboxing untrusted binaries” is not an actual design goal of pledge and if it’s useful for that goal it’s only useful by accident.
Yeah so this is kinda weird: it makes it easy to manage the child as a single entity and then interactively control it. But systemd-run is, ofc, just a proxy, spawning the child as a transient unit and monitoring it until exit.
This effectively means that systemd-run does not itself control the spawned process’s lifetime. When you run it with –pty, Ctrl-C will kill the child normally… because it’s going through the tty. But if you’re running it detached from the tty (e.g. because you need to control stdout/stdin from your program), or you just signal the process directly, the actual service will remain running in the background. The only way of directly controlling that lifecycle is by grabbing the PID or (preferably) transient unit name and then targeting it directly or controlling it via the D-Bus interface.
But it’s a transient unit, it shows up in the output of systemctl list-units, right? That means you can operate on it with eg systemctl stop the-unit just like other systemd units?
It is, yeah, which is why I had mentioned the “it makes it easy to […] interactively control it”. It’s just a lot harder in turn to automatically do things like “oh the user did Ctrl-C, let me stop all my processes”.
From my admittedly passing acquaintance with both of them: Capsicum is much finer grained.
Pledge/unveil solves the 80% use case, Capsicum aims to solve the 100% use-case.
I.e. it would be very difficult, perhaps impossible to implement capsicum in pledge/unveil, but easy enough to do with capsicum.
That said, there is probably more veil/pledge actually implemented in binaries out in the wild. I think all of the base OpenBSD system is done now. Last I checked only some of FreeBSD has Capsicum implemented in base.
Leadership (likely Linus) needs to step in here and either say “rust is ok” or “rust is not ok.” Otherwise these same rehashed arguments in the LKML will be going over and over again, and nothing gets done except people burning out.
The Rust support was merged in v6.1 into mainline in order to help in determining whether Rust as a language was suitable for the kernel, i.e. worth the tradeoffs.
That said, people like GregKH are already convinced that Rust for Linux has been success (I do as well, but I’m just watching from the peanut gallery). But that doesn’t mean that “rust is ok” w/o further discussion. Different developers/maintainers still have to be convinced.
Watching from the outside it seems that some maintainers don’t want to be convinced in the first place.
From personal experience with some of the involved in this thread from the maintainers side, I disagree. It’s unsurprising that, after years and years of holding the kernel as a pure C project for good reasons (not even allowing the sister language C++ in), there’s people that hold this as a value. Those aren’t convinced easily, not on a short timeline and not via email. I know people wish for a strong word from Linus, but this is only partially in his hands - particularly as the person who previously held the “pure C” line.
I’m not a fan the tone, but I was for example completely unsurprised by Chris Hellman holding that line and not arbitrarily.
R4L is not just a substantial engineering effort, it is also a substantial social effort. And that means a ton of legwork, and maybe some beers at a bar.
My naive and oversimplified take on this is that Rust would be allowed, but is expected to have backwards compatibility assurances, and so long as Rust constantly changes things and lacks those assurances, Rust won’t be added.
Is this correct? Somewhat correct? Not really the issue? Incorrect?
As someone who sees Rust getting rebuilt monthly or even more often than monthly because of new versions, and codebases like Firefox (and even Rust itself) that can’t use an ever-so-slightly older version of Rust, I get the impression that Rust has a long way to go before it settles enough to be used for software that has extremely long maintenance cycles. But that’s just my impression - I have no experience actually programming in Rust.
The results of the annual survey have come out, and 90% of users use the current stable version for development. 7.8% use a specific stable released within the past year.
These numbers are only so high because it is such a small hassle to update even large Rust codebases between releases.
Rust is stable in the sense of “is backwards compatible” even if it isn’t in the sense of “doesn’t have a slow release cadence.”
A new version of Rust comes out every 6 weeks. Rust has many so-called unstable features, which are not available by default and have to be opted into. Those features can change at any moment. But if you don’t opt in to such features, the language is extremely stable. Every time a new Rust version is being prepared, they compile and run the test suites of pretty much all known publicly available Rust code, just to make sure nothing went wrong.
Rust for Linux does opt into a few unstable features, but they’re pretty close to being finished and making sure R4L can work without unstable features is a high priority goal for the Rust Project.
Rust has stability guarantees written down and heavily tested since nearly 10 years to particularly allow evolution with very strong backwards guarantees.
Rust (ideally) never breaks backwards compatibility except in a very defined set of cases. (e.g. bugs in the language frontend that allow you to bypass it’s guarantees are bugs, not features and will be fixed, at the cost of breaking some notion of backwards compatibility). It has an extremely heavy hammer test suite to ensure no unwanted changes to go in and/or assess the impact of changes called crater - which literally runs for days. https://github.com/rust-lang/crater?tab=readme-ov-file#crater
Recommendation: before you actually enter discussions about Rusts backwards guarantee (I know you haven’t, this is more for the reader), please read the two RFCs. They are relatively short, subtle and good. I often see discussions going wrong where people haven’t read those docs and have discussions that have no basis in reality.
Being a BSD masochist^Wuser, I generally maintain my own package repo. Firefox is included in that repo. I love having full control over the packages installed on my system. I’m probably an outlier here, though.
well now we’re changing the topic, but one reason is that it removes the need to trust external builds. another would be to patch it e.g. to restore FTP support. another is that it’s a necessary on-ramp to contributing, or generally to exercising the rights granted by the license.
These are all good and valid points. Thanks for sharing :-). I can see how that’s important to you and the latter being really important for both of us.
I don’t think this is correct. Rust would be experimental and it would be entirely on the RFL members to ensure it stays up to date and correct, without blocking others. None of this would have to do with the language.
so if a casual linux user hears “linux runs on M1 macs,” then spends their whole paycheck on a computer with no ethernet or USB-A ports because of it, then too bad for them because they should have known that “it runs linux” no longer means it has the stability and longevity that could once be expected.
Asahi linux and RFL are two different projects with totally unrelated stability guarantees, none of those guarantees have to do with the RFL code working.
As for the user spending money or whatever, I have nothing to say on the matter. Are users responsible for purchasing decisions? I don’t know, I don’t think it’s relevant at all.
Asahi linux and RFL are two different projects with totally unrelated stability guarantees, none of those guarantees have to do with the RFL code working.
what I read is that a lot of the drivers for asahi linux are written in rust. are they not part of the main kernel tree?
They’re in the Rust for Linux tree, but they’re not in Linus’s tree yet, because they’re blocked on other stuff getting merged first (like the DMA abstraction).
is “upstream” synonymous with “the main kernel tree”?
Yes. That is Linus’s tree, which is the ultimate upstream of the Linux project.
are all of the rust drivers that an asahi linux system uses part of the asahi project and not in the main kernel tree?
I think so. Most of their C drivers aren’t upstreamed yet either, I believe. The C drivers I don’t think are blocked by anything in particular, it’s just work that isn’t finished yet. The announcement blog post says that they are going to focus on upstreaming this year. The Rust drivers are blocked by needed Rust for Linux abstractions not being upstreamed yet.
is “upstream” synonymous with “the main kernel tree”?
Yeah.
are all of the rust drivers that an asahi linux system uses part of the asahi project and not in the main kernel tree?
I’m not sure how much is actually merged, if it is though it’s experimental. I believe much of it is not merged, and it was naturally developed outside of the main tree (as anything would be). The GPU driver, often cited as a big success story for Asahi, is not merged, for example.
Max reply depth reached. Perhaps blog about this and submit it?
(We have a max reply depth for technical reasons. But also, at this depth, previous discussions have always gone off the rails in topic or tone.)
a first?? continuing here…
presumably “experimental” code is more liable to have bugs.
Nope, not in this case. It just means it’s an experiment, if it isn’t successful it’ll get pushed back downstream.
I think I’ve been misunderstanding what is meant by “behavioral” or “API/ABI” stability. I thought this referred to the stability of the interface between the kernel and userland, and that being “experimental” would mean the external interface is not maintained in the same way as other parts of the kernel. but now I’m thinking that the API/ABI stability is between different components within the kernel, and they want to “experiment” with making those internal interfaces more stable. do I have that right now?
That would be right, at least for the most relevant stuff like the filesystem discussions. It’s ensuring that when something changes on the kernel side (not userland facing) that the Rust code matches that.
ok that helps. so to go back to what kicked off this discussion:
Rust would be experimental and it would be entirely on the RFL members to ensure it stays up to date and correct, without blocking others.
so this means that the C kernel devs could change things that break RFL code and aren’t obligated to fix it, whereas if it were any other part of the kernel, the C devs would be obligated to fix it or make sure it gets fixed. right?
That’s about right, although there’s always some shared responsibility between the person changing the API and the callers (in RFL’s case it’s all on the Rust devs).
so if the reputation of linux is due to the C developers, then having a completely separate team develop code that people are told is linux could subvert the expectation that linux is developed by the same group that built its reputation.
that’s what I was getting at when I said “‘it runs linux’ no longer means it has the stability and longevity that could once be expected.” of course it’s a matter of debate whether the rust effort will yield better or worse stability/longevity, but the development process for M1 macs is not time-tested in the same way as the development process for, say, the thinkpad x13s. is that fair to say?
and do you think the recent debacle is a bad sign for the stability/longevity of linux on M1 macs? regardless of who you blame for it. I saw some other comments to that effect.
I’m not sure that the reputation argument is going to hold much water with me. Linux has a pretty bad reputation in my mind, but how it’s marketed is completely disconnected from that. I can’t tell you how things should or shouldn’t be marketed, or the complexities of layman making technical purchasing decisions, or how the experimental branch might change things, or what is or is not ethical to say about support for a Mac on Linux. If you want to say that Asahi is somehow wrong for something they’re saying about support or stability, you can do so, I just don’t think it’s relevant to RFL. If you want to see their messaging, this seems to be the relevant page: https://asahilinux.org/about/
but the development process for M1 macs is not time-tested in the same way as the development process for, say, the thinkpad x13s. is that fair to say?
Maybe? It’s really hard to say. Many drivers are poorly supported or maintained by far fewer/ less motivated people than Asahi.
and do you think the recent debacle is a bad sign for the stability/longevity of linux on M1 macs? regardless of who you blame for it. I saw some other comments to that effect.
It’s a bad sign for Linux in general, which, as I’ve stated elsewhere, is not going to be a dominant OS in the future because of upstream’s behavior and fundamental structure. In the short term I think the major impact is going to be that Asahi probably isn’t interested in staying out of tree forever, they likely had loftier goals and wanted this to be a larger project as a part of RFL, and so by upstream pushing RFL away Asahi developers will be pushed away/ fail to gain as much traction. I think this will be bad for Asahi and bad for Linux users, sure.
your answers have been duly noted. I take them as assurance that my original comment wasn’t completely off-base or reliant on a fundamental misunderstanding.
so if the reputation of linux is due to the C developers, then having a completely separate team develop code that people are told is linux could subvert the expectation that linux is developed by the same group that built its reputation.
There is no separate team. RfL is being done by regular kernel maintainers who happened to pick up an interest in Rust. Pretty much everyone (maybe literally everyone) contributing Rust code to Linux has contributed and continues to contribute C code.
then why the need for a different policy on who is responsible for what in regards to RFL vs the rest of the kernel? seems like a separation to me.
(please don’t mistake my use of “completely separate” as implying that there are no developers in both groups or that they are hermetically insulated from each other.)
then why the need for a different policy on who is responsible for what in regards to RFL vs the rest of the kernel? seems like a separation to me.
Because the vast majority of Linux maintainers do not know Rust, and therefore this experiment couldn’t be run at all if maintainers of C code were expected to fix Rust code when they make changes. And even if RfL is a complete success and Rust becomes a permanent part of the kernel, most likely there will need to continue to be a collaboration between Linux devs who know Rust and those who don’t, to keep Rust code up to date with changes in C interfaces.
Asahi linux and RFL are two different projects with totally unrelated stability guarantees, none of those guarantees have to do with the RFL code working.
in general terms it seems like if any of the rust code used by asahi is merged with the main tree, then the stability of asahi linux does depend on the stability of that code.
I’m wondering if we’re talking about stability in the same way? Are you talking about stability in terms of stable behaviors/ API/ ABI? Or do you mean in terms of crashing? The former is what’s being discussed with RFL, not the latter.
so if a casual linux user hears “linux runs on M1 macs,” then spends their whole paycheck on a computer with no ethernet or USB-A ports because of it, then too bad for them because they should have known that “it runs linux” no longer means it has the stability and longevity that could once be expected.
here I was referring to “stability and longevity” in the sense that would be relevant to a casual linux user, who may have come to expect that if a system runs linux it will continue to run linux for a decade or more with fewer crashes and bugs than a proprietary OS.
I am acutely aware that user concerns are conspicuously absent from the RFL discussion.
I don’t really follow your point throughout this. Is your concern that Rust will be less stable in the sense of less reliable or something? Or that Asahi Linux will be? I don’t really know how that’s relevant to RFL or actually anything that’s been brought up, or why you’re bringing it up.
as an uninformed casual linux user, over the past year I have gotten the impression that “linux runs on M1 macs,” and in another life this might have motivated me to buy one. with this news it seems like linux might not run on M1 macs for much longer, or might not gain the eventual reliability that I would normally expect if I hear that linux is getting ported to a platform.
I was under the impression that Asahi Linux was hoping to eventually depend on RFL for the practical aspects of reliability, and if it’s “entirely on the RFL members to ensure it stays up to date and correct,” then that is qualitatively less assurance than if the code is supported by the kernel team as a whole, as was once implied if linux is said to run on a platform.
I see. So yeah, I think it’s good to point out that the stability referred to in RFL conversations is in terms of behavioral stability, not things like bug fixes. Asahi is a downstream project, it is maintained separately, and its stability (in terms of not crashing) has nothing to do with RFL. Asahi users will continue to get patches for bugs as long as there are developers willing to do so, this is not related to RFL, although presumably Asahi wants RFL to happen to ease their development burdens etc.
I was under the impression that Asahi Linux was hoping to eventually depend on RFL for the practical aspects of reliability, and if it’s “entirely on the RFL members to ensure it stays up to date and correct,” then that is qualitatively less assurance than if the code is supported by the kernel team as a whole,
Right, so there are a few things here.
With regards to bug fixes/ patching, it is not up to the RFL members at all, it’s up to the Asahi developers, who work downstream. This is totally separate from RFL.
With regards to RFL, completely distinct from Asahi, the issue is not crashing it is behavioral and API stability. As RFL is “experimental” it is up for RFL to maintain interfaces that are up to date and not the C developers who maintain other code. Nothing to do with Asahi or bug fixes etc.
You might be under the impression that the Linux kernel considers stability to be a shared responsibility (ie: “everyone is responsible for bug fixes”) but this is not the case at all. Typically it is one developer maintaining a suite of drivers, a filesystem, etc, and they are the only ones responsible. There isn’t a big difference in reliability between something upstream or downstream, what changes is primarily on the committers side in terms of maintaining patches, others contributing Rust, etc, which is what RFL is about. If one of those solo committers/ maintainers left users would be just as fucked as ever - and this happens.
I see. So yeah, I think it’s good to point out that the stability referred to in RFL conversations is in terms of behavioral stability, not things like bug fixes. Asahi is a downstream project, it is maintained separately, and its stability (in terms of not crashing) has nothing to do with RFL. Asahi users will continue to get patches for bugs as long as there are developers willing to do so, this is not related to RFL, although presumably Asahi wants RFL to happen to ease their development burdens etc.
I still don’t get this part. doesn’t a lack of behavioral stability risk creating bugs?
if asahi’s stability “in terms of not crashing” doesn’t depend on RFL, how would RFL ease their development burdens? if some code that is needed for asahi to run is taken up by RFL, then woudn’t bugs in that RFL code affect the running of an asahi linux system?
I still don’t get this part. doesn’t a lack of behavioral stability risk creating bugs?
Maybe, but since Asahi is its own distro it picks its own kernel and userland, so the distro can just not upgrade userland components that would rely on some behavioral change in the kernel. They own that themselves so their users aren’t any worse off.
if asahi’s stability “in terms of not crashing” doesn’t depend on RFL, how would RFL ease their development burdens?
I think there’s a number of things that would play out longer term. One thing that RFL wants is to start to formalize some of the behaviors in the kernel so that their drivers can provide safe, stable interfaces, and reduce the burden for all developers in maintaining them. Asahi would then have less of a burden of development.
if some code that is needed for asahi to run is taken up by RFL, then woudn’t bugs in that RFL code affect the running of an asahi linux system?
Of course, but why would RFL change anything? The code has a bug or it doesn’t. The issue is things like relying on the behavior of the C driver vs the behavior of the Rust driver, which is why RFL wants to formalize those semantics.
I think we’ll probably start hitting the limits of my knowledge if we get too into the details of why Asahi wants to do one thing or another, RFL has numerous motivations. The tl;dr is that the stability discussed is about ABI/API stability, RFL would help Asahi because it would help them formally adopt the behaviors of the C code (by stating those behaviors vs those behaviors just being assumed by one maintainer), and Asahi users aren’t going to experience a less stable OS by virtue of RFL being “experimental” since RFL’s impact would only mean that the code lives in one spot vs another.
Maybe, but since Asahi is its own distro it picks its own kernel and userland, so the distro can just not upgrade userland components that would rely on some behavioral change in the kernel. They own that themselves so their users aren’t any worse off.
all else being equal, a decrease in kernel ABI/API stability would mean more work to keep up with changes and identify which userland components are safe to upgrade. for the same amount of developer/maintainer time, the system would be either less reliable or less up to date and their users would be worse off.
if asahi’s stability “in terms of not crashing” doesn’t depend on RFL, how would RFL ease their development burdens?
I think there’s a number of things that would play out longer term. One thing that RFL wants is to start to formalize some of the behaviors in the kernel so that their drivers can provide safe, stable interfaces, and reduce the burden for all developers in maintaining them. Asahi would then have less of a burden of development.
point taken.
if some code that is needed for asahi to run is taken up by RFL, then woudn’t bugs in that RFL code affect the running of an asahi linux system?
Of course, but why would RFL change anything? The code has a bug or it doesn’t.
presumably “experimental” code is more liable to have bugs.
Asahi users aren’t going to experience a less stable OS by virtue of RFL being “experimental” since RFL’s impact would only mean that the code lives in one spot vs another.
are you saying that Asahi wouldn’t rely on RFL code if it weren’t experimental? or that all of the RFL code relied upon by Asahi will inevitably come from the Asahi project, and would be in Asahi if it weren’t in RFL?
all else being equal, a decrease in kernel ABI/API stability would mean more work to keep up with changes and identify which userland components are safe to upgrade. for the same amount of developer/maintainer time, the system would be either less reliable or less up to date and their users would be worse off.
Right, RFL would presumably help that, which is why they want RFL so that they can go upstream.
presumably “experimental” code is more liable to have bugs.
Nope, not in this case. It just means it’s an experiment, if it isn’t successful it’ll get pushed back downstream.
are you saying that Asahi wouldn’t rely on RFL code if it weren’t experimental? or that all of the RFL code relied upon by Asahi will inevitably come from the Asahi project, and would be in Asahi if it weren’t in RFL?
Hmmm, I’m not sure what you mean. Asahi relies on the code that it relies on, that’s all. RFL would allow their code to live upstream, and would imply some things that RFL is pushing for like more defined behaviors of existing interfaces. That’s what I’m saying. Asahi will rely on RFL code when their code makes it upstream as “experimental”, otherwise that same code would be downstream but otherwise the same. RFL code won’t necessarily come from Asahi, certainly, anyone is free to try to push their own Rust code to upstream.
the paycheck I had in mind would be biweekly with taxes and benefits taken out.
but even your X/12 idea seems needlessly judgemental and paternalistic, and doesn’t account for savings and fluctuations in income. the average salaried indian makes $200-300 a month; median is probably much less. it would be irresponsible for them to spend that much on a computer?
The normal rules for intra-kernel interfaces are “you can break somebody else’s code, but you have to then fix it”.
But if you break some Rust code, it’s the duty of the Rust for Linux people to fix it.
The basic problem with getaddrinfo() is that it isn’t a DNS API, it’s a name service API, and the name service switch might look up names using /etc/hosts, mDNS, NIS, NETBIOS, who knows what else. Oh and probably DNS too. So the results you get from getaddrinfo() are very much a lowest common denominator.
Applications that depend on DNS specifics should probably pull in a modern stub resolver library, and avoid the ancient BIND-derived res_* functions. There are a couple of problems with this idea:
It might not be possible to get the recursive server IP addresses out of the libc resolver. Implementations have diverged since the BIND 4 days, especially wrt IPv6 support. Some resolver libraries parse /etc/resolv.conf themselves and try to do so in a compatible manner. Check support for fun things like scoped link-local IPv6 addresses.
The system might have a DNS cache that you might accidentally bypass. If that cache provides recursive DNS service on a loopback address it might be shit. You might be better off using a proprietary API instead. (Which is basically what the article concluded.)
The second problem is that it’s synchronous. Looking in hosts is fast and so that’s fine. NETBIOS is probably on the local network, so might be fast. mDNS is link-local and mostly served from a local cache. DNS may miss in a local cache and require a chain of synchronous fetches from DNS servers somewhere in the world, which may take hundreds of ms.
If you want to do one name lookup, that’s fine. If you want to do more, that’s a problem because the only way to overlap them is to have a separate thread for each.
Edit: this is a special case of the problem that a lot of transparent RPC systems encounter. It’s really hard to write software with performance that you can reason about when the latency of a call may vary by 3-4 orders of magnitude.
Applications that depend on DNS specifics should probably pull in a modern stub resolver library
I agree but I don’t think there is one, at least in C land your options are:
dns.c which is a suspiciously large amount of code for a not very complicated protocol (10k LOC), has a difficult API, and hasn’t been updated in 10 years
c-ares is a ridiculous amount of code (50k LOC)
rip out musl’s resolver, it’s not a lot of code but it’s split across 400 files and it all looks like this
It might not be possible to get the recursive server IP addresses out of the libc resolver.
The system might have a DNS cache that you might accidentally bypass.
i wouldn’t mind systems (the OS) just providing a (good!) recursive resolver on the loopback ip and listing it in /etc/resolv.conf. in other words: the dns protocol is the api.
then everyone can use their own stub resolver library with an api of their choice. the OS can do “smart things” in its recursive resolver (like redirect requests for internal domains to some other internal name server; macos has some config options for this in /etc that i have enjoyed but haven’t seen elsewhere; the system resolver could also do doh, etc). these stub resolver libraries may also look at /etc/hosts, but the system loopback resolver could even serve records based on that file too (and hopefully from a new file in /etc in zone syntax). going through a loopback resolver prevents the issue mentioned in the article with caching responses.
btw, is the /etc/resolv.conf syntax still updated at times? so stub resolvers could make use of modern features (i’m thinking of do[thq]).
it’s a name service API, and the name service switch might look up names using /etc/hosts, mDNS, NIS, NETBIOS, who knows what else
i haven’t used getaddrinfo much, certainly not recently. nowadays i (pretend to) live in a Go world, using the pure go resolver (https://pkg.go.dev/net#hdr-Name_Resolution), without going through the system libc resolver. works well for me. i’ve never expected name resolution to return names from mdns/nis/netbios, and i’ve never knowingly used nsswitch (perhaps i’m missing something great?). unfortunately, the current standard library go resolver api has the same issues as mentioned in the article with not providing access to the ttl, or the dnssec status, or the cnames followed (and their dnssec statusses).
This highlights why it’s important for certain sensitive use cases to use Signal behind Tor. Using Tor would mean that the cache serving the content would be the one closest to the Tor exit node, not the closest one to the end user.
It’s still pseudo anonymous because you’re not making a full tor circuit to connect to Signal and using the same account and traffic pattern out of the exit.
In the spririt of hoping to be corrected: it appears that most of these depend on either a running rsyncd (which I haven’t seen in 20 years) or the attacker having access to the source filesystem while an rsync is in progress.
Many vendors, especially those of open source operating systems, use rsync in daemon mode to sync build artifacts to various mirrors. HardenedBSD is one such vendor.
Edit[1]: Clarify how the daemon is run (rsyncd -> rsync in daemon mode.)
Their is a similar question open on the mailing list about whether the code is only active in rsyncd or maybe also when invoking rsync --server --sender via ssh (currently unanswered): https://marc.info/?l=oss-security&m=173688743232255&w=2
After a couple months of health issues between me, the missus, and our two dogs, I plan to finally catch up on studying for my OSCP cert. A few coworkers are starting a study group and I need to catch up on some HackTheBox challenges.
I also need to review some HardenedBSD merge requests. That, and I need to figure out which commit broke bhyve in FreeBSD.
Browser choice is not an ideology. It’s a pragmatic choice for nearly everyone. Chrome is simply consistently better. Shaming people for not using Firefox for ideological reasons won’t work.
If chrome disables the use of ad blockers, first of all most people won’t even notice. For the minority that do, chromium forks will emerge or they’ll switch to Firefox at that point.
I think this was true like … five years ago or so, but up to the point last year where I finally ditched Chromium altogether I wasn’t really seeing any difference whatsoever between the two.
If chrome disables the use of ad blockers, first of all most people won’t even notice
Honestly this is kind of sad. Ad blocking technology right now is far and away the most important User Empowerment thing we’ve got going for us. You have Linux Zealots going around trying to convince people to switch operating systems for abstract reasons that no one actually finds convincing, or trying to get people to stop using Facebook which has some serious social isolation downsides, but meanwhile installing an ad blocker takes like two minutes, has really compelling and self-evident benefits, and no down sides.
or trying to get people to stop using Facebook which has some serious social isolation downsides,
I don’t want to let this statement go unchallenged. I think it’s a harmful fallacy. Social interactions via “traditional” channels like phone, email, text and video conference are excellent.
We may not promote or educate people about them enough anymore, but they are more social than the often semi-anonymous and harmful interactions platforms like FB foster.
GP is right unfortunately. You lose awareness of many in-person events, and even among people considered friends it can be difficult to make the transition to more direct contact and not have it be weird. I’ve doubled down and accepted the cost for long enough that there’s no going back, though I wonder sometimes if it was really worth it.
The way to make progress on these kinds of problems is coordinating lots of people to move together. This is why Jon Haidt promotes Wait Until Eighth to keep kids off social media and so on.
Social interactions via “traditional” channels like phone, email, text and video conference are excellent.
Those technologies are fine, but they don’t offer the sense of “ambient humanity” that Facebook, Instagram, Twitter, et al. do. Those platforms allow you to lurk. It’s a very different interaction model from a phone call, where at least one party has to explicitly initiate it, and then both parties have to continue participating (at least for the best results!).
I do agree that there are still ways to get meaningful social interaction outside the big platforms. I have a bunch of SMS and iMessage group chats that allow me to keep in touch with close friends and family, and I can participate more actively or more passively depending on my mood and whether or not I have something to say. You could set up the same kind of thing on any number of chat platforms. But my point is that Facebook was never just a substitute for calling a friend on the phone.
That lurking is the worst aspect. Its the one that prompts people to preen on social media and to envy others and then lapse into depression, negativity or anxiety.
If anything since deleting my FB account I have been more socially active, because whenever I want to communicate something I text people or call them and I have an actual conversation, while before I would have broadcasted the thing to a bunch of people in exchange for some like…
Yeah, I haven’t actually used facebook so admittedly I don’t know what I’m talkitg about here; I should have said “perceived downsides” because it doesn’t matter for the larger point if it’s true or not.
I finally ditched Chromium altogether I wasn’t really seeing any difference whatsoever between the two.
There have been ups and downs in the competition between the two ever since chrome was released but chrome has always more or less held its own. It’s either been much better or about the same in this period. That’s why I used the word “consistently.”
Honestly this is kind of sad.
Strong agree with all of your reasoning here. The ability to provide a practical benefit like avoiding ads is a huge selling point for FOSS but instead people are finger wagged for reasons they will never understand.
Using Firefox mobile was noticeable slower (on android at least). On my new-ish phone (Samsung S23) it’s fine, but I wouldn’t was it’s for everyone. I love having extensions and supporting an alternative browser, but not everyone can afford high-end phones to just do browsing.
I think this was true like … five years ago or so…
I switched to Firefox for work a couple years ago and basically everything is fine except for a couple apps. For example, Grafana just cannot handle large queries on Firefox, it’s 90% of the reason I still have Chrome installed at all. I suspect that they only test it on Chrome and that there are just subtle differences in the JS implementations, so I wouldn’t say Chrome is “better”, but it certainly “works” in some cases where Firefox does not.
When people talk about what “most people” think about a topic, I don’t get who they’re talking about. I think most of my friends would care if Adblock was removed, and they’re a very diverse set of people.
I think most people do care about these topics like privacy and diversity in browser space, if you take the time to educate them as to why they should. No one cared about the environment nor democracy initially either, it took a lot of campaigning to get people to start caring.
if you take the time to educate them as to why they should
But that’s the entire point. The vast majority of chrome users dont use Adblock and don’t care enough to seek out education on Adblock. That’s just the reality.
The worst part of tech the past 20 years is consistently hearing over and over that technologists and their aesthetics don’t matter because the masses put up with whatever they’re force-fed.
If people want their browsers to track the crap out of them, that’s fine by me. I prefer a world of healthy alternatives. And I hate hearing that my values don’t matter. They do matter, and I know I represent a quiet but stubborn faction of people who see the internet not as five sites but the beautiful messy decentralized system it is.
We will take it back. It won’t be something that will be recognized by non-technologists for a long time. And that’s a feature.
Honestly, it’s not terribly surprising that webdevs allowed this to happen. They’re fed a steady diet of the web not being enough (just use Angle Reaction 24.8!) as is.
If people want their browsers to track the crap out of them, that’s fine by me.
… until you realize that these people are helping data-hoarding-bigcos track the crap out of you as well. Your neighbours scan your wifi and bluetooth devices, your contacts share your phone number, name and whatever data they happen to know about you (maybe they fill in your DoB, workplace or upload your picture), when you called each other, meet each other and such.
I prefer a world of healthy alternatives. And I hate hearing that my values don’t matter.
Healthy alternatives exist and you’re free to use them. Your values likely don’t matter to the majority of other people in the world, they’re your values. The world is a big place.
We will take it back. It won’t be something that will be recognized by non-technologists for a long time.
I think you’re underestimating how many people are on the internet and how many of them don’t care about technology at all but simply use it to get from point a to point b. This isn’t the mid 90s anymore.
Large companies who must behave according to data to survive understand this.
At least that’s what Google believes (they wouldn’t go ahead with the breaking change if they thought it’d cause too many users would switch away from Chrome), and they surely know their users better than we do.
But some of the users who don’t care enough can be made to care with a bit of advocacy, like in this article. Just like with environmental issues, it can take a lot of explaining to understand how important a topic is.
That’s exactly what people said about Internet Explorer back in the day, and how it got to be such a nuisance… Once a monoculture has become entrenched, it’s very hard to get rid of it when it ceases to be the better option.
I agree it’s a pragmatic choice, but the main way in which Chrome is “better” in 2024 is that everyone is already using it. Your peers would look at you a little funny for using something else, switching takes effort, and it isn’t obviously worse such that you’d be motivated to switch. At this point Chrome inherited its dominant position; it isn’t particularly earning that position anew by better addressing user needs. Not unlike Google web search.
Because maintaining a browser (or even, third party patches for a browser in this case) is a massive, time consuming, ongoing, never ending effort that requires constant reworking after every minor web change, or upstream change.
It’s simply not feasible for small open source communities to maintain a patchset as massive as this.
Because maintaining a browser (or even, third party patches for a browser in this case) is a massive, time consuming, ongoing, never ending effort that requires constant reworking
The same could be said of all work. Any serious endeavor requires constant labor, open source or not. The way we accomplish these things is by creating sustainable revenue streams so that we can fund the labor. The real problem here is that few people care about privacy enough to sustain this development effort. Ideology doesn’t pay the bills.
At a recent security event (National Academies thing on memory safety a couple of weeks ago, I think), someone mentioned that Chrome has an average of one security issue that needs patching and fixing every 1.5 days. The team has to create the fix, test it, and roll it out in update channels that often, in addition to adding new features. Doing that while also being downstream from the company that is doing the work upstream is incredibly hard.
Doing that while also being downstream from the company that is doing the work upstream is incredibly hard.
I don’t deny that it’s hard but clearly it can be done if someone if willing to fund it. Many people are claiming that browser privacy etc. is an important feature for users that chrome is increasingly ignoring but if that were true, where is the demand for such a browser feature? It doesn’t exist in any significant way, at least enough to fund a browser that prioritizes this issue, therefore we must conclude that most users don’t really care about browser privacy and it isn’t an important feature.
It’s not just a matter of funding; it’s also a matter of time. No amount of funding is going to provide more hours in a day. The time it takes to maintain a project downstream is time spent away from family, friends, and those other things dearly held.
It’s not just a matter of funding; it’s also a matter of time.
Time is money. More salaries fundraised equates to more full time labor being allocated to working on this. There is nothing written in stone that privacy-oriented browsers must only be worked on during one’s free time.
This is way different in that the third party project doesn’t initiate the changes, and the upstream project is extremely big - there’s a massive, well-funded company working on this highly technical and complex project with lots of churn. And over here you have a handful of unpaid folks even just trying to parse what they’re doing upstream, and then having to rebase their own work onto those changes.
Sure that’s a pretty fair assessment of the situation. I agree.
We should ask “why” so few care. They can’t be bothered? Lack of tech education? Lack of interest? Probably a combination of all of that.
I find it strange that people who complain about a Chrome monoculture would prefer to have a Firefox monoculture in their circle of friends.
And it’s not as if Mozilla is the friendly David against the evil Goliath. One of Mozilla’s founders posted rather recently:
Now hear me out, but What If…? browser development was in the hands of some kind of nonprofit organization?
Mozilla has become a company of bad decisions over the last twenty years. “It’s not Chrome” is insufficient as a major advantage - in my opinion; neither are SeaMonkey, NetSurf, Ladybird and so on. And they are all far less profit-orientated; hence: they are all far less exactly like Google.
Nowhere in this article does the author wish for a Firefox monoculture, among their circle of friends or otherwise.
It is a plea against a Chrome monoculture, and (thanks to very bad decisions by Opera and Microsoft) from any cross-platform perspective, that practically means being a plea for a healthy balance between Firefox and Chrome-derivatives. There is also Safari (I’m a happy user), but Apple killed off the Windows version.
At the point where someone is both a web developer and the only person you know, among all web developer colleagues, who doesn’t use a Chrome derivative, we’re fucked. That’s how you end up in a vicious cycle of poor website cross-browser compatibility caused by lack of cross-browser testing making Firefox less attractive for users, making developers less likely to test on it, etc. (From this perspective, suggesting browsers such as NetSurf and Ladybird that don’t reliably support any given vaguely recent CSS feature is missing the point even more badly.)
Nowhere in this article does the author wish for a Firefox monoculture, among their circle of friends or otherwise.
I understand the author to mean that he wouldn’t have a big problem with 90% Firefox market share. I mean, at the end of the article he asks people to use Firefox; what if everyone does?
suggesting browsers such as NetSurf and Ladybird that don’t reliably support any given vaguely recent CSS feature is missing the point even more badly.
I did not do that. Quite the opposite: I pointed out that “not Chrome” often means “not useful for most people”. (Although I actually like NetSurf, but I don’t use web applications much.)
The reason why the article doesn’t have large, flashing disclaimers warning to avoid giving Firefox too much market share is because its user-base is so small that it’s infinitesimally unlikely. Chrome, Chromium derivatives and Safari are bundled in major operating systems. Microsoft and Google also control key websites and services where they can add special interoperability and advertisements for their browsers, while Apple straight-up prohibits other web engines on iOS.
Firefox is just the default browser on some Linux distributions. It’s not overtaking them anytime soon, even if they start innovating and take back Servo.
It’s not overtaking them anytime soon, even if they start innovating and take back Servo.
One of the reasons for this is that for many years Mozilla has shifted its focus away from developing what it considers to be the best web browser and towards generating as much profit as possible. (Just have a look at what their CEO earns). They won’t innovate anymore, which is actually sad to see.
thanks to very bad decisions by Opera and Microsoft
Why is it bad that opera and Microsoft adopted the chrome engine? Really, why is a browser monoculture bad? It seems like you’re saying a “poly culture” is good for its own sake.
I can see that the reason why the IE “monoculture” was bad was because the browser wasn’t open source. Since chrome is open source, I don’t see any sort of existential monopoly on browser development being held by Google. The problem wasn’t a lack of diversity of browser usage.
But that’s not being compelled by law or force. Anyone can contribute or fork, and many have. It’s not google’s fault that they are one of the few entities investing in browser development. This is not Microsoft keeping others out.
there are sites that don’t work on anything but Chrome
There are sites that only work with JavaScript too, sucks for me. That’s not chrome’s fault. Nor is it even necessarily a fault. The web is decentralized, complain to the webmaster. Or would you like to enforce all websites work the way you want them to from a central authority?
People don’t even know or care, but some do.
Most don’t care but those that do are free to use another browser.
I can see that the reason why the IE “monoculture” was bad was because the browser wasn’t open source.
No, a major reason that it was bad was because people were stuck on it, not knowing any better even if better options were available (and they were - Opera, Firefox and later on Safari). This was a problem for two reasons:
Web developers had to bend over backwards to support this broken old browser
Web developers were unable to use new improvements on the web like CSS 3, transparent PNGs etc
The browser being open source would not have helped - it was installed by default on the world’s most dominant operating system and users had been trained to click on “the blue E” which basically represented “going on the internet” for them. In corporate environments, machines are often locked down to the point where regular users are unable to install new browsers, and getting IT to support a second browser is a fight you probably won’t win.
Note that the conditions that kept people stuck on IE are still true for Chrome.
Any monoculture is bad. OpenSSL and Crowdstrike are two very recent tangible examples as to why we need more software and hardware diversity. Otherwise, we’ll end up in a “one bug to rule them all” state, exploitable by any and every bad actor. Diversity mitigates that by providing a resilient ecosystem.
There are pros and cons to both monoculture and polyculture. You’re overweighting monoculture’s cons and underweighting its pros. Monocultures benefit from lack of redundant work and standards-overhead. Monocultures benefit in security by having more eyes focused on the problem, e.g. in Linux. Monocultures aren’t bad in themselves, nor are polycultures good in themselves. Rational evaluation requires looking at the actual pros and cons in any given situation.
I’m gonna make up a few hours at ${DAYJOB} lost due to the lack of advanced notice of CVE-2024-6387. And I want to work on unpacking the boxes in our garage. I hope to eventually set up a lab desk in the garage, and have a place to put the car during hail storms.
Wow. I thought PasswordAuthentication no & PubkeyAuthentication yes were like table stakes, sure. I thought accept 0.0.0.0:22 wasn’t that bad. That was yesterday, I guess.
I think table stakes these days is: services on your machines should be behind a wireguard / tailscale VPN unless they absolutely need to be public. That includes ssh - if you’re connecting from a fresh laptop / phone then it has to authenticate itself to your VPN first.
(I note that I haven’t actually reached this security nirvana myself, but I’m working out how to get there…)
The tailscale client is small, opensource & written in Go: It’s probably more secure than ssh based on the evidence to date?
Someone could attack the server-side of course & you can make your own security tradeoffs but if someone has to compromise both the tailscale auth server & ssh to gain access then you’re probably better off than with ssh alone?
Most folks tend to use a Wireguard implementation that is backed by a kernel module. Now your attack surface includes additional kernel code. Just something to keep in mind.
I really need to organize my home office better. I have a hard time knowing how best to organize the various bills and pieces of mail that can’t be immediately discarded. Both my main desk and lab desk are covered in paperwork and cables and I’m really starting to feel claustrophobic.
I might see if I could deploy a server that is just gathering dust. I’d like to see if I can get a lab VM host online. I lack confidence that I have enough power capacity.
I’m preparing for next week: BSDCan! I’m going to bore the missus to sleep by rehearsing my HardenedBSD presentation enough times that I’ve got it memorized.
I’m also hoping to fix a few ports in HardenedBSD 15-CURRENT now that we have set _FORTIFY_SOURCE=2 across the entire ecosystem (base userland and ports).
I literally just finished deploying HardenedBSD 14-STABLE on a brand new Dell Precision 7680. It’s an Intel Raptor Lake laptop with a discrete NVIDIA GPU, Intel wireless, 64GB RAM, 1TB NVMe. The ONLY thing that isn’t working is the trackpad. I’m assuming that’s because the vendor IDs haven’t been updated in the kernel. I’m assuming that’s an easy fix.
I don’t think the default scheduler has been taught the concept of P/E cores. I know there has been talk on various mailing lists about the subject, but I’m unaware of any tangible movement. For now, I’ve disabled the E cores.
I would be interested in learning about the security aspects of P/E aware scheduling. I could envision a scenario where explicit_bzero might take longer on one core versus another. But I’m wholly ignorant of both the inner workings of the default scheduler and of the underlying CPU model.
I would definitely volunteer as a guinea pig to help test patches to teach the scheduler the concept of P/E core types.
Improved scheduler performance, including the ability to more appropriately spread load on a mixture of slow and fast cores (e.g. big.LITTLE Arm CPUs).
Not sure if its only ARM related or more ‘generic’ but I think its a good place to start if FreeBSD has ‘zero’ hybrid CPU awareness (IMHO).
I’m going to expand power capacity to the server room at ${HOME}, specifically needed for the HardenedBSD dev/build infrastructure. Yesterday (Thursday), the portable air conditioning unit tripped the breaker while I was running errands, and the server room got to 91F. I’m hoping to add two 20A circuits to the room and put my home office on its own circuit.
Your real name should not be an anonymous id or false name that misrepresents who you are.
I 100% agree with this — I think it is fine if people use pseudonyms or misrepresent their real names in stuff like online gaming, but somehow I feel like this is not okay in the open source world. If I am a company running code, I don’t want to run some code from a user “pinkkitty31”, rather I want to run code submitted by a “Michael Smith” who has signed a CLA and verified his identity to be held accountable.
That being said, I don’t want that to be enforced. I don’t want people to have to prove their identities when signing up for GitHub, for example. But I would like to see major software projects adopt this on a voluntary basis, so that we as a community can do our best to reduce the ease of which supply-chain attacks can be performed. The xz attack was caught, thankfully. But this is not the end, it is merely the beginning. Russia and China lost this one, but they have an abundance of cheap labour and can keep doing this all day, and some day we will not catch it, and the implications will be grave. So I would rather have pinkkitty31 give up his legal name than live in a world where we allow state-actors to perform these kinds of attacks.
There was recently a story about someone interacting with a “company” where everyone on the video call was a virtual person generated by what’s nowadays called AI. In other words, we can assume that in the short to medium future faking your identity online, even via a video call, is as easy as doing it by email/text.
And if you’re motivated enough, you can hire an actor to portray the person you want to present yourself as. Once that person has been introduced IRL, signed papers, gotten the hardware signing key etc, they just hand it all over to the “bad guys” and disappear forever.
MORE IMPORTANTLY
why should FLOSS maintainers and project leads shoulder the responsibility to vet contributors for honesty and integrity??? The software they are offering for free always has a license file disclaiming all responsibility. If you choose to base your company on such software, you also assume the risk. You can mitigate this risk, by reading the source yourself, hiring someone to do so, funding a sort of Underwriters Laboratories-style outfit, etc etc. What you cannot do is force people to do all this for you, for free.
There seems to be some weird sort of bad conscience among some people withing FLOSS. “We need to step up, we need to be grownups in the room, we need to take responsibility”. No, no you don’t. Seek to get more funding for FOSS. Ensure that existing and future bad workflows are corrected. But don’t take the security of multinational corporations on your shoulders.
I agree with this! We’re in a weird spot of where the world’s infrastructure is built on top of open-source projects with little time and funding.
we can assume that in the short to medium future faking your identity online, even via a video call, is as easy as doing it by email/text
Agreed! AI doesn’t exactly help here. It can be made harder (by requiring verification) but ultimately, it is a force multiplier.
why should FLOSS maintainers and project leads shoulder the responsibility to vet contributors for honesty and integrity?
They don’t have to, but I am assuming that some projects will have an interest in making sure their code is somewhat protected from such bad actors in the future. But you are right — FLOSS maintainers don’t have to do anything, the software is provided as-is, without warranty.
In the US, there is no such thing as a legal name. (This is an authoritatively cited law review article.) Normatively, there shouldn’t be. My family, friends, colleagues, and strangers address me in many different ways as appropriate for the different situations, all of which are more “real” than what some office has decided it wants to call me. There’s strong evidence for the value of this in studies that show using chosen names produces better outcomes than imposing names (recent example, or deeper understanding).
I don’t quite know how to make sense of the document you have linked. It seems to address some gripes that trans people have with legal names. It does not seem very relevant to my point, and does not dispute the existence of legal names (as is on your social security/birth certificate/driver’s license/passport, which are mentioned in the document, see page 135).
Whatever you call it, by Legal Name I am referring to the name that is on your identity documents. The US does have identity documents. It does not even have to be a name, you could substitute s/legal name/legal identifier/. Just something that uniquely identifies a person. It could be an Ed25519 key for all I care, as long as there is a regulated registry, such that submissions to open-source software is linked to a person rather than a pseudonym. I suppose in the US you could use a social security number for this purpose, though I don’t understand the identity-theft implications of that.
I’m also not saying that people cannot keep using nicknames or pseudonyms — they are useful in communication. Just that it seems quite risky to have an entire civilization build on top of software that is written by people anonymously, it seems like a big attack vector.
I didn’t say people had zero legal names, I said people have many. The point of the law article is that there is no unified definition of a legal name in the US and there is no restriction to a single legal name. I personally have valid US identity documents with different names on them. As in the legal article’s examples, some of them are due to technical limitations, some are due to people having different names in different contexts, some of them are mistakes, some are changes over time, some are federalism, etc. I think trans people come up many times in the article because they prompt many examples that are unfamiliar enough to be recognized, where, say, the familiar complexity of marital name changes vanishes into the background.
As a political belief, I do not consider any name a state or business assigns me to be more real than the names I choose to use. As the book explains, imposing a single simplification on civilization’s historical complexity often fails even at its intended purpose.
I understand what you are saying, but I still disagree with your point. I interpret the fact that you have multiple valid US ID documents with different names on them not as evidence of the fact that you can have multiple legal names, but rather as evidence of the fact that the system is broken. I admit that this might be my German/European perspective talking, because this stuff is very regulated here: you, at any point in time, only have one legal name, which is on your birth certificate, ID cards, passports. Any place that matters (banks) will verify your legal name with your ID card. If you manage to have valid documents under differing names, this is either fraud or an error. In fact, it is a felony here to put a false name when signing up for something (even Facebook, although in practice it is not widely enforced, only banks will enforce it, because they are liable if they don’t). I don’t think it is fair to draw conclusions from the brokenness of the US system to discredit legal names as not something approximating “useful identifiers”.
Besides: Even if a person can have multiple legal names, this system will still work. If there is some CLA that you have signed and it was verified against your ID card, and it calls you “J. R. Porter” but your legal name is “Jordan Ryan Porter”, then it is still close enough to be a match. Even if you change your name at some point — I know people who have done this, for various reasons — there is a paper tail of this happening. Both your previous legal name and your new legal name can be resolved to your identity.
Obviously, there will be edge cases. We will never have anything perfect, unless we get a copy of your biological identifiers (DNA, iris). But we don’t need perfection, all we need is to make it harder for bad actors to infiltrate open-source, and if they do, it gives us some ability to hold them accountable. Accountability is practically non-existent today. We don’t know who “Jia Tan” is, and maybe never will, just because there is no system in place that verifies identities.
You are welcome, though I did not realize that this was a political issue.
But, to my original point: would you not agree that it would be advantageous if core infrastructure (openssl, core libraries) had some form of an audit trail that would allow us to link contributions to people’s identities in an effort to thwart supply-chain attacks that we will inevitably see more of in the future (even if this was not based on legal names)? I feel that long-term this is the only way to protect against state actors with a lot of manpower, such as China, Russia and North Korea.
You are welcome, though I did not realize that this was a political issue.
I don’t mean this in any inflammatory way, but your particular stance here aligns here with authoritarianism (in an overall sense) — some authority gets to designate your identity in a way you cannot negotiate or opt out of.
This rankles many folks who have a range of concerns over such things, from the more ‘crackpot’ types who think that a government trialling digital ID (in the global (non-EU) West, in the year of our lord 2024) must be wanting to microchip everyone and deny you the ability to buy food unless you submit to them (none of whom have ever seen how Europe does it [1]), to those who have very good concerns — two examples that come to mind immediately are folks working on deniable cryptography who operate in less secure countries, and trans people.
At any rate, talking about names and identity is an issue of incredible political heat and importance, and many, many words have been spent on it in the past decades.
[1] at the same time, European countries’ implementations usually have some very good legal safeguards involved and tend to be co-ordinated closely by the government acting under those laws, whereas implementations elsewhere are often, uh, lacking, implemented often by a range of independent companies all trying to undercut each other, with a much shakier legal backdrop.
your particular stance here aligns here with authoritarianism
It is always funny to me when authoritarianism is mentioned in threads. I feel like you are attacking me because you disagree with me, and I don’t feel that this is nice. But I will take your criticism seriously and address it in the best way I can.
I believe you either misunderstand my idea, or you misunderstand authoritarianism. Feel free to clarify what you mean to avoid confusion. Authoritarianism means the enforcement or advocacy of strict obedience to authority at the expense of personal freedom.
What I am talking about is an idea that open-source projects can adopt, if they want to. Being opt-in, it is by definition not authoritarian.
The idea is to verify the identity of the people that contribute. This should not be inflammatory in any way. It is standard practice to require an ID document to participate in society. This is neither novel nor unusual. For example:
getting a job
registering a vehicle
getting a driver’s license
opening up a bank account
For any identification to work, you need to have a trusted authority. By design, you cannot opt out or negotiate, then you would be able to change your identity (which undermines the whole thing, because then bad actors can do it again). If you consider it authoritarian to require identification, then you are saying that the entirety of the western hemisphere is authoritarian.
I also mentioned that folks who simply do not have an ID don’t need to do this verification, any system needs to have flexibility built-in to allow for the realities of life. This means that nobody is excluded who lives in a country that does not or will not issue an ID. Therefore, this system is not strict, states cannot withhold ID to prevent you from contributing. Therefore, not authoritarian. Projects need to weigh their needs for security, their time for proper code review and the need of the public to participate. Life is a tradeoff.
two examples that come to mind immediately are folks working on deniable cryptography who operate in less secure countries, and trans people.
Since the knowledge of the identity would be kept by the open-source project maintainers, I see no issue with anyone submitting to this. If you don’t want to verify, then you do not need to contribute to the particular project that enforces it. Err on the side of caution. If there is a legitimate reason not to verify and share PII, then it is always possible to talk to the maintainers and skip verification, and have your contributions be subject to more scrutiny. This procedure is not designed to keep people out. It is just designed to safeguard open-source projects.
At any rate, talking about names and identity is an issue of incredible political heat and importance, and many, many words have been spent on it in the past decades.
It is new to me that names are something political. I feel a bit uneasy now, it feels to me like there is some amount of bias here on this topic, and it should not be. My comment, which is a reasonable idea and something that a majority of financial services do, is treated as if this was a radical idea designed to oppress. My advice would be to reflect on your opinions, or perhaps suggest an alternative way to keep open-source safe. Perhaps there are better ways of doing this?
I feel like you are attacking me because you disagree with me, and I don’t feel that this is nice.
I have tried my best to avoid this (opening with “I don’t mean this in any inflammatory way”, giving examples from “both sides” of the political spectrum, etc.), and it would appear I have failed; that’s my bad!
What I am talking about is an idea that open-source projects can adopt, if they want to. Being opt-in, it is by definition not authoritarian.
I think this is a little naïve. If an idea of a particular political thrust takes off and becomes widely adopted, then there is a de facto (and perhaps in future de jure) implementation of a particular way of thinking. Facebook’s “Real Name” policy was a step in that direction, and carries many of the issues that your suggestion does.
If you consider it authoritarian to require identification, then you are saying that the entirety of the western hemisphere is authoritarian.
In so many cases it is, when it comes to marginalised peoples. This is not news. Are you seriously saying you’re unaware that folks in the western hemisphere struggle with getting a job, opening a bank account, getting a driver’s license, voting, getting medical attention, etc. etc., solely due to ID issues? These issues are rampant.
This means that nobody is excluded who lives in a country that does not or will not issue an ID. Therefore, this system is not strict, states cannot withhold ID to prevent you from contributing. Therefore, not authoritarian.
Let me zero in on this. Let’s say your country does not allow name changes in the case of trans people. (Or perhaps you can change your name, but you’re not allowed to change your surname to have the masculine or feminine ending as appropriate, and therefore your legal name still contradicts your identity.)
But your country still issues ID, so your policy mandates they use it. Now your policy is enforcing a particular country’s political ideas on identity! This is extraordinary.
It is new to me that names are something political.
My advice would be to do some reading of your own if this is new to you; I meant it when I said decades!
The heat here has increased enough that I’m bowing out here, but I wish you all the best.
If an idea of a particular political thrust takes off and becomes widely adopted, then there is a de facto (and perhaps in future de jure) implementation of a particular way of thinking. Facebook’s “Real Name” policy was a step in that direction, and carries many of the issues that your suggestion does.
I understand that people want to use Facebook pseudonymously, even here in Germany we have a court decision that allows for this. However, the things you post on Facebook don’t power every single computer system in the world. The implications are not the same, I don’t think it is a fair comparison. There is no fundamental reason for Facebook to know your true identity (although, Facebook does have a problem with criminal activity going on).
In so many cases it is, when it comes to marginalised peoples. This is not news. Are you seriously saying you’re unaware that folks in the western hemisphere struggle with getting a job, opening a bank account, getting a driver’s license, voting, getting medical attention, etc. etc., solely due to ID issues? These issues are rampant.
I think I would need to see some evidence for that to believe it. It might also be a US thing. I can tell you that here in Europe, I have yet to hear about a single case of someone having issues with their ID. I can tell you many cases of people struggling with bureaucracy, but that is an entirely different issue (understaffed and inefficient governmental agencies).
Let me zero in on this. Let’s say your country does not allow name changes in the case of trans people. (Or perhaps you can change your name, but you’re not allowed to change your surname to have the masculine or feminine ending as appropriate, and therefore your legal name still contradicts your identity.)
But your country still issues ID, so your policy mandates they use it. Now your policy is enforcing a particular country’s political ideas on identity! This is extraordinary.
This is where you are wrong! This scheme does not enforce any political ideas. The identity is used for verification purposes, and for nothing else. I’ll give you an example:
Let’s say you are “Peter Smith”, but you feel more female and therefore go by “Katherine”, or “kitty69” online. You have not or cannot change your legal name to reflect this.
You want to contribute to OpenSSL, so you verify (using your governmental ID) and sign the CLA. Since your legal name is “Peter Smith”, that is the name you verify as. This verification is only between you and a maintainer, and the signed CLA with your real name goes into a safe.
After the verification, you contribute as “kitty69”. Your true identity (“Peter Smith”) is protected and not revealed to anyone else. The only time where that true identity is looked at is when there is evidence of you contributing harmful code.
The heat here has increased enough that I’m bowing out here, but I wish you all the best.
I’ve toned it down a bit. While we may not agree, it is a useful discourse. I hope I did my best to try and show you how this system could work and why it should not be an issue.
Counter-question: How does using TLS certificates defend against attacks, when a state security agency can trivially mint new certificates and man-in-the middle connections?
We can never achieve perfect security. All we can do is make it harder, and more expensive. And requiring identification is certainly a higher burden than just registering an account on GitHub, which takes 10 seconds.
Good grief, you are the one that proposed a specific defence against a specific attack. You should at least be able to explain how your proposal is effective without diverting on to a different topic, or dragging the goalposts over to vague generalities.
I believe that I gave a useful explainer, but I can try again:
There are various kinds of potential threat actors, not all of them have the ability to mint ID cards. For example, consider a ransomware group. They likely do not have the resources to do it. This scheme would keep them out.
Defending against nation-states is extremely difficult. They might be able to create valid IDs for their own countries. However, taking the cost of performing this attack from zero (a GitHub account) to a higher cost (needing to mint an ID) makes it harder to perform. It would also give away the nationalities of the attackers, which is data that could be useful to us.
This is not the ultimate defense. Secure systems consist of multiple layers. This, combined with thorough code review allows us to raise the bar of performing these attacks.
I’m not tied to this scheme, but I feel that in practise it has the best cost-reward tradeoff. If you have a better idea for how to do this, I would love to hear it!
Can you explain how a CLA would keep a ransomware group out?
Hey Tony, what I meant by that is that ransomware groups likely don’t have the resources or access to mint new identities, such that they would have to use their real identities. Which, if a group is based in North Korea, could give away some clues. Additionally, it would allow bad actors to be marked and prevent them from participating in other projects in the future. I feel like I have explained that before, I hope you can see how that makes sense. It is not a perfect defense, it is a layer on top of the processes we have already (code review, fuzzing, etc). It is a better situation than we are in now, where a single person can create GitHub accounts all day and create fake personas. Jia Tan could already have other personas committing code to the Linux kernel, curl and other foundational projects, for all we know. Do you see how identities could make this significantly harder (but not impossible)?
You are being ridiculously naïve.
Ouch, there is a nicer way of saying that. In general, for a productive conversation it is important not to fling (perceived) insults at other people. A better way of phrasing your feelings here would be to say: I am afraid that your threat model of ransomware groups is too simplistic, I feel that you underestimate their abilities and links to nation-states. That would be a much better way of expressing what you think without coming across (even if unintentionally) as hurtful. You should always use “I”-expressions rather than “You”-expressions to avoid this.
You are also failing to take into account the cost of your scheme in terms of wasted maintainer time and lost contributions.
This system is unlikely to be implemented due to the burden it places on maintainers and due it driving away possible contributions. I acknowledge that.
My comments are more me thinking loudly on something we could possibly do, because I don’t want to live in a world that is so easily thwarted by bad actors. And to be honest I’m a bit frustrated because I feel like multiple people in this thread are trying to tear my idea down needlessly, rather than trying to suggest better options.
In your opinion, what do you think should core-infrastructure open-source projects do to protect themselves from threat actors?
My comments are more me thinking loudly on something we could possibly do, because I don’t want to live in a world that is so easily thwarted by bad actors.
The only reason this actor/group/whatever went through the considerable effort to craft this backdoor and delivery method is that up to 77% of software used in corporate environments is open source (source). If there was a blanket ban on FLOSS in companies, this would not be profitable to do. So you’d root some hobbyist machines, who cares?
Now, I’m not sure what you mean when you say “we”. Maybe you’re working for a company that relies on FLOSS. Fine. Then that company or an association of companies should take responsibility and fund mitigation efforts.
when we take software from the commons, we are like raccoons digging through a dumpster to find something useful. There is no “supply chain” in reality, but there is an effort by corporations which consume software from the commons to pretend there is one in order to shift the obligations related to ingesting third-party code away from themselves and to the original authors and maintainers of the code they are using.
Don’t be gaslit into thinking there’s a “FLOSS supply chain”, nor that securing that “chain” is the responsibility of the FLOSS community.
Took me a little sleeping on it, but I think Worse is Better gets at the heart of the disagreement on this idea. You’re advocating for a maximally effective system to impose on the chaos, and I’m trying to say there’s irreducible complexity in the problem space and a single system would do more harm than good.
There’s the classic Falsehoods Programmers Believe About Names. I’ve shared this author’s experience of being in a country that doesn’t use the latin alphabet and having a name contains phonemes or vowel patterns that the locally popular languages don’t. The resulting mistakes are charming right up until the force of law imposes grave, irreconcilable inconsistencies. I’ve put together a few databases so I know to reach for Unicode, to model one-to-many alternate representations, to use bitemporality and attestation, to write training manuals for the frontline bureaucrats. But I’ve put together so many databases and business processes that I don’t think it’s possible to capture the complexity of human names, let alone human identity, let alone at a reasonable cost, let alone without allowing the state abuses that have resulted from every one of these systems previously attempted.
To put it another way: you sketch out an identity standard to increase the cost of attacks but the attackers most likely responsible for the xz backdoor and the specific attackers you list are the entities most able to afford those costs and in the best position to subvert such a system. My criticism here comes down to this system being fundamentally ineffective and inhumane. As a programmer I’m vulnerable to the siren call of simple, elegant systems, I want better to be better, but this plan has crashed into the rocks before it sets sail.
Hey Peter, I will summarize my stances on the points you’ve raised:
I do think that, given what I know, this system is the best I can come up with. I also think it is quite unlikely that it is implemented. I disagree with the idea that it does any harm at all, the only way it would do so is if it were inflexible, keeping people out that simply do not have identification. You can never build a system that is perfect, therefore it needs to have some flexibility built-in, and this one does.
The issues raised around names and alphabets all assume that the legal names are stored in any kind of database, which is not the case. As long as someone is capable of writing their name on a piece of paper (a CLA), it will work. If they can’t, the system is flexible enough that we can skip verification for that person, this is an edge case that is so rare that it is unlikely that any one of us would ever see it during our lifetime. Therefore, all of those concerns are irrelevant.
More powerful attackers have more resources, this is true. But even just raising the cost associated with an attack is a net win. By your argumentation, we should have stayed with 52-bit cryptography, because state actors probably have the resources to crack higher-bit cryptography. But we know that, even if algorithms might have attacks on them we don’t know about (or cannot do yet, like post-quantum crypto), we should strive to make it as difficult as possible to perform such attacks. This idea does that, by making it more difficult to forge an identity. We will never have truly unbreakable cryptography, we just have some that are too costly to crack with our current technologies and energy supply. We can never have a fully secure system for open-source, but we can think about adding some layers to it that make it more costly to attack.
My biggest concern is that software is fundamentally built on trust. There is a popular saying that goes “trust, but verify”. This idea is that verification part. I think it is very risky to build software the way we do right now, where identities can easily be spoofed and we do nothing to address that.
I think I have laid out my arguments in a fairly straightforward manner, I hope they make sense, even if you don’t agree with them. I think it is fair to say that we agree to disagree. The beauty of a pluralist society is that we can all hold differing beliefs. Often times, there is no single perfect answer to a problem (not yet, or we don’t know enough that we can identify it as such even if there is). All I hope is that we will not see successful infiltration attacks like these, and even more so I hope that they do not lead to the loss of human lives. Software is everywhere, we are more vulnerable than we are aware of.
I have multiple distinct legal names in my different countries of citizenship, one of them indeed being an EU member state. (They’re not even related forms of each other, not in given or last names.) What is my unique identity?
Real, human systems don’t work this way. Humanity is many ways about the lack of machine-like processing of rules with a precise system of identity and recognition that admits no exceptions. (Jean-Luc Picard: “there can be no justice so long as laws are absolute.”) Names are neither singular nor static.
My choice of the word unique was perhaps not quite wise. I meant it in the sense of “uniquely identify”. But even that is not really what I wanted to say. More like, “given your nationality and name, we roughly know who your are, or at least we know enough to be able to sue you”. If people were born with UUIDs, we should use those. Sadly, that is not the case.
Indeed, multiple countries might have a different idea of what your legal name is. Every country is it’s own authority in determining a person’s legal name in their system. As pushcx has pointed out, in some cases even a single country might have different ideas of what your legal name is.
In your case, all of your identifiers are valid. If you have a French passport with the name of “Loïc”, then (France, Loïc) is a valid identifier for you. It is enough information to bring forth a lawsuit in the case you do something illegal. Such is the case for the other passports you hold.
My phrasing was perhaps not clear or incorrect there, but I think that this is not as complicated as you make it sound. I don’t quite understand why it is that we need to get hung up on talking about names, when my point was merely that we should have an audit trail (could be linked to anything, like a social security number, or whatever). I did not want to veer into politics and defend names, they are merely the most common identifier for people in use.
Just that it seems quite risky to have an entire civilization build on top of software that is written by people anonymously, it seems like a big attack vector.
Most open source is pseudonymous, identifying contributors by their usernames or email addresses. Anonymity (actual lack of name) is very rare.
You are correct, I misspoke. s/anonymous/pseudonymous!
Haha oh dear my sweet summer child.
Thank you for posting that, it is a great article. I am aware of it, it was posted here some years ago I believe. 😄
I should perhaps clarify what I mean, because I don’t think anything discussed in this article is an issue for the scheme I am proposing. What I am thinking is that, for a given open-source project (let’s take openssl for example), anyone who wants to contribute has to sign a CLA (on paper), go on a short video call showing his/her signed CLA (with his/her handwritten name on it) and show an ID document to match the hand-written name to the one on the ID. Then the CLA is snail-mailed in to the developers, which keep it in a safe. After this process, contributions from this person are accepted. This does not require much from names, doesn’t even require that they are mapped into Unicode, or that you can parse it in any way, just visually compare.
If you live in a country that doesn’t have IDs, or doesn’t use names at all, well then you just don’t do this step. This encompasses so few people that we can just not do the verification for those people. These systems can never be fully rigid; they have to allow for some flexibility. The purpose of this is not gatekeeping.
In the event of a compromise, the true identity of the actor is known to the maintainers of the project. That is the point of this, so that when we detect something, at least we know whom to sue.
Obviously this system is not perfect: ID cards can be forged, there could be human errors in comparing them, people might live outside of our jurisdiction. But it is not designed to be perfect, it is only designed to make it more difficult for state-actors. Today, it is too easy for state-actors to crate fake identities and start contributing to projects, and us falling victim to ever more sophisticated attacks. The one on xz was spotted, thankfully. But someone really motivated could do a lot better, such as introducing hard-to-trigger memory unsafety issues in C/C++ codebases that can be triggered to cause remote-code-execution. Yes, we do have some fuzzing infrastructure, and we are doing great things to catch these, but there are ways to thwart this as well (as we have seen in xz, some parts of the codebase were simply disabled).
I’m not saying that this should be mandatory for all core infrastructure, it is more of a thought experiment for what we could do to make it harder for these attacks to occur. Using legal names for this scheme is not an issue, even all the “incorrect invariants” and the broken system in the US that pushcx mentioned would not be problematic for this scheme. The question is more of whether open-source projects would adopt this, because it creates more work for them. And the answer is likely no, sadly.
The question is more of whether open-source projects would adopt this, because it creates more work for them.
As the maintainer of an open source project, I don’t want to be held responsible for maintaining physical copies of incredibly sensitive personal information. And I wouldn’t want to entrust my personal info with any random open source maintainer.
It’s not about whether it creates more work, it’s a matter of long-term irrevocable trust.
But it is not designed to be perfect, it is only designed to make it more difficult for state-actors. Today, it is too easy for state-actors to crate fake identities and start contributing to projects
And I assume you’re thinking that instead of being easy, that it would be difficult for state actors to create fake national IDs and start contributing to projects…? Is that because you think creating a physical document would take… perhaps a few more seconds… than creating a github account?
Also, if you require me to send my national ID to contribute to your open-source project, or require me to engage in any other kind of identity verification that could be reused to perform a replay attack, that would be a sure-fire way to ensure that I would never contribute to it. Copies of national IDs can be (and often are) used to steal identities and engage in criminal activities, so every time you share it with any entity, you are putting yourself at risk from being a victim of those crimes (even when not done intentionally, e.g. individual, company and government databases can be hacked into and your identity stolen as a result).
Furthermore, nowadays with AI it’s entirely possible to join one of these video calls you propose with a fake avatar that looks like a real person, of which perhaps you only need a picture to create a realistic-looking copy of that person, especially considering that people can change their looks drastically from one day to the next, so the fake avatar doesn’t even have to 100% match a picture to pass the identity check. Or better yet, state actors could just create entirely fake people and join these video calls using those.
Perhaps some form of cryptography could be used to attest that you are registered in a national citizen database without it being possible for any particular attestation to be reused in other activities, but I think you’re failing to consider that you are trusting governments not to attack you, when the attacker is a government. A government can just create fake entries in its national database whenever it wants to, so unless I’m missing something, it seems like your scheme would be completely pointless in addressing the problem it purports to address.
And just for the sake of argument, let’s say that you succeed in identifying the spy that sabotaged your open-source project and then sue that spy, presumably in his country of residence (Russia? China? Israel? US? North Korea?). What do you think would happen as a result? Absolutely nothing. The court case would probably be moved to some secret court for national security reasons and then summarily dismissed after it being investigated, since the sabotage operation was sanctioned by the government in the first place. So even if you could, what would be the point of suing?
Is that because you think creating a physical document would take… perhaps a few more seconds… than creating a github account?
It takes a lot more than just a few seconds. The physical document has to be produced by the nation’s ID printing, due to the security features involved this can take weeks and has a non-zero cost. In many countries, there are regulations and red tape around who and when is allowed to mint new identity documents.
Also, if you require me to send my national ID to contribute to your open-source project, or require me to engage in any other kind of identity verification that could be reused to perform a replay attack, that would be a sure-fire way to ensure that I would never contribute to it.
That is fair, I would assume that most projects don’t adopt this scheme for practicality purposes and because it drives away contributions. And that is fine — I’m not expecting this scheme to be implemented, more thinking loudly over what process we could implement to make these attacks harder.
Copies of national IDs can be (and often are) used to steal identities and engage in criminal activities, so every time you share it with any entity, you are putting yourself at risk from being a victim of those crimes (even when not done intentionally, e.g. individual, company and government databases can be hacked into and your identity stolen as a result).
Possession of a scanned ID document should not allow for crime, in theory. In practice, yes you are right, it can happen. However, a lot of places you need to trust with it: banks, any hotel you check in requires your ID or passport. For protection, I don’t advocate for keeping a copy of the ID, just a signed CLA with the legal name on it that is kept in a safe. The ID is only used briefly on a video call for verification. This is the same system we use here when you want to get a phone contract, or a bank account, or anything else.
Nowadays with AI it’s entirely possible to join one of these video calls you propose with a fake avatar that looks like a real person, of which perhaps you only need a picture to create a realistic-looking copy of that person, especially considering that people can change their looks drastically from one day to the next.
That is true. Fundamentally, that is hard to fix. What existing ID verification schemes do is ask you to do some operations, such as moving closer to and further from the camera (which changes the POV), and ask you to shake your ID so that security features become more visible.
I don’t think we have an AI yet that can do this in a convincing way, but we might get some at some point. At that point, we need to rethink how to do online ID verification.
Or better yet, state actors could just create entirely fake people and join these video calls using those.
This is true. No matter what, we can never be fully safe from state actors. All we can do is make it harder for them. If a state actor wants to create 1000 identities that they can use for open-source attacks, it makes a big difference to them if they:
only need to create a GitHub account
need to mint a new identity, and create a GitHub account
need to mint a new identity, create an AI solution that allows them to pass human verification, and create a GitHub account
All of these measures make creating and executing large-scale attacks harder. Any scheme that is harder to break is more intrusive to security, which we don’t want. This is true with cryptography: any cryptography is breakable, we just design it so that breaking it becomes prohibitively expensive.
Perhaps some form of cryptography could be used to attest that you are registered in a national citizen database without it being possible for any particular attestation to be reused in other activities, but I think you’re failing to consider that you are trusting governments not to attack you, when the attacker is a government.
Some governments already have ID cards that contain cryptographic keys that could be used for this. And yes, for governments we cannot fully prevent attacks, we can just add some hurdles that make it harder.
And just for the sake of argument, let’s say that you succeed in identifying the spy that sabotaged your open-source project and then sue that spy, presumably in his country of residence (Russia? China? Israel? US? North Korea?). What do you think would happen as a result?
So, there are several elements to this. The most important one is that it just makes it harder. If a state-actor still does it, we could catch irregularities (such as a lot of people from Russia verifying in a short amount of time) that we currently cannot catch due to accounts being pseudonymous. Next, we still obviously need code review, so even if a state-actor is able to infiltrate and produce proper ID documents and slowly create personas, our existing safeguards are still in place.
If we do detect anomalies and find out that there has been an attack, then we know the (real or potentially fake) identities of the attackers. It means that we have some idea of who performed this attack. Fundamentally, yes we cannot take people to court that are outside of our jurisdiction. The main idea for this system is that it doesn’t come that far. Another upside is that we prevent governments from reusing identities: now all of the identities associated with the attack are known and “burned”, and they have to start from scratch, slowly building trust.
It takes a lot more than just a few seconds. The physical document has to be produced by the nation’s ID printing, due to the security features involved this can take weeks and has a non-zero cost.
I’m a citizen of a country in the EU and I can get a new passport in less than 24h, although it only takes that long due to the underlying bureaucracy, not because it’s not technically possible to create it in minutes.
The central services of my national government already create more than a million ID cards per year and there’s no reason why they couldn’t create 5 or 10 million per year if they wanted to. The cost of printing a card is negligible when compared to employing an engineer in a national security agency.
In many countries, there are regulations and red tape around who and when is allowed to mint new identity documents.
And in the countries we’re talking about, capable of sabotaging an open-source project like xz, their national security agencies can mint new identity documents for their spies whenever they want to. I really don’t think it’s a significant barrier for them.
The ID is only used briefly on a video call for verification. This is the same system we use here when you want to get a phone contract, or a bank account, or anything else.
Exactly, and I think that’s a problem. If everyone did that, my ID would have been shown to hundreds of strange people who I’ve never met nor will I ever meet. These people could screenshot my face and my ID, create a copy of them (perhaps using AI), then open a bank account in my name using exactly the same process. As far as I know, the security features of the ID are not meaningful over video calls (and even in person, I think they are almost never really paid attention to).
All of these measures make creating and executing large-scale attacks harder.
… (such as a lot of people from Russia verifying in a short amount of time)
I don’t really believe that. As you can see, it only took one fake identity to almost compromise the entire planet. You only need one well-placed vulnerability to do a large-scale attack, you don’t need to compromise thousands of projects (which you could do with only a few dozen identities), much less create thousands of different identities.
It means that we have some idea of who performed this attack.
As far as I know, this has never been a major problem, especially for open-source projects, or even proprietary ones. For example, what if we found out that the Linux kernel backdoor attempt was made by North Korea (or China, or Russia, or the US, or Israel, …)? Would that change how the Linux kernel accepted contributions? I really don’t think so, except for banning the contributions of the one person who submitted the backdoor… which IMO would not meaningfully slow down a national security agency (especially if the identity was fake). The identity is already burned regardless of whether there’s a national ID document behind it or just a github account.
Fundamentally, yes we cannot take people to court that are outside of our jurisdiction. The main idea for this system is that it doesn’t come that far.
Why wouldn’t it go that far? I still don’t understand how knowing which government did it would deter them from doing it.
Another upside is that we prevent governments from reusing identities: now all of the identities associated with the attack are known and “burned”, and they have to start from scratch, slowly building trust.
But even with just a github account, they’d already have to do that anyway. Having to create a new fake national ID would not change that, the real barrier is slowly gaining trust over years of contributions.
I hope that this makes sense, at least somewhat.
To me it doesn’t make much sense, because it seems like you’d be greatly punishing legitimate contributors (especially for casual or relatively-casual contributions), while not meaningfully preventing 3-letter agencies from accomplishing their goals.
Since these attackers are so powerful and have almost-infinite resources, I tend to think that it’s extremely difficult to defend against them. As you said, I think code review is part of the answer, but it’s not likely to be enough. Some technical suggestions like using git checkouts rather than release tarballs would have made this attack or similar ones a bit more difficult, but it would not have meaningfully solved the problem.
I’m actually very pessimistic about attacks like these because I see how often people just download and run pre-built binaries rather than compile their software from source, or even how often projects encourage users to do curl <url> | bash, so I don’t see an end to these problems anytime soon. Some kind of trustworthy formal verification of entire systems could also be an answer, but we’re even more far away from reaching a goal like that than systematically compile everything from source.
And in many ways, I think we are actually getting more far away from solving this problem than we are getting closer. Software keeps getting larger and more complex every year, the avg number of dependencies keeps increasing, vendoring dependencies is very popular nowadays (making systematic code review and patching hard or impossible), container usage (which contain binaries) is more popular than ever, some projects are extremely difficult to build from source so binary artifacts are actually quite common, build systems and code editor plugins often download binaries from the web, compilers are often written in their own languages making bootstrap-from-understandable-source impossible, smartphone platforms exclusively using binaries rather than compiling from source, IoT and networking platforms using vulnerable software that hasn’t been updated in years (e.g. the Linux kernel), etc, etc… IMHO it’s all just a big impossible-to-solve mess, really, especially when sophisticated attackers can easily turn random bugs into backdoors.
That’s not even mentioning hardware or firmware vulnerabilities and backdoors, which I’m guessing nowadays are much easier for these agencies to introduce without any suspicions (or even with them), due to the infinite complexity of modern computers and their features (which often cannot even be disabled).
The cost of printing a card is negligible when compared to employing an engineer in a national security agency. And in the countries we’re talking about, capable of sabotaging an open-source project like xz, their national security agencies can mint new identity documents for their spies whenever they want to. I really don’t think it’s a significant barrier for them.
National security agencies have more reach, but this already makes it harder for other threats that don’t have an ability to mint IDs.
Even in national security agencies, you cannot just willy-nilly print thousands of IDs, like you can create GitHub accounts today
You are treating this as if it is intended to be ab absolute defense, which it is not. It is an additional security layer. It increased the complexity of operating such an attack, because you need multiple people (different faces) and multiple IDs to execute it. Making it more expensive and time-intensive is the ultimate goal.
If everyone did that, my ID would have been shown to hundreds of strange people who I’ve never met nor will I ever meet.
This verification is only really useful or intended for a handful of core-infrastructure projects. And yes, when you work an travel you will also show your ID to hundreds of strange people you’ve never met, when you check into a Hotel.
These people could screenshot my face and my ID, create a copy of them (perhaps using AI), then open a bank account in my name using exactly the same process. As far as I know, the security features of the ID are not meaningful over video calls (and even in person, I think they are almost never really paid attention to).
IDs should really not give anyone more access to anything. I’ve discussed this in another reply, but the TL;DR is that there needs to be some amount of trust between you and the maintainers.
I’ve discussed the AI issue in a separate reply, but in general once AI becomes good enough to fool these verification processes then we need to rethink them. But that should not stop us from implementing improvements now.
For example, what if we found out that the Linux kernel backdoor attempt was made by North Korea (or China, or Russia, or the US, or Israel, …)? Would that change how the Linux kernel accepted contributions? I really don’t think so, except for banning the contributions of the one person who submitted the backdoor… which IMO would not meaningfully slow down a national security agency (especially if the identity was fake). The identity is already burned regardless of whether there’s a national ID document behind it or just a github account.
So, this is a good question. The main utility behind this verification is just to create it harder to create fake identities. We might be able to use this to spot patterns and do more thorough code review if we notice anything suspicious. In countries with a good legal system, it allows to take legal actions against individuals that participate in this. But yes, there might be cases where we cannot do anything, and that is alright — just the fact that it makes it harder to perform attacks is a big win.
the real barrier is slowly gaining trust over years of contributions
Trust, but verify.
To me it doesn’t make much sense, because it seems like you’d be greatly punishing legitimate contributors (especially for casual or relatively-casual contributions), while not meaningfully preventing 3-letter agencies from accomplishing their goals.
Since these attackers are so powerful and have almost-infinite resources, I tend to think that it’s extremely difficult to defend against them. As you said, I think code review is part of the answer, but it’s not likely to be enough. Some technical suggestions like using git checkouts rather than release tarballs would have made this attack or similar ones a bit more difficult, but it would not have meaningfully solved the problem.
I agree that it is almost impossible to defend against three-letter agencies. That is true today and it will be true tomorrow, regardless of what we do. A defense-in-depth strategy has multiple layers of defense:
Verification of the individuals participating in the development
Code review, to have a human in the loop to make sure code looks sound and is aligned with the project’s goals.
Automated testing, to ensure that code is at least somewhat correct in doing what it is supposed to be doing.
Automated fuzzing, to ensure that for any possible inputs, the code behaves correctly according to the system invariants (memory safety, thread safety, etc).
The verification simply ensures that it is difficult for individuals to create multiple pseudonymous accounts and build trust, which they can later exploit. It just makes it harder. You need more resources (more people), perhaps fake identities. Every layer makes it a bit harder (read: expensive) to perform these attacks, due to needing more people, identities.
I’m actually very pessimistic about attacks like these because I see how often people just download and run pre-built binaries rather than compile their software from source, or even how often projects encourage users to do curl | bash, so I don’t see an end to these problems anytime soon. Some kind of trustworthy formal verification of entire systems could also be an answer, but we’re even more far away from reaching a goal like that than systematically compile everything from source.
I agree with you on some of these parts. The precompiled binaries is not ideal. Even if we can systematically compile everything from source, this does not fix anything. There is still either a requirement for the source to be valid, or you need to manually check it. It is not possible for a single human, or even an organization, to review all of the source code of the software they use without employing many dedicated people to do so. But I agree that there would be a benefit to this.
I think the underlying learning here is that all of the tech world is ultimately built on trust.
Software keeps getting larger and more complex every year, the avg number of dependencies keeps increasing, vendoring dependencies is very popular nowadays (making systematic code review and patching hard or impossible), container usage (which contain binaries) is more popular than ever, some projects are extremely difficult to build from source so binary artifacts are actually quite common, build systems and code editor plugins often download binaries from the web, compilers are often written in their own languages making bootstrap-from-understandable-source impossible, smartphone platforms exclusively using binaries rather than compiling from source, etc, etc… IMHO it’s all just a big impossible-to-solve mess, really, especially when sophisticated attackers can easily turn random bugs into backdoors.
100% agree with you on that, although this is something that we really can’t fix, software will keep on getting more complex. Or maybe it will become super easy, just an AI runtime and all the software we use is just ONNX models. But at that point we can forget about any kind of security, because we won’t be able to understand the software we use at all.
That’s not even mentioning hardware or firmware vulnerabilities and backdoors, which I’m guessing nowadays are much easier for these agencies to introduce without any suspicions (or even with them), due to the infinite complexity of modern computers and their features (which often cannot even be disabled).
This is true. Bunnie Huang is doing some interesting work in that regard. Some other examples of this would be the Intel ME, which runs a binary blob (a Minix-based operating system) inside every Intel processor that has ring -1 permissions (including networking). I agree that on the physical level, it’s not looking so great. You could run all of your stuff on open-source hardware (RISC-V), but even then you need to trust the fab. I honestly don’t have a great solution to this, because verification is so hard. And even if you wanted to, it would be close to impossible:
If you scan the silicone, you can compare it to a known good sample. But how do you trust that the sample is even good?
You could get the hardware-description sources, and somehow match them to the silicone. But then, how do you know the sources are good?
Ultimately, again, you need trust. Hardware designs have become so complex that again, you’d need a large team and millions of dollars to verify the sources, and to verify they match the silicone, and by the time you are done, the hardware is obsolete.
That all being said, I think anything we can do to improve the security, even if marginally, is a good thing. I hope that my response makes some amount of sense, you have raised a few good points.
So I would rather have pinkkitty31 give up his legal name than live in a world where we allow state-actors to perform these kinds of attacks.
Are nation state actors not able to create fictitious identities that appear legitimate to the average person (or even to other nation state entities that verify identification documents?)
I’m pretty sure there’s a trove of nation state covert intelligence operatives already using alternative identities.
Neither FreeBSD nor HardenedBSD are directly affected by this issue. However, I suspect that those running an amd64 linux glibc jail on FreeBSD (or HardenedBSD) have the potential to be affected.
I still don’t understand why pledge(2)/unveil(2) have not been ported to other kernels. They have proven to work very well for a almost a decade now, as they were introduced in 2015.
SerentityOS [1] [2] has ported pledge+unveil. Reply thread here mentions NanoVMS [3] too.
But i agree. It’s a really easy-to-use, simple protection that seems like a no-brainer for pretty much everything to have now.
1: https://man.serenityos.org/man2/pledge.html
2: https://awesomekling.github.io/pledge-and-unveil-in-SerenityOS/
3: https://nanovms.com/dev/tutorials/applying-sandbox-security-node-js-unikernels-openbsd-pledge-unveil
We’re doing a capstone project with one of my students where we’re porting pledge to FreeBSD. We’re not doing unveil because I don’t know the internals as good as pledge, but hopefully something good comes out of this experiment.
You might want to reach out to some of the HardenedBSD community members. We have a port of pledge that is nearing completion and will likely be merged into HardenedBSD on the inside of a year, quicker if we have help. :-)
The Linux approach, for better or worse, is to provide more generic/complex kernel APIs, the two most similar to pledge/unveil being respectively seccomp-bpf and landlock. Given those, you can port pledge/unveil in userspace. But that obviously results in less uptake than an API blessed/mandated by the OS developers in the OpenBSD style.
edit: Although see previous discussion for more caveats.
From the porting link:
This seems pretty easy on Linux with systemd, am I missing something? The program itself doesn’t even have to know about any control mechanisms like
pledgeor whatever, we can enforce it from outside.pledgeandunveilare specifically designed as tools for the programmer. They aren’t meant to be imposed from the outside as a sandbox. Theo has repeatedly rejected the idea of adding a utility to OpenBSD that runs an arbitrary command line under a particular pledge, for example. The intended use is for the developer (or knowledgeable porter) to pledge/unveil down to the resources that they know the program needs. It’s a tool for defensive programming: if your pledged process gets owned, it has as little ambient authority as possible.I agree. The programmer knows better than the user what resources a program needs.
Besides, the external approach imposes a static set that stays the same during the entire runtime, which is sort of critical, mostly because many programs require more privileges during the initialization which can then be dropped later.
I agree, but OTOH the user has the much greater incentive to care about sandboxing programs than their programmers (when the user and the programmer are not the same).
OK but my point is that the linked post says that this functionality is extremely difficult in Linux, but if we shift our thinking slightly to work with Linux’s execution resource controls, it seems to be quite easy.
It…depends. Linux sandboxing solutions are not particularly unified and depend on stitching a lot of pieces together, sometimes with confusing or bizarre edge cases. It’s not awful, but it’s still a fair bit of effort and a surprising amount of room for error.
(I will say that Landlock helps a lot here by being a relatively high-level set of access controls for things that are otherwise more difficult to sandbox.)
No, it really looks quite simple. Check the link I posted earlier. It’s as simple as adding a couple of lines to the systemd unit file or a couple of flags to the
systemd-runcommand line.There’s a significant structural difference between the two. I honestly don’t know why the Internet keeps lumping them together. Yes, both apply restrictions, but they’re completely different mechanisms. It’s like lumping email and keyloggers together because both ultimately boil down to delivering a series of keypresses to a third-party.
pledgeandunveilare things that the program does, which has two major implications:pledgeing a particular restriction is a supported mode of operation.pledgekills the program withSIGABRTand you get a stack trace pointing to wherever the promise was broken.pledgeorunveilwhenever you want during a program’s execution (but there are restrictions to what you can “unpledge” or “un-unveil”). So you can e.g. start with full access rights to the user’s home path in order to read configuration, and you can drop filesystem access privileges entirely once you’ve read configuration data.“External” sandboxing solutions allow you to apply the same restrictions, but:
IPAddressDeny=an address, but if sending telemetry to that address is a blocking operation, you’ll just get a blocked program. That’s obviously not on the sandboxing method itself, but…IPAddressDeny=packets just get dropped.The whole point of
pledgeandunveilis that you write your program so that you make certain promises about how it’s going to work, and sandboxing works as protection against accidentally breaking those promises, either straight as a bug, or through a bug getting exploited. They’re design-by-contract tools, more or less.I’m a bit confused, I wouldn’t expect “Linux’s execution resource controls” to include systemd-specific APIs? Tbc these toggles do not cleanly map to OS primitives at all; you can’t just go “ah yes I want systemd’s IP address restrictions myself” without writing your own BPF filtering.
If you did just mean systemd specifically, note that it’s quite a bit trickier to, say, sandbox things in a flexible way with that. In particular, to sandbox something that’s not a service with systemd-run has the overhead of spawning the child under the service manager and piping the output, and you lose the ability to easily control and kill the child (because you’re just killing the proxying process, not the actual child).
Yes, that’s what I meant.
But the whole point of systemd is that it makes it easy to control and kill the child processes that it runs…
Yes but these things are happening on different levels and mechanisms.
One is baked into the software by design, the other is not.
systemd is just flat out not a replacement for pledge+unveil, end of story. Completely different mechanisms.
I didn’t say it’s a ‘flat out replacement’, I said it achieves the same goals that were mentioned in the linked post ie preventing a piece of software I downloaded off the internet from ‘phoning home’ and uploading telemetry.
Okay I understand now.. The way I see it, the example in that post was a one-off example, and a pretty bad one, because I think from this you’ve misunderstood the purpose of pledge. While there may be some overlap in the functionaility of BPF filters they are far, far, from 1-1.
To help clear this up:
So in this scenerio of telemetry:
There would be no point in using pledge here.
Yeah exactly, the overlap is what I’m talking about. This is what I was referring to earlier–if you shift your mindset a bit, it becomes pretty easy to externally impose similar security restrictions using systemd. If you don’t mind that the exact way it’s done is a bit different, you can achieve very similar goals.
Part of the pledge/unveil model is that you can progressively drop privileges during program execution. The observation is that programs may need a lot of privileges in order to start themselves up, and then hardly any for the remainder of runtime. For example, consider the recommendations for using pledge when opening handles to sndiod in OpenBSD:
However:
And in fact
aucat(1)does exactly this, using a bunch of privileges at startup time (but dropping other very sensitive promises likeprocandexecright away) and then dropping most of them when it’s time to start playback or recording from the sound device handle.The purpose of pledge is for the programmer to mitigate the privileges available to exploits, not for the user to defend against code they chose to run. As far as I know, these goals, which are the main point of
pledgeandunveil, do not overlap at all with what you can do by filtering access via systemd.They overlap with the goal that was stated in the linked post. That was what I was referring to. I agree that dropping complex combinations of privileges in Linux at different points within an application’s lifecycle doesn’t seem easy.
I encourage you to read the rest of my messages in this thread to get the fuller context. It’s better than responding to one message at a time: https://lobste.rs/s/ny2s9f/openbsd_innovations#c_bds2yk
Yeah but the linked post misunderstands what pledge is actually for; “sandboxing untrusted binaries” is not an actual design goal of pledge and if it’s useful for that goal it’s only useful by accident.
Yeah so this is kinda weird: it makes it easy to manage the child as a single entity and then interactively control it. But systemd-run is, ofc, just a proxy, spawning the child as a transient unit and monitoring it until exit.
This effectively means that systemd-run does not itself control the spawned process’s lifetime. When you run it with –pty, Ctrl-C will kill the child normally… because it’s going through the tty. But if you’re running it detached from the tty (e.g. because you need to control stdout/stdin from your program), or you just signal the process directly, the actual service will remain running in the background. The only way of directly controlling that lifecycle is by grabbing the PID or (preferably) transient unit name and then targeting it directly or controlling it via the D-Bus interface.
But it’s a transient unit, it shows up in the output of
systemctl list-units, right? That means you can operate on it with egsystemctl stop the-unitjust like other systemd units?It is, yeah, which is why I had mentioned the “it makes it easy to […] interactively control it”. It’s just a lot harder in turn to automatically do things like “oh the user did Ctrl-C, let me stop all my processes”.
How does pledge/unveil compare to Capsicum?
From my admittedly passing acquaintance with both of them: Capsicum is much finer grained.
Pledge/unveil solves the 80% use case, Capsicum aims to solve the 100% use-case.
I.e. it would be very difficult, perhaps impossible to implement capsicum in pledge/unveil, but easy enough to do with capsicum.
That said, there is probably more veil/pledge actually implemented in binaries out in the wild. I think all of the base OpenBSD system is done now. Last I checked only some of FreeBSD has Capsicum implemented in base.
We ended up porting this to Nanos: https://nanovms.com/dev/tutorials/applying-sandbox-security-node-js-unikernels-openbsd-pledge-unveil .
Leadership (likely Linus) needs to step in here and either say “rust is ok” or “rust is not ok.” Otherwise these same rehashed arguments in the LKML will be going over and over again, and nothing gets done except people burning out.
But it is neither, I don’t know where people think to think that the adoption of Rust in the Linux kernel is already a decision that has been made years ago. From: https://docs.kernel.org/rust/index.html#the-rust-experiment
That said, people like GregKH are already convinced that Rust for Linux has been success (I do as well, but I’m just watching from the peanut gallery). But that doesn’t mean that “rust is ok” w/o further discussion. Different developers/maintainers still have to be convinced.
Watching from the outside it seems that some maintainers don’t want to be convinced in the first place.
Some seem ready to actually make an effort to see what the experiment will lead to, but that’s far from the majority.
From personal experience with some of the involved in this thread from the maintainers side, I disagree. It’s unsurprising that, after years and years of holding the kernel as a pure C project for good reasons (not even allowing the sister language C++ in), there’s people that hold this as a value. Those aren’t convinced easily, not on a short timeline and not via email. I know people wish for a strong word from Linus, but this is only partially in his hands - particularly as the person who previously held the “pure C” line.
I’m not a fan the tone, but I was for example completely unsurprised by Chris Hellman holding that line and not arbitrarily.
R4L is not just a substantial engineering effort, it is also a substantial social effort. And that means a ton of legwork, and maybe some beers at a bar.
At this point what is happening there is not ‘leadership’.
My naive and oversimplified take on this is that Rust would be allowed, but is expected to have backwards compatibility assurances, and so long as Rust constantly changes things and lacks those assurances, Rust won’t be added.
Is this correct? Somewhat correct? Not really the issue? Incorrect?
As someone who sees Rust getting rebuilt monthly or even more often than monthly because of new versions, and codebases like Firefox (and even Rust itself) that can’t use an ever-so-slightly older version of Rust, I get the impression that Rust has a long way to go before it settles enough to be used for software that has extremely long maintenance cycles. But that’s just my impression - I have no experience actually programming in Rust.
The results of the annual survey have come out, and 90% of users use the current stable version for development. 7.8% use a specific stable released within the past year.
These numbers are only so high because it is such a small hassle to update even large Rust codebases between releases.
Rust is stable in the sense of “is backwards compatible” even if it isn’t in the sense of “doesn’t have a slow release cadence.”
A new version of Rust comes out every 6 weeks. Rust has many so-called unstable features, which are not available by default and have to be opted into. Those features can change at any moment. But if you don’t opt in to such features, the language is extremely stable. Every time a new Rust version is being prepared, they compile and run the test suites of pretty much all known publicly available Rust code, just to make sure nothing went wrong.
Rust for Linux does opt into a few unstable features, but they’re pretty close to being finished and making sure R4L can work without unstable features is a high priority goal for the Rust Project.
Rust has stability guarantees written down and heavily tested since nearly 10 years to particularly allow evolution with very strong backwards guarantees.
Language: https://rust-lang.github.io/rfcs/1122-language-semver.html Libraries: https://rust-lang.github.io/rfcs/1105-api-evolution.html
Rust (ideally) never breaks backwards compatibility except in a very defined set of cases. (e.g. bugs in the language frontend that allow you to bypass it’s guarantees are bugs, not features and will be fixed, at the cost of breaking some notion of backwards compatibility). It has an extremely heavy hammer test suite to ensure no unwanted changes to go in and/or assess the impact of changes called crater - which literally runs for days. https://github.com/rust-lang/crater?tab=readme-ov-file#crater
Recommendation: before you actually enter discussions about Rusts backwards guarantee (I know you haven’t, this is more for the reader), please read the two RFCs. They are relatively short, subtle and good. I often see discussions going wrong where people haven’t read those docs and have discussions that have no basis in reality.
I don’t think that’s true. You get amazing backcompat by default and guaranteed compat by using Rust editions.
Firefox doesn’t have to upgrade every six week. We enjoy upgrading. We can do so because the benefits outweigh the costs.
the benefits to whom? goodness gracious…
news flash: your users don’t enjoy you upgrading.
Are you compiling Firefox by yourself?
no; it’s impractical to do so.
Help me understand. Why would you want to compile it yourself?
Being a BSD masochist^Wuser, I generally maintain my own package repo. Firefox is included in that repo. I love having full control over the packages installed on my system. I’m probably an outlier here, though.
well now we’re changing the topic, but one reason is that it removes the need to trust external builds. another would be to patch it e.g. to restore FTP support. another is that it’s a necessary on-ramp to contributing, or generally to exercising the rights granted by the license.
These are all good and valid points. Thanks for sharing :-). I can see how that’s important to you and the latter being really important for both of us.
no problem
I don’t think this is correct. Rust would be experimental and it would be entirely on the RFL members to ensure it stays up to date and correct, without blocking others. None of this would have to do with the language.
so if a casual linux user hears “linux runs on M1 macs,” then spends their whole paycheck on a computer with no ethernet or USB-A ports because of it, then too bad for them because they should have known that “it runs linux” no longer means it has the stability and longevity that could once be expected.
Asahi linux and RFL are two different projects with totally unrelated stability guarantees, none of those guarantees have to do with the RFL code working.
As for the user spending money or whatever, I have nothing to say on the matter. Are users responsible for purchasing decisions? I don’t know, I don’t think it’s relevant at all.
what I read is that a lot of the drivers for asahi linux are written in rust. are they not part of the main kernel tree?
They’re in the Rust for Linux tree, but they’re not in Linus’s tree yet, because they’re blocked on other stuff getting merged first (like the DMA abstraction).
Asahi Linux is not upstream, that’s correct.
is “upstream” synonymous with “the main kernel tree”?
are all of the rust drivers that an asahi linux system uses part of the asahi project and not in the main kernel tree?
I don’t know much about this so I want to make sure I understand.
Yes. That is Linus’s tree, which is the ultimate upstream of the Linux project.
I think so. Most of their C drivers aren’t upstreamed yet either, I believe. The C drivers I don’t think are blocked by anything in particular, it’s just work that isn’t finished yet. The announcement blog post says that they are going to focus on upstreaming this year. The Rust drivers are blocked by needed Rust for Linux abstractions not being upstreamed yet.
so then none of the rust drivers are merged in the main tree. can we say that definitively?
Yeah.
I’m not sure how much is actually merged, if it is though it’s experimental. I believe much of it is not merged, and it was naturally developed outside of the main tree (as anything would be). The GPU driver, often cited as a big success story for Asahi, is not merged, for example.
a first?? continuing here…
I think I’ve been misunderstanding what is meant by “behavioral” or “API/ABI” stability. I thought this referred to the stability of the interface between the kernel and userland, and that being “experimental” would mean the external interface is not maintained in the same way as other parts of the kernel. but now I’m thinking that the API/ABI stability is between different components within the kernel, and they want to “experiment” with making those internal interfaces more stable. do I have that right now?
That would be right, at least for the most relevant stuff like the filesystem discussions. It’s ensuring that when something changes on the kernel side (not userland facing) that the Rust code matches that.
ok that helps. so to go back to what kicked off this discussion:
so this means that the C kernel devs could change things that break RFL code and aren’t obligated to fix it, whereas if it were any other part of the kernel, the C devs would be obligated to fix it or make sure it gets fixed. right?
That’s about right, although there’s always some shared responsibility between the person changing the API and the callers (in RFL’s case it’s all on the Rust devs).
so if the reputation of linux is due to the C developers, then having a completely separate team develop code that people are told is linux could subvert the expectation that linux is developed by the same group that built its reputation.
that’s what I was getting at when I said “‘it runs linux’ no longer means it has the stability and longevity that could once be expected.” of course it’s a matter of debate whether the rust effort will yield better or worse stability/longevity, but the development process for M1 macs is not time-tested in the same way as the development process for, say, the thinkpad x13s. is that fair to say?
and do you think the recent debacle is a bad sign for the stability/longevity of linux on M1 macs? regardless of who you blame for it. I saw some other comments to that effect.
I’m not sure that the reputation argument is going to hold much water with me. Linux has a pretty bad reputation in my mind, but how it’s marketed is completely disconnected from that. I can’t tell you how things should or shouldn’t be marketed, or the complexities of layman making technical purchasing decisions, or how the experimental branch might change things, or what is or is not ethical to say about support for a Mac on Linux. If you want to say that Asahi is somehow wrong for something they’re saying about support or stability, you can do so, I just don’t think it’s relevant to RFL. If you want to see their messaging, this seems to be the relevant page: https://asahilinux.org/about/
Maybe? It’s really hard to say. Many drivers are poorly supported or maintained by far fewer/ less motivated people than Asahi.
It’s a bad sign for Linux in general, which, as I’ve stated elsewhere, is not going to be a dominant OS in the future because of upstream’s behavior and fundamental structure. In the short term I think the major impact is going to be that Asahi probably isn’t interested in staying out of tree forever, they likely had loftier goals and wanted this to be a larger project as a part of RFL, and so by upstream pushing RFL away Asahi developers will be pushed away/ fail to gain as much traction. I think this will be bad for Asahi and bad for Linux users, sure.
your answers have been duly noted. I take them as assurance that my original comment wasn’t completely off-base or reliant on a fundamental misunderstanding.
There is no separate team. RfL is being done by regular kernel maintainers who happened to pick up an interest in Rust. Pretty much everyone (maybe literally everyone) contributing Rust code to Linux has contributed and continues to contribute C code.
then why the need for a different policy on who is responsible for what in regards to RFL vs the rest of the kernel? seems like a separation to me.
(please don’t mistake my use of “completely separate” as implying that there are no developers in both groups or that they are hermetically insulated from each other.)
Because the vast majority of Linux maintainers do not know Rust, and therefore this experiment couldn’t be run at all if maintainers of C code were expected to fix Rust code when they make changes. And even if RfL is a complete success and Rust becomes a permanent part of the kernel, most likely there will need to continue to be a collaboration between Linux devs who know Rust and those who don’t, to keep Rust code up to date with changes in C interfaces.
makes sense
cool good to know. so can you clarify this part:
in general terms it seems like if any of the rust code used by asahi is merged with the main tree, then the stability of asahi linux does depend on the stability of that code.
I’m wondering if we’re talking about stability in the same way? Are you talking about stability in terms of stable behaviors/ API/ ABI? Or do you mean in terms of crashing? The former is what’s being discussed with RFL, not the latter.
here I was referring to “stability and longevity” in the sense that would be relevant to a casual linux user, who may have come to expect that if a system runs linux it will continue to run linux for a decade or more with fewer crashes and bugs than a proprietary OS.
I am acutely aware that user concerns are conspicuously absent from the RFL discussion.
I don’t really follow your point throughout this. Is your concern that Rust will be less stable in the sense of less reliable or something? Or that Asahi Linux will be? I don’t really know how that’s relevant to RFL or actually anything that’s been brought up, or why you’re bringing it up.
as an uninformed casual linux user, over the past year I have gotten the impression that “linux runs on M1 macs,” and in another life this might have motivated me to buy one. with this news it seems like linux might not run on M1 macs for much longer, or might not gain the eventual reliability that I would normally expect if I hear that linux is getting ported to a platform.
I was under the impression that Asahi Linux was hoping to eventually depend on RFL for the practical aspects of reliability, and if it’s “entirely on the RFL members to ensure it stays up to date and correct,” then that is qualitatively less assurance than if the code is supported by the kernel team as a whole, as was once implied if linux is said to run on a platform.
I see. So yeah, I think it’s good to point out that the stability referred to in RFL conversations is in terms of behavioral stability, not things like bug fixes. Asahi is a downstream project, it is maintained separately, and its stability (in terms of not crashing) has nothing to do with RFL. Asahi users will continue to get patches for bugs as long as there are developers willing to do so, this is not related to RFL, although presumably Asahi wants RFL to happen to ease their development burdens etc.
Right, so there are a few things here.
With regards to bug fixes/ patching, it is not up to the RFL members at all, it’s up to the Asahi developers, who work downstream. This is totally separate from RFL.
With regards to RFL, completely distinct from Asahi, the issue is not crashing it is behavioral and API stability. As RFL is “experimental” it is up for RFL to maintain interfaces that are up to date and not the C developers who maintain other code. Nothing to do with Asahi or bug fixes etc.
You might be under the impression that the Linux kernel considers stability to be a shared responsibility (ie: “everyone is responsible for bug fixes”) but this is not the case at all. Typically it is one developer maintaining a suite of drivers, a filesystem, etc, and they are the only ones responsible. There isn’t a big difference in reliability between something upstream or downstream, what changes is primarily on the committers side in terms of maintaining patches, others contributing Rust, etc, which is what RFL is about. If one of those solo committers/ maintainers left users would be just as fucked as ever - and this happens.
thanks for the overview.
I still don’t get this part. doesn’t a lack of behavioral stability risk creating bugs?
if asahi’s stability “in terms of not crashing” doesn’t depend on RFL, how would RFL ease their development burdens? if some code that is needed for asahi to run is taken up by RFL, then woudn’t bugs in that RFL code affect the running of an asahi linux system?
Maybe, but since Asahi is its own distro it picks its own kernel and userland, so the distro can just not upgrade userland components that would rely on some behavioral change in the kernel. They own that themselves so their users aren’t any worse off.
I think there’s a number of things that would play out longer term. One thing that RFL wants is to start to formalize some of the behaviors in the kernel so that their drivers can provide safe, stable interfaces, and reduce the burden for all developers in maintaining them. Asahi would then have less of a burden of development.
Of course, but why would RFL change anything? The code has a bug or it doesn’t. The issue is things like relying on the behavior of the C driver vs the behavior of the Rust driver, which is why RFL wants to formalize those semantics.
I think we’ll probably start hitting the limits of my knowledge if we get too into the details of why Asahi wants to do one thing or another, RFL has numerous motivations. The tl;dr is that the stability discussed is about ABI/API stability, RFL would help Asahi because it would help them formally adopt the behaviors of the C code (by stating those behaviors vs those behaviors just being assumed by one maintainer), and Asahi users aren’t going to experience a less stable OS by virtue of RFL being “experimental” since RFL’s impact would only mean that the code lives in one spot vs another.
all else being equal, a decrease in kernel ABI/API stability would mean more work to keep up with changes and identify which userland components are safe to upgrade. for the same amount of developer/maintainer time, the system would be either less reliable or less up to date and their users would be worse off.
point taken.
presumably “experimental” code is more liable to have bugs.
are you saying that Asahi wouldn’t rely on RFL code if it weren’t experimental? or that all of the RFL code relied upon by Asahi will inevitably come from the Asahi project, and would be in Asahi if it weren’t in RFL?
Right, RFL would presumably help that, which is why they want RFL so that they can go upstream.
Nope, not in this case. It just means it’s an experiment, if it isn’t successful it’ll get pushed back downstream.
Hmmm, I’m not sure what you mean. Asahi relies on the code that it relies on, that’s all. RFL would allow their code to live upstream, and would imply some things that RFL is pushing for like more defined behaviors of existing interfaces. That’s what I’m saying. Asahi will rely on RFL code when their code makes it upstream as “experimental”, otherwise that same code would be downstream but otherwise the same. RFL code won’t necessarily come from Asahi, certainly, anyone is free to try to push their own Rust code to upstream.
Why would you spend your whole paycheck on a computer? That’s irresponsible.
if someone makes under $30k a year, buying a $1000 computer is irresponsible?
If someone makes X a year, buying a X/12 computer is irresponsible.
the paycheck I had in mind would be biweekly with taxes and benefits taken out.
but even your X/12 idea seems needlessly judgemental and paternalistic, and doesn’t account for savings and fluctuations in income. the average salaried indian makes $200-300 a month; median is probably much less. it would be irresponsible for them to spend that much on a computer?
the idea that you can have Rust in the kernel but it doesn’t have the same stability guarantees is just atrocious.
what stability guarantees?
The normal rules for intra-kernel interfaces are “you can break somebody else’s code, but you have to then fix it”. But if you break some Rust code, it’s the duty of the Rust for Linux people to fix it.
The basic problem with getaddrinfo() is that it isn’t a DNS API, it’s a name service API, and the name service switch might look up names using /etc/hosts, mDNS, NIS, NETBIOS, who knows what else. Oh and probably DNS too. So the results you get from getaddrinfo() are very much a lowest common denominator.
Applications that depend on DNS specifics should probably pull in a modern stub resolver library, and avoid the ancient BIND-derived
res_*functions. There are a couple of problems with this idea:It might not be possible to get the recursive server IP addresses out of the libc resolver. Implementations have diverged since the BIND 4 days, especially wrt IPv6 support. Some resolver libraries parse /etc/resolv.conf themselves and try to do so in a compatible manner. Check support for fun things like scoped link-local IPv6 addresses.
The system might have a DNS cache that you might accidentally bypass. If that cache provides recursive DNS service on a loopback address it might be shit. You might be better off using a proprietary API instead. (Which is basically what the article concluded.)
Yeah, it’s a mess.
The second problem is that it’s synchronous. Looking in hosts is fast and so that’s fine. NETBIOS is probably on the local network, so might be fast. mDNS is link-local and mostly served from a local cache. DNS may miss in a local cache and require a chain of synchronous fetches from DNS servers somewhere in the world, which may take hundreds of ms.
If you want to do one name lookup, that’s fine. If you want to do more, that’s a problem because the only way to overlap them is to have a separate thread for each.
Edit: this is a special case of the problem that a lot of transparent RPC systems encounter. It’s really hard to write software with performance that you can reason about when the latency of a call may vary by 3-4 orders of magnitude.
I agree but I don’t think there is one, at least in C land your options are:
I was thinking of something like adns, ldns, getdns
There’s a lot of fiddly parsing in a DNS implementation because of the many different RR types, so it’s hard to make it both small and easy to use.
Also, that musl code appears to have completely incorrect domain name parsing. musl’s stub resolver is very bad.
libunbound is just shy of 3KLOC:
i wouldn’t mind systems (the OS) just providing a (good!) recursive resolver on the loopback ip and listing it in /etc/resolv.conf. in other words: the dns protocol is the api. then everyone can use their own stub resolver library with an api of their choice. the OS can do “smart things” in its recursive resolver (like redirect requests for internal domains to some other internal name server; macos has some config options for this in /etc that i have enjoyed but haven’t seen elsewhere; the system resolver could also do doh, etc). these stub resolver libraries may also look at /etc/hosts, but the system loopback resolver could even serve records based on that file too (and hopefully from a new file in /etc in zone syntax). going through a loopback resolver prevents the issue mentioned in the article with caching responses.
btw, is the /etc/resolv.conf syntax still updated at times? so stub resolvers could make use of modern features (i’m thinking of do[thq]).
i haven’t used getaddrinfo much, certainly not recently. nowadays i (pretend to) live in a Go world, using the pure go resolver (https://pkg.go.dev/net#hdr-Name_Resolution), without going through the system libc resolver. works well for me. i’ve never expected name resolution to return names from mdns/nis/netbios, and i’ve never knowingly used nsswitch (perhaps i’m missing something great?). unfortunately, the current standard library go resolver api has the same issues as mentioned in the article with not providing access to the ttl, or the dnssec status, or the cnames followed (and their dnssec statusses).
This is how most local (usually caching) resolvers work. unbound, systemd-resolved, etc…
I agree that it would be good to make it a “standard” such that it is always expected to be configured.
This highlights why it’s important for certain sensitive use cases to use Signal behind Tor. Using Tor would mean that the cache serving the content would be the one closest to the Tor exit node, not the closest one to the end user.
It’s still pseudo anonymous because you’re not making a full tor circuit to connect to Signal and using the same account and traffic pattern out of the exit.
If you use Tor in Transparent Proxy Mode, then you’re using Tor for everything–including connecting to Signal itself.
This is what I do for my OPSEC-friendly Signal account.
In the spririt of hoping to be corrected: it appears that most of these depend on either a running rsyncd (which I haven’t seen in 20 years) or the attacker having access to the source filesystem while an rsync is in progress.
Many vendors, especially those of open source operating systems, use
rsyncin daemon mode to sync build artifacts to various mirrors. HardenedBSD is one such vendor.Edit[1]: Clarify how the daemon is run (
rsyncd->rsyncin daemon mode.)Anecdotal,
rsyncdis used by of the Tier 0 and some Tier 1 package mirrors in Arch Linux.Infrastructure source: https://gitlab.archlinux.org/archlinux/infrastructure/-/tree/master/roles/dbscripts?ref_type=heads
Their is a similar question open on the mailing list about whether the code is only active in rsyncd or maybe also when invoking
rsync --server --sendervia ssh (currently unanswered): https://marc.info/?l=oss-security&m=173688743232255&w=2Synology uses rsync (and I think rsyncd but maybe not?) to migrate/sync data between their NAS boxes.
Full report PDF is here: https://freebsdfoundation.org/wp-content/uploads/2024/11/2024_Code_Audit_Capsicum_Bhyve_FreeBSD_Foundation.pdf
Notably missing: the BSDs. the three main BSDs (FreeBSD, NetBSD, OpenBSD) all have different implementations.
HardenedBSD, a derivative of FreeBSD, differs from its upstream, even.
So there’s at least four (perhaps five, dunno about DragonflyBSD) unique implementations across the BSDs.
After a couple months of health issues between me, the missus, and our two dogs, I plan to finally catch up on studying for my OSCP cert. A few coworkers are starting a study group and I need to catch up on some HackTheBox challenges.
I also need to review some HardenedBSD merge requests. That, and I need to figure out which commit broke bhyve in FreeBSD.
Browser choice is not an ideology. It’s a pragmatic choice for nearly everyone. Chrome is simply consistently better. Shaming people for not using Firefox for ideological reasons won’t work.
If chrome disables the use of ad blockers, first of all most people won’t even notice. For the minority that do, chromium forks will emerge or they’ll switch to Firefox at that point.
I think this was true like … five years ago or so, but up to the point last year where I finally ditched Chromium altogether I wasn’t really seeing any difference whatsoever between the two.
Honestly this is kind of sad. Ad blocking technology right now is far and away the most important User Empowerment thing we’ve got going for us. You have Linux Zealots going around trying to convince people to switch operating systems for abstract reasons that no one actually finds convincing, or trying to get people to stop using Facebook which has some serious social isolation downsides, but meanwhile installing an ad blocker takes like two minutes, has really compelling and self-evident benefits, and no down sides.
Do you? Much like the Rust Evangelism Strike Force, I don’t see much of this, at least not in the last half decade or so.
I don’t want to let this statement go unchallenged. I think it’s a harmful fallacy. Social interactions via “traditional” channels like phone, email, text and video conference are excellent.
We may not promote or educate people about them enough anymore, but they are more social than the often semi-anonymous and harmful interactions platforms like FB foster.
GP is right unfortunately. You lose awareness of many in-person events, and even among people considered friends it can be difficult to make the transition to more direct contact and not have it be weird. I’ve doubled down and accepted the cost for long enough that there’s no going back, though I wonder sometimes if it was really worth it.
The way to make progress on these kinds of problems is coordinating lots of people to move together. This is why Jon Haidt promotes Wait Until Eighth to keep kids off social media and so on.
I deleted my FB account six or seven years ago. I have an anonymous account for tracking organizations that post events.
It may have been my personality, but I’ve been a lot happier since.
Every time I dip into some “social “ platform like reddit I’m reminded how terrible people are when they have masks on.
Fair, but Facebook, which requires the use of real names is equally terrible, just in a different flavor.
Those technologies are fine, but they don’t offer the sense of “ambient humanity” that Facebook, Instagram, Twitter, et al. do. Those platforms allow you to lurk. It’s a very different interaction model from a phone call, where at least one party has to explicitly initiate it, and then both parties have to continue participating (at least for the best results!).
I do agree that there are still ways to get meaningful social interaction outside the big platforms. I have a bunch of SMS and iMessage group chats that allow me to keep in touch with close friends and family, and I can participate more actively or more passively depending on my mood and whether or not I have something to say. You could set up the same kind of thing on any number of chat platforms. But my point is that Facebook was never just a substitute for calling a friend on the phone.
That lurking is the worst aspect. Its the one that prompts people to preen on social media and to envy others and then lapse into depression, negativity or anxiety.
If anything since deleting my FB account I have been more socially active, because whenever I want to communicate something I text people or call them and I have an actual conversation, while before I would have broadcasted the thing to a bunch of people in exchange for some like…
Yeah, I haven’t actually used facebook so admittedly I don’t know what I’m talkitg about here; I should have said “perceived downsides” because it doesn’t matter for the larger point if it’s true or not.
Not if you’re under 50. ;-)
So replace Facebook with Instagram then. It’s literally the same company.
And only have family and friends in the same range.
And are in certain countries.
There have been ups and downs in the competition between the two ever since chrome was released but chrome has always more or less held its own. It’s either been much better or about the same in this period. That’s why I used the word “consistently.”
Strong agree with all of your reasoning here. The ability to provide a practical benefit like avoiding ads is a huge selling point for FOSS but instead people are finger wagged for reasons they will never understand.
Using Firefox mobile was noticeable slower (on android at least). On my new-ish phone (Samsung S23) it’s fine, but I wouldn’t was it’s for everyone. I love having extensions and supporting an alternative browser, but not everyone can afford high-end phones to just do browsing.
I switched to Firefox for work a couple years ago and basically everything is fine except for a couple apps. For example, Grafana just cannot handle large queries on Firefox, it’s 90% of the reason I still have Chrome installed at all. I suspect that they only test it on Chrome and that there are just subtle differences in the JS implementations, so I wouldn’t say Chrome is “better”, but it certainly “works” in some cases where Firefox does not.
I find this use of the English language truly amazing.
When people talk about what “most people” think about a topic, I don’t get who they’re talking about. I think most of my friends would care if Adblock was removed, and they’re a very diverse set of people.
I think most people do care about these topics like privacy and diversity in browser space, if you take the time to educate them as to why they should. No one cared about the environment nor democracy initially either, it took a lot of campaigning to get people to start caring.
But that’s the entire point. The vast majority of chrome users dont use Adblock and don’t care enough to seek out education on Adblock. That’s just the reality.
The worst part of tech the past 20 years is consistently hearing over and over that technologists and their aesthetics don’t matter because the masses put up with whatever they’re force-fed.
If people want their browsers to track the crap out of them, that’s fine by me. I prefer a world of healthy alternatives. And I hate hearing that my values don’t matter. They do matter, and I know I represent a quiet but stubborn faction of people who see the internet not as five sites but the beautiful messy decentralized system it is.
We will take it back. It won’t be something that will be recognized by non-technologists for a long time. And that’s a feature.
Honestly, it’s not terribly surprising that webdevs allowed this to happen. They’re fed a steady diet of the web not being enough (just use Angle Reaction 24.8!) as is.
… until you realize that these people are helping data-hoarding-bigcos track the crap out of you as well. Your neighbours scan your wifi and bluetooth devices, your contacts share your phone number, name and whatever data they happen to know about you (maybe they fill in your DoB, workplace or upload your picture), when you called each other, meet each other and such.
Healthy alternatives exist and you’re free to use them. Your values likely don’t matter to the majority of other people in the world, they’re your values. The world is a big place.
I think you’re underestimating how many people are on the internet and how many of them don’t care about technology at all but simply use it to get from point a to point b. This isn’t the mid 90s anymore.
Large companies who must behave according to data to survive understand this.
At least that’s what Google believes (they wouldn’t go ahead with the breaking change if they thought it’d cause too many users would switch away from Chrome), and they surely know their users better than we do.
But some of the users who don’t care enough can be made to care with a bit of advocacy, like in this article. Just like with environmental issues, it can take a lot of explaining to understand how important a topic is.
That’s exactly what people said about Internet Explorer back in the day, and how it got to be such a nuisance… Once a monoculture has become entrenched, it’s very hard to get rid of it when it ceases to be the better option.
That will keep all of the manifest v2 stuff that Google is ripping out, and keep it working as the internal APIs change?
I can’t imagine anyone doing that vs. just switching to Firefox.
I agree it’s a pragmatic choice, but the main way in which Chrome is “better” in 2024 is that everyone is already using it. Your peers would look at you a little funny for using something else, switching takes effort, and it isn’t obviously worse such that you’d be motivated to switch. At this point Chrome inherited its dominant position; it isn’t particularly earning that position anew by better addressing user needs. Not unlike Google web search.
I think I’d get more funny looks for using Chrome to be honest.
So, just like modern webdev then? :)
Most privacy and/or security enhanced open source community effort forks of Chromium don’t last. See: Hexavalent, Chromite.
And why do you think that is?
Because maintaining a browser (or even, third party patches for a browser in this case) is a massive, time consuming, ongoing, never ending effort that requires constant reworking after every minor web change, or upstream change.
It’s simply not feasible for small open source communities to maintain a patchset as massive as this.
The same could be said of all work. Any serious endeavor requires constant labor, open source or not. The way we accomplish these things is by creating sustainable revenue streams so that we can fund the labor. The real problem here is that few people care about privacy enough to sustain this development effort. Ideology doesn’t pay the bills.
At a recent security event (National Academies thing on memory safety a couple of weeks ago, I think), someone mentioned that Chrome has an average of one security issue that needs patching and fixing every 1.5 days. The team has to create the fix, test it, and roll it out in update channels that often, in addition to adding new features. Doing that while also being downstream from the company that is doing the work upstream is incredibly hard.
Yes! This is exactly what I was getting at.
I don’t deny that it’s hard but clearly it can be done if someone if willing to fund it. Many people are claiming that browser privacy etc. is an important feature for users that chrome is increasingly ignoring but if that were true, where is the demand for such a browser feature? It doesn’t exist in any significant way, at least enough to fund a browser that prioritizes this issue, therefore we must conclude that most users don’t really care about browser privacy and it isn’t an important feature.
It’s not just a matter of funding; it’s also a matter of time. No amount of funding is going to provide more hours in a day. The time it takes to maintain a project downstream is time spent away from family, friends, and those other things dearly held.
Time is money. More salaries fundraised equates to more full time labor being allocated to working on this. There is nothing written in stone that privacy-oriented browsers must only be worked on during one’s free time.
This is way different in that the third party project doesn’t initiate the changes, and the upstream project is extremely big - there’s a massive, well-funded company working on this highly technical and complex project with lots of churn. And over here you have a handful of unpaid folks even just trying to parse what they’re doing upstream, and then having to rebase their own work onto those changes.
Why would nobody be willing to pay for such a privacy-focused chrome fork?
Perhaps when Firefox truly dies off…
It would have to be a true fork, not a Chrome-resynch-with-branches project. Otherwise Google will thrash you to death with upstream changes.
If you’re going to work on a truly different codebase, Firefox is right there. But then Mozilla will thrash you to death.
Sure that’s a pretty fair assessment of the situation. I agree.
We should ask “why” so few care. They can’t be bothered? Lack of tech education? Lack of interest? Probably a combination of all of that.
I find it strange that people who complain about a Chrome monoculture would prefer to have a Firefox monoculture in their circle of friends.
And it’s not as if Mozilla is the friendly David against the evil Goliath. One of Mozilla’s founders posted rather recently:
Mozilla has become a company of bad decisions over the last twenty years. “It’s not Chrome” is insufficient as a major advantage - in my opinion; neither are SeaMonkey, NetSurf, Ladybird and so on. And they are all far less profit-orientated; hence: they are all far less exactly like Google.
Nowhere in this article does the author wish for a Firefox monoculture, among their circle of friends or otherwise.
It is a plea against a Chrome monoculture, and (thanks to very bad decisions by Opera and Microsoft) from any cross-platform perspective, that practically means being a plea for a healthy balance between Firefox and Chrome-derivatives. There is also Safari (I’m a happy user), but Apple killed off the Windows version.
At the point where someone is both a web developer and the only person you know, among all web developer colleagues, who doesn’t use a Chrome derivative, we’re fucked. That’s how you end up in a vicious cycle of poor website cross-browser compatibility caused by lack of cross-browser testing making Firefox less attractive for users, making developers less likely to test on it, etc. (From this perspective, suggesting browsers such as NetSurf and Ladybird that don’t reliably support any given vaguely recent CSS feature is missing the point even more badly.)
I understand the author to mean that he wouldn’t have a big problem with 90% Firefox market share. I mean, at the end of the article he asks people to use Firefox; what if everyone does?
I did not do that. Quite the opposite: I pointed out that “not Chrome” often means “not useful for most people”. (Although I actually like NetSurf, but I don’t use web applications much.)
If everyone used Firefox that would also be bad, but we’re in no danger of that so I don’t see the problem suggesting people use it
The reason why the article doesn’t have large, flashing disclaimers warning to avoid giving Firefox too much market share is because its user-base is so small that it’s infinitesimally unlikely. Chrome, Chromium derivatives and Safari are bundled in major operating systems. Microsoft and Google also control key websites and services where they can add special interoperability and advertisements for their browsers, while Apple straight-up prohibits other web engines on iOS.
Firefox is just the default browser on some Linux distributions. It’s not overtaking them anytime soon, even if they start innovating and take back Servo.
One of the reasons for this is that for many years Mozilla has shifted its focus away from developing what it considers to be the best web browser and towards generating as much profit as possible. (Just have a look at what their CEO earns). They won’t innovate anymore, which is actually sad to see.
Why is it bad that opera and Microsoft adopted the chrome engine? Really, why is a browser monoculture bad? It seems like you’re saying a “poly culture” is good for its own sake.
I can see that the reason why the IE “monoculture” was bad was because the browser wasn’t open source. Since chrome is open source, I don’t see any sort of existential monopoly on browser development being held by Google. The problem wasn’t a lack of diversity of browser usage.
Chromium is.
99% of the development is done by them, and they decide how things will or will not be.
But that’s not being compelled by law or force. Anyone can contribute or fork, and many have. It’s not google’s fault that they are one of the few entities investing in browser development. This is not Microsoft keeping others out.
The article mentioned some of the things - there are sites that don’t work on anything but Chrome. That is the kind of monopoly we’re facing.
Another big issue, do you know that chrome is moving in the direction so that soon, and blockers will not work? (Or is that already deployed?)
Do you know that, by default, Chrome tracks the shit out of you? People don’t even know or care, but some do.
Some of us remember how the web was better before Google pushed spam and ads and walled gardens to the top results.
I can’t watch Netflix in Firefox since recently, I’m not sure why.
That is what a monopoly brings you most of the times. Rarely it’ll turn out fine, but almost never if it’s a private monopoly.
There are sites that only work with JavaScript too, sucks for me. That’s not chrome’s fault. Nor is it even necessarily a fault. The web is decentralized, complain to the webmaster. Or would you like to enforce all websites work the way you want them to from a central authority?
Most don’t care but those that do are free to use another browser.
But it is.
https://en.wikipedia.org/wiki/Monoculture_(computer_science)
You’d think people would’ve caught on to this with the recent Crowdstrike debacle…
No, a major reason that it was bad was because people were stuck on it, not knowing any better even if better options were available (and they were - Opera, Firefox and later on Safari). This was a problem for two reasons:
The browser being open source would not have helped - it was installed by default on the world’s most dominant operating system and users had been trained to click on “the blue E” which basically represented “going on the internet” for them. In corporate environments, machines are often locked down to the point where regular users are unable to install new browsers, and getting IT to support a second browser is a fight you probably won’t win.
Note that the conditions that kept people stuck on IE are still true for Chrome.
Any monoculture is bad. OpenSSL and Crowdstrike are two very recent tangible examples as to why we need more software and hardware diversity. Otherwise, we’ll end up in a “one bug to rule them all” state, exploitable by any and every bad actor. Diversity mitigates that by providing a resilient ecosystem.
There are pros and cons to both monoculture and polyculture. You’re overweighting monoculture’s cons and underweighting its pros. Monocultures benefit from lack of redundant work and standards-overhead. Monocultures benefit in security by having more eyes focused on the problem, e.g. in Linux. Monocultures aren’t bad in themselves, nor are polycultures good in themselves. Rational evaluation requires looking at the actual pros and cons in any given situation.
I’m gonna make up a few hours at ${DAYJOB} lost due to the lack of advanced notice of CVE-2024-6387. And I want to work on unpacking the boxes in our garage. I hope to eventually set up a lab desk in the garage, and have a place to put the car during hail storms.
Wow. I thought
PasswordAuthentication no&PubkeyAuthentication yeswere like table stakes, sure. I thought accept 0.0.0.0:22 wasn’t that bad. That was yesterday, I guess.I think table stakes these days is: services on your machines should be behind a wireguard / tailscale VPN unless they absolutely need to be public. That includes ssh - if you’re connecting from a fresh laptop / phone then it has to authenticate itself to your VPN first.
(I note that I haven’t actually reached this security nirvana myself, but I’m working out how to get there…)
I’d be curious on what basis you think it is obvious that tailscale is more secure than SSH?
There’s a reason why I asked about the tailscale part
The tailscale client is small, opensource & written in Go: It’s probably more secure than ssh based on the evidence to date?
Someone could attack the server-side of course & you can make your own security tradeoffs but if someone has to compromise both the tailscale auth server & ssh to gain access then you’re probably better off than with ssh alone?
Most folks tend to use a Wireguard implementation that is backed by a kernel module. Now your attack surface includes additional kernel code. Just something to keep in mind.
I really need to organize my home office better. I have a hard time knowing how best to organize the various bills and pieces of mail that can’t be immediately discarded. Both my main desk and lab desk are covered in paperwork and cables and I’m really starting to feel claustrophobic.
I might see if I could deploy a server that is just gathering dust. I’d like to see if I can get a lab VM host online. I lack confidence that I have enough power capacity.
HardenedBSD now has a new flavor (lite) of the security/keepassxc port: https://git.hardenedbsd.org/hardenedbsd/ports/-/issues/50
The default flavor keeps enabled all the default features.
I’m preparing for next week: BSDCan! I’m going to bore the missus to sleep by rehearsing my HardenedBSD presentation enough times that I’ve got it memorized.
I’m also hoping to fix a few ports in HardenedBSD 15-CURRENT now that we have set
_FORTIFY_SOURCE=2across the entire ecosystem (base userland and ports).I literally just finished deploying HardenedBSD 14-STABLE on a brand new Dell Precision 7680. It’s an Intel Raptor Lake laptop with a discrete NVIDIA GPU, Intel wireless, 64GB RAM, 1TB NVMe. The ONLY thing that isn’t working is the trackpad. I’m assuming that’s because the vendor IDs haven’t been updated in the kernel. I’m assuming that’s an easy fix.
Everything else is working beautifully.
For info on the hardware, here’s the hardware probe output: https://bsd-hardware.info/?probe=4987815b22
How does FreeBSD scheduler works on that Intel performance/efficiency cores hybrid CPU?
I don’t think the default scheduler has been taught the concept of P/E cores. I know there has been talk on various mailing lists about the subject, but I’m unaware of any tangible movement. For now, I’ve disabled the E cores.
I would be interested in learning about the security aspects of P/E aware scheduling. I could envision a scenario where
explicit_bzeromight take longer on one core versus another. But I’m wholly ignorant of both the inner workings of the default scheduler and of the underlying CPU model.I would definitely volunteer as a guinea pig to help test patches to teach the scheduler the concept of P/E core types.
Intel and ‘Security’ are two opposite sides but NetBSD team implemented scheduler for ‘hybrid’ CPUs in 10.0:
Not sure if its only ARM related or more ‘generic’ but I think its a good place to start if FreeBSD has ‘zero’ hybrid CPU awareness (IMHO).
So…the trackpad isn’t the ONLY thing not working.
I’m going to expand power capacity to the server room at ${HOME}, specifically needed for the HardenedBSD dev/build infrastructure. Yesterday (Thursday), the portable air conditioning unit tripped the breaker while I was running errands, and the server room got to 91F. I’m hoping to add two 20A circuits to the room and put my home office on its own circuit.
Re: Anonymity in open source
I 100% agree with this — I think it is fine if people use pseudonyms or misrepresent their real names in stuff like online gaming, but somehow I feel like this is not okay in the open source world. If I am a company running code, I don’t want to run some code from a user “pinkkitty31”, rather I want to run code submitted by a “Michael Smith” who has signed a CLA and verified his identity to be held accountable.
That being said, I don’t want that to be enforced. I don’t want people to have to prove their identities when signing up for GitHub, for example. But I would like to see major software projects adopt this on a voluntary basis, so that we as a community can do our best to reduce the ease of which supply-chain attacks can be performed. The
xzattack was caught, thankfully. But this is not the end, it is merely the beginning. Russia and China lost this one, but they have an abundance of cheap labour and can keep doing this all day, and some day we will not catch it, and the implications will be grave. So I would rather havepinkkitty31give up his legal name than live in a world where we allow state-actors to perform these kinds of attacks.There was recently a story about someone interacting with a “company” where everyone on the video call was a virtual person generated by what’s nowadays called AI. In other words, we can assume that in the short to medium future faking your identity online, even via a video call, is as easy as doing it by email/text.
And if you’re motivated enough, you can hire an actor to portray the person you want to present yourself as. Once that person has been introduced IRL, signed papers, gotten the hardware signing key etc, they just hand it all over to the “bad guys” and disappear forever.
MORE IMPORTANTLY
why should FLOSS maintainers and project leads shoulder the responsibility to vet contributors for honesty and integrity??? The software they are offering for free always has a license file disclaiming all responsibility. If you choose to base your company on such software, you also assume the risk. You can mitigate this risk, by reading the source yourself, hiring someone to do so, funding a sort of Underwriters Laboratories-style outfit, etc etc. What you cannot do is force people to do all this for you, for free.
There seems to be some weird sort of bad conscience among some people withing FLOSS. “We need to step up, we need to be grownups in the room, we need to take responsibility”. No, no you don’t. Seek to get more funding for FOSS. Ensure that existing and future bad workflows are corrected. But don’t take the security of multinational corporations on your shoulders.
I agree with this! We’re in a weird spot of where the world’s infrastructure is built on top of open-source projects with little time and funding.
Agreed! AI doesn’t exactly help here. It can be made harder (by requiring verification) but ultimately, it is a force multiplier.
They don’t have to, but I am assuming that some projects will have an interest in making sure their code is somewhat protected from such bad actors in the future. But you are right — FLOSS maintainers don’t have to do anything, the software is provided as-is, without warranty.
In the US, there is no such thing as a legal name. (This is an authoritatively cited law review article.) Normatively, there shouldn’t be. My family, friends, colleagues, and strangers address me in many different ways as appropriate for the different situations, all of which are more “real” than what some office has decided it wants to call me. There’s strong evidence for the value of this in studies that show using chosen names produces better outcomes than imposing names (recent example, or deeper understanding).
I don’t quite know how to make sense of the document you have linked. It seems to address some gripes that trans people have with legal names. It does not seem very relevant to my point, and does not dispute the existence of legal names (as is on your social security/birth certificate/driver’s license/passport, which are mentioned in the document, see page 135).
Whatever you call it, by Legal Name I am referring to the name that is on your identity documents. The US does have identity documents. It does not even have to be a name, you could substitute
s/legal name/legal identifier/. Just something that uniquely identifies a person. It could be an Ed25519 key for all I care, as long as there is a regulated registry, such that submissions to open-source software is linked to a person rather than a pseudonym. I suppose in the US you could use a social security number for this purpose, though I don’t understand the identity-theft implications of that.I’m also not saying that people cannot keep using nicknames or pseudonyms — they are useful in communication. Just that it seems quite risky to have an entire civilization build on top of software that is written by people anonymously, it seems like a big attack vector.
I didn’t say people had zero legal names, I said people have many. The point of the law article is that there is no unified definition of a legal name in the US and there is no restriction to a single legal name. I personally have valid US identity documents with different names on them. As in the legal article’s examples, some of them are due to technical limitations, some are due to people having different names in different contexts, some of them are mistakes, some are changes over time, some are federalism, etc. I think trans people come up many times in the article because they prompt many examples that are unfamiliar enough to be recognized, where, say, the familiar complexity of marital name changes vanishes into the background.
As a political belief, I do not consider any name a state or business assigns me to be more real than the names I choose to use. As the book explains, imposing a single simplification on civilization’s historical complexity often fails even at its intended purpose.
I understand what you are saying, but I still disagree with your point. I interpret the fact that you have multiple valid US ID documents with different names on them not as evidence of the fact that you can have multiple legal names, but rather as evidence of the fact that the system is broken. I admit that this might be my German/European perspective talking, because this stuff is very regulated here: you, at any point in time, only have one legal name, which is on your birth certificate, ID cards, passports. Any place that matters (banks) will verify your legal name with your ID card. If you manage to have valid documents under differing names, this is either fraud or an error. In fact, it is a felony here to put a false name when signing up for something (even Facebook, although in practice it is not widely enforced, only banks will enforce it, because they are liable if they don’t). I don’t think it is fair to draw conclusions from the brokenness of the US system to discredit legal names as not something approximating “useful identifiers”.
Besides: Even if a person can have multiple legal names, this system will still work. If there is some CLA that you have signed and it was verified against your ID card, and it calls you “J. R. Porter” but your legal name is “Jordan Ryan Porter”, then it is still close enough to be a match. Even if you change your name at some point — I know people who have done this, for various reasons — there is a paper tail of this happening. Both your previous legal name and your new legal name can be resolved to your identity.
Obviously, there will be edge cases. We will never have anything perfect, unless we get a copy of your biological identifiers (DNA, iris). But we don’t need perfection, all we need is to make it harder for bad actors to infiltrate open-source, and if they do, it gives us some ability to hold them accountable. Accountability is practically non-existent today. We don’t know who “Jia Tan” is, and maybe never will, just because there is no system in place that verifies identities.
Thanks, I think you’ve given a great description of the fundamental differences of political opinion here.
You are welcome, though I did not realize that this was a political issue.
But, to my original point: would you not agree that it would be advantageous if core infrastructure (openssl, core libraries) had some form of an audit trail that would allow us to link contributions to people’s identities in an effort to thwart supply-chain attacks that we will inevitably see more of in the future (even if this was not based on legal names)? I feel that long-term this is the only way to protect against state actors with a lot of manpower, such as China, Russia and North Korea.
I don’t think the downsides are worth it, no. (related)
I don’t mean this in any inflammatory way, but your particular stance here aligns here with authoritarianism (in an overall sense) — some authority gets to designate your identity in a way you cannot negotiate or opt out of.
This rankles many folks who have a range of concerns over such things, from the more ‘crackpot’ types who think that a government trialling digital ID (in the global (non-EU) West, in the year of our lord 2024) must be wanting to microchip everyone and deny you the ability to buy food unless you submit to them (none of whom have ever seen how Europe does it [1]), to those who have very good concerns — two examples that come to mind immediately are folks working on deniable cryptography who operate in less secure countries, and trans people.
At any rate, talking about names and identity is an issue of incredible political heat and importance, and many, many words have been spent on it in the past decades.
[1] at the same time, European countries’ implementations usually have some very good legal safeguards involved and tend to be co-ordinated closely by the government acting under those laws, whereas implementations elsewhere are often, uh, lacking, implemented often by a range of independent companies all trying to undercut each other, with a much shakier legal backdrop.
It is always funny to me when authoritarianism is mentioned in threads. I feel like you are attacking me because you disagree with me, and I don’t feel that this is nice. But I will take your criticism seriously and address it in the best way I can.
I believe you either misunderstand my idea, or you misunderstand authoritarianism. Feel free to clarify what you mean to avoid confusion. Authoritarianism means the enforcement or advocacy of strict obedience to authority at the expense of personal freedom.
What I am talking about is an idea that open-source projects can adopt, if they want to. Being opt-in, it is by definition not authoritarian.
The idea is to verify the identity of the people that contribute. This should not be inflammatory in any way. It is standard practice to require an ID document to participate in society. This is neither novel nor unusual. For example:
For any identification to work, you need to have a trusted authority. By design, you cannot opt out or negotiate, then you would be able to change your identity (which undermines the whole thing, because then bad actors can do it again). If you consider it authoritarian to require identification, then you are saying that the entirety of the western hemisphere is authoritarian.
I also mentioned that folks who simply do not have an ID don’t need to do this verification, any system needs to have flexibility built-in to allow for the realities of life. This means that nobody is excluded who lives in a country that does not or will not issue an ID. Therefore, this system is not strict, states cannot withhold ID to prevent you from contributing. Therefore, not authoritarian. Projects need to weigh their needs for security, their time for proper code review and the need of the public to participate. Life is a tradeoff.
Since the knowledge of the identity would be kept by the open-source project maintainers, I see no issue with anyone submitting to this. If you don’t want to verify, then you do not need to contribute to the particular project that enforces it. Err on the side of caution. If there is a legitimate reason not to verify and share PII, then it is always possible to talk to the maintainers and skip verification, and have your contributions be subject to more scrutiny. This procedure is not designed to keep people out. It is just designed to safeguard open-source projects.
It is new to me that names are something political. I feel a bit uneasy now, it feels to me like there is some amount of bias here on this topic, and it should not be. My comment, which is a reasonable idea and something that a majority of financial services do, is treated as if this was a radical idea designed to oppress. My advice would be to reflect on your opinions, or perhaps suggest an alternative way to keep open-source safe. Perhaps there are better ways of doing this?
I have tried my best to avoid this (opening with “I don’t mean this in any inflammatory way”, giving examples from “both sides” of the political spectrum, etc.), and it would appear I have failed; that’s my bad!
I think this is a little naïve. If an idea of a particular political thrust takes off and becomes widely adopted, then there is a de facto (and perhaps in future de jure) implementation of a particular way of thinking. Facebook’s “Real Name” policy was a step in that direction, and carries many of the issues that your suggestion does.
In so many cases it is, when it comes to marginalised peoples. This is not news. Are you seriously saying you’re unaware that folks in the western hemisphere struggle with getting a job, opening a bank account, getting a driver’s license, voting, getting medical attention, etc. etc., solely due to ID issues? These issues are rampant.
Let me zero in on this. Let’s say your country does not allow name changes in the case of trans people. (Or perhaps you can change your name, but you’re not allowed to change your surname to have the masculine or feminine ending as appropriate, and therefore your legal name still contradicts your identity.)
But your country still issues ID, so your policy mandates they use it. Now your policy is enforcing a particular country’s political ideas on identity! This is extraordinary.
My advice would be to do some reading of your own if this is new to you; I meant it when I said decades!
The heat here has increased enough that I’m bowing out here, but I wish you all the best.
I understand that people want to use Facebook pseudonymously, even here in Germany we have a court decision that allows for this. However, the things you post on Facebook don’t power every single computer system in the world. The implications are not the same, I don’t think it is a fair comparison. There is no fundamental reason for Facebook to know your true identity (although, Facebook does have a problem with criminal activity going on).
I think I would need to see some evidence for that to believe it. It might also be a US thing. I can tell you that here in Europe, I have yet to hear about a single case of someone having issues with their ID. I can tell you many cases of people struggling with bureaucracy, but that is an entirely different issue (understaffed and inefficient governmental agencies).
This is where you are wrong! This scheme does not enforce any political ideas. The identity is used for verification purposes, and for nothing else. I’ll give you an example:
I’ve toned it down a bit. While we may not agree, it is a useful discourse. I hope I did my best to try and show you how this system could work and why it should not be an issue.
How does keeping a “real ID” on file defend against a state security agency that can trivially mint new IDs for their agents?
Counter-question: How does using TLS certificates defend against attacks, when a state security agency can trivially mint new certificates and man-in-the middle connections?
We can never achieve perfect security. All we can do is make it harder, and more expensive. And requiring identification is certainly a higher burden than just registering an account on GitHub, which takes 10 seconds.
Good grief, you are the one that proposed a specific defence against a specific attack. You should at least be able to explain how your proposal is effective without diverting on to a different topic, or dragging the goalposts over to vague generalities.
I believe that I gave a useful explainer, but I can try again:
I’m not tied to this scheme, but I feel that in practise it has the best cost-reward tradeoff. If you have a better idea for how to do this, I would love to hear it!
Can you explain how a CLA would keep a ransomware group out?
You are being ridiculously naïve.
You are also failing to take into account the cost of your scheme in terms of wasted maintainer time and lost contributions.
Hey Tony, what I meant by that is that ransomware groups likely don’t have the resources or access to mint new identities, such that they would have to use their real identities. Which, if a group is based in North Korea, could give away some clues. Additionally, it would allow bad actors to be marked and prevent them from participating in other projects in the future. I feel like I have explained that before, I hope you can see how that makes sense. It is not a perfect defense, it is a layer on top of the processes we have already (code review, fuzzing, etc). It is a better situation than we are in now, where a single person can create GitHub accounts all day and create fake personas. Jia Tan could already have other personas committing code to the Linux kernel, curl and other foundational projects, for all we know. Do you see how identities could make this significantly harder (but not impossible)?
Ouch, there is a nicer way of saying that. In general, for a productive conversation it is important not to fling (perceived) insults at other people. A better way of phrasing your feelings here would be to say: I am afraid that your threat model of ransomware groups is too simplistic, I feel that you underestimate their abilities and links to nation-states. That would be a much better way of expressing what you think without coming across (even if unintentionally) as hurtful. You should always use “I”-expressions rather than “You”-expressions to avoid this.
This system is unlikely to be implemented due to the burden it places on maintainers and due it driving away possible contributions. I acknowledge that.
My comments are more me thinking loudly on something we could possibly do, because I don’t want to live in a world that is so easily thwarted by bad actors. And to be honest I’m a bit frustrated because I feel like multiple people in this thread are trying to tear my idea down needlessly, rather than trying to suggest better options.
In your opinion, what do you think should core-infrastructure open-source projects do to protect themselves from threat actors?
The only reason this actor/group/whatever went through the considerable effort to craft this backdoor and delivery method is that up to 77% of software used in corporate environments is open source (source). If there was a blanket ban on FLOSS in companies, this would not be profitable to do. So you’d root some hobbyist machines, who cares?
Now, I’m not sure what you mean when you say “we”. Maybe you’re working for a company that relies on FLOSS. Fine. Then that company or an association of companies should take responsibility and fund mitigation efforts.
As noted by Adriane:
Don’t be gaslit into thinking there’s a “FLOSS supply chain”, nor that securing that “chain” is the responsibility of the FLOSS community.
Took me a little sleeping on it, but I think Worse is Better gets at the heart of the disagreement on this idea. You’re advocating for a maximally effective system to impose on the chaos, and I’m trying to say there’s irreducible complexity in the problem space and a single system would do more harm than good.
There’s the classic Falsehoods Programmers Believe About Names. I’ve shared this author’s experience of being in a country that doesn’t use the latin alphabet and having a name contains phonemes or vowel patterns that the locally popular languages don’t. The resulting mistakes are charming right up until the force of law imposes grave, irreconcilable inconsistencies. I’ve put together a few databases so I know to reach for Unicode, to model one-to-many alternate representations, to use bitemporality and attestation, to write training manuals for the frontline bureaucrats. But I’ve put together so many databases and business processes that I don’t think it’s possible to capture the complexity of human names, let alone human identity, let alone at a reasonable cost, let alone without allowing the state abuses that have resulted from every one of these systems previously attempted.
To put it another way: you sketch out an identity standard to increase the cost of attacks but the attackers most likely responsible for the xz backdoor and the specific attackers you list are the entities most able to afford those costs and in the best position to subvert such a system. My criticism here comes down to this system being fundamentally ineffective and inhumane. As a programmer I’m vulnerable to the siren call of simple, elegant systems, I want better to be better, but this plan has crashed into the rocks before it sets sail.
Hey Peter, I will summarize my stances on the points you’ve raised:
I think I have laid out my arguments in a fairly straightforward manner, I hope they make sense, even if you don’t agree with them. I think it is fair to say that we agree to disagree. The beauty of a pluralist society is that we can all hold differing beliefs. Often times, there is no single perfect answer to a problem (not yet, or we don’t know enough that we can identify it as such even if there is). All I hope is that we will not see successful infiltration attacks like these, and even more so I hope that they do not lead to the loss of human lives. Software is everywhere, we are more vulnerable than we are aware of.
I have multiple distinct legal names in my different countries of citizenship, one of them indeed being an EU member state. (They’re not even related forms of each other, not in given or last names.) What is my unique identity?
Real, human systems don’t work this way. Humanity is many ways about the lack of machine-like processing of rules with a precise system of identity and recognition that admits no exceptions. (Jean-Luc Picard: “there can be no justice so long as laws are absolute.”) Names are neither singular nor static.
My choice of the word unique was perhaps not quite wise. I meant it in the sense of “uniquely identify”. But even that is not really what I wanted to say. More like, “given your nationality and name, we roughly know who your are, or at least we know enough to be able to sue you”. If people were born with UUIDs, we should use those. Sadly, that is not the case.
Indeed, multiple countries might have a different idea of what your legal name is. Every country is it’s own authority in determining a person’s legal name in their system. As pushcx has pointed out, in some cases even a single country might have different ideas of what your legal name is.
In your case, all of your identifiers are valid. If you have a French passport with the name of “Loïc”, then
(France, Loïc)is a valid identifier for you. It is enough information to bring forth a lawsuit in the case you do something illegal. Such is the case for the other passports you hold.My phrasing was perhaps not clear or incorrect there, but I think that this is not as complicated as you make it sound. I don’t quite understand why it is that we need to get hung up on talking about names, when my point was merely that we should have an audit trail (could be linked to anything, like a social security number, or whatever). I did not want to veer into politics and defend names, they are merely the most common identifier for people in use.
Understood! I think we got hung up on talking about names when the primary and repeated example of an identity given was, well, names.
I do continue to disagree and contest that trying to tie contributions to a “real”, verifiable identity, in any way, is a clear net negative.
Thank you! I don’t like the fact that everyone got so hung up on names, rather than discussing the idea itself. 😄
Why would you consider it to be a clear net negative? I am quite curious.
Haha oh dear my sweet summer child. https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
Most open source is pseudonymous, identifying contributors by their usernames or email addresses. Anonymity (actual lack of name) is very rare.
You are correct, I misspoke.
s/anonymous/pseudonymous!Thank you for posting that, it is a great article. I am aware of it, it was posted here some years ago I believe. 😄
I should perhaps clarify what I mean, because I don’t think anything discussed in this article is an issue for the scheme I am proposing. What I am thinking is that, for a given open-source project (let’s take openssl for example), anyone who wants to contribute has to sign a CLA (on paper), go on a short video call showing his/her signed CLA (with his/her handwritten name on it) and show an ID document to match the hand-written name to the one on the ID. Then the CLA is snail-mailed in to the developers, which keep it in a safe. After this process, contributions from this person are accepted. This does not require much from names, doesn’t even require that they are mapped into Unicode, or that you can parse it in any way, just visually compare.
If you live in a country that doesn’t have IDs, or doesn’t use names at all, well then you just don’t do this step. This encompasses so few people that we can just not do the verification for those people. These systems can never be fully rigid; they have to allow for some flexibility. The purpose of this is not gatekeeping.
In the event of a compromise, the true identity of the actor is known to the maintainers of the project. That is the point of this, so that when we detect something, at least we know whom to sue.
Obviously this system is not perfect: ID cards can be forged, there could be human errors in comparing them, people might live outside of our jurisdiction. But it is not designed to be perfect, it is only designed to make it more difficult for state-actors. Today, it is too easy for state-actors to crate fake identities and start contributing to projects, and us falling victim to ever more sophisticated attacks. The one on xz was spotted, thankfully. But someone really motivated could do a lot better, such as introducing hard-to-trigger memory unsafety issues in C/C++ codebases that can be triggered to cause remote-code-execution. Yes, we do have some fuzzing infrastructure, and we are doing great things to catch these, but there are ways to thwart this as well (as we have seen in xz, some parts of the codebase were simply disabled).
I’m not saying that this should be mandatory for all core infrastructure, it is more of a thought experiment for what we could do to make it harder for these attacks to occur. Using legal names for this scheme is not an issue, even all the “incorrect invariants” and the broken system in the US that pushcx mentioned would not be problematic for this scheme. The question is more of whether open-source projects would adopt this, because it creates more work for them. And the answer is likely no, sadly.
As the maintainer of an open source project, I don’t want to be held responsible for maintaining physical copies of incredibly sensitive personal information. And I wouldn’t want to entrust my personal info with any random open source maintainer.
It’s not about whether it creates more work, it’s a matter of long-term irrevocable trust.
Now where did I set my car keys?
And I assume you’re thinking that instead of being easy, that it would be difficult for state actors to create fake national IDs and start contributing to projects…? Is that because you think creating a physical document would take… perhaps a few more seconds… than creating a github account?
Also, if you require me to send my national ID to contribute to your open-source project, or require me to engage in any other kind of identity verification that could be reused to perform a replay attack, that would be a sure-fire way to ensure that I would never contribute to it. Copies of national IDs can be (and often are) used to steal identities and engage in criminal activities, so every time you share it with any entity, you are putting yourself at risk from being a victim of those crimes (even when not done intentionally, e.g. individual, company and government databases can be hacked into and your identity stolen as a result).
Furthermore, nowadays with AI it’s entirely possible to join one of these video calls you propose with a fake avatar that looks like a real person, of which perhaps you only need a picture to create a realistic-looking copy of that person, especially considering that people can change their looks drastically from one day to the next, so the fake avatar doesn’t even have to 100% match a picture to pass the identity check. Or better yet, state actors could just create entirely fake people and join these video calls using those.
Perhaps some form of cryptography could be used to attest that you are registered in a national citizen database without it being possible for any particular attestation to be reused in other activities, but I think you’re failing to consider that you are trusting governments not to attack you, when the attacker is a government. A government can just create fake entries in its national database whenever it wants to, so unless I’m missing something, it seems like your scheme would be completely pointless in addressing the problem it purports to address.
And just for the sake of argument, let’s say that you succeed in identifying the spy that sabotaged your open-source project and then sue that spy, presumably in his country of residence (Russia? China? Israel? US? North Korea?). What do you think would happen as a result? Absolutely nothing. The court case would probably be moved to some secret court for national security reasons and then summarily dismissed after it being investigated, since the sabotage operation was sanctioned by the government in the first place. So even if you could, what would be the point of suing?
It takes a lot more than just a few seconds. The physical document has to be produced by the nation’s ID printing, due to the security features involved this can take weeks and has a non-zero cost. In many countries, there are regulations and red tape around who and when is allowed to mint new identity documents.
That is fair, I would assume that most projects don’t adopt this scheme for practicality purposes and because it drives away contributions. And that is fine — I’m not expecting this scheme to be implemented, more thinking loudly over what process we could implement to make these attacks harder.
Possession of a scanned ID document should not allow for crime, in theory. In practice, yes you are right, it can happen. However, a lot of places you need to trust with it: banks, any hotel you check in requires your ID or passport. For protection, I don’t advocate for keeping a copy of the ID, just a signed CLA with the legal name on it that is kept in a safe. The ID is only used briefly on a video call for verification. This is the same system we use here when you want to get a phone contract, or a bank account, or anything else.
That is true. Fundamentally, that is hard to fix. What existing ID verification schemes do is ask you to do some operations, such as moving closer to and further from the camera (which changes the POV), and ask you to shake your ID so that security features become more visible.
I don’t think we have an AI yet that can do this in a convincing way, but we might get some at some point. At that point, we need to rethink how to do online ID verification.
This is true. No matter what, we can never be fully safe from state actors. All we can do is make it harder for them. If a state actor wants to create 1000 identities that they can use for open-source attacks, it makes a big difference to them if they:
All of these measures make creating and executing large-scale attacks harder. Any scheme that is harder to break is more intrusive to security, which we don’t want. This is true with cryptography: any cryptography is breakable, we just design it so that breaking it becomes prohibitively expensive.
Some governments already have ID cards that contain cryptographic keys that could be used for this. And yes, for governments we cannot fully prevent attacks, we can just add some hurdles that make it harder.
So, there are several elements to this. The most important one is that it just makes it harder. If a state-actor still does it, we could catch irregularities (such as a lot of people from Russia verifying in a short amount of time) that we currently cannot catch due to accounts being pseudonymous. Next, we still obviously need code review, so even if a state-actor is able to infiltrate and produce proper ID documents and slowly create personas, our existing safeguards are still in place.
If we do detect anomalies and find out that there has been an attack, then we know the (real or potentially fake) identities of the attackers. It means that we have some idea of who performed this attack. Fundamentally, yes we cannot take people to court that are outside of our jurisdiction. The main idea for this system is that it doesn’t come that far. Another upside is that we prevent governments from reusing identities: now all of the identities associated with the attack are known and “burned”, and they have to start from scratch, slowly building trust.
I hope that this makes sense, at least somewhat.
I’m a citizen of a country in the EU and I can get a new passport in less than 24h, although it only takes that long due to the underlying bureaucracy, not because it’s not technically possible to create it in minutes.
The central services of my national government already create more than a million ID cards per year and there’s no reason why they couldn’t create 5 or 10 million per year if they wanted to. The cost of printing a card is negligible when compared to employing an engineer in a national security agency.
And in the countries we’re talking about, capable of sabotaging an open-source project like
xz, their national security agencies can mint new identity documents for their spies whenever they want to. I really don’t think it’s a significant barrier for them.Exactly, and I think that’s a problem. If everyone did that, my ID would have been shown to hundreds of strange people who I’ve never met nor will I ever meet. These people could screenshot my face and my ID, create a copy of them (perhaps using AI), then open a bank account in my name using exactly the same process. As far as I know, the security features of the ID are not meaningful over video calls (and even in person, I think they are almost never really paid attention to).
I don’t really believe that. As you can see, it only took one fake identity to almost compromise the entire planet. You only need one well-placed vulnerability to do a large-scale attack, you don’t need to compromise thousands of projects (which you could do with only a few dozen identities), much less create thousands of different identities.
As far as I know, this has never been a major problem, especially for open-source projects, or even proprietary ones. For example, what if we found out that the Linux kernel backdoor attempt was made by North Korea (or China, or Russia, or the US, or Israel, …)? Would that change how the Linux kernel accepted contributions? I really don’t think so, except for banning the contributions of the one person who submitted the backdoor… which IMO would not meaningfully slow down a national security agency (especially if the identity was fake). The identity is already burned regardless of whether there’s a national ID document behind it or just a github account.
Why wouldn’t it go that far? I still don’t understand how knowing which government did it would deter them from doing it.
But even with just a github account, they’d already have to do that anyway. Having to create a new fake national ID would not change that, the real barrier is slowly gaining trust over years of contributions.
To me it doesn’t make much sense, because it seems like you’d be greatly punishing legitimate contributors (especially for casual or relatively-casual contributions), while not meaningfully preventing 3-letter agencies from accomplishing their goals.
Since these attackers are so powerful and have almost-infinite resources, I tend to think that it’s extremely difficult to defend against them. As you said, I think code review is part of the answer, but it’s not likely to be enough. Some technical suggestions like using git checkouts rather than release tarballs would have made this attack or similar ones a bit more difficult, but it would not have meaningfully solved the problem.
I’m actually very pessimistic about attacks like these because I see how often people just download and run pre-built binaries rather than compile their software from source, or even how often projects encourage users to do
curl <url> | bash, so I don’t see an end to these problems anytime soon. Some kind of trustworthy formal verification of entire systems could also be an answer, but we’re even more far away from reaching a goal like that than systematically compile everything from source.And in many ways, I think we are actually getting more far away from solving this problem than we are getting closer. Software keeps getting larger and more complex every year, the avg number of dependencies keeps increasing, vendoring dependencies is very popular nowadays (making systematic code review and patching hard or impossible), container usage (which contain binaries) is more popular than ever, some projects are extremely difficult to build from source so binary artifacts are actually quite common, build systems and code editor plugins often download binaries from the web, compilers are often written in their own languages making bootstrap-from-understandable-source impossible, smartphone platforms exclusively using binaries rather than compiling from source, IoT and networking platforms using vulnerable software that hasn’t been updated in years (e.g. the Linux kernel), etc, etc… IMHO it’s all just a big impossible-to-solve mess, really, especially when sophisticated attackers can easily turn random bugs into backdoors.
That’s not even mentioning hardware or firmware vulnerabilities and backdoors, which I’m guessing nowadays are much easier for these agencies to introduce without any suspicions (or even with them), due to the infinite complexity of modern computers and their features (which often cannot even be disabled).
I’ll try to get back to you:
This verification is only really useful or intended for a handful of core-infrastructure projects. And yes, when you work an travel you will also show your ID to hundreds of strange people you’ve never met, when you check into a Hotel.
IDs should really not give anyone more access to anything. I’ve discussed this in another reply, but the TL;DR is that there needs to be some amount of trust between you and the maintainers.
I’ve discussed the AI issue in a separate reply, but in general once AI becomes good enough to fool these verification processes then we need to rethink them. But that should not stop us from implementing improvements now.
So, this is a good question. The main utility behind this verification is just to create it harder to create fake identities. We might be able to use this to spot patterns and do more thorough code review if we notice anything suspicious. In countries with a good legal system, it allows to take legal actions against individuals that participate in this. But yes, there might be cases where we cannot do anything, and that is alright — just the fact that it makes it harder to perform attacks is a big win.
Trust, but verify.
I agree that it is almost impossible to defend against three-letter agencies. That is true today and it will be true tomorrow, regardless of what we do. A defense-in-depth strategy has multiple layers of defense:
The verification simply ensures that it is difficult for individuals to create multiple pseudonymous accounts and build trust, which they can later exploit. It just makes it harder. You need more resources (more people), perhaps fake identities. Every layer makes it a bit harder (read: expensive) to perform these attacks, due to needing more people, identities.
I agree with you on some of these parts. The precompiled binaries is not ideal. Even if we can systematically compile everything from source, this does not fix anything. There is still either a requirement for the source to be valid, or you need to manually check it. It is not possible for a single human, or even an organization, to review all of the source code of the software they use without employing many dedicated people to do so. But I agree that there would be a benefit to this.
I think the underlying learning here is that all of the tech world is ultimately built on trust.
100% agree with you on that, although this is something that we really can’t fix, software will keep on getting more complex. Or maybe it will become super easy, just an AI runtime and all the software we use is just ONNX models. But at that point we can forget about any kind of security, because we won’t be able to understand the software we use at all.
This is true. Bunnie Huang is doing some interesting work in that regard. Some other examples of this would be the Intel ME, which runs a binary blob (a Minix-based operating system) inside every Intel processor that has ring
-1permissions (including networking). I agree that on the physical level, it’s not looking so great. You could run all of your stuff on open-source hardware (RISC-V), but even then you need to trust the fab. I honestly don’t have a great solution to this, because verification is so hard. And even if you wanted to, it would be close to impossible:That all being said, I think anything we can do to improve the security, even if marginally, is a good thing. I hope that my response makes some amount of sense, you have raised a few good points.
Are nation state actors not able to create fictitious identities that appear legitimate to the average person (or even to other nation state entities that verify identification documents?)
I’m pretty sure there’s a trove of nation state covert intelligence operatives already using alternative identities.
HardenedBSD’s response: https://hardenedbsd.org/article/shawn-webb/2024-03-29/hardenedbsd-unaffected-cve-2024-3094-backdoor-xzlzma-560561