1.  

    Our idea was that if we could make it really hard to make any exploit work on it, then we wouldn’t have to worry about individual exploits.

    That just sounds like “security by obscurity” to me. The rest of the interview doesn’t convice me otherwise, but then it’s not very technical.

    1. 6

      they’re reencrypting the return stack pointer every 100ms, and implied that’s happening to many more places in memory also - how is that obscurity?

      not trying to be contrary, I just don’t understand the dismissal.

      In the paper we wrote about [the Morpheus concept], we had 504 bits of knobs. In the design that we put into this attack, we had almost 200. And 2^200 is a big space to search.

      The way we do it is actually very simple: We just encrypt stuff. We take pointers—references to locations in memory—and we encrypt them. That puts 128 bits of randomness in our pointers. Now, if you want to figure out pointers, you’ve got to solve that problem.

      1.  

        What I’m sceptical of is the seemingly arbitrary “let’s encrypt this, let’s encrypt that”. Their approach to security is complexity, and there are no formal models/proofs that these measures actually enhance the security of the system.

        Of course this is a valid, albeit in my opinion rather poor, approach to security. Instead of a tangible problem formulation (what are the attacker capabilities? what do we want to protect? how do we achieve that?) it’s a bunch of encryption. Which also has me asking: How are they generating the encryption keys? Because once you break/tap into that you’ve essentially won anyway, regardless of their countermeasures.


        Ah they have a paper, I must have missed that before, my bad. Not really an excuse, but information security is a niche in which claims fly wild and I’ve learned to apply a healthy amount of scepticism to any new shiny thing that comes out.

        At first glance the paper looks reasonable to me - the only questionable security assumption in my opinion is support from the OS scheduler.

    1. 4

      A friend of mine also did it himself, using SQLite, which I found interesting journey into the strengths and weaknesses of SQLite.

      1. 8

        Part of the solution could be Subresource Integrity. You can include a content hash in each <script> or <link> tag, which the browser checks.

        That only works if the <script> tag itself hasn’t been tampered with though.

        (edit) Another thought: since this is an app, the HTML probably doesn’t do much besides load the JS. Maybe all the HTML you have is <script src="main.js" integrity=... >. If you wrap that up in a data URL and put it in the git repo, then if a user starts from the git repo and click the URL, they know they’re getting the right HTML because it’s actually embedded in the link (assuming they trust the contents of the git repo).

        1. 1

          I did not know about that standard, thx.

          So if this were to be used, that means the index.html that would ideally come directly from the site itself needs to be trusted. I still feel like something needs to be separate from the site in order to verify the site’s contents or maybe the index.html is signed by the owner with the signature appended, but it still requires the public key to be held onto somewhere for validation outside of the retrieved index.html

          1. 5

            Hi, co-author of the SRI spec here. I have toyed with an approach that has a bootstrap-index.html page as a standalone, downloadable and widely hostable page. The page would load all of its assets through a metadata file that can be centrally hosted and versioned. Signatures would have to come yourself (web crypto? ugh). But the metadata could contain integrity metadata and you could enforce those to be in place for all subresources through a ServiceWorker.

            Even though SRI is only supported in html syntax for scripts and styles, every fetch() can bear the integrity metadata. This means that you can add them on-the-fly through a ServiceWorker and have the browser verify it for you. This is a bit brittle and you have to include an escape hatch for when ServiceWorkers are disabled or the website is force-reloaded (which bypasses the ServiceWorker), but it is absolutely doable. So doable, that I have in fact started to implement it three times (though all incomplete 😬).

            This might be some interesting reading non the less: https://github.com/mozfreddyb/serviceworker-sri and https://github.com/freddyb/sri-worker and https://github.com/freddyb/sri-boot.

            I also created a tiny serviceworker-security challenge in 2017 where I provided a website that uses ServiceWorkers for a similar security feature to find out exactly how brittle it is. It was insightful in itself, but my experiment was a bit ill-defined and is probably worth running again. The results on using service workers for security are on my blog.

            1. 1

              That’s what TLS is supposed to solve. Of course, nowadays it has become much easier to obtain a signed certificate for any domain (e.g. by CA compromise) that this isn’t the foolproof solution it was [intended to] be.

              1. 1

                There are also certificate/key pinning. But HPKP died: hhttps://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

                In the end, you have a technology mismatch here. e2e security essentially relies on the endpoints being secure and protecting the connection between them. Any kind of updates for the software jeopardizes the secure endpoint.

          1. 1

            I’ve used (something like) this with Tamarin, and it is immensely useful when working with provers that employ a high degree of automation.

            1. 8

              A very nice proof, and delightfully short as well. Honestly I’m not the least bit surprised by this ;)

              I’m missing a reference to a resource which proves that m-tag systems (for m >= 2) are Turing complete, could you add that? Thanks!

              1. 6

                Added a bunch! The history of the proof turns out to be a bit more complicated than I thought.

              1. 2

                I love turtle graphics! In high school our teacher used turtle graphics and Lindenmayer systems to introduce us to GUI programming (in PASCAL/Delphi, even though it was “only” 8 years ago).

                For anybody wanting to read up on this, search for Lindenmayer systems (presumably why this project is named “lyndenn”).

                P.S. The “Koch” preset doesn’t look like the snowflake I expected, should that be a different system?

                1. 25

                  “Have you used any of the following ergonomic keyboards” is missing a “No” option IMO, since it is a required question.

                  1. 2

                    Thanks, you are right this would have been better with a ‘no’ option, I’ve stopped it being a required question.

                  1. 83

                    Apparently I need to remind people that:

                    1. No, it doesn’t matter if a cryptography blog has cartoons on it.
                    2. No, it’s off topic to rehash this meta discussion. Again. You can click the domain to find it on several earlier posts.
                    3. No, it’s not appropriate to flame the author because their blog has cartoons. This has been the final straw in at least one ban so far.
                    4. No, it’s not appropriate to flag the story for mod attention because it feels like you get to punish cartoons. Reread the previous point and consider whether you want mod attention. You can click ‘hide’ below the title if you want to not see the story or any comments to it.
                    1. 4

                      I feel this and I agree with you. However, I have flagged this as spam because this person keeps posting their own blog over and over. Maybe that’s not how that flag is intended to be used? I’m open to criticism about that. In any case I wanted to be clear about my motives for flagging this since it seems like there’s some other thing going on that I didn’t know about until reading this.

                      1. 56

                        A qualitatively good article every two weeks is hardly spam in my opinion.

                        1. 45

                          Spam is low effort, low quality, high volume. This is none of those things.

                          1. 31

                            It’s well written work, yes it’s posted regularly, but that doesn’t make it blog spam. The submissions tend to see engagement, so I think there’s some level of consensus there amongst the community.

                            1. 3

                              there’s a previous thread somewhere discussing if self-posting should be permitted or not, there’s definitely arguments for both sides. some users routinely post their own site and it’s just really uninteresting stuff (including this post), but I don’t think that’s spam— it’s just content I’m not interested in personally.

                              Also, there’s a user script for hiding posts from a domain/user/whatever. someone linked it to me in a previous thread but the story was nuked.

                              1. 6

                                Here’s the Greasemonkey script for blocking domains, stories, or users.

                                1. 3

                                  Yeah, this is more in line with what my opinion is. I’m not arguing whether or not it’s well written and it’s certainly on topic for this site. I’m not trying to come in here to argue with folks. I flag something as spam if someone keeps posting “self-promotion” things like this. That still seems like spam to me but I’m fine being told I’m wrong as it’s clear what the consensus is. I won’t reply to each person that replied but I appreciate them all the same.

                                  1. 9

                                    If it helps to add context, I do submit things other than what I’ve written, if I believe they belong on this site. :)

                                    1. 4

                                      Yes, I see 4 out of your 15 posts aren’t something you authored. One of which comes after this thread started. Either way, my opinions aren’t personal attacks or facts… they’re just opinions. I mean you no disrespect.

                                      1. 9

                                        If it’s on-topic then it’s on-topic, and does it really matter who submitted it? In general I prefer it when authors submit their own stuff, because if I have some comment or criticism I can write “I don’t agree with you there”, “I think you are mistaken”, “I think this is unclear”, etc. and can then have a conversation with the author themselves, instead of “I don’t agree with the author”.

                                        1. 3

                                          Obviously, I think it matters or I wouldn’t have flagged it. Seems we prefer different things.

                                          1. 7

                                            If you don’t personally like it, even though it’s on topic and there’s nothing wrong with it, use the hide feature.

                            1. 3

                              I was curious what the practical implications of having an undecidable type system are. Apparently, it means you can make a program that makes the compiler crash during type checking: https://bugs.openjdk.java.net/browse/JDK-6558545

                              1. 4

                                I don’t think that’s a requirement. It can also mean that the type checker can go into an infinite loop (without crashing).

                                1. 3

                                  The compiler crashing is rather a side-effect of the underlying undecidability.

                                  Concretely, undecidability means that there is no universal algorithm which, given a candidate Java program to compile, correctly terminates within some finite time (dependent on the input length), i.e. it may loop infinitely for some programs. It may also require infinite computing resources, such as stack space in this instance, which leads to the compiler crashing. But as @munksgaard correctly said, it can also “just” loop infintely.

                                  1. 3

                                    Practically, there is none. As soon as compilation takes too long, you’ll cancel it and rewrite the code anyway.

                                    1. 1

                                      I agree with @munksgaard and @bfieldler, crashing during type checking is just one way in which the undecidability can show.

                                    1. 4

                                      Union types also do not form a category-theoretical coproduct, contrary to sum types.

                                      1. 18

                                        What this rant does not focus on: It’s a good thing that these usecases are broken. Wayland prohibits your desktop applications from capturing keystrokes or recording other apps’ screens by default. X’s security model (and low level graphics APIs) is/are severely outdated, and Wayland promises not only to be more secure, but also expose cleaner APIs at the lower level (rendering, etc.)

                                        These usecases are/will still be supported though, but this time via standardized interfaces, many of which already exist and are implemented in today’s clients.

                                        X is based on a 30 year old code base and an outdated model (who runs server-side display servers these days?). Of course, switching from X to Wayland will break applications, and until they are rewritten with proper Wayland support they will stay that way. For most X11 apps there even is Xwayland, which allows you to run X11 apps in Wayland if you must.

                                        1. 25

                                          What this rant does not focus on: It’s a good thing that these usecases are broken

                                          You should have more compassion for users and developers who have applications that have worked for decades, are fully featured, and are being asked to throw all of that away. For replacements that are generally very subpar. With no roadmap when party will be reached. For a system that does not offer any improvements they care about (you may care about this form of security, not everyone does).

                                          I could care less about whether when I run ps I see Xorg or wayland. And I doubt that most of the people who are complaining really care about x vs wayland. They just don’t want their entire world broken for what looks to them like no reason at all.

                                          1. 5

                                            I’m not saying that those apps should be thrown away immediately. Some of these work under XWayland (I sometimes stream using OBS and it records games just fine).

                                            If your application really does not run under XWayland, then run an X server! X is not going to go away tomorrow, rather it is being gradually replaced.

                                            I’m simply explaining that there are good reasons some applications don’t work on Wayland. I’m a bit sore of hearing “I switched to Wayland and everything broke” posts: Look behind the curtain and understand why they broke.

                                          2. 17

                                            I’m kind of torn on the issue.

                                            On the one hand, the X security model is clearly broken. Like the UNIX security model, it assumes that every single application the user wants to run is 100% trusted. It’s good that Wayland allows for sandboxing, and “supporting the use cases, but this time via standardized interfaces” which allow for a permission system sounds good.

                                            On the other hand, there’s clearly no fucking collaboration between GNOME and the rest of the Wayland ecosystem. There’s a very clear rift between the GNOME approach which uses dbus for everything and the everything-else approach which builds wayland protocol extensions for everything. There doesn’t seem to be any collaboration, and as a result, application authors have to choose between supporting only GNOME, supporting everything other than GNOME, or doing twice the work.

                                            GNOME also has no intention of ever supporting applications which can’t draw their own decorations. I’m not opposed to the idea of client-side decorations, they’re nice enough in GTK applications, but it’s ridiculous to force all the smaller graphics libraries which just exist to get a window on the screen with a GL context - like SDL, GLFW, GLUT, Allegro, SFML, etc - to basically reimplement GTK just to show decorations on GNOME on Wayland. The proposed solution is libdecorations, but that seems to be at least a decade away from providing a good, native-feeling experience.

                                            This isn’t a hate post. I like Wayland and use Sway every day on my laptop. I like GNOME and use it every day on my desktop (though with X because nvidia). I have written a lot of wayland-specific software for wlroots-based compositors. But there’s a very clear rift in the wayland ecosystem which I’m not sure if we’ll ever solve. Just in my own projects, I use the layer-shell protocol, which is a use-case GNOME probably won’t ever support, and the screencopy protocol, which GNOME doesn’t support but provides an incompatible dbus-based alternative to. I’m also working on a game which uses SDL, which won’t properly support GNOME on Wayland due to the decorations situation.

                                            1. 13

                                              the X security model is clearly broken

                                              To be honest I feel the “brokenness” of the security model is vastly overstated. How many actual exploits have been found with this?

                                              Keyloggers are a thing, but it’s not like Wayland really prevents that. If I have a malicious application then I can probably override firefox to launch something that you didn’t intend (via shell alias, desktop files) or use some other side-channel like installing an extension in ~/.mozilla/firefox, malicious code in ~/.bashrc to capture ssh passwords, etc. Only if you sandbox the entire application is it useful, and almost no one does that.

                                              1. 10

                                                This isn’t a security vulnerability which can be “exploited”, it’s just a weird threat model. Every single time a user runs a program and it does something to their system which they didn’t want, that’s the security model being “exploited”.

                                                You might argue that users should never run untrusted programs, but I think that’s unfair. I run untrusted programs; I play games, those games exist in the shape of closed-source programs from corporations I have no reason to trust. Ideally, I should be able to know that due to the technical design of the system, those closed source programs can’t listen to me through my microphone, can’t see me through my webcam, can’t read my keyboard inputs to other windows, and can’t see the content in other windows, and can’t rummage through my filesystem, without my expressed permission. That simply requires a different security model than what X and the traditional UNIX model does.

                                                Obviously Wayland isn’t enough on its own, for the reasons you cite. A complete solution does require sandboxing the entire application, including limiting what parts of the filesystem it can access, which daemons it can talk to, and what hardware it can access. But that’s exactly what Flatpak and Snaps attempts to do, and we can imagine sandboxing programs like Steam as well to sandbox all the closed source games. However, all those efforts are impossible as long as we stick with X11.

                                                1. 3

                                                  Every single time a user runs a program and it does something to their system which they didn’t want, that’s the security model being “exploited”.

                                                  If you think a permission system is going to solve that, I going to wish you good luck with that.

                                                  Ideally, I should be able to know that due to the technical design of the system, those closed source programs can’t listen to me through my microphone, can’t see me through my webcam, can’t read my keyboard inputs to other windows, and can’t see the content in other windows, and can’t rummage through my filesystem, without my expressed permission.

                                                  Ah yes, and those closed-source companies will care about this … why exactly?

                                                  They will just ask for every permission and won’t run otherwise, leaving you just as insecure as before.

                                                  But hey, at least you made the life of “trustworthy” applications worse. Good job!

                                                  But that’s exactly what Flatpak and Snaps attempts to do […]

                                                  Yes, letting software vendors circumvent whatever little amount of scrutiny software packagers add, that will surely improve security!

                                                  1. 7

                                                    If you think a permission system is going to solve that, I going to wish you good luck with that.

                                                    It… will though. It’s not perfect, but it will prevent software from doing things without the consent of the user. That’s the goal, right?

                                                    You may be right that some proprietary software vendors will just ask for every permission and refuse to launch unless given those permissions. Good. That lets me decide between using a piece of software with the knowledge that it’ll basically be malware, or not using that piece of software.

                                                    In reality though, we don’t see a lot of software which takes this route from other platforms which already have permission systems. I’m not sure I have ever encountered a website, Android app or iOS app which A) asked for permissions to do stuff it obviously didn’t need, B) refused to run unless given those permissions, and C) wasn’t obviously garbage.

                                                    What we do see though is that most apps on the iOS App Store and websites on the web, include analytics packages which will gather as much info on you as possible and send it back home as telemetry data. When Apple, for example, put the contacts database behind a permission wall, the effect wasn’t that every app suddenly started asking to see your contacts. The effect was that apps stopped snooping on users’ contacts.

                                                    I won’t pretend that a capability/permission system is perfect, because it isn’t. But in the cases where it has already been implemented, the result clearly seems to be improved privacy. I would personally love to be asked for permission if a game tried to read through my ~/.ssh, access my webcam or record my screen, even if just to uninstall the game and get a refund.

                                                    Yes, letting software vendors circumvent whatever little amount of scrutiny software packagers add, that will surely improve security!

                                                    I mean, if you wanna complain about distros which use snaps and flatpaks for FOSS software, go right ahead. I’m not a huge fan of that myself. I’m talking about this from the perspective of running closed source software or software otherwise not in the repos, where there’s already no scrutiny from software packagers.

                                                    1. 3

                                                      There’s probably evidence from existing app stores on whether users prefer to use software that asks for fewer permissions. There certainly seems to be a market for that (witness all the people moving to Signal).

                                                      1. 3

                                                        But hey, at least you made the life of “trustworthy” applications worse. Good job!

                                                        “Trustworthy software” is mostly a lie. Every application is untrustworthy after it gets remotely exploited via a security bug, and they all have security bugs. If we lived in a world without so much memory-unsafe C, then maybe that wouldn’t be true. But we don’t live in that world so it’s moot.

                                                        Mozilla has its faults, but I trust them enough to trust that Firefox won’t turn on my webcam and start phoning home with the images. I could even look at the source code if I wanted. But I’d still like Firefox sandboxed away from my webcam because Firefox has memory bugs all the time, and they’re probably exploitable. (As does every other browser, of course, but I trust those even less.)

                                                      2. 1

                                                        A complete solution does require sandboxing the entire application, including limiting what parts of the filesystem it can access, which daemons it can talk to, and what hardware it can access. But that’s exactly what Flatpak and Snaps attempts to do

                                                        But that’s quite limited sandboxing, I think? To be honest I’m not fully up-to-speed with what they’re doing exactly, but there’s a big UX conundrum here because write access to $HOME allows side-channels, but you also really want your applications to do $useful_stuff, which almost always means accessing much (or all of) $HOME.

                                                        Attempts to limit this go back a long way (e.g. SELinux), and while this works fairly well for server applications, for desktop applications it’s a lot harder. I don’t really fancy frobbing with my config just to save/access a file to a non-standard directory, and for non-technical users this is even more of an issue.

                                                        So essentially I don’t really disagree with:

                                                        I should be able to know that due to the technical design of the system, those closed source programs can’t listen to me through my microphone, can’t see me through my webcam, can’t read my keyboard inputs to other windows, and can’t see the content in other windows, and can’t rummage through my filesystem, without my expressed permission. That simply requires a different security model than what X and the traditional UNIX model does.

                                                        and I’m not saying that the Wayland model isn’t better in theory (aside from some pragmatical implementation problems, which should not be so casually dismissed as some do IMHO), but the actual practical security benefit that it gives you right now is quite limited, and I think that will remain the case for the foreseeable future as it really needs quite a paradigm shift in various areas, which I don’t really seeing that happening on Linux any time soon.

                                                        1. 2

                                                          I don’t really fancy frobbing with my config just to save/access a file to a non-standard directory

                                                          If a standard file-picker dialog were used, it could be granted elevated access & automatically grant the calling application access to the selected path(s).

                                                          1. 1

                                                            there’s a big UX conundrum here because write access to $HOME allows side-channels, but you also really want your applications to do $useful_stuff, which almost always means accessing much (or all of) $HOME.

                                                            This is solved on macOS with powerboxes. The Open and Save file dialogs actually run as a separate process and update the application’s security policy dynamically to allow it to access files that the user has selected, but nothing else. Capsicum was designed explicitly to support this kind of use case, it’s a shame that NIH prevented Linux from adopting it.

                                                            1. 1

                                                              This sounds like a good idea! I’d love to see that in the X11/Wayland/Unix ecosystem, even just because I hate that awful GTK file dialog for so many reasons and swapping it out with something better would make my life better.

                                                              Still; the practical security benefit I – and most users – would get from Wayland today would be very little.

                                                        2. 5

                                                          I think “broken” is too loaded; “no longer fit for purpose” might be better.

                                                          1. 2

                                                            Well, the security model is simply broken.

                                                            I agree that a lot of focus is put on security improvements compared to Wayland’s other advantages (tear-free rendering being the one most important to me). But it’s still an advantage over X, and I like software which is secure-by-default.

                                                            1. 1

                                                              How many actual exploits have been found with this?

                                                              They were very common in the ‘90s, when folks ran xhost +. Even now, it’s impossible to write a secure password entry box in X11, so remember that any time you type your password into the graphical sudo equivalents that anything that’s currently connected to your X server could capture it. The reason it’s not exploited in the wild is more down to the fact that *NIX distros don’t really do much application sandboxing and so an application that has convinced a user to run it already has pretty much all of the access that it needs for anything malicious that it wants to do. It’s also helped by the fact that most *NIX users only install things from trusted repositories where it’s less likely that you’ll find malware but expect that to change if installing random snap packages from web sites becomes common.

                                                            2. 4

                                                              It’s good that Wayland allows for sandboxing

                                                              If I wanted to sandbox an X application, I’d run it on a separate X server. Maybe even an Xnest kind of thing.

                                                              I’ve never cared to do this (if I run xnest it is to test network transparency or new window managers or something, not security), so I haven’t tried, but it seems to me it could be done fairly easily if someone really wanted to.

                                                              1. 2

                                                                Whoa, I’ve never heard about the GNOME issues (mostly because I’m in a bubble including sway and emersion, and what they do looks sensible to me). That sucks though, I hope they somehow reconcile.

                                                                Regarding Nvidia I think Simon mentioned something that hinted at them supporting something that has to do with Wayland, but I could just as easily have misunderstood.

                                                              2. 8

                                                                Wayland prohibits your desktop applications from capturing keystrokes or recording other apps’ screens by default

                                                                No, it doesn’t. Theoretically it might enable doing this by modifying the rest of the system too, but in practice (and certainly the default environment) it is still trivial for malware to keylog and record screen on current Wayland desktop *nix installs.

                                                                1. 3

                                                                  it is still trivial for malware to keylog and record screen on current Wayland desktop *nix installs.

                                                                  I don’t think that’s true. The linked article says recording screens and global hotkeys is “broken” by Wayland. How can it be so trivial for “malware” to do something, and absolutely impossible for anyone else?

                                                                  Or is this malware that requires I run it under sudo?

                                                                  1. 10

                                                                    It’s the difference between doing something properly and just doing it. Malware is happy with the latter while most non malware users are only happy with the former.

                                                                    There are numerous tricks you can use if you are malware, from using LD_PRELOAD to inject code and read events first (since everyone uses libwayland this is really easy), to directing clients to connect to your mitm Wayland server, to just using a debugger, and so on and so forth. None of these are really Wayland’s fault, but the existence of them means there is no meaningful security difference on current desktops.

                                                                    1. 2

                                                                      I don’t know if I agree that the ability to insert LD_PRELOAD in front of another application is equivalent to sending a bytestring to a socket that is already open, but at least I understand what you meant now.

                                                                  2. 4

                                                                    I’m sick of this keylogger nonsense.

                                                                    X11 has a feature which allows you to use the X11 protocol to snoop on keys being sent to other applications. Wayland does not have an equivalent feature.

                                                                    Using LD_PRELOAD requires being on the other side of an airtight hatch. It straight-up requires having arbitrary code execution, which you can use to compromise literally anything. This is not Wayland’s fault. Wayland is a better lock for your front door. If you leave your window open, it’s not Wayland’ fault when you get robbed.

                                                                    1. 7

                                                                      Indeed, it’s not waylands fault, and I said as much in response to the only reply above yours, an hour and 20 minutes before you posted this reply. You’re arguing against a straw man.

                                                                      What is the case is that that “airtight hatch” between things that can interact with wayland and things that can do “giant set of evil activities” has been propped wide open pretty much everywhere on desktop linux, and isn’t reasonably easy to close given the rest of desktop software.

                                                                      If you were pushing “here’s this new desktop environment that runs everything in secure sandboxes” and it happened to use wayland there would be the possibility of a compelling security argument here. Instead what I see is people making this security argument in a way that could give people the impression it secures things when it doesn’t actually close the barn doors, which is outright dangerous.

                                                                      In fact, as far as I know the only desktop *nix OS that does sandbox everything thing is QubesOS, and it looks like they currently run a custom protocol on top of an X server…

                                                                      1. 2

                                                                        Quoting you:

                                                                        Wayland prohibits your desktop applications from capturing keystrokes or recording other apps’ screens by default

                                                                        No, it doesn’t.

                                                                        Yes, it does. Wayland prohibits Wayland clients from using Wayland to snoop on other Wayland clients. X11 does allow X11 clients to use X11 to snoop on other X11 clients.

                                                                        Other features of Linux allow you to circumvent this within the typical use-case, but that’s a criticism of those features moreso than of Wayland, and I’m really tired of it being trotted out in Wayland discussions. Wayland has addressed its part of the problem. Now it’s on the rest of the ecosystem to address their parts. Why do you keep dragging it into the Wayland dicsussion when we’ve already addressed it?

                                                                        1. 7

                                                                          This

                                                                          Wayland prohibits your desktop applications from capturing keystrokes or recording other apps’ screens by default

                                                                          And this

                                                                          Wayland prohibits Wayland clients from using Wayland to snoop on other Wayland clients.

                                                                          Are two very different statements. The latter partially specifies the method of snooping, the former does not.

                                                                          Why do you keep dragging it into the Wayland dicsussion when we’ve already addressed it?

                                                                          I do not, I merely reply to incorrect claims brought up in support of wayland claiming that it solves a problem that it does not. It might one day become part of a solution to that problem. It might not. It certainly doesn’t solve it by itself, and it isn’t even part of a solution to that problem today.

                                                                  3. 4

                                                                    X’s design has many flaws, but those flaws are well known and documented, and workarounds and extensions exist to cover a wide range of use cases. Wayland may have a better design regarding modern requirements, but has a hard time catching up with all the work that was invested into making X11 work for everyone over the last decades.

                                                                    1. 3

                                                                      X’s design has many flaws, but those flaws are well known and documented, and workarounds and extensions exist to cover a wide range of use cases.

                                                                      Once mere flaws become security issues it’s a different matter though.

                                                                      [Wayland] has a hard time catching up with all the work that was invested into making X11 work for everyone over the last decades.

                                                                      This may be true now, but Wayland is maturing as we speak. New tools are being developed, and there isn’t much missing in the realm of protocol extensions to cover the existing most-wanted X features. I see Wayland surpassing X in the next two, three years.

                                                                      1. 2

                                                                        Yeah, I started to use sway on my private laptop and am really happy with it. Everything works flawlessly, in particular connecting an external HiDPI display and setting different scaling factors (which does not work in X). However, for work I need to be able to share my screen in video calls occasionally and record screencasts with OBS, so I’m still using X there.

                                                                    2. 4

                                                                      I wonder if X’s security model being “outdated” is partly due to the inexorable slide away from user control. If all your programs are downloaded from a free repo that you trust, you don’t need to isolate every application as if it’s out to get you. Spotify and Zoom on the other hand are out to get you, so a higher level of isolation makes sense, but I would still prefer this to be the exception rather than the rule.

                                                                      In practice 99.9% of malicious code that is run on our systems is done via the web browser, which has already solved this problem, albeit imperfectly, and only after causing it in the first place.

                                                                      1. 4

                                                                        If all your programs are downloaded from a free repo that you trust, you don’t need to isolate every application as if it’s out to get you

                                                                        I completely agree, as long as all of my programs are completely isolated from the network and any other source of untrusted data, or are formally verified. Otherwise, I have to assume that they contain bugs that an attacker could exploit and I want to limit the damage that they can do. There is no difference between a malicious application and a benign application that is exploited by a malicious actor.

                                                                        1. 1

                                                                          all of your programs are completely isolated from the network?

                                                                          how are you posting here?

                                                                          1. 2

                                                                            They’re not, that’s my point and that’s why I’m happy that my browser runs sandboxed. Just because I trust my browser doesn’t mean that I trust everyone who might be able to compromise it.

                                                                            1. 1

                                                                              that makes sense for a browser, which is both designed to run malicious code and too complex to have any confidence in its security. but like i said i would prefer cases like this to be the exception. if the rest of your programs are relatively simple and well-tested, isolation may not be worth the complexity and risk of vulnerabilities it introduces. especially if the idea that your programs are securely sandboxed leads you to install less trustworthy programs (as appears to be the trend with desktop linux).

                                                                              1. 2

                                                                                Okay, what applications do you run that never consume input from untrusted sources (i.e. do not connect to the network or open files that might come from another application)?

                                                                                1. 1

                                                                                  I don’t think you are looking at this right. The isolation mechanism can’t be 100% guaranteed free of bugs any more than an application can. Your rhetorical question is pretty far from what I thought we were discussing so maybe you could rephrase your argument.

                                                                      2. 1

                                                                        This argument seems similar to what happened with cinnamon-screensaver a few weeks ago:

                                                                        https://github.com/linuxmint/cinnamon-screensaver/issues/354#issuecomment-762261555 (responding to https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/)

                                                                        It’s a good thing for security (and maybe for users in the long term once they work again) that these usecases are broken, but it is not a good thing for users in the short term that these usecases don’t work on Wayland.

                                                                      1. 33

                                                                        Wayland also does not solve any problems for most users. That’s the biggest reason adoption is so slow. People might put up with some breakage for some benfit, but for no (perceivable) benefit? Nah. I run X in all my devices including my phone. I recently had to walk my Mom through switching off wayland (her laptop came with it on) so her screen sharing could work for teaching classes. She hasn’t noticed the switch except that things are reportedly more stable now.

                                                                        1. 7

                                                                          That’s completely fair. It is hard to see the benefits of switching when ideally, at the user level, the systems should be indistinguishable.

                                                                          That being said, I’ve switched because under X screen tearing was driving me nuts, and it has vanished on Wayland.

                                                                          1. 2

                                                                            X has absolutely no support for per-screen DPI scaling (and almost certainly never will). It makes my current monitor setup almost completely unusable, so I’m either stuck with Windows or I use wayland..

                                                                            1. 9

                                                                              Have you tried xrandr’s –scale ?

                                                                              xrandr -d :0 --fb 6572x3696 --output DP1-2 --mode 3840x2160 --scale 1x1 --rate 60 --pos 0x0 --primary
                                                                              xrandr -d :0 --fb 6572x3696 --output eDP1  --mode 1366x768  --scale 2x2 --panning 2732x1536+3840+0
                                                                              
                                                                              1. 1

                                                                                I was under the impression that DPI scaling is usually done by the UI toolkit (such as GTK) in response to an environment variable that can be set per-process?

                                                                                That said, I’ve only playing with DPI scaling on my pinephone. My desktop is a single 4K monitor so no need for any scaling stuff there. I’m very open to believing your use case is one wayland is good at and X is not, in which case by all means :) To each their own.

                                                                                1. 1

                                                                                  That may work for single displays. The issue is two displays (multi-head) with significantly different DPIs. GTK’s scaling works to a degree, but it’s still not per-monitor aware last time I checked, and it doesn’t elegantly handle font scaling.

                                                                                  1. 1

                                                                                    GTK’s under X is per-process. So unless windows from one process are on each monitor… then I guess you’re back to the same problem again if you need to scale on one of them.

                                                                                    Like I said, I don’t use scaling usually. I just run things at their normal size.

                                                                                    1. 2

                                                                                      Or if you drag windows between monitors. Also, if you’re using a 4k display on X, you’re probably using a 200% scaling factor (unless you’re on a huge monitor), either as a pixel scale or your desktop is scaling for you.

                                                                                      1. 1

                                                                                        Yup, huge monitor :) I wouldn’t bother with 4K on a smaller monitor.

                                                                            1. 11

                                                                              It’s my birthday! But I also have an exam next week, so studying mostly.

                                                                              1. 2

                                                                                Happy Birthday!

                                                                                1. 2

                                                                                  Happy birthday!

                                                                                  1. 1

                                                                                    Happy birthday!

                                                                                    1. 1

                                                                                      Happy Birthday!

                                                                                    1. 4

                                                                                      Opening this on a 21:9 ultra-widescreen monitor exemplifies a brilliant reason for the CSS max-width property.

                                                                                      1. 1

                                                                                        I think prefers-color-scheme is great.

                                                                                        I just wish it were easier to switch between light/dark mode in browsers for testing purposes (or just for the sake of it). Something like a toggle in developer settings.
                                                                                        I don’t like how it’s usually locked to the OS dark mode setting.

                                                                                        1. 4

                                                                                          All major desktop browsers have exactly that feature, see the post for links on how to activate it.

                                                                                          1. 1

                                                                                            Wow thanks! Can’t believe I missed that.

                                                                                        1. 2
                                                                                          1. If you try to encrypt a message longer than 256 bytes with a 2048-bit RSA public key, it will fail. (Bytes matter here, not characters, even for English speakers–because emoji.)
                                                                                          2. This design completely lacks forward secrecy. This is the same reason that PGP encryption sucks.

                                                                                          Could these tradeoffs be worth it if it means the system is really simple and easy to understand?

                                                                                          1. 12

                                                                                            The first one, no. Breaking on large messages is a serious usability pain-point, and doing a hybrid public key encryption is 100% worth the additional complexity.

                                                                                            The second one, YES! If you make the threat model clear, then eliminating forward secrecy greatly simplifies your protocol. (Implementing X3DH requires an online server to hand out “one-time pre-keys” to be totally safe.) At worst, you’re as bad off as PGP encryption (except, if you follow the advice in my blog, you’re probably going to end up using an authenticated encryption construction rather than CAST5-YOLO).

                                                                                            1. 1

                                                                                              The first one, no. Breaking on large messages is a serious usability pain-point, and doing a hybrid public key encryption is 100% worth the additional complexity.

                                                                                              Isn’t it something people are quite used to though? Both SMS and tweets have a character limit.

                                                                                              But let’s say we do want to go with the simplest secure model, without forward secrecy but no character limit. So hybrid encryption but not X3DH. What library functions would the smart developer use?

                                                                                              1. 5

                                                                                                If they’re using libsodium? crypto_box_seal() and crypto_box_seal_open(). Problem solved for them.

                                                                                                If they’re using OpenSSL (or one of the native wrappers), something like this:

                                                                                                type SealedMessage = {cipher: Buffer, tag: Buffer, wrappedKey: buffer};
                                                                                                const DOMAIN_SEPARATION_AES = Buffer.from('AES-256-CTR');
                                                                                                const DOMAIN_SEPARATION_HMAC = Buffer.from('HMAC-SHA256');
                                                                                                
                                                                                                function hmacSha256(msg: string|Buffer, key: Buffer): Buffer {
                                                                                                    const hmac = crypto.createHmac('sha256', key);
                                                                                                    hmac.update(msg);
                                                                                                    return hmac.digest();
                                                                                                }
                                                                                                
                                                                                                function seal(msg: string|Buffer, recipientPublicKey: Buffer): SealedMessage {
                                                                                                    // Generate and wrap the primary key 
                                                                                                    // (which is split into two keys: one for AES, one for HMAC)
                                                                                                    const key = crypto.randomBytes(32);
                                                                                                    const aesKey = hmacSha256(Buffer.concat([key, DOMAIN_SEPARATION_AES]), key);
                                                                                                    const macKey = hmacSha256(Buffer.concat([key, DOMAIN_SEPARATION_HMAC]), key);
                                                                                                    const rsaCiphertext = crypto.publicEncrypt(
                                                                                                        {
                                                                                                            key: recipientPublicKey,
                                                                                                            padding: crypto.constants.RSA_PKCS1_OAEP_PADDING,
                                                                                                            oaepHash: "sha256",
                                                                                                        },
                                                                                                        key
                                                                                                    );
                                                                                                    
                                                                                                    // Encrypt the data
                                                                                                    const nonce = crypto.randomBytes(16);
                                                                                                    const aes = crypto.createCipheriv('aes-256-ctr', aesKey, nonce);
                                                                                                    const ciphertext = Buffer.concat([
                                                                                                        nonce, 
                                                                                                        aes.update(Buffer.from(string)), 
                                                                                                        aes.finish()
                                                                                                    ]);
                                                                                                    
                                                                                                    // Authenticate the data
                                                                                                    const tag = hmacSha256(ciphertext, macKey);
                                                                                                    
                                                                                                    return {
                                                                                                        cipher: ciphertext,
                                                                                                        tag: tag,
                                                                                                        wrappedKey: rsaCiphertext
                                                                                                    };
                                                                                                }
                                                                                                
                                                                                                function unseal(sealed: SealedMessage, secretKey: Buffer): Buffer {
                                                                                                    const key = crypto.privateDecrypt(
                                                                                                        {
                                                                                                            key: secretKey,
                                                                                                            padding: crypto.constants.RSA_PKCS1_OAEP_PADDING,
                                                                                                            oaepHash: "sha256"
                                                                                                        },
                                                                                                        sealed.wrappedKey
                                                                                                    );
                                                                                                    const aesKey = hmacSha256(Buffer.concat([key, DOMAIN_SEPARATION_AES]), key);
                                                                                                    const macKey = hmacSha256(Buffer.concat([key, DOMAIN_SEPARATION_HMAC]), key);
                                                                                                    const nonce = sealed.cipher.slice(0, 16); // AES-CTR nonce size
                                                                                                    const ciphertext = sealed.cipher.slice(16);
                                                                                                    if (!crypto.timingSafeEqual(sealed.tag, hmacSha256(ciphertext, macKey)) {
                                                                                                        throw new Error("Integrity check failed");
                                                                                                    }
                                                                                                    const aes = crypto.createDecipheriv('aes-256-ctr', aesKey, nonce);
                                                                                                    return Buffer.concat([aes.update(ciphertext), aes.final()]);
                                                                                                }
                                                                                                

                                                                                                (This is why “just use libsodium” is so much better.)

                                                                                                1. 1

                                                                                                  Please consider using Pastebin for code; Lobsters renders code in a larger-appearing font than text in its comment section and doesn’t seem to fold it away properly, creating a wall of text that makes it harder to scroll through comments.

                                                                                                  1. 1

                                                                                                    I somewhat agree, but I don’t think that there’s a good pastebin which is free to Lobsters without signup and also allows posts to persist. (The Reputation Problem disincentivizes such a service; it would be open to abuse.) It would be cool if Lobsters had the ability to click to expand/hide long code snippets.

                                                                                                    1. 1

                                                                                                      Definitely the best solution would be for Lobsters to fix code rendering in comments.

                                                                                                      1. 4

                                                                                                        We have an issue tracking this if anyone wants to pick up the work

                                                                                                    2. 1

                                                                                                      For what it’s worth, that comment looks ok to me (Chrome on Windows).

                                                                                              2. 2

                                                                                                If you are okay with giving up on security (e.g. for educational purposes) then it could be worth it.

                                                                                                In practice absolutely not.

                                                                                                1. 1

                                                                                                  Giving up on security is too vague, sorry. Can eve read my messages? No? Then I think I’m pretty safe.

                                                                                                  1. 2

                                                                                                    Maybe bfiedler refers to the second point, meaning if Eve compromises Alice’s private key, then Eve can read past, present and future messages. My personal opinion is that this should be default for any secure messaging system.

                                                                                              1. 3

                                                                                                I agree that the problem described occurs often in practice, however I am against defining new keywords (or combinations of keywords) for this, as this unneccessarily complicates the language, and zero values for package-exported types should be valid.

                                                                                                I would much rather see go vet support for this, i.e. a warning when not using the package’s constructor if present (e.g. “manual struct initialization of XXX, use NewXXX instead”), maybe using some opt-in methods such as //vet:checkConstructor on the constructor(s)

                                                                                                1. 1

                                                                                                  I’d be very open to any non-keyword approach to the syntax - can’t think of anything off the top of my head though.

                                                                                                  re zero-values: just to check I understand what you mean. Zero-values are valid for package-created-types, they just can’t be created outside the defining package. I guess you could have the same thing as this proposal that only restricts explicit initialisation, or partial initialisation (i.e initialize with a subset of fields), but the benefits seem much narrower. Also you would lose the proposal’s benefit re enums - all enums would gain zero in their range of values, so you’d still need to validate most of the time.

                                                                                                  1. 1

                                                                                                    Oh indeed, I meant partial initialization in the above, whoops.

                                                                                                    My argument is that the most extreme partial initialization would be not specifying anything - i.e. the zero value of your package type.

                                                                                                    1. 1

                                                                                                      We use capitalisation for exported/not-exported, so type names are already significant.

                                                                                                      Would using a leading underscore (a la C-style “ths is internal”) to mean “may only be instantiated in this package” be too magic?

                                                                                                      Then you can be sure that any instances which escape the package were constructed in it, presumably allowing invariants to be honoured.

                                                                                                      Edit:

                                                                                                      I’ve now read the likely-decline reason:

                                                                                                      As discussed above, this proposal does not support zero values, and does not provide any special mechanism for copying a value (or avoiding copying a value). Without those features this functionality is not a good fit for the language and would be quite difficult to use in practice. Therefore, this is a likely decline. Leaving open for four weeks for final comments.

                                                                                                      Which I don’t address, ah well.

                                                                                                  1. 1

                                                                                                    Have you found a good alternative to Ansible?

                                                                                                    If yes, I’d be interested in what you found, and otherwise you can check out cdist.

                                                                                                    1. 1

                                                                                                      Unfortunately, I haven’t. I’ve looked into cdist, unfortunately that’s not what I was looking for. I don’t want to write shell scripts manually.

                                                                                                      I’m border line thinking about doing my own thing :/ .

                                                                                                      1. 2

                                                                                                        I feel you, that’s also my current approach for (FreeBSD) jail-aware stuff…

                                                                                                        1. 2

                                                                                                          May I recommend having a look at pyinfra, a lightweight alternative to Ansible.

                                                                                                        2. 1

                                                                                                          Maybe mgmt but it competes more with Puppet’s approach than Ansible. I saw a demo of it at FOSDEM 2017 and was quite impressed, mainly because of its speed. Turns out they also gave a presentation at last year’s FOSDEM.

                                                                                                        1. 2

                                                                                                          That is really interesting. I’m always surprised that these things run open on the internet with a public IP. I’ve always expected them to be behind some kind of VPN.

                                                                                                          Not that this makes the device “secure”, but it just adds one layer of security in case of a vulnerability in these IoT products.

                                                                                                          Sometimes, I’m happy that I’m not working on airplane software, because I might not fly ever again…

                                                                                                          1. 3

                                                                                                            Oh the hardware is already scary enough, no need to look at the software ;)

                                                                                                            1. 2

                                                                                                              Working manufacturing IT / with SCADA systems is really an experience. Lots of very old systems powering very expensive automation and with no security.

                                                                                                              I once saw a storage closet full of VAXes and jokingly asked if I could have one. Nope: backups for the overhead robotic transport system. But they were better than the Windows 2000 systems all around the factory floor that had to be aggressively firewalled off – fewer VMS worms running around the internet.

                                                                                                              1. 1

                                                                                                                For the vintage computing people, this is why it’s hard to find VAXen/Alphas - because companies will buy them up for hot spares!

                                                                                                                1. 1

                                                                                                                  The person I e-know who works at a plant that uses software written for VAX has told me they run it under emulation. Unfortunately I couldn’t find the URL for the software in my logs, but I do remember the home page looked very 90s…

                                                                                                                  1. 1

                                                                                                                    Replying to myself, the company is https://www.avtware.com/, and my e-friend says emulation is definitely a good option if you have source - maybe not if you don’t .