DEV Community: Bevan Stanely

Sending a file with light: fountain codes and animated QR

Bevan Stanely — Wed, 07 Oct 2026 14:38:36 +0000

Originally published on stan-ely.com.

Correction, 8 October 2026. The first version of this post said a numbered loop needs 8.3 × N frames at 10% loss. That figure modelled chunks picked at random, not the in-order loop described here. Rerun, the loop needs about 3.9 × N, against about 1.6 × N for the fountain code. The table, chart and text below are corrected, the script that produces them is now committed, and the table gains a column for losses that arrive in runs. Thanks to @VerdettoQR on Mastodon, whose question prompted the rerun.

There is a machine in a locked room with no network on it, and a file that has to get out. The realistic answer to that is a USB stick, which is why the interesting question isn't whether you can beat a USB stick — you mostly can't — but what the alternative has to look like before it's worth reaching for at all.

qrdrop has a mode called beam for this, shipped in 0.2.0 and current as of 0.6.0. The sender animates QR codes on its screen at roughly ten frames a second; the receiver points a camera at them. Nothing crosses a wire, no radio comes on, and there is no signalling of any kind between the two devices. It's the same package as the WebRTC transfer and almost none of the engineering is shared, because removing the network removes something much more specific than bandwidth: it removes the back channel.

What a one-way channel takes away

Every transfer protocol you have ever used assumes it can ask a question. TCP asks "did you get that?" a few hundred times a second. HTTP asks "what encodings do you accept?" before it sends a byte.

A screen and a camera cannot ask anything. The sender is never told which frames were missed, whether anyone is watching at all, or what the receiver is capable of decoding. The only feedback is a human looking at the receiving device and deciding to keep holding the phone up. So every decision below is downstream of one property: the sender picks blind, forever.

That is not a bandwidth problem, it's an information problem — and it changes the answer at four separate layers.

The obvious design, and what a missed frame costs it

The obvious design is to number the chunks and loop them. Chunk 1, chunk 2, … chunk N, back to chunk 1. qrbeam, which is where the idea of adding this to qrdrop came from at all, does exactly this. It is correct, it is about fifty lines, and it is genuinely fine when nothing is dropped.

The trouble is that things are dropped, and the failure is not proportional. To finish, the receiver needs every one of N specific chunks — so once it has most of them, each new lap delivers mostly things it already has while it waits on the two or three it is still missing. It's a coupon-collector problem run in laps: every lap offers each missing chunk one more chance, and the transfer ends only when the unluckiest of N chunks has finally been seen, which takes about ln(N) / ln(1/loss) laps. That grows with the file, and you start paying it the moment anything at all is lost. At N = 1,748 and ten frames a second, 10% loss turns a three-minute transfer into an eleven-minute one, because a missed frame doesn't cost you a frame, it costs you a full extra lap.

Frames are missed. jsQR needs 50–100 ms to decode one, so a phone browser manages about ten decodes a second against a display emitting exactly ten frames a second. There is no headroom in that. A hand that moves, a repaint caught mid-frame, an autofocus hunt — each one is a lap.

Needing enough frames rather than particular ones

The fix is a fountain code, specifically an LT code. Instead of carrying chunk i, each frame carries the XOR of some pseudorandomly chosen set of chunks. Whenever a frame's set has exactly one unknown block left in it, that block falls out; XOR it away from every other frame that mentions it, and that may free another. This is peeling, and it runs until everything is solved or nothing more can be.

The property that matters is not the cleverness. It's that a frame no longer has an identity worth waiting for: it doesn't matter which frames arrived, only how many. A dropped frame costs one frame, not a lap. That single change is what makes the transfer survivable over a channel with no way to ask for a retransmit — and it's the reason this is an 800-line codec instead of a chunk-and-cycle loop.

The measurement

Frames the sender has to emit before the receiver has the complete file, over 1,748 blocks — which is a 1 MiB payload at this frame size, since 1,048,576 ÷ 600 rounds up to 1,748:

frame loss	this codec	this codec, bursty	numbered loop	loop, bursty
0%	1.05×	1.05×	1.00×	1.00×
10%	1.58× (1.46–1.73)	1.61× (1.47–1.82)	3.89× (2.90–5.87)	3.12× (1.96–5.96)
30%	2.06× (1.96–2.13)	2.05× (1.88–2.17)	7.02× (5.41–10.14)	6.01× (4.27–8.41)
50%	2.79× (2.66–2.90)	2.75× (2.58–2.90)	11.22× (8.70–14.52)	11.08× (8.35–17.85)

How that was produced, since a table with no method attached is just a claim: the real codec encodes 1 MiB of seeded random bytes, a seeded PRNG decides whether each emitted frame reaches the decoder, the decoder is fed the survivors, and the count is frames emitted until it reports complete. Each cell is the mean of 20 seeds, with the lowest and highest in brackets. Seeded, because a flaky erasure-code benchmark is worse than none — it trains you to re-run until it passes, which is precisely how a real decoder stall gets waved through. The script is beam-loss-bench.mjs, committed alongside this post and moving into the qrdrop repo so anyone can rerun it.

"Independent" means every frame gets its own coin flip. A phone camera doesn't lose frames like that: it hands the decoder only the newest frame, so everything shown while the decoder is busy is lost together, in runs. The bursty columns model that, with runs averaging eight frames at the same overall loss rate. The fountain code doesn't notice, because it only counts arrivals. The loop doesn't get worse on average either, since a random run of lost chunks is simply re-offered next lap.

What does break the loop is rhythm. A decoder that stalls on a fixed beat — one frame lost in every four, say — misses the same chunks on every lap whenever that beat divides N, and 1,748 is divisible by four. In that case the loop never finishes, in all 20 runs, while the fountain code completes at 1.96 × N. Add a single frame of jitter to the beat and the loop recovers to 5.93 × N. Real decoders jitter, so this is a worst case rather than the normal one, but it is a failure mode a fountain code simply doesn't have.

What the committed test suite pins is the 30% case, on a smaller payload, as a bound rather than a constant: test/beam.test.mjs fails if the emitted count is not under half of N·ln(N). That is deliberately a loose regression guard on the shape — and N·ln(N) is the cost of chunks picked at random, not of the loop above, which is the confusion that put 8.3 × N in the first version of this post.

Read the shape rather than the constants in any case. The loop doesn't degrade gently: it goes from 1.00 × N to nearly 3.9 × N between 0% and 10% loss, because it starts paying for the unluckiest chunk as soon as there is one. The fountain stays inside a small factor across the whole range.

The systematic prefix, which is a trade and not a win

Here is the one real departure from the closest prior art, and it costs something.

A pure fountain pays its overhead even when nothing goes wrong: you always need somewhat more than N frames to recover N blocks, because some arrive carrying nothing you can peel yet. For small N and a robust soliton distribution that overhead is genuinely bad — 1.3–1.5× for a handful of blocks.

So the first N frames are sent systematically: block 0 plain, block 1 plain, and only then does the fountain start. A clean capture therefore costs exactly N frames and nothing more, which is the common case on a decent camera. Nothing downstream needs to know about the special case — a systematic frame is just a degree-1 frame whose single index the decoder derives the same way it derives every other set.

The cost is real and shows up under loss. With a systematic prefix the decoder needs about 1.35 distinct frames per block, against the ~1.13 a pure LT code reaches (both measured by the same script, 20 seeds at 10–50% loss). By the time the fountain starts, most blocks are already solved, so a degree-d frame drawn against all N carries far fewer unknowns than its degree suggests. You are paying for degree you can't use.

Which side of that trade is right depends entirely on how good you expect the camera to be, and this bets on it being good. That's a bet, not a proof, and the number that would falsify it sits in the README next to the table.

The frame is a line of text

A beam frame is a QR code, and a QR code is a string, so the wire format is pipe-delimited text:

QRD1|D|<session>|<seed>|<base64url payload>|<crc32>

The sizing runs backwards from the QR. A version-20 code at error correction level L holds 858 bytes in byte mode, the header costs about 50 characters, and base64url inflates the payload by a third. 600 raw bytes lands just inside that, and keeps every frame at a module count a phone can lock onto from across a desk. Raising it pushes the QR version up, and a denser code is one that takes three attempts to scan — which costs far more than the bytes gained.

The seed is the interesting field. A frame is the XOR of a set of blocks and the decoder has to know which set. The obvious encoding is a list of indices, but a degree-40 frame would then need forty numbers in its header — at 600 bytes a frame, a meaningful fraction of the payload. Instead the frame carries an eight-character seed, and both halves run the same PRNG, splitmix32, to regenerate the set. Eight characters whatever the degree.

That makes the generator part of the wire format. Changing splitmix32 breaks compatibility exactly as surely as renaming a field would, which is why it's pinned in the codec rather than reached for from somewhere general, and why the protocol tag QRD1 exists to be bumped the day a decoder of the previous version would misread a frame.

The degree comes from a robust soliton distribution, precomputed once per transfer as a CDF (c = 0.03, delta = 0.05, the standard constants for N in the hundreds-to-thousands). The ideal soliton distribution has exactly the right expected behaviour and is useless in practice: it expects precisely one peelable frame at every step, and peeling stalls the moment variance takes that away. The robust version adds a spike of extra low-degree frames to keep the ripple populated, for a few percent more frames overall.

CRC32, and why it is not a hash

Every frame ends in eight hex characters of CRC32, and that is not a security control.

What it defends against is a QR decoder handing back a plausible-looking string it got slightly wrong — a real failure mode when a camera catches a frame mid-repaint. One corrupt block XORed into the peeling state silently poisons every block that depends on it, and the damage surfaces minutes later as a SHA-256 mismatch on the whole file with nothing to point at. CRC32 catches that at the door for eight characters.

It is not a forgery defence and nothing pretends it is. An attacker who can put frames on the screen the receiver is pointed at has already won, by definition.

The manifest, woven in

The receiver can do nothing with a data frame until it knows N and the block size — and it cannot be assumed to have been pointed at the screen when the sender started. So the manifest isn't sent once at the front; it's interleaved into the cycle every 20 frames.

Sending it once would be free, and would strand anyone who didn't catch the first two seconds of the loop. Every 20 frames means a receiver joining at any moment waits about two seconds at most, for roughly a 5% cost in frames. In a mode where the receiver is a person picking up a phone, that is not a close call.

gzip, specifically not brotli

Payloads are gzipped first, and the compressed result is kept only if it actually shrank. Text, CSV, JSON and source typically compress 3–10×; a 900 KB JPEG doesn't shrink and is refused against the cap.

Brotli is the better algorithm — 15–20% smaller on text at this size — and no longer a dependency question either, since the WHATWG Compression Standard now lists it as a CompressionStream format. It is still the wrong choice here, for a reason particular to this mode: a one-way channel cannot negotiate. The sender picks blind, and the receiver either can inflate it or cannot.

gzip has been baseline in every browser since May 2023. Brotli is Safari 18.4+ and Firefox 147+, with Chrome — the likely sender and a very common receiver — behind. A sender choosing brotli hands some phones a file they structurally cannot open, and the only remedy the UI could offer is "try a different browser". Twenty-five seconds off a three-minute transfer is a bad trade when the failure mode is total.

This is why the manifest's encoding field is a string rather than a boolean. When Chrome ships brotli, preferring it is a feature-detect and one string.

There is a guard on the other side of it, too: a manifest may not declare an original size above 64 MiB, and the inflate is stopped the moment it exceeds the size the manifest declared. The manifest arrives from the peer exactly as the filename does, and this codebase treats that as hostile input — a decompression bomb being the obvious attack on "we will inflate whatever you tell us to".

Roughly 6 kB/s, and a cap that is admitted rather than hidden

Beam runs at about 6 kB/s, with a 1 MiB cap applied after compression. At that rate the cap is already a three-and-a-half minute transfer, so it's a limit on patience as much as on anything technical.

Minutes is also long enough to meet a failure that has nothing to do with coding theory. A beam is one device showing a code to another device's camera with nobody touching either screen, which is exactly what a display timeout counts — so until 0.5.0 the code being read could go dark part-way through. The display is now held awake from the moment a transfer starts until it ends, and taken back after a glance at a notification, which the platform would otherwise not return.

The second reason is structural: a fountain code has no ordering. The decoder cannot write anything to disk until peeling completes, because any block may turn out to be needed to solve any other, so every block is held in memory until the last one arrives. That is the bill for not needing particular frames.

Raising the cap would want fountain-coding independent ~256 KiB windows, so memory stays bounded and each window can be flushed as it solves. That is not built. It roughly doubles the protocol's moving parts to raise a cap that a 6 kB/s transfer rate makes academic — written down as a known limitation rather than left for someone to discover.

Beam is not encrypted, and it cannot be

This needs its own section rather than a footnote, because everything else qrdrop publishes about confidentiality describes the WebRTC path and stops at this mode's edge.

There is no handshake here, so there is no ECDH, no forward secrecy, and no short-authentication-string check. There is no peer to authenticate — only photons. The only adversary that exists in this mode is someone who can see the screen, against whom a key displayed on that same screen is worth nothing.

Both beam screens say so, the README carves the mode out of the threat model explicitly rather than letting the document's other claims appear to cover it, and the changelog entry that shipped it led with the limitation. Beam is offered as an alternative to a USB stick on an air-gapped machine, not as a private channel — and a mode that looked as protected as the WebRTC path while not being so would be worse than having no offline mode at all.

For the same reason there is no qrdrop beam command and there will not be one: the mode needs a screen to animate and a camera watching it, and a terminal on the receiving end has neither.

The desktop app wraps the same page, so beam is there too — and on Linux, where WebKitGTK ships no RTCPeerConnection, it is the only way the app can move a file at all.

Prior art, and what is actually mine

Neither the idea nor the design is original here, and it would be tidier but dishonest to present them that way.

The prompt was qrbeam, which sends a file offline as animated QR codes to an iOS receiver. That is where the idea of adding this to qrdrop came from at all. Its wire format numbers the chunks and loops them, which is what the table above compares against — named, because a benchmark against an unnamed strawman is worth less to a reader and unfair to the party being measured.

txqr by Ivan Daniluk got to the fountain code first, and is the closest prior art to what's built here: animated QR frames carrying LT-coded blocks, so the receiver needs enough frames rather than particular ones. Daniluk's write-up on fountain codes and animated QR is the better explanation of why LT codes suit this problem at all, and is worth reading before this post. The reasoning above was arrived at independently, which makes it convergent rather than novel — no code was taken from either project.

What differs is small, and worth stating plainly rather than dressing up: the first N frames are systematic, compression is decided by measurement rather than assumption, the manifest is interleaved so a receiver can join mid-stream, and both halves run in a browser with no install on either side.

That last one is the part I'd defend. The coding theory here is decades old and better explained elsewhere. What's mine is the set of trades made against one specific one-way channel, each with the number that would have changed the answer written down beside it.

Open share.stan-ely.com on your laptop and point your phone's camera at it.

qrdrop: what 'no server' forces you to build

Bevan Stanely — Tue, 08 Sep 2026 15:21:25 +0000

"No server" sounds like a feature you'd put in a bullet list. It isn't one. It's a constraint, and constraints don't hand you good decisions — they just remove the bad ones that would otherwise have been easiest. qrdrop is a file-transfer tool (npm i -g qrdrop, or just try it at share.stan-ely.com) built around exactly one rule: nothing in between the two devices ever holds a readable copy of the file. There's no account, no upload, no backend that could see the bytes even if it wanted to. Everything below is what that rule cost, in the order the costs showed up.

One real transfer, filmed from both ends — not staged, not sped up. ▶ Watch the 12-second recording on the original post.

No account, so the QR has to be the entire credential

Start from the constraint: there's no server to register a device with, so there's nothing to log into. Two devices in the same room have to recognize each other using only what passes between them, and the one channel a network attacker can't stand in the middle of is a physical QR scan — a phone's camera pointed at a laptop screen.

So the QR has to carry a credential, not a pointer to one. qrdrop's QR is 32 bytes of CSPRNG output, full stop. Everything the protocol needs — the room the peers meet on, the password that encrypts their signalling, the session keys, even the words they'll read aloud to each other — is derived from those 32 bytes with HKDF. There's no identity behind the code, no account it belongs to. That's also the honest limit of what it protects: anyone with the code can join. It's the entire credential. Show the QR to a person, not to a room.

The room ID can't be the secret — a public relay is watching

The obvious next move, once you have a 32-byte secret, is to use it directly as the room name two peers meet on. It's the shortcut a first draft reaches for, and it works — the two peers show up in the same place, first try, every time you test it.

It's also wrong, because "no server" means signalling has to happen somewhere public. qrdrop's peers announce over Nostr relays and WebTorrent trackers — networks neither peer controls and neither trusts — and a room name on a public relay is not private. If the room ID were the secret, every relay operator watching announcements would have your decryption key the moment pairing started, for free, before a single file byte moved.

The fix is that the room ID is derived from the secret (HKDF(secret, "topic")), never the secret itself. A relay sees a room name it can't invert back to the QR contents. This is the kind of bug that a demo doesn't catch — the transfer completes, the file arrives, everything looks fine — because publishing the key to a room name doesn't fail the transfer, it just fails the promise you made about it in the README.

No server to vouch for either side, so a human has to

A server, if there were one, could do identity checking for you — you'd log in, and the server would tell each side who the other one was. There isn't one here, so nothing can attest that the peer on the other end of the WebRTC data channel is actually the phone that scanned the code, rather than something between them. WebRTC signalling gets a password derived from the secret too (HKDF(secret, "signal")), which stops an observer from substituting their own session description in transit — the textbook man-in-the-middle on WebRTC signalling, and the specific thing the QR exists to prevent. But that's defense against a network attacker forging the connection; it isn't proof the two humans looking at their screens agree on what got connected.

For that, qrdrop falls back to the oldest trust anchor there is: a person. Once the data channel is up, both screens derive and display four emoji — the same four, if the pairing is genuine — and a human reads them aloud and matches them by eye. The words under the emoji are what a screen reader speaks, because those are the words a person actually says out loud to their peer; the emoji tiles are decoration on top of that.

The sender confirms this SAS before the file manifest goes out, because the manifest alone discloses filename and size to whoever's on the other end of that channel. This is the gesture the project treats as non-negotiable: --yes on the CLI skips the receiver's accept prompt, and cannot skip the SAS confirmation. A flag that skipped it would be a vulnerability wearing convenience's clothes — the SAS is the whole defense against a successful man-in-the-middle, and there's no server anywhere in this picture that could do that job instead.

Bytes cross a relay you don't control, so they're sealed twice

Direct peer-to-peer doesn't always work out. When NAT traversal fails, WebRTC falls back to a TURN relay — in qrdrop's case, the Open Relay Project's public, shared, metered infrastructure, because there's no server of its own to run one. That relay sits between the two devices and forwards every packet. It should not be able to read any of them.

DTLS already encrypts the WebRTC data channel itself, terminating at each peer's browser — but "no server" also means qrdrop can't fully trust the signalling layer underneath that connection, so the file bytes get sealed a second time, independently, with an ephemeral ECDH key exchanged directly between the two peers and used to derive AES-GCM keys per direction. Two layers that fail independently: if Trystero's signalling encryption were ever broken outright, an attacker still needs the QR secret to derive the session key, because the ECDH uses that secret as its HKDF salt. A TURN relay operator, in the worst case, sees ciphertext and byte counts. Never contents.

The load-bearing word in all of that is ephemeral — a keypair generated fresh, per session, and thrown away with the room, which is what gives a leaked code no power over a transfer that already finished. It rests on one line of code: the keypair is created inside joinVia, per call, never hoisted to module scope. Hoisting it looks like an obvious optimization — one keypair generation instead of two, since openRoom races two signalling strategies and only needs one to win — and it would silently turn every transfer a running process ever makes into one long session with forward secrecy quietly gone. test/room.test.mjs pairs twice over the same secret against a fake in-memory strategy and asserts the second session can't decrypt the first's traffic, specifically so that regression fails in two seconds locally rather than surviving to a release.

The WebRTC path — room ID, signalling password, session keys, and the SAS all derive from the 32 bytes in the QR.

No network at all means no transfer — unless the screen is the network

Every decision above assumes a network exists, even a hostile, public, unreliable one. Take that away — an air-gapped machine — and there's genuinely nothing left: no relay to announce on, no TURN to fall back to, no data channel to open. The constraint doesn't relax here; it just changes shape. If there's no network, the only channel left is the screen itself.

That's what Beam is: the sender animates QR codes on screen at roughly ten frames a second, and the receiver's camera reads them, with no wire, no radio, and no signalling of any kind between the two devices. The payload is fountain-coded rather than a numbered loop, because a numbered loop turns a missed frame into a coupon-collector problem — waiting for the specific frame you missed, out of a loop you have to sit through again. A fountain frame doesn't care which frames were missed, only how many arrived, which is why the difference between the two grows sharply as frame loss climbs (measured over 1,748 blocks of a 1 MiB payload): 1.05× N frames needed at 0% loss versus 1.00× N for a numbered loop, but 2.08× N versus 10.7× N at 30% loss.

Beam mode — the sender's screen emits ~10 LT-coded QR frames a second; the receiver's camera reads them. No back channel.

And here is where the constraint stops being convenient and just states its own limit plainly: Beam is not encrypted, and it cannot be. No network means no handshake, which means no key agreement, no forward secrecy, and no SAS — there's no peer to authenticate over a channel of light, only photons, and a key shown on the same screen as the payload protects nothing. Both beam screens say so directly. It's offered as the alternative to a USB stick on an air-gapped machine, not as a private channel, and the project is explicit that everything it claims about confidentiality elsewhere in the document stops at Beam's edge.

The constraint is what made it worth building

None of this reads like a feature list, and that's the point. A server would have made every one of these problems disappear — an account instead of a 32-byte credential, a private room name instead of a derived one, a trusted third party instead of four emoji read aloud, TLS to a backend instead of a second encryption layer over a public relay. Removing the server didn't remove the problems; it just moved every one of them onto the two devices and the person standing between them, which is exactly where a network attacker can't reach the contents.

The honest caveats stay attached rather than getting rounded off: TURN is free, shared, and capped at 100 MB for exactly that reason; Firefox and Safari buffer whole files in memory before saving, so practical transfers there cap out well short of what Chromium can stream to disk; the page serving the code could itself be compromised, and no in-browser design stops that — it's mitigated by a strict CSP and shipped source maps so the claims can be checked against what's actually running, not eliminated. None of that is dressed up, because the constraint that produced the interesting decisions is the same one that produces the limits.

That distinction is not academic. A report came in from the field — Out-of-order frame: expected 0, got 13877, on a transfer under a megabyte — and behind it was a stranger in the rendezvous room ending a live transfer with fourteen bytes of well-formed cleartext. Frame headers were being read for type and sequence before the AES-GCM tag was checked, and inbound frames weren't filtered to the paired peer, so one packet from someone who held no key and never paired was enough to make the receiver abort and throw away the partial file. Nothing was readable, forgeable or alterable; what was lost was availability, which is still a real thing to lose. Frames are authenticated before their headers are trusted now, and one that fails its tag is dropped and counted rather than treated as a fault in the transfer.

The part worth keeping isn't the fix. It's that the report was legible as a bug at all. A stray packet only reads as an attack if the document already says who was supposed to be able to send one.

stan-ely / qrdrop

Send a file straight from one device to another. A QR code carries the key; the file goes over WebRTC; nothing in between ever holds a readable copy.

qrdrop

Send a file straight from one device to another.
A QR code carries the key; the file goes over WebRTC;
nothing in between ever holds a readable copy

share.stan-ely.com — no install, no account, no upload

npx qrdrop send report.pdf     # prints a QR code in your terminal
npx qrdrop receive             # on the other machine
npx qrdrop web                 # or run the browser UI locally, from this copy

npx stays the headline because it installs nothing. If you would rather have it on PATH:

brew install stan-ely/tap/qrdrop                                   # macOS, Linux
scoop bucket add stan-ely https://github.com/stan-ely/scoop-bucket  # Windows
scoop install stan-ely/qrdrop
npm i -g qrdrop                                                    # anywhere, Node 22+

A file sent from the CLI can be received in a browser, and the other way round. That interoperability is the reason this is one package rather than three.

Where	How
Browser	share.stan-ely.com, or `<qr-drop>` in a page

…

View on GitHub

If you want to see whether it holds up: open share.stan-ely.com on a laptop, drop a file onto it, and point a phone's camera at the code that appears. Watch the four words. Then check that they matched.

cuda-gdb error with libtinfo.so.5

Bevan Stanely — Thu, 08 Jul 2021 14:50:33 +0000

Originally Published on bevs.xyz

I had a fresh install of cuda-tools from the Manjaro software repository and I simply couldn’t run cuda-gdb. I was getting the following error

cuda-gdb: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

A related error was as follows:

cuda-gdb: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

I had to investigate the files libtinfo.so.5 and libncursesw.so.5. It was a simple version-conflict with ncurses. My distro had ncurses 6.2, whereas cuda-gdb was insisting on ncurses 5. A simple symlink was in order, actually two. The following two lines saved my day!

sudo ln -s /usr/lib/libncursesw.so.6.2  /usr/lib/libtinfo.so.5

sudo ln -s /usr/lib/libncursesw.so.6.2  /usr/lib/libncursesw.so.5

I got the necessary pointers from this stackoverflow answer for an unrelated Android Studio question.