Is there a safe way to handle USB drives on Linux?
As far as I know their are two main threats:
What are the most effective and pragmatic way’s to prevent both things on Linux?
And am I right with my assumption that an USB drive probably can’t harm a Pixel running GrapheneOS, without a zero day exploit or very advanced malware?
The Qubes sys-usb model has to be the most secure. USB controller devices are isolated to a dedicated VM when mounted, devices must be manually attached per instance to access any other part of your system
Probably impractical overkill for most threat models, but it’s reasonably secure
You could just spam the super/windows key if you fear a USB device will act as a malicious input device. If you don’t want to spam, you could create a script that executes every time a new USB device is detected on the system to do this for you.
Spamming the super/windows key will cause you to escape out of any input box – like a terminal – which will prevent the payload from properly being executed. But this method would only work if the USB device began acting maliciously immediately after plugging it in.
A USB data or port blocker.
That depends on your threat model.
I don’t think this option would work because the OP is talking about USB drives. USB drives need to be able to transmit data to the device its plugged into.
Well the OP has not clearly defined a threat model nor workflow to begin with, so my answer assumes that prevention of these two explicit attack vectors are the only requirements, ignoring all other potential factors such as usability.
Do you search for something to block it? Like USBGuard.
End-users may be required to adjust the default USBGuard policy within their Linux distribution of choice in order to tailor to their exact requirements, so it can be potentially implemented as a viable solution.
Wasn’ the OP saying he want a pragmatic solution? 
I mean you can’t use your system will spamming super key because it throws you out of yourcurrent window
Is there a way to use this on a distro that is not QubesOS?
We’re venturing outside my realm of expertise, though I’d have doubts that any adjacent implementation would provide meaningful value outside of Qubes, as much of the VM security Qubes offers is inherited from Xen hypervisor
t would be cool to have QubesOS sandbox optional for untrusted things or just for every app that doesn’t come as a Flatpak
For sure, I’d like to see the QubesOS model for virtual isolation by default to be the norm. Microsoft is a plague for privacy, but their Application Guard VM feature is pretty good for security. I see GrapheneOS & SecureBlue taking steps in this direction too.
No.
Yes. He could just spam it for a time and then get to doing whatever he has to do after he has verified it isn’t malicious. Pragmatic doesn’t mean immediate convenience.
How does the super key verfies anything?
If the stick is malicous he can still be malicous after you stopped spaming super key
It doesn’t verify anything after the super key stops getting pressed. That’s why I made a disclaimer saying
and only if it attacks by acting as an input device and not some other attack vector, which there’s no way to know, and you’re faster than it is, and there’s not some other factor at play, etc.
I don’t think this is particularly good advice because it might give some a false sense of security.
To be clear for anyone reading, spamming the Windows key when inserting a USB drive is not a way to protect yourself if the drive is malicious.
This depends on your threat model and level of trust you have in that USB drive to be plugged in.
In worst case scenarios, USB sticks might act as keyloggers, exploit/hack USB controller firmware mainboard itself (= low-level software, which is responsible for managing USB ports of your computer), or do physically damage to your computer. For the last two, even Qubes OS can provide only limited/no protection. And I guess there are countless more types of malicious USB sticks.
Those hardware protections known as “USB condoms” enable safe charging, while preventing data operations. Not sure, if there are protection devices the other way round for “safe data transfer” for normal consumers (would be interested to hear, if you know one).
Hence I think the most feasible, “reasonably safe” and not too inconvenient way for untrusted/foreign USB drives is to have a cheap old computer with an USB port that acts as sandbox. It can be your old 50 bucks router with shell access for example. Plug that USB stick in, locate data and transfer it over network to your desired destination. Of course, network should be secured, i.e. optimally firewalled with isolated VLAN and access to only a single hardened network storage location. Also note, this workflow secures against malicious USB devices, but you also need ensure, that extracted data content is safe, which probably is a different topic.
Neither of the last two can be mitigated by Qubes OS in any form, or any operating system for that matter:
Relevant quote (post #8):
In this particular topic, Qubes OS cannot do anything about the NovaCustom NV56’s sole USB controller, so if it becomes compromised, that will expose all peripherals connected to it. USBKill (V4) can affect any USB port with a data line:
app-linux-input-proxy, which is the USB proxy @deeplow is referring to, cannot defend against discharges.