6 ms·

> copy-paste When I was talking about switching to wayland with a colleague, who was already moved over at the time, he tried to convince me that having no cop

> copy-paste When I was talking about switching to wayland with a colleague, who was already moved over at the time, he tried to convince me that having no copy paste is better for security. And I, using a password manager that generates unspeakably complex passwords everywhere, was kinda stunned by that blindsightedness. If you don't want copy and paste, use Qubes OS. That's the philosophy matching the rest of the architecture of the OS. But as long as you have a binary named "[" on your system, don't try to convince people that you are doing it in the name of security. There is much more rotten fish to throw away before that. The only thing that recently convinced me to give wayland another go is hyprland. Seeing all kinds of nice WM concepts being implemented in it, maybe hyprland is "the interoperability specification" we needed all along.

jwells89 2y ago
On the other hand, I think it’d make total sense to implement an optional mode that blocks programs’ ability to read the clipboard until the user explicitly approves them. I understand why some people might not want that (which is why I’d like it to be a setting), but it’s always felt a little weird that any program on desktop programs can grab the clipboard at will. Things like making the clipboard “intelligent” might help too. On macOS there’s a bit of this when copying passwords from the system password manager, where the clipboard is cleared either after paste or after some short period of time to reduce chances of grabby programs pulling it.
- connicpu 2y ago
  I feel like there's some other reasonable middle grounds too. If you don't want your clipboard to always be cleared, it seems sensible to e.g. only allow the currently active window to read the clipboard.
  - vanviegen 2y ago
    Yeah, or show a popup with the name of the window that just grabbed your paste buffer.
- roenxi 2y ago
  It makes a huge amount of sense to control what programs can snoop on each other. There won't be a lot of people against the idea in principle. Eventually the Wayland ecosystem will be strictly better than X because at least there is some amount of control over that sort of thing. The problem that Wayland had is it took the stance of "just no!" and that means Wayland is now almost an adult (15 years, so a little time to go) and only just arrived at a place where a Wayland compositor is about as useable as an X11 based system (thanks Pipewire). Wayland has been a mess for so long I think even in Debian Bullseye swaywm didn't support Zoom (or any other program) screensharing. Which for 2022 was a remarkable gap in capability. I'm all aboard for the Wayland transition because it is a definite improvement, but Wayland's "security" debacle is a legendary case study in design gone wrong.
  - rcxdude 2y ago
    It's not just security, there's a bit of an over-obsession with generalised future-proofing: useful optional proposed protocols have been shot down because they 'assume windows will be laid out on a screen with xy coordinates'. It's a recipe for committee bikeshedding to run rampant, especially with multiple very opinionated parties involved, any of which can torpedo even an 'accepted' extension by just not implementing it. It's a nightmare of fragmentation.
- welterde 2y ago
  The X11 primary selection buffer is an even better variant of that though. It allows single-shot copy&paste (meaning only one application can grab it) from the password manager to the target application and it tells the password manager the name of the application that grabbed it. I think it shouldn't be too hard to hack in a dialog to password managers to confirm if the destination is correct before replying to the data request. But even without that one at least notices that a malicious/wrong application grabbed the password.
Propelloni 2y ago
Preach it! I'm always dumbfounded by the insanity on MS Windows (and nowadays Gnome, too!) that disallows copy-pasting into the UAC. Do they want me to use weak passwords? I don't get it.
pxc 2y ago
What's wrong with having a symlink called '[' for 'test'?
- cookiengineer 2y ago
  A programming language should not be parsed and neither lexed on the filesystem layer. This is what REPL or interpreters are for. Counter question: would you have all C++ macros from libboost as symlinks on the filesystem, too? How would that work? /usr/bin/C++/[ and /usr/bin/bash/[ maybe? What's the difference of the operator behaviors, given that macros exist? If you're not understanding where I am getting at: these types of hacks were the reason for a lot of fuckups and a lot of CVEs in the past. Directly or indirectly. I'd even encourage every distro to use busybox at this point, just for having a centralized entrypoint for your shell scripts.
  - pxc 2y ago
    I have come to love shells with little special syntax, namely fish, so generally write if test rather than if [ in any shell. I'm not particularly a fan of special syntax, let alone external commands pretending to be special syntax. But restricting commands to specific character sets also seems a bit cheesy to me. It seems more natural that a character is a character. I can see the other side here, though. I'm curious about those CVEs. Surely any script involving the hijacking of `[` to obfuscate malicious code could also just as well have hijacked `test` (wherever `test` is not a shell built-in), right? > I'd even encourage every distro to use busybox at this point, just for having a centralized entrypoint for your shell scripts. For operating system scripts, I guess that's fine. But administrators who are writing their own scripts should choose a shell that's actually pleasant to read and write, and ship an appropriate runtime, including external commands. You can do this today in a portable way with Nix or Guix and a bit of footwork, just as well with bash as with Python. If you're writing scripts in something other than your daily login shell, you might as well use a non-shell programming language, because you're now losing the advantage of writing in a language that you practice constantly. And BusyBox is not a pleasant daily login shell, so you shouldn't use it for that, either.

jwells89 2y ago

On the other hand, I think it’d make total sense to implement an optional mode that blocks programs’ ability to read the clipboard until the user explicitly approves them. I understand why some people might not want that (which is why I’d like it to be a setting), but it’s always felt a little weird that any program on desktop programs can grab the clipboard at will. Things like making the clipboard “intelligent” might help too. On macOS there’s a bit of this when copying passwords from the system password manager, where the clipboard is cleared either after paste or after some short period of time to reduce chances of grabby programs pulling it.

connicpu 2y ago
I feel like there's some other reasonable middle grounds too. If you don't want your clipboard to always be cleared, it seems sensible to e.g. only allow the currently active window to read the clipboard.
- vanviegen 2y ago
  Yeah, or show a popup with the name of the window that just grabbed your paste buffer.
roenxi 2y ago
It makes a huge amount of sense to control what programs can snoop on each other. There won't be a lot of people against the idea in principle. Eventually the Wayland ecosystem will be strictly better than X because at least there is some amount of control over that sort of thing. The problem that Wayland had is it took the stance of "just no!" and that means Wayland is now almost an adult (15 years, so a little time to go) and only just arrived at a place where a Wayland compositor is about as useable as an X11 based system (thanks Pipewire). Wayland has been a mess for so long I think even in Debian Bullseye swaywm didn't support Zoom (or any other program) screensharing. Which for 2022 was a remarkable gap in capability. I'm all aboard for the Wayland transition because it is a definite improvement, but Wayland's "security" debacle is a legendary case study in design gone wrong.
- rcxdude 2y ago
  It's not just security, there's a bit of an over-obsession with generalised future-proofing: useful optional proposed protocols have been shot down because they 'assume windows will be laid out on a screen with xy coordinates'. It's a recipe for committee bikeshedding to run rampant, especially with multiple very opinionated parties involved, any of which can torpedo even an 'accepted' extension by just not implementing it. It's a nightmare of fragmentation.
welterde 2y ago
The X11 primary selection buffer is an even better variant of that though. It allows single-shot copy&paste (meaning only one application can grab it) from the password manager to the target application and it tells the password manager the name of the application that grabbed it. I think it shouldn't be too hard to hack in a dialog to password managers to confirm if the destination is correct before replying to the data request. But even without that one at least notices that a malicious/wrong application grabbed the password.

Propelloni 2y ago

Preach it! I'm always dumbfounded by the insanity on MS Windows (and nowadays Gnome, too!) that disallows copy-pasting into the UAC. Do they want me to use weak passwords? I don't get it.

pxc 2y ago

What's wrong with having a symlink called '[' for 'test'?

cookiengineer 2y ago
A programming language should not be parsed and neither lexed on the filesystem layer. This is what REPL or interpreters are for. Counter question: would you have all C++ macros from libboost as symlinks on the filesystem, too? How would that work? /usr/bin/C++/[ and /usr/bin/bash/[ maybe? What's the difference of the operator behaviors, given that macros exist? If you're not understanding where I am getting at: these types of hacks were the reason for a lot of fuckups and a lot of CVEs in the past. Directly or indirectly. I'd even encourage every distro to use busybox at this point, just for having a centralized entrypoint for your shell scripts.
- pxc 2y ago
  I have come to love shells with little special syntax, namely fish, so generally write if test rather than if [ in any shell. I'm not particularly a fan of special syntax, let alone external commands pretending to be special syntax. But restricting commands to specific character sets also seems a bit cheesy to me. It seems more natural that a character is a character. I can see the other side here, though. I'm curious about those CVEs. Surely any script involving the hijacking of `[` to obfuscate malicious code could also just as well have hijacked `test` (wherever `test` is not a shell built-in), right? > I'd even encourage every distro to use busybox at this point, just for having a centralized entrypoint for your shell scripts. For operating system scripts, I guess that's fine. But administrators who are writing their own scripts should choose a shell that's actually pleasant to read and write, and ship an appropriate runtime, including external commands. You can do this today in a portable way with Nix or Guix and a bit of footwork, just as well with bash as with Python. If you're writing scripts in something other than your daily login shell, you might as well use a non-shell programming language, because you're now losing the advantage of writing in a language that you practice constantly. And BusyBox is not a pleasant daily login shell, so you shouldn't use it for that, either.