The primary reason why I use Ventoy is because of its ability to use multiple ISO's, which I can select from when booting. I don't think that's possible with dd.
It's also possible to use the usb stick for regular files, Ventoy will just ignore them. Pretty useful when you need it.
It absolutely is and its a pleasant language to work with. Although it is in a kinda-symbiotic relationship with Flutter, I've found myself using it for small scripts and cli tools instead of Python because of its strong+static typing with null safety.
Relevant to the topic, Dart (and Flutter) supports targeting wasm.
The primary F-droid repo also hosts the app developer builds in case of reproducible builds, where F-droid will first build from source and then compare it with the dev's build. If its identical, it uses the dev build in the repo and if its not, the build fails.
The use of AllowedAPKSigningKeys afaik is to compare that key with the key used for signing the dev build. If its not the same, the dev build is rejected.
From what I've understood from this POC, its possible to bypass this signature check. The only exploit I can think of with this bypass is that someone who gets access to the developer's release channel can host their own signed apk, which will either get rejected by Android in case of update (signature mismatch) or gets installed in case of first install. But in either case, its still the same reproducible build, only the signature is different.
> The only exploit I can think of with this bypass is that someone who gets access to the developer's release channel can host their own signed apk, which [...] gets installed in case of first install.
That still enables a supply chain attack, which should not be dismissed - virtually all modern targeted attacks involve some complex chain of exploits; a sufficiently motivated attacker will use this.
>But in either case, its still the same reproducible build, only the signature is different.
That means the attacker still has to compromise the source repo. If they don't and try to upload a backdoored apk, that would cause a mismatch with the reproducible build and be rejected. If you can compromise the source repo, you're already screwed regardless. Apk signature checks can't protect you against that.
In a previous post you said that - in case of matching builds - the dev's version is used. Why is the "dev's" version relevant? And assuming I'm correct that it isn't. What is the added benefit vs. just building from source (from a known good state, e.g. by a blessed git hash)?
Android will block any update to an existing app that wasn't signed with the same signature. The benefit of using the developer's signature (even if the app is built by F-Droid) is that the F-Droid release of the app is not treated as a "different app" by the Android OS, and thus it can be updated by other app stores or through direct APK releases from the developer. If the user chooses to stop using F-Droid in the future, they can still receive updates through other means without uninstalling and reinstalling the app.
It also allows the user to place a little less trust on F-Droid because the developer, as well as F-Droid, must confirm any release before it can be distributed. (Now that I think of it, that probably creates an issue where if malware somehow slips in, F-Droid has no power to remove it via an automatic update. Perhaps they should have a malware response or notification system?)
Also, the wording on f-droid suggests the version that f-droid hosts is built by them, rather than a version that's uploaded by the dev. If you go on any app and check the download section, it says
> It is built by F-Droid and guaranteed to correspond to this source tarball.
> ... it does have groups and profiles.
You probably know this, but Firefox has its own version of profiles, although its a bit hidden.
You can see the profiles by going to about:profiles or launching Firefox with -ProfileManager as a cli option, which launches a profile manager window.
Container tabs are a much more powerful alternative to 'profiles'.
Profiles are nice for multiple people sharing a pc/account, container-tabs are for seperating online persona's or work/private browsing
Graphene has questionable dev choices, especially given the limited hardware options -- basically, Google hardware. I do not trust Google at all anymore. Their interests align directly against privacy.
If you can't attack their code/work, you attack the person ?
Atleast one of their devs is being gangstalked by Kiwifarms and has powerfull adversaries in the weapons industry who work against him and his work.
Please be careful with your criticism because there is entire troll-farms/PR-bureaus out to hurt them. Glowies are probably not happy with them either, so that's a tough world they live in .
The questionable dev choices I am talking about is such limited hardware support, pixel devices only being officially supported. That is Google hardware and I don't trust it.
That isn't attacking a person, that is a direct criticism of a project.
Your argument puts the world upside down. Non supported hardware/platforms have limited support for the latest hard & software security features.
Pixels simply lag least behind the curb compared to other devices. And if Google, Qualcomm or Intel for that matter where to be trusted they would have made onto the Wassenaar lists as Dual-Use goods already.
There are limits to as far as you can go.
I feel a bit embarassed saying this but, Puss in Boots: The Last Wish.
I've had issues dealing with the concept of death and this movie helped me more than anything else. The panic attack scenes resonated quite hard and the end message left a lasting impact.
