I put that info on my thingiverse: https://www.thingiverse.com/thing:4961260
In a nutshell:
Although the above linked issue says that this only applies to phones where the user explicitly flashed the image and did not then proceed to change the master key - and does not apply when the phone is initially shipped by Purism.
To me this is a bad enough problem because the average customer may not be aware of the need to do this even though perhaps most customers will not have cause to reflash their phone.
Maybe the solution is:
Do we know this for sure? I thought all phones sent out by purism are also flashed with an image and thus at least those with the same version of PureOS would share the same masterkey 
I like the two ideas! Additional thoughts:
I think publishing a hash of the key would be enough to check this, so for example the output of the cryptsetup luksDump command.
But this should come with a warning that the phone needs to be charged first / have full battery. Doing it immediately on first boot might be (i) dangerous if the battery runs out during reencryption[1] and (ii) unwanted if someone else turns the phone on before / while it is on its way to the owner. So maybe reencrpytion should be mandatory when the passphrase is changed the first time, and offered as optional when it is changed again later?
[1] What would actually happen then? Can LUKS cope with a partition or volume where half of it is encrypted with another master key 
Depends on what level of certainty you require. It is stated by @dos in the most recent comment on the above-linked Issue. Good enough for me!
It would but why bother? Since any motivated person can extract the actual master key from the flash image for download, isnât it security through obscurity to publish a hash rather than the actual master key.
Yes. By telling the user and requiring confirmation to continue,
a) you allow the user not to continue if the phone is not in an adequate charge state, and
b) you generate some entropy in order to improve the locally-generated master key.
Depends on whether it is malicious or accidental.
If accidental, it can be partially addressed by educating users to expect to be prompted this way on first boot - and hence they will recognise when it isnât working as described.
If malicious, you have much bigger problems and this discussion by itself isnât going to solve all of it e.g. a malicious party could alter the code so that it still prompts to continue on to re-encryption, goes through the motions of re-encrypting but either doesnât actually re-encrypt or uses a compromised master key. (In that case your only real option is to download the image, and reflash, and hence ignore whatever the shipped state of the device was - but you also want all of the other things that Purism will offer as part of Anti-Interdiction for the Librem 5.)
Anyway, I think we can see that Purism is aware of the problem.
The phones are manually re-encrypted before shipping.
Regarding the publishing of the key, thatâs not the solution. If you donât trust Purism to provide you with a correctly set up phone, then there are a lot more places where mistakes can happen. Youâre better off reflashing yourself.
If youâre worrying about interdiction, then the key does not matter anyway. The man in the middle can generate a new one, not matching any published keys, but still insecure (because known to third parties). The solution to that is not helped by publishing the key.
To be fair to @m4lvin, it was my suggestion to publish the master key: in order to solve a specific problem, namely that the customer him or herself flashes the phone, does not realise the need to re-encrypt and/or forgets to do it and/or somehow thinks that it was successfully run but actually the customer managed to stuff it up, and subsequently wants to verify the state of encryption on the phone.
Absolutely it will do nothing about malicious activity. It is only suggested to cover accidents i.e. mistakes by the customer.
This is no stupid question. I also would prefere an official how to for an update procedure! 
@david.hamner
In the âcommunity/librem-5â Matrix chat room @Kyle_Rankin wrote this yesterday: âwe are also working on a GUI tool (and accompanying blog post) to make it easier for folks who are on amber to reflash to byzantiumâ
I need some clarification about GPS. Do you just take out the phone for some time with clear skies? I have installed gnss-share, took the phone outside for 35 minutes it still shows that I am in China (and I am not).
Do I need to do something when I take the phone out? Do I miss some software or something is not enabled?
I could be wrong, but as far as I know all you need is to have the at least one killswitches on so that you are not in âlockdown modeâ where the GPS is off. Then go outside for a while, and make sure you really have lots of clear sky during at least 20 minutes or so. You wrote that you were outside for 35 minutes, that should be enough time but maybe you did not have enough clear sky.
Mine was also showing a position in China first, it was not until I put it outside on a roof terrace for a while that it started working properly. I think if you just walk around outside with it, maybe some trees or whatever that happens to obscure the particular satellite it is using could cause problems. Anyway it seemed that way to me, like you really need a lot of clear sky during the whole initialization time which apparently is around 20 minutes.
Apart of the the geolocation in some map (like the app Maps), is there some more technical app which shows the GPS environment, the satellites etc? I tried the app Satellites but this does not show anything, and not any fix.
thanks @Skalman I will try again then. There are mountains where I live. Maybe I have to climb ⌠
Maybe
It would be great if someone who knows more about this could comment on it, but this is how I imagine it works: the âinitialization phaseâ (the thing that needs to happen before the GPS can start working properly) requires receiving an uninterrupted signal from one satellite during ~20 minutes, to download some info it needs. So the âinitializationâ is not robust, it may be enough for that specific satellite to be obscured for a short time, that already can cause the download to fail and need to start over. If that is how it works then thatâs very different from the normal operation that starts after the initialization is complete, then there is redundancy because many satellites are available and a fix can be computed even if some of them happen to be out of sight.
I have mountains where I live as well, tried getting higher up in clear areas for 2 hours and still it couldnât get a fix for me.
Sadly thatâs all I can report, which isnât good news
This is what I did. Iâm running Byzantium.
I first turned on location services, had the Wifi/BT HKS set to the functioning position, and started up the Maps app. It showed my approximate location with a wide Wifi (I assume) location radius.
I set the phone down outside on a wooden table, with the Maps app displayed on the screen. The view of the sky the L5 had was about one-half of the entire overhead hemisphere (I was on the deck of my backyard). I returned 30 minutes later. The screen had gone to sleep. Upon waking the phone up, the location radius had shrunk down to a very small radius, compared to the wifi radius. This indicates to me that GPS/GNSS had become initialized.
I used the grep command.
sudo cat /dev/gnss0 will give you a stream of information, which will be relatively incomprehensible unless you track down some documentation. I have teseo-liv3f-dm00398983-teseoliv3-gnss-moduleâsoftware-manual-stmicroelectronics.pdf which I imagine was linked to in this forum. I am not going to pretend that I am an expert but the information in that document was adequate to confirm the type of messages that the GNSS was emitting and approximately what those messages mean i.e. adequate for a human to parse the message and understand it.
sudo grep -a '$..GLL' /dev/gnss0
will give you your fix, so to speak.
From the above document, the format of that message is: $<TalkerID>GLL,<Lat>,<N/S>,<Long>,<E/W>,<Timestamp>,<Status>,<mode indicator>*<checksum><cr><lf>
and an example from that document is:
$GPGLL,4055.04673,N,01416.54941,E,110505.000,A,A*54
^
I have indicated with ^ the status field. It is A for valid and V for invalid. You of course want A but you donât get an A until
a) the phone gets a fix on one satellite, and
b) maintains the fix for long enough to download the ephemeris, and then
c) gets a fix on enough satellites to determine your position.
I already did the first two steps. So I just wandered outside with my Librem 5, doing the above grep command, and it took maybe 20 or 30 seconds to get a fix and thereby reported
$GPGLL,<lat>,S,<long>,E,021343.000,A,A*40
(where I have removed the latitude and longitude for privacy reasons, but they were correct before I removed them).
As far as I am aware, I have not installed gnss-share. What I am doing here is just very basic, low-level diagnostics to demonstrate that the GNSS chip is working.
Thanks for the lot of yout technical information. I will check with the grep my device. Maybe we should start a new thread for L5 and GPS.
Years ago, I used the Openmoko Freerunner. I pulled it out of the dust, it still boots, but the battery is dead. Have to look for a new one (itâs replaceable). The documentation for GPS and pictures of the app can be found here: https://wiki.openmoko.org/wiki/Manuals/SHR (look for the chapter Position.
I have the L5 in my garden with blue sky above for some minutes, and the sudo grep -a '$..GLL' /dev/gnss0 does not show an A, only V, one line every second.
Could you please send me a pointer to the document or the PDF itself by mail. Thanks.
This post: Librem 5 GPS/Location Tracking says âat least 12 minutesâ. Thatâs probably under ideal conditions, so you would potentially need more than 12 minutes.
And that post has the link to the PDF documentation.
OK, I got a fix following @Zimmy instructions. I left the Maps running and it worked. I had done the same without Maps running and did not work. I do not know if this was accidental or Maps need to be running.
grep -a '$..GLL' /dev/gnss0
gives me only V but I will get again out to check.
BUT this thing with Maps to require being online is annoying. How to get offline maps? On android I had downloaded the maps from OSM. A big download indeed, but on L5 I can put the offline maps to the sdcard. and it is much more convenient to have offline maps.