First things first: I never implied (or wanted to imply) that you were introducing malware in that patchset, just that you could introduce it and I wouldn't be able to find that in a PR so big. Sorry if that came out wrong.
Still, that 3.18.140 kernel is ancient, it's not worth doing anything with it unless we find a bug that prevents something from working. Especially since there _is_ a mainline effort, and there's a 6.0 based tree that has most of the things working already except for some bugs with the nand and audio.
And that's the reason why there hasn't been a new release lately, because I hadn't had a lot of time, and because I'm spending all my little remaining energy on trying to get the userspace working with mainline.
For those who may not know, the userspace acts as a sort of bridge between the baseband and the Pinephone, by proxying stuff between them (that's how you can hijack some things and implement voice calls and SMS). When moving to mainline, there's certain devices that cease to exist, some others needs adapting, and I'm taking the time to try and get openqti to be more flexible and out of the box support different audio settings for different models, different flash configurations (for those modems which don't have a dedicated user data partition etc)
I feel you should get more encouragement here. Thanks for your great work. You did a lot. Yes, the whole state of mobile is frustrating, but here is someone improving things. If our governments weren't the corrupt authoritarian shitheads they are, these kinds of trojan horses should be illegal.
It has had different phone numbers before, but we always ended up having some issue with some app where the it (correctly) thought the number was invalid, wouldn't allow you to reply etc.
So I settled with two easy to remember numbers: +22 33 44 55 66 77 for normal user<-->modem communication and +22 33 44 55 66 78 for Cell Broadcast message relays
Probably on every connect, there are ways to randomize your IMEI on every boot on certain phones though (that might be not very legal in some countries)
I did the mod with a Pinecil and some tweezers in my kitchen table in 15 minutes. Might look hard but if you have steady hands and a $25 soldering iron you can do it without issues
On the other hand, I have a XPS 15 9500 I use with Linux all day and never had an issue with anything. Always suspends, never wakes up by itself, no hardware issues... My work 16" MBP on the other hand killed the battery after one week in "suspend" when I was on vacation, probably due to the Power Nap functionality, which sounds pretty much like the Modern Standby being talked on.
I'm no expert, but if you ask me, I would completely erase the phone, upgrade it via DFU, and start fresh. After setting it up again, run another backup and rerun the tool to doublecheck. That or ditch the phone
What’s the best procedure for getting data off a compromised iPhone before wiping? Plugging it into other devices via usb or backing up to iCloud seems sketchy to me but maybe I’m overly paranoid.
You've never plugged your phone into your computer before? If so, I doubt it could cause more harm to do it again unless you haven't done it since your device was infected. You're just mentally aware of it now, but how long has it been there and how many devices have you plugged your phone into since then, even just to charge? If you never plug your phone into another device, it's moot, but I suspect most people do at sometime or another. "Hey, can I plug my phone in real quick to charge a bit" type stuff. Airdrop is good for quick, small files, but I'm not going to be transferring multiple gigabytes of 4k video via wifi speeds that way.
Thanks. Wasn’t sure how airdrop worked so wasn’t sure if connecting a compromised device that way was a concern. Unfortunately there is no info out there because the official line is “all apple devices are secure don’t worry!”
Given there's an electronic lock on the other side with a keypad, it makes me think that thing has its own actuator and didn't want to mess with it. Otherwise it would just be a matter of adding an "Electric strike?" (https://www.tesa.es/en/site/tesa/products/electromechanical-...), feed it 12/24v through a relay connected to the pi zero, and add another api endpoint
After the Unifi Video fiasco, I bought a UDM Pro to test Unifi Protect.
Once I saw it required cloud login I got scared.
After I saw an ubiquiti ssh key preinstalled in a device with unfeteted internet access I shut it down to never bring it up again
There was no option to bypass cloud login when it got to my hands, apparently that has been "fixed" with some update, but if you buy a device and it comes with an outdated firmware, as it tends to be the case with their cameras and APs, your only choice is activate on cloud, setup, update, factory reset, setup on local.
About 2... I guess when you got access to all their source and infra is just a matter of pushing an update to enable ssh and they don't even need to even push a key. My problem with the keys is that they come bundled with it and you don't know it. There's no reason for them to install a key in there without your consent. Imagine Microsoft presetting an Administrator account on every Windows Server without telling anyone... It's just a security problem, even more in a firewall
You can connect multiple accounts from the desktop client if that's what you mean... If you mean nextcloud to nextcloud there's also federation, but haven't really tried that as I've never needed it.
Still, that 3.18.140 kernel is ancient, it's not worth doing anything with it unless we find a bug that prevents something from working. Especially since there _is_ a mainline effort, and there's a 6.0 based tree that has most of the things working already except for some bugs with the nand and audio.
And that's the reason why there hasn't been a new release lately, because I hadn't had a lot of time, and because I'm spending all my little remaining energy on trying to get the userspace working with mainline.
For those who may not know, the userspace acts as a sort of bridge between the baseband and the Pinephone, by proxying stuff between them (that's how you can hijack some things and implement voice calls and SMS). When moving to mainline, there's certain devices that cease to exist, some others needs adapting, and I'm taking the time to try and get openqti to be more flexible and out of the box support different audio settings for different models, different flash configurations (for those modems which don't have a dedicated user data partition etc)