Still looking for an upstream bug reference. https://bugs.archlinux.org/task/55785 suggests that it may be fixed upstream, in which case we need to get the fix into Debian Testing and then PureOS.

Please mention the version of PureBrowser that you do not experience the issue.

<avph> KaKaRoTo: does purism have any plans on using vboot btw?
<KaKaRoTo> avph, I'm not familiar with it, so I never looked into it. I was asked that same question last week and I opened this task for it : https://tracker.pureos.net/T315
<KaKaRoTo> it's mostly about "what is it? what is it for? do we need it? can we enable it ? etc..."
<KaKaRoTo> avph, so if you're familiar with vboot and want to give us some pointers on that, I'd appreciate it
<nico_h> mostly for a secure update mechanism
<nico_h> so not every malware can write to the flash chip
<avph> well it won't run the malware mostly :)
<nico_h> um, scratch the latter
<KaKaRoTo> nico_h, how does it achieve it? needs a portion of the flash to be read-only, no ? does it use an IFD region for that ?
<KaKaRoTo> does it require a TPM or is it a way to get verified boot without TPM ?
<nico_h> Google uses the write-protection feature and /WP pin of the flash chips
<nico_h> I'm not sure if it requires a TPM (I think only for downgrade protections or something)
<avph> KaKaRoTo: no read only is (or can be) achieved with southbridge registers. TPM is to prevent updates rollback but the secure boot and safe updates are still there
<KaKaRoTo> /WP pin of the flash chip with protect the entire chip, not just a portion of it
<nico_h> no, /WP pin to protected part of the flash chip
<nico_h> usually, /WP only protects the block protection setup of the chip not the whole chip
<nico_h> but... that depends on the chip
<nico_h> KaKaRoTo: the general idea is: 1. have one part RO during runtime (can be achieved with early programming of PCH registers, as avph pointed out). 2. the RO part only runs other (updated) parts if a signature verification worked out
<KaKaRoTo> ok
<KaKaRoTo> I assume the early programming of PCH registers is done by vboot itself already
<avph> not sure but certainly saw stuff like that
<KaKaRoTo> I have this in my TO-READ list, so I'll explore that more later : https://www.coreboot.org/git-docs/Intel/vboot.html
<nico_h> unlikely, as it's mostly only used on chromebooks with the /WP thing

Also experiencing this issue - can't start any VM from a known good ISO. Running PureOS OEM image, gnome-boxes is 3.26.2 - issue persists across multiple DEs and reboots.

I'm no longer seeing this issue and could probably be closed.

More debug info:

I added more logging and tried again. here are the (sanitized) results:

I've uploaded virsh capabilities output as well

When you attempt to start a pureos live cd image in Boxes, you will get the following error in the terminal:

Oh and

Hi,
can you please do a

I'm not seeing this anymore so task could be closed.

You won't taint it because this task/project is about writing a bash script, there's no proprietary bits in the bash script itself. Unless it's about the FSF requirement and the fact that the script itself will manipulate a binary file? Somehow I'm not sure that's a valid reason, considering that the librem-coreboot-updater script is already in PureOS and this task is about porting that script to the fwupd system
Either way, whether it's tagged PureOS or not, a PureOS developer is still probably the best person for the task here.

After discussion, removing the PureOS tags as we don't want to risk tainting PureOS with the remaining proprietary software in our coreboot firmware. This project will remain on the coreboot side.

More work on this today. Got compiling going etc, and the "system-info" call works, etc. etc. \o/

Given most of the work for this is not coreboot work, but PureOS work integrating an existing firmware image (which we'd treat as a binary blob) with fwupd, I don't know that this is really a coreboot project as much as a PureOS project.

Thanks. Have synced with debian-boot team on this..

@chris.lamb no, I cannot confirm that it has ever been working. I have never seen it work.

To fix the gnome-shell should be updated to 3.26.2-4, see Debian Bug report logs - #888653

This might be an evdev/libinput thing, but d-i does not ship (has has not shipped) with libinput, so there is possibly some hardware regression/change involved here.

This is stumping me at the moment, alas. Whilst the trackpad is being detected, it does not appear to be registering as a mouse device. Well, /dev/input/event5 is being detected as the touchpad, rather than /dev/input/mouse0 ("no input driver specified"). Not sure if that is even meaningful. X has -- unfortunately -- always worked for me in the past. Device exists in /proc/bus/input/devices as expected

@chris.lamb The latest one where I could reproduce the bug with was the one from 2018-01-20

I can reproduce this:

@blendergeek I need to package it but I needed to package (at least) two dependencies first, hence my updates and references to "NEW", etc.

Freedom, security, privacy (and anonymity) that don't hamper everyday workflow or slow down to much is the philosophy.
I trust lamby will do adopt and do things correctly for our side.

Now Anbox can be added too? What needs to be done to add Anbox?

@francois "OEM install" - you are using the downloaded ISO? If so, please give me the SHA1 of said image so we are working from the same version as there were some changes recently.

Both deps now in Debian unstable

Seems they do security tightening - not freedom tightening. Mentioning in case others (like me) misunderstood the description of this bug regarding being "closer to our philosophy".

@lamby, please take a look and debug this one.

Most likely a configuration issue, other downstreams have similar reports...

I have run PureOS on a Libreboot X200, and not run into this problem. From the Libreboot GRUB menu, try selecting the "Select GRUB2 configuration from external disk" option instead of, "Boot from USB," and then choose the install option from there; that has always worked for me.

Oh yeah, here's the changes needed to enable SGX (over commit id 65d2754e1aaa4e90059b65fac3c00d847e2e465f) :

The format was reverse engineered by PT at Blackhat 2017 : https://www.blackhat.com/eu-17/briefings.html#intel-me-flash-file-system-explained

I have update the page, ended up with this:

I am a member of the debian-www team, and have write access to those pages. What text would you like to present PureOS?

Your browser-about.svg looks good. And with embedded IDs for globe and appname. Thanks!

This issue is flagged as "invalid" but not "closed for good".

PureBrowser is a quite close cousin of the particular Mozilla techonlogy called "Firefox".

NetworkManager has a provision for this, and it gets exposed in the WiFi connection preferences in nm-connection-editor, but IIRC:

I prefer and would advocate for option 2 because it instructs sites that (mistakenly or not) use browser versions to determine how to behave that PureBrowser is most compatible with a particular version of Firefox (which it is, having been almost entirely derived from that browser, with some modifications), while also informing the site that the browser is not in fact Firefox, but something else.

Before the ticket is closed for good, could you provide a User Agent string workaround (if that would work, otherwise some other workaround) so we have steps to present to another user who runs into this or similar problems?

This is not a bug in PureBrowser, but instead in that specific website.

From what I've read on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/EDID/HOWTO.txt the kernel only includes EDIDs up to 1920x1080:

dbus-cpp now in NEW

process-cpp out of NEW

I was able to get a Librem 13v2 to output at 2560x1440 by switching to GNOME on Xorg at the GDM login prompt for my user and using the steps from here to generate a custom modeline.

process-cpp now in NEW

The Ubuntu 14.04 Live disk was able to see the full suite of resolutions from my external monitor up to 3840x2160 @ 30hz and 2560x1440 @ 60hz. It uses the 3.19.0-25-generic kernel so perhaps we are seeing some regression with Skylake on more recent 4.x kernels.

I've tested this so far with a few other Live disks including Tails (4.14.12-2 kernel), Fedora 27 (4.13.9-300.fc27.x86_64), Ubuntu 17.10 (4.13.0-21) and Ubuntu 16.04 (4.10.0-28-generic). All of those live disks had the same 1080p limitation.

Just to confirm this specific issue is resolved in PureBrowser 52.5.0. Thanks!