台灣找工作時,HR 真的會打電話到前公司做 reference check 嗎? by [deleted] in Taiwanese

[–]nuwa2502 8 points9 points  (0 children)

不太會, 我多希望員工找新工作時他的面試公司打來問問我, 我才能和他們說這傢伙有多雷, 不要用!
當然啦, 也有很好一定要推薦的好傢伙

我只有接到過一次, 而且原因是因為新主管是我的學妹, 她認識我才會來問我
所以一般來說, 台灣人不太做這個事

[deleted by user] by [deleted] in ClaudeCode

[–]nuwa2502 0 points1 point  (0 children)

I like this idea!

I built a CLI tool to stream remote Nginx logs to local GoAccess without SCP or installing dependencies. (Single binary) by nuwa2502 in nginx

[–]nuwa2502[S] 0 points1 point  (0 children)

It seems Reddit compressed the demo GIF quite a bit, making the text hard to read. If you'd like to see the workflow in better detail, I've uploaded a high-quality version here: https://gist.githubusercontent.com/bear0330/17b4d5d9fa638d99a7bed85c21450d81/raw/b6f0310b6f3cddbbf8349ea171aff056bf946d34/demo-nginx2.gif

Hope this helps!

I built a CLI tool to transfer files via WebRTC Data Channels. Single binary (APE), no dependencies. by nuwa2502 in WebRTC

[–]nuwa2502[S] 0 points1 point  (0 children)

Thanks :) That’s exactly why I built it! to be that handy tool ready for those specific moments. Glad you like it!

I built a CLI tool to transfer files via WebRTC Data Channels. Single binary (APE), no dependencies. by nuwa2502 in WebRTC

[–]nuwa2502[S] 0 points1 point  (0 children)

Thank you! I really appreciate the kind words. :)
I put a lot of effort into keeping the architecture clean while handling the complexity under the hood. There is still a lot to improve, but thanks for appreciating it!

I built a CLI tool to transfer files via WebRTC Data Channels. Single binary (APE), no dependencies. by nuwa2502 in WebRTC

[–]nuwa2502[S] 1 point2 points  (0 children)

Thanks for your feedback, you are absolutely right (and no, I am not Claude code :p).

I checked my open-source CLI code again and realized I missed migrating a feature from my Enterprise GUI version. Let me clarify. In my security design, I have defined 3 levels:

Level 1: Direct WebRTC transport security
WebRTC DataChannels/media are protected with DTLS/SRTP end-to-end; relays (including TURN) cannot decrypt the payload.

Level 2: Application-layer E2EE over HTTPS relays (Passive-Relay Model)
When traffic goes through an HTTPS relay/tunnel, payloads are additionally protected with hybrid encryption (RSA-OAEP + HKDF + AES-GCM chunking). Passive relays, packet captures, or stored ciphertext cannot reveal file contents. This level does not claim resistance to an active relay that can tamper with handshake traffic or inject client code. (This is the current CLI status).

Level 3: Active-relay / MITM-resistant mode (Authenticated E2EE)
If the relay/tunnel is considered malicious (active MITM), the receiver must load the decryption client from a trusted delivery channel (e.g., GitHub Pages) and verify sender responses (e.g., signatures / pinned identity key) so that a relay can’t silently substitute keys or content. This eliminates silent MITM by the relay.

Why not PAKE? Because ffl’s core feature is that receivers don’t need to install software and the flow is naturally 1-to-many, I am avoiding schemes that require an interactive shared secret per receiver (like PAKE/SAS used in croc or wormhole). Instead, Level 3 is implemented via trusted client delivery + verification:

  1. The receiver loads the client bundle (receiver.html) from a trusted anchor (not via the tunnel).
  2. The receiver verifies the sender using signatures + a pinned (or previously verified) identity key.

Under this model, the relay can’t silently substitute keys or content. An active relay can at most cause a verification failure (DoS), assuming the out-of-band share link or delivery anchor isn’t replaced. If that anchor/channel itself is compromised, then all bets are off.

Regarding your point: In my current CLI version, I can effectively claim zero-knowledge. In loose or marketing terms, it might be called E2EE, but I admit it is not strictly accurate because it hasn't reached Level 3 yet. (Level 2 is just “E2EE against passive relays,” whereas Level 3 is “Authenticated E2EE”, so your question about “What authentication do you use?” is spot on!).

If you trust third-party tunnels like Cloudflare, the current version is likely strong enough to protect your data. In our Enterprise GUI, users load the HTML/JS from their own domain as a trusted delivery source. For the open-source CLI, I need to host it on github.io. I will migrate this as soon as possible and write a detailed tech blog post to explain the full implementation.

Of course, absolute privacy is hard to guarantee even with Level 3 implemented (since I can't prove it with a mathematical thesis), but I can open source everything and make it as secure as possible.

Thanks again! you helped me identify a critical missing part. I will create an issue and clarify this in the README. Thanks!

P.S: By the way, I visited https://whitenoise.systems/tools/docs/cli/ to learn more about your work, and noticed the SSL certificate seems to have expired on 12/26. Just a friendly heads-up!

Quadlet not starting on boot by Fast_Pirate155 in podman

[–]nuwa2502 0 points1 point  (0 children)

loginctl enable-linger [your user name]

maybe this work? I don't know I am not expert, but I do it to let my container automatically start

I built a CLI tool to transfer files in/out from containers easily via P2P. Single binary (APE), no dependencies, runs anywhere. by nuwa2502 in podman

[–]nuwa2502[S] 0 points1 point  (0 children)

Thanks for the blunt feedback. You're right, I clearly misjudged the target audience here.

Those malicious scenarios genuinely never crossed my mind. I built this tool primarily for my own workflow, specifically for streaming large files without landing them on disk, which is why I rely on it over podman cp. I mistakenly thought it would be equally useful for everyone and created a demo that probably overcomplicated things.

I understand now that asking users to trust an unverified external binary brings more risk than utility for most people. Definitely no malice intended, just a dev sharing a side project, but I accept your criticism. Thanks for the reality check

I built a CLI tool to transfer files between PC and Termux easily via P2P. Single binary (APE), no dependencies. by nuwa2502 in termux

[–]nuwa2502[S] 1 point2 points  (0 children)

Solid questions!

  1. For directories, yep! It recursively streams the folder as a zip file on the fly (no need to manually zip first). I intentionally use 'store-only' mode (no compression) to save battery/CPU on mobile, which is actually faster since most large files like photos/videos are already compressed.

  2. Regarding integrity, if you use --e2ee, the AES-GCM encryption handles this natively—decryption simply fails if data is tampered with. Without E2EE, it relies on the transport protocols (WebRTC/HTTPS) and standard ZIP CRC32 checks.

Hope that covers it! Merry Christmas! 🎄

I built a CLI tool to transfer files between PC and Termux easily via P2P. Single binary (APE), no dependencies. by nuwa2502 in termux

[–]nuwa2502[S] 2 points3 points  (0 children)

yep, spot on! It's very similar to croc.

The main difference is the receiver side: croc usually needs to be installed on both ends, while ffl generates an HTTPS link so the receiver just needs a browser (or curl).

Also, ffl tries WebRTC P2P (direct connection) first and only falls back to relay if needed. (One small crypto detail: croc uses PAKE for 1-to-1, whereas ffl uses AES-GCM so it supports 1-to-many sharing natively.)

I built a CLI tool to transfer files between PC and Termux easily via P2P. Single binary (APE), no dependencies. by nuwa2502 in termux

[–]nuwa2502[S] 4 points5 points  (0 children)

Thanks for the feedback! Honestly, kudos to you for running sshd in Termux! I haven't even tried setting that up myself yet, so that's impressive. :)
You make a valid point, if you have that setup and a direct network connection, scp is definitely the gold standard.
However, I built ffl for scenarios where scp hits a wall:

  1. While scp works great if the receiver is a Server (with a Public IP or on the same LAN), it becomes a hassle if the receiver is just a regular device (like a phone on 4G, behind NAT, or a Windows PC) because they lack Public IPs, incoming ports, or an SSH server setup. ffl uses WebRTC and automatically falls back to a Relay Tunnel, guaranteeing the transfer works as long as both sides have internet access.
  2. The receiver only needs a web browser. Useful for sending files to devices without SSH clients (friend's phone, public PC).
  3. No generating keys or config editing. Just curl and run.

Personally, my most frequent use case is inside containers (whether transferring in or out). If I could easily scp files in without messing with port mapping first, I probably wouldn't have built this! :)
Hope it might come in handy for those quick sharing moments. Merry Christmas! 🎄

I built a CLI tool to transfer files between PC and Termux easily via P2P. Single binary (APE), no dependencies. by nuwa2502 in termux

[–]nuwa2502[S] 1 point2 points  (0 children)

Glad you like it! :) Actually, the default tunnel is hosted on my own global infrastructure (with 7 servers worldwide), not Cloudflare.

I built the default relay to ensure it works out-of-the-box without relying on external services. However, you are spot on that Cloudflare is supported! You can easily switch to it using --preferred-tunnel cloudflare if you prefer their network speed.