Notices by varx/tech (varx@infosec.exchange)

OK, I've got JDK 23 installed, from Oracle's download site: https://www.oracle.com/java/technologies/downloads/

signal-cli runs, now. I can call the registration endpoint. And now it's captcha time, apparently.

...which involves going to some random-ass website that explains nothing but gives me a bullshit ambiguous hCaptcha that takes several tries to solve, and then tries to open a "signalcaptcha" URL in my OS.

And now Signal Desktop shows me a QR code that I can't copy, which means I'll have to screenshot it, save that to disk, install *another* application (QtQR) to decode it, open the file, and get a sgnl:// URL.

After several manual steps for installing Signal Desktop (download a keyring, install it in the system, add a repo signed by that keyring, and *then* update and install the package) I'm now onto trying to use signal-cli.

It turns out that my options for signal-cli are:

1. Use a newer or different operating system, because it needs a cutting-edge version of Java (JRE 21) while my OS only has version 17; or
2. Use the native build, which requires a newer *processor*, lord only knows why.

This is some real bullshit, Signal.

Signal Desktop got stuck on this "Syncing Contacts and Groups" screen for a full minute. Wild, because I don't have any.

And... I think I'm in?

Now it's over to some random gist (https://gist.github.com/szepeviktor/2c6a19cb91c4bb561369707f22bcf413 "Signal on Windows without a smartphone" although I'm not on Windows) because this is apparently The Authoritative Guide to doing this unofficial thing.

The guide asks you to upload a QR code to a completely unaffiliated barcode-decoding site at one point so that you can decode it. Is this safe? Who knows! Probably not!

(I used a local program. Probably most people don't do this.)

Now Signal Desktop is paired or whatever...

...oh, no, apparently I was supposed to ignore that prompt, and instead copy a link that appears *after a delay* in that page, and then call signal-cli with that as the --captcha arg.

This fails the first few times, maybe because timeouts?

But finally, a text message!

Now I call signal-cli again, but with a verify command.

Did it work? I cannot tell.

The latest in my #Signal Desktop saga: An annoying little banner has appeared telling me to launch Signal on my phone.

https://support.signal.org/hc/en-us/articles/9021007554074-Open-Signal-on-your-phone-to-keep-your-account-active

Apparently I'll need to download a new version of signal-cli (my "phone") every month or two and access my account that way, or Signal might stop working on my laptop.

What a load of bullshit.

I've still got this signal-cli "device" attached to my account. I wonder if this will cause problems. Does it need to periodically be synced to the server? Does it store things less securely than the official client? Is it even possible to unregister this "device", or will that break everything?

Let's tally up my Signal Desktop first-time experience!

- Time spent on setup: 1 hour
- Third-party websites trusted: 3
- Commands executed: 30
- Temporary files created: 5 (URLs, QR screenshots, etc.)
- Captchas attempted: 6
- Positive vibes towards Signal at the moment: 0

I've seen #AppArmor used primarily to *harden* the security of an existing program. Is it also reasonable to use it to *sandbox* known-malicious code? Or are other methods required?

(I assume you also want ulimit or similar on the side, but that's to prevent resource consumption attacks rather than sandbox escapes.)

#Linux #sandboxing

@fifonetworks This method still requires a phone number. That's not the issue at hand—the problem is that Signal requires a *smart phone*, not just a phone number.

Signal *really* doesn't like having desktop users, do they?

Apparently the only way to get this working without a smartphone is to install their desktop app (which *does* exist—this screenshot is from before I enabled JS) but then also install a third-party tool called "signal-cli" that uses a hacked-up version of Signal to provide functionality like creating an account based on an SMS or voice call.

It's kind of appalling. There's no reason the desktop app couldn't have this functionality. Why are Signal forcing people to use a third-party utility? It's very weird in juxtaposition to their tight central control of Signal in other ways.

#signal #desktop

@feld @cuchaz Heh, sorry, what I mean is -- what is the *category* named? EST and EDT aren't "time zones", as far as I'm aware, because ET is the time zone. So what are they?

@cuchaz wait what

@cuchaz I see... *local* time means checking the env, and the env is a global mutable thing.

So I guess you need to check the locale at startup, cache that somewhere, and use that explicitly whenever you need to get the time...

@cuchaz Hmm... is that really true, though? If I'm in the Eastern time zone, the UTC offset changes twice a year, but I'm still in the time zone.

(I don't know what EST and EDT are called, though, given that as far as I can tell, "ET" is the time zone.)

@ryanc @Mara I'm glad to see that, but I really have a hard time seeing 24647 as inflammatory. Is there some history here where an *earlier* attempt was actually inflammatory, so anything similar was also marked as "political"?

@StompyRobot ...pretty sure they just needed someone to look at the logs.

@feld Nope, just stuck into the README next to the "This project is licensed under the GPL". (Editing the GPL would be a different kettle of fish, yeah...)

Software licensing question, semi-hypothetical:

I encountered a repo available under the GPL, *but* there's also a note about "you can't sell this". This... isn't actually compatible with the GPL, and reveals the author's poor understanding of the license they chose. It doesn't matter for me, because I'm not planning on selling it, but it does raise an interesting question: What is the most likely *effect* of this statement?

- License grant is invalid?
- GPL prevails entirely?
- No-sale applies to original work, but not to derivatives?

I'm leaning towards the first one, myself. Curious to hear what others think.

@cuchaz Cavern has a problem that's very similar; my solution is for the friends to have to brute-force the list until they find something they can decrypt, but not have to do this *often*.

Not sure if this is appropriate in your use-case, but consider whether there's a way to "stabilize" the numbers you're sending your friends; if they can act optimistically on the presumption of the number not having changed since last time (if that's even a meaningful concept) then they get to skip the expensive step whenever they're right.

Barring that, it feels like this might require some fancy math involving combining multiple people's public keys. :-/