read_deleuze

joined 3 years ago
[–] [email protected] 9 points 8 months ago

Yes; Organisation du traité de l'Atlantique nord

[–] [email protected] 3 points 8 months ago (3 children)

Just because everything checks out in principle doesn't mean it's actually secure. First off, we have no certainty of the client code running; it's open source, sure, but unless they ensure reproducible builds - which, given it's on the Play store (and I assume Apple app store), they can't be, since the binaries must be signed - we have no way of knowing whether the code actually being downloaded and run is actually the same as the FOSS version. Further, even if it is, it may have intentional subtle vulnerabilities meant to be used by the French govt (so would easily pass certification by having the ANSSI be instructed top-down to overlook certain things), or it may be that the server can trigger a known bug resulting in leakage of data. At an even more paranoid level, it's possible that the encryption itself is faulty; the specification says it uses aes256 and ed25519 which is about as battle-tested as it gets, but the PRNG seems to be mostly their own innovation. It specifies a minimum of 32 bytes of entropy, which (though cryptography is not my expertise, so at this point I'm wildly speculating) is probably trivial to send or embed in some other communication with the server e.g. by ensuring the PRNG is deterministic after the first keygen and faulty in some known way and sending over a future result.

I wouldn't trust the French government.

[–] [email protected] 5 points 9 months ago (1 children)

To be fair, nix would probably be a lot more intuitive if commands were in black speech instead

[–] [email protected] 10 points 9 months ago (2 children)

cope and seethe, transphobe

[–] [email protected] 38 points 10 months ago (3 children)

Nieuw-Amsterdam komt terug, het is slechts een kwestie van tijd

[–] [email protected] 3 points 11 months ago

Love how you just assume I'm from the west. I'm eastern european, my family is also, and we lived through everything - and I've yet to meet someone other than western investors and young kids who thinks things are good/better now

[–] [email protected] 23 points 11 months ago (9 children)

I'm deeply sorry that we don't like supporting the oppression of marginalized groups here

[–] [email protected] 1 points 1 year ago

Glad to have been informative :D and good luck on your laptop hunt

[–] [email protected] 3 points 1 year ago

That's correct, mea culpa; I've only seriously worked with qcom so entirely forgot that's a thing. I'll update my comment, thanks!

[–] [email protected] 17 points 1 year ago* (last edited 1 year ago) (5 children)

It's complicated.

ARM system initialization doesn't happen the same way as on x86 (the instruction set your computer is probably using unless you're on a phone/tablet). On x86, once the CPU is initialized, it can inform the Linux kernel of what hardware is installed and how to talk to it through a protocol called ACPI. Thus, for Linux to work on a system, it must only support the CPU and some necessary hardware (e.g. I doubt you'll have a usable system if USB, graphics, audio, and networking are unsupported, but otherwise it's fine).

~~ARM functions quite differently; ACPI doesn't exist~~ ACPI is also usable on ARM but Qualcomm refuses to implement it, so instead the Linux kernel has to already know what hardware is installed and where through a configuration file called a device tree blob - basically weird JSON. Therefore it's not enough that Linux supports the Snapdragon 7c (it does) - there must also be a builtin device tree config for your specific device. There likely is one; a simple way to check would be to look here for your device's name (the Snapdragon 7c's codename is SC7180, so the file you're looking for would be sc7180-$vendor-$model.dts). If there isn't and you're willing to get moderately deep in the weeds, you can write your own device tree source file and load it into the kernel (assuming you have at least a rudimentary familiarity with programming, this is doable with a little dedication).

As for your other questions, you don't need to worry too much about instruction set and architecture - being ARM will limit what software can run, but emulation is sort of okay too. It will, however, be far more power-efficient than a 6th gen Intel i3 if that's what you care about - and gut instinct says faster.

It really depends on your usecase, though. If your budget is limited enough that these are serious options, I'd honestly recommend finding a decent second-hand laptop running something a bit better and more recent - but if you run mostly open-source software, don't care about gaming at all, and are willing to get a little deeper than the average hobbyist for some extra battery life, the ARM laptop might be interesting.

[–] [email protected] 1 points 1 year ago (3 children)
[–] [email protected] 4 points 1 year ago* (last edited 1 year ago)

Good point and I absolutely should have mentioned this in my original comment, but I do think there is a risk here worth mentioning. A lot of guides for installing some arbitrary piece of software on Manjaro (or, to be fair, any Arch-based distro) will boil down to installing some package from the AUR, and the average Manjaro user is probably less tech-savvy than the average Arch user. Also, the pamac warning dialog only warns against packages not compiling or being buggy, not against malicious ones, and as far as I know - though it's been a while since I used pamac - it doesn't allow you to inspect the PKGBUILD at install-time, whereas most CLI AUR helpers e.g. paru which I use require it and require manual signoff every time said build script changes.

As an entirely unscientific test, I googled "manjaro enable aur" and checked the first 5 results to see if there's any warnings (I figured this is a relatively common query from Manjaro users?) and only 2 even mentioned the risk of malicious packages, with the top result not mentioning any risks whatsoever, not even breakage or bugginess. I'm sure there are many resources that do make this clear, but I doubt the average Manjaro user will see them.

This is arguably an issue on most Arch-based distros with a pretty installer, though it seems Manjaro is particularly vulnerable since it's marketed as a beginner-friendly distro despite all of these footguns.

Edit: at the risk of crucifixion, this is also why I usually direct newcomers towards using flatpaks wherever possible instead of using 3rd party repositories unless said repositories come directly from the developers of said (trusted) package. Briefly looking over the Manjaro docs, it seems like enabling flatpaks is actually harder than enabling AUR packages as it requires installing a compat plugin (whereas AUR support appears to just be a settings change). Maybe there's an option during the installer to enable it, but I couldn't find a mention, and this might also push users towards the less-secure and unsandboxed AUR.

view more: next ›