java-keyring VS rpi-open-firmware

https://github.com/javakeyring/java-keyring

People are complaining that the OS is not able to securely identify between two applications in the same user context. So they filed a bogus CVE, where the content of the CVE is basically "Linux is not an iPhone". It is a OS app sandboxing feature request, masquerading as a bug report to the keyring team.

Read the belated reply from the gnome keyring folks, pleading with people to understand what the linux security model is, and that linux doesn't have the sandboxing capabilities that have been rolled out to other (paid) operating systems:

https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhiloso...

Yet people don't understand. They are demanding that everything be turned into an iphone (in terms of app sandboxes) but they are also demanding that once the OS vendor has the power to install a chokepoint around all the apps, that they wont set up a little toll booth there as well.

But IMO asking vendors to not exploit that for commercial gain is only going to be safeguarded by regulation. It's not going to be safeguarded by consumer choice.

> Please correct me if I'm wrong.

My memory told me it was the GPU that needed the blobs. So I asked at DDG

https://duckduckgo.com/?t=ftsa&q=binary+blobs+and+the+Raspbe...

Turned up this: https://wiki.debian.org/RaspberryPi and it says...

> All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W, 2, 3, Zero 2 W) boot from their GPU (not from the CPU!), so they require a non-free binary blob to boot

So the 4 (and I suppose the 5, if it ever actually comes...)

Goes on to say:

> Since then, Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016. See more at https://news.ycombinator.com/item?id=11703842 . Unfortunately development of rpi-open-firmware is currently (2021-06) stalled.

So there you are. Not wrong, are you, but not strictly correct, depending on "...to run properly" definition

https://github.com/librerpi/rpi-open-firmware has updates 3-months ago

many of those demos work on the the entire pi model range

pi3 support is only broken due to arm side problems, which could be fixed by just using a different bootloader

and the https://github.com/librerpi/rpi-open-firmware codebase can already boot linux headlessly on both pi2 and pi3, it uses a different arm bootloader

Yes, and some folks are reverse engineering their stuff:

https://github.com/librerpi/rpi-open-firmware/

rpi-open-firmware: open-source VPU side bootloader for Raspberry Pi\ (35 comments)

There is work being done on the RPi4, for example the SHA1 HMAC protecting the boot on the RPi4 had to be cracked (and was easily), I hear future versions have RSA signing support, so the proprietary firmware might become mandatory at some point.

https://github.com/librerpi/rpi-open-firmware/blob/master/do...

There is a project to create an open source version of the proprietary GPU firmware that boots into the ARM processor:

https://github.com/librerpi/rpi-open-firmware

I note that even the Raspberry Pi is moving towards locked down devices, the RPi4 has an (easily cracked) HMAC blocking booting into the open source firmware and I hear more recent hardware editions have RSA signing support in the bootrom code.

https://github.com/librerpi/rpi-open-firmware/blob/master/do...